Home

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

Вместо того, чтобы спрашивать, какие тесты вам автоматизировать, задавайте более точные вопросы.

Если вы подразумеваете "Как мне расценивать использование инструментов в тестировании", прочитайте статьи "Контекстно-ориентированный подход к автоматизации в тестировании", и "Тестирование и проверки".

Если вы спрашиваете о проверке результата или других фактов о состоянии продукта, продолжайте чтение.

По-настоящему хорошая проверка фактов выигрывает от учета вашего статуса, чтобы вы не тратили время зря:

• Достаточно ли я знаю о продукте, о том, где могут быть проблемы? Надо убедиться, что я не тороплюсь с разработкой проверок.

Если ответ "нет", то лучше глубже изучить продукт, делая заметки о риске по ходу дела.

Если ответ "да", дайте ответ на ряд вопросов, начиная с этих:

• Какой конкретный факт о результате работы или состоянии продукта я хочу проверить?
• Достаточно ли я знаю о продукте и том, где могут быть проблемы, чтобы быть достаточно уверенным, что это действительно важный для проверки факт?
• Не проверяет ли кто-то другой (например, разработчик) этот факт?

Затем подумайте о продуктовых рисках:

• Что может пойти не так с продуктом, чтобы я заметил это, проверяя этот факт?
• Это действительно проблема? Значимый риск?
• Почему мы полагаем, что это значимый риск?
• Что нам пытается сообщить это предчувствие?

Возможно, при наличии серьезного риска лучше обсудить риск, а не продумывать тестирование или проверки.

Предположим, что это значимый факт. Подумайте о том, как его проверить, и о затратах на проверку.

• Как проверить этот факт наилучшим образом?
• Это самый быстрый, простой, дешевый способ его проверить?
• Будет ли проверка предназначена для машинного интерфейса?

Подумайте об альтернативных издержках, особенно если проверяете на уровне GUI:

• С какими проблемами я столкнусь, проверяя этот факт таким способом, и делая это надежно?
• Какие проблемы, тут или в другом месте, я могу упустить, концентрируясь на этом факте и проверяя его этим способом?
• Нет ли чего-то более ценного, чем проверка этого факта, для выполнения прямо сейчас? А в долгосрочной перспективе?

Подумайте о долгосрочной перспективе. С одной стороны, продукт и некоторые факты о нем могут быть очень стабильными:

• Что вызовет изменение этого факта? Вероятно ли это? Если нет, стоит ли создавать проверку для этого факта?

С другой стороны, продукт, платформа, данные или тест-окружение могут стать нестабильными. Возможно, они уже нестабильны:

• Если эта проверка будет выдавать непостоянный или ненадежный результат, обратим ли мы на это внимание, сделаем ли с этим что-нибудь? Чего нам это будет стоить?

Остерегайтесь химеричной надежности. Этот отличный термин я впервые прочитал у Кирка и Миллера в книге Reliability and Validity in Qualitative Research. Он относится к ситуации, когда мы наблюдаем постоянный результат, который обманывает нас – например, сломанный термометр верно сообщает о 37 градусах Цельсия (у Кирка и Миллера сказаны важные вещи и про подтверждающее исследование).

• Есть ли шанс, что эта проверка загипнотизирует нас, успешно срабатывая таким образом, что мы будем обмануты?

Чтобы справиться с риском химеричной надежности и получить преимущество от полученной информации, хорошо бы периодически присматриваться к каждой проверке:

• Когда мы будем пересматривать эту проверку? Дабы улучшить ее или расширить?

Достаточно большой набор проверок сложен для понимания, поэтому нет смысла запускать проверки, которые более не нужны:

• Каков наш план по более редкой проверке этого факта, когда он будет нужен нам реже? А по удалению этой проверки?

Следующие вопросы особенно важны, если вы тестировщик. Проверки дешевле и ценнее, когда они дают быструю обратную связь разработчикам – настолько, что неплохой идеей будет проверка кода до того, как он вообще попадет к вам.

• Тот ли я человек, который должен брать на себя ответственность за проверку этого факта? Единственный ли я человек? Должен ли я им быть?
• Проверка этого факта этим способом – это наиболее быстрый способ узнать о связанной с ним реальной проблеме?

Учитывая все вышесказанное, подумайте о полезности – функции затрат, риска и ценности:

• Я действительно все еще убежден, что этот факт нуждается в проверке? Стоит ли разрабатывать проверку для него?

Задав эти вопросы, переходите к следующему факту.

Вы можете ответить, что ответ на эти вопросы займет кучу времени.

Да нет, не кучу. Теперь, когда вы подготовлены, вы будете держать этот набор идей в уме и пробегать по списку вопросов со скоростью мысли. Сравните ответ на эти вопросы со временем, которое вы потратите на создание, прогон, интерпретацию, пересмотр, исправление и поддержку даже одной бессмысленной проверки.

Верно, можно сберечь время и силы, не занимаясь интерпретацией, пересмотром и поддержкой. То есть игнорируя проверку после ее создания. Но если вам все равно, что вам говорит эта проверка, зачем вы вообще ее затеяли? Все еще проще вообще ее не создавать.

С опытом ответы на эти вопросы станут обычным делом. Не думайте, что это полный список; задавайте собственные вопросы. Если вы обращаете внимание на ответы, это повысит вашу уверенность в том, что ваши проверки мощны, ценны и дешевы.

Обсудить в форуме