Home

Автор: Майкл Болтон

Перевод: Дмитрий Дудников по заказу Software-Testing.RU

Оригинал: http://www.developsense.com/2009/09/when-do-we-stop-test.html

Несколько лет назад, примерно в то же время, когда я начал проводить тренинг «Быстрое тестирование ПО» (Rapid Software Testing), мой соавтор Джеймс Бах (James Bach) записал видео для демонстрации быстрого стресс-тестирования. В его примере подход заключался в подаче на вход визарда приложения огромного объема данных, по существу заставляя приложение нагружать само себя.

Видео длится почти шесть минут. Примерно на середине Джеймс спрашивает: «Вы можете поинтересоваться, почему я не хочу остановиться сейчас. Причина в том, что мы наблюдаем неуклонное ухудшение ситуации. Мы могли бы остановиться сейчас, но возможно мы увидим нечто худшее, если будем продолжать». Таким образом, он продолжил тест. А вскоре после этого Джеймс предложил эвристики для остановки: мы останавливаемся, когда: 1) мы обнаружили достаточно серьезную проблему, или 2) в поведении программы нет явных изменений – программа в целом работает стабильно, или 3) ценность от продолжения теста не оправдывает стоимость. Таковы были эвристики для остановки того теста.

Где-то через год после того, как я впервые увидел это видео, я решил более полно описать эвристики для прекращения тестирования в колонке для журнала «Better Software». По этому поводу мы с Джеймсом устроили транспективную беседу. Колонку вы можете найти здесь. Ещё год спустя колонка превратилась в неформальную лекцию, которую я прочитал в нескольких местах.

Примерно через шесть месяцев после этого мы оба нашли еще больше эвристик для остановки тестирования. Мы обсуждали их на STAR East 2009, и проходившие в тот момент мимо нас Дэйл Эмери (Dale Emery) и Джеймс Линдсей (James Lyndsay) присоединились к дискуссии. В частности, Дэйл высказал предположение, что во время сражения стрельба может быть остановлена в нескольких случаях: временное затишье, поступление команды «прекратить огонь», соглашение между сторонами о прекращении огня, отход сторон на начальные позиции, разоружение противника. Это показалось мне интересным.

В общем, сейчас я расскажу все эвристики, которые мы нашли. Я подчеркиваю, что эти эвристики для остановки являются именно эвристиками. Эвристики – это быстрые, недорогие способы решения проблемы или принятия решения. Эвристики подвержены ошибкам, то есть они могут как сработать, так и не сработать. Эвристики недостаточно абстрактны, они могут перекрываться и пересекаться друг с другом. Также эвристики зависят от контекста, поэтому предполагается, что они будут использоваться людьми, имеющими знания и навыки для их разумного использования. Ниже я перечислил эвристики и для каждой из них указал некоторые вопросы, при помощи которых можно проверить правомочность её использования.

1. Эвристика «Время вышло!». Для многих специалистов по тестированию это наиболее распространенная эвристика: мы останавливаем тестирование, когда заканчивается выделенное на него время.

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

2. Эвристика пиньяты (The Piñata Heuristic). Мы прекращаем ломать программу, когда начинают выпадать конфеты – мы останавливаем тестирование, когда видим первую достаточно серьезную проблему.

Не застряло ли в ноге пиньяты еще несколько конфет? Является ли первая серьезная проблема самой важной? Единственной, о которой стоит беспокоиться? Не найдем ли мы другие интересные проблемы, если продолжим тестирование? Что если наше ощущение «серьезности» ошибочно и проблема не столь грандиозна?

3. Эвристика «мертвой лошади» (The Dead Horse Heuristic). В программе слишком много ошибок, так что продолжение тестирования не имеет смысла. Мы знаем, что все изменится настолько, что сведет на нет результаты текущего тестирования.

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

4. Эвристика «Задание выполнено» (The Mission Accomplished Heuristic). Мы останавливаем тестирование, когда найдены ответы на все поставленные вопросы.

В процессе нашего тестирования могут возникнуть новые вопросы. Это приводит нас к эвристике Рамсфелда (Rumsfeld Heuristic): «Есть то, про что мы знаем, что мы это не знаем, и есть то, про что мы не знаем, что мы этого не знаем». Достаточно ли неизвестных переместило наше тестирование в область известного? Обнаружило ли наше тестирование новые неизвестные? И сложный для разбора, но важный вопрос: удовлетворены ли мы тем, что мы переместили достаточно неизвестных неизвестных в область известного или по крайней мере сделали их известными неизвестными.

5. Эвристика «Отмена задания» (The Mission Revoked Heuristic). Наш клиент сказал нам: «пожалуйста, прекратите тестирование». Это может произойти по причине перерасхода бюджета, или вследствие отмены проекта, и по любой другой причине. Какова бы ни была причина, нам поручили остановить тестирование. (На самом деле эвристика «Время вышло!» может быть частным случаем более общей «Отмены задания», в том случае, если предпочтительнее, чтобы не мы сами, а заказчик принял решение о том, что время вышло.)

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

6. Эвристика «Я зашел в тупик!» (The I Feel Stuck! Heuristic). По какой бы то ни было причине мы останавливаемся, поскольку обнаруживаем некое препятствие. У нас нет информации, которая нам требуется (например, многие люди заявляют, что не могут тестировать без достаточного количества спецификаций). Имеется блокирующая ошибка, и таким образом мы не можем перейти в ту область продукта, которую необходимо протестировать, у нас нет необходимого оборудования или инструментария, у команды нет квалификации, требуемой для выполнения некоторых специальных тестов.

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

7. Эвристика «освежающей паузы» (The Pause That Refreshes Heuristic). Вместо прекращения тестирования мы приостанавливаем его на некоторое время. Мы можем остановить тестирование и сделать перерыв, когда мы устали, когда нам стало скучно или пропало вдохновение. Мы можем сделать паузу на то, чтобы выполнить некоторые исследования, разработать планы, поразмыслить над тем, что мы делали в прошлом и понять, что делать дальше. Идея заключается в том, что нам требуется определенный перерыв, после которого мы сможем вернуться к продукту со свежим взглядом или свежими мыслями.

Также есть и другой вид паузы: мы можем остановить тестирование какой-либо функции, поскольку в настоящий момент другая имеет более высокий приоритет.

Конечно, мы можем чувствовать себя уставшими, нам может быть скучно, но не нужно ли проявить упорство и продолжить двигаться вперед? Не получится ли изучить требуемое в процессе работы с программой, вместо того, чтобы делать это отдельно? Не найдется ли тот критичный бит информации, которого нам не хватает, благодаря лишь еще одному тесту? Является ли функция с «более высоким приоритетом» действительно более приоритетной? Готова ли она к тестированию? Не протестировали ли мы ее и так уже достаточно?

8. Эвристика «Отсутствие продвижения» (The Flatline Heuristic). Что бы мы ни делали, мы получаем тот же самый результат. Это может происходить в случае, когда программа падает определенным способом или перестает отвечать, но также мы можем не продвигаться, когда программа в основном ведет себя стабильно: "выглядит хорошо!"

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

9. Эвристика Привычного завершения (The Customary Conclusion Heuristic). Мы останавливаем тестирование тогда, когда мы обычно останавливаем тестирование. Имеется протокол, задающий определенное количество идей для тестирования, или тест-кейсов, или циклов тестирования, или как вариант – имеется определенный объем работ по тестированию, который мы выполняем и после этого останавливаемся. Agile-команды, например, часто применяют такой подход: «когда выполнены все приемочные тесты, мы знаем, что продукт готов к поставке». Эвальд Руденриджс (Ewald Roodenrijs) приводит в своем блоге пример этой эвристики в статье «Когда прекращать тестирование». Он говорит, что он останавливается, «когда выполнено определенное количество тестовых циклов, включая регрессионное тестирование».

Отличие от эвристики «Время вышло!» в том, что временные ограничения могут изменяться более гибко, чем некоторые другие. Поскольку в большинстве проектов главенствует именно график проекта, и у меня и у Джеймса заняло некоторое время осознание того, что эта эвристика также очень распространена. Иногда мы можем слышать фразы типа «один тест на требование» или «один положительный и один отрицательный тест на требование», в качестве соглашения для определения «достаточно хорошего» тестирования. (Конечно же, мы не согласны с этим, но мы слышим это).

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

10. Больше нет интересных вопросов (No more interesting questions). В этот момент мы решаем, что не осталось вопросов, ответы на которые были бы достаточно ценными, чтобы оправдать стоимость продолжения тестирования, и поэтому мы останавливаемся. Эта эвристика используется в основном как дополнение к другим эвристикам, помогая принять решение о том, есть ли какие-то вопросы или риски, которые отменяют действие этих эвристик (примеры таких вопросов я привожу после каждой эвристики). Кроме того, если одна эвристика советует нам прекратить тестирование, следует проверить, нет ли интересных вопросов или серьезных рисков в других областях, и если они есть, то мы скорее продолжим тестирование, чем остановимся.

Что мы думаем о наших моделях рисков? Нет ли опасности недооценки или наоборот переоценки риска, не случилось ли так, что мы не заметили Чёрного лебедя (а может быть даже Белого лебедя)? Достигли ли мы достаточного покрытия? Достаточно ли тщательно мы проверили свои оракулы?

11. Эвристика уклонения/безразличия (The Avoidance/Indifference Heuristic). Иногда людей не интересует дополнительная информация, либо они не хотят знать, что происходит в программе. Тестируемое приложение может быть первой версией, которую, как мы знаем, скоро заменят. Некоторые люди прекращают тестирование по причине лени, злого умысла или отсутствия мотивации. Иногда бизнес-критичность выпуска нового релиза настолько высока, что никакая мыслимая проблема не остановит выход программы, и поэтому никакие новые результаты тестирования не будут иметь значения.

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

Дополнение: Кем Канер (Cem Kaner) предложил еще одну эвристику: «Отказ от выполнения задания» (Mission Rejected), в которой тестировщик сам отказывается от продолжения тестирования. Подробнее читайте здесь.

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