Home

Автор: Майкл Болтон (Michael Bolton)

Оригиналы: http://www.developsense.com/articles/2008-02-HowMuchIsEnough.pdf

http://www.developsense.com/blog/2009/09/when-do-we-stop-test/

http://www.developsense.com/2009/10/when-do-we-stop-testing-one-more-sure.html

Перевод: Ольга Алифанова

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

Прелесть идеально "сценарных" задач в том, что мы всегда знаем, когда нам остановиться. Последняя нота, последняя строчка диалога в сценарии, последний кусочек пустого места на холсте означают, что конец работы близко. Если вы используете сценарный подход к тестированию, то вы останавливаетесь, если заметили проблему, или если у вас появились вопросы/любопытные идеи.

Если вы исследуете продукт, сказать, когда нужно остановиться, не так-то просто. На джем-сейшенах музыканты сигнализируют друг другу при помощи глаз и музыки, когда нужно затихнуть или остановиться совсем. Для человека неопытного причины, влияющие на решение закончить работу, могут быть непонятными или незримыми. Даже в среде артистов менее опытные люди могут быть не в состоянии объяснить, почему все остановились, но у мастера своего дела с объяснениями никаких затруднений не будет.

Как нам определить, когда нужно остановиться?

Первый шаг на этом пути – это осознание, что мы не можем быть уверены, что мы завершили свою работу. Любая попытка найти ответ на вопрос, когда нужно остановиться – это эвристика. Эвристики – быстрый и дешевый метод принятия решений. Они ненадежны – могут сработать, а могут и нет. Они абстрактны и могут быть похожими друг на друга. Они зависимы от контекста – предполагается, что ими будет пользоваться достаточно компетентный и опытный человек. Они похожи на лампочки на приборной панели вашей машины. Когда какая-то из них загорается, вам нужно решить, а не остановиться ли до того момента, пока она снова не станет зеленой – но, возможно, важнее игнорировать ее и продолжать движение?

Я составил список эвристик для остановки тестирования, а также привел причины для сомнений в каждой из них.

1. Время вышло! Самая распространенная причина закончить тестирование: наше время, отведенное на него, истекло.

Получили ли мы нужную информацию? Насколько высок риск, связанный с прекращением тестирования прямо сейчас, может, нужно его продолжать? Наш дедлайн навязан искусственно? Может, он выбран случайно? Ведется ли еще разработка, понадобится ли тестировать продукт в дальнейшем?

2. Пиньята. Мы перестаем лупить продукт палками, когда из него начинают сыпаться конфеты – мы заканчиваем тестировать, как только обнаруживаем первую достаточно серьезную проблему.

Может, часть конфет застряла в ноге пиньяты? Найденная нами "первая серьезная проблема" самая значимая, или единственная, достойная внимания? Можем ли мы найти другие интересные проблемы, если продолжим? Что, если мы неправильно воспринимаем серьезность найденной, и на самом деле она не так уж и критична?

3. Дохлая лошадь. Программа чересчур забагована, чтобы дальнейшее тестирование имело смысл. Мы понимаем, что все может измениться настолько сильно, что результаты нашего тестирования превратятся в тыкву.

Мы основываемся на предположении, что мы уже нашли порядочно интересных и важных багов. Если мы остановимся сейчас, мы точно не упустим что-нибудь еще более важное и интересное?

4. Миссия выполнена. Мы заканчиваем тестирование, когда нашли ответы на все поставленные нами вопросы.

Наше тестирование могло вызвать новые вопросы. Это приводит нас к эвристике Румсфельда – "существует известное неизвестное и неизвестное неизвестное". Достаточно ли "известное неизвестное" сдвинулось в сторону известного благодаря нашему тестированию? Вскрыли ли мы что-то новое и значимое из "известного неизвестного"? И трудный, но важный вопрос – удовлетворены ли мы тем, как мы продвинули "неизвестное неизвестное" в область известного (или хотя бы "известного неизвестного")?

5. Миссия отменена. Наш клиент попросил нас прекратить тестирование. Возможно, мы вышли за рамки бюджета, или проект отменили, или что угодно еще было тому причиной. Вне зависимости от повода, мы обязаны остановиться (эвристика "Время вышло" может быть особым случаем "Отмены миссии", если решение о том, что время вышло, принимает клиент, а не мы).

Хорошо ли наш клиент осознает ценность тестирования, если оно будет продолжаться, или риски прекращения его прямо сейчас? Если мы с ним не согласны, достаточно ли мы знаем о бизнес-причинах остановить тестирование?

6. Я застрял! Мы останавливаемся, потому что нам что-то мешает. У нас нет нужной информации (многие жалуются, что не могут тестировать без спецификации, например). В системе блокирующий баг, и мы не можем добраться до той области, которую хотим протестировать. У нас нет нужного оборудования или необходимых инструментов. Нам не хватает опыта, чтобы выполнить специализированный тест.

Выбраться из тупика можно множеством способов. Возможно, нам нужна помощь, а возможно, просто передышка (см. ниже). Может быть, если мы продолжим тестирование, мы узнаем то, что нам необходимо. Может, цель тестирования – это именно исследование продукта в поисках недостающей информации. Может, блокер можно обойти, может, оборудование и инструменты нам доступны, просто мы ничего об этом не знаем или не спросили нужных людей правильным образом. Возможно, внутри команды, или среди разработчиков, или на бизнес-стороне есть эксперты, которые могут нам помочь, но мы этого не осознаем. Между ощущением, что вы застряли, и реальным застреванием есть некоторая разница.

7. Пауза для отдыха. Мы не останавливаем тестирование – мы приостанавливаем его. Мы берем паузу, потому что мы устали, или заскучали, или нас покинуло вдохновение. Возможно, пауза нужна, чтобы что-то выяснить или спланировать, а может, чтобы поразмышлять о том, что мы уже сделали, с целью выяснить, что нам делать дальше. Основная идея в том, что нам нужен перерыв, и позже мы вернемся к продукту отдохнувшими и со свежим взглядом.

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

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

8. Плато. Что бы мы ни делали, результат одинаковый. Может, приложение крашится или перестает отвечать, но одинаковые результаты можно получить и в случае, когда приложение особенно стабильно – "ну, вроде все ок".

Приложение действительно рухнуло с концами, или пытается восстановиться? Отсутствие отклика само по себе – важный результат теста? Мы действительно перепробовали все-все-все и включили в свои тесты достаточно вариаций и различную нагрузку?

9. Так принято. Мы прекращаем тестировать, как обычно. У нас есть правила насчет определенного количества тест-идей, кейсов или циклов тестирования, и когда определенное количество работы выполнено, мы останавливаемся. Говорят, Agile-команды действуют именно так – "когда пройдены все приемочные тесты, мы готовы к релизу".

Эта эвристика отличается от "Время вышло" – время более эластично. Этот подход достаточно широко распространен – мы часто слышим, что достаточно хорошее тестирование считается тем, где есть хотя бы один тест на каждое требование (или хотя бы один негативный и один позитивный тест на каждое требование). Я несогласен, конечно же, но это распространенная точка зрения.

Критично ли мы подходим к вопросу, почему мы всегда останавливаемся именно здесь? Не нужно ли протестировать продукт дополнительно? Может, нужно тестировать его меньше? Есть ли доступная нам информация – к примеру, от отдела продаж, службы поддержки или внешних наблюдателей – которая сигнализирует, что нам стоит отойти от привычных шаблонов? Рассмотрели ли мы другие эвристики?

10. Интересных вопросов не осталось. Мы решили, что никакие вопросы более не оправдывают цену поиска ответов на них, и мы завершаем тестирование. Эта эвристика информирует, что если какой-либо вопрос или риск достаточно важны, мы продолжим тестировать.

Уверены ли мы в своем моделировании рисков? Нет ли опасности влететь в "черного лебедя" (или белого лебедя, который был проигнорирован)? Достигли ли мы достаточного покрытия? Надежны ли наши оракулы?

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

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

12. Отказ от миссии. Мы прекращаем тестировать, если результатом продолжения тестирования станет проблема – например, этическая – для конкретного человека.

Будете ли вы продолжать тест, если он даст фальшивые результаты? Повлечет за собой ложь? Ущерб для ценного оборудования? Ущерб для человека, как в эксперименте Милграма или Стэнфордском эксперименте? Может, жертвой будет не подопытный, а клиент – будете ли вы продолжать, если издержки на тестирование (включая вашу зарплату) непропорциональны ценности от тестов? Может, жертва – вы сами? Остановитесь ли вы, если вам недостаточно платят?