Автор: Маарет Пиаярви (Maaret Pyhäjärvi).

Оригинал статьи

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

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

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

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

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

Я начала эту статью с целью разобраться, как бы я отнеслась к просьбе подсчитать тест-кейсы. Стала бы я этим заниматься, учитывая мой опыт? Когда бы я этим занялась? Есть ли что-то, что я могу посоветовать тем, кто все еще считает их?

Поиск наименьшего смысла

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

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

Добавление смысла

Думая о том, как я считала кейсы восемь лет назад, я вспоминаю бессмысленную битву, которая превратилась в продуктивные переговоры. Начала я с предпосылки, что способ, которым все всегда делалось – подсчет пройденных и упавших тестов – это путь к плохому тестированию и плохим отношениям с менеджментом. Я столкнулась с тем, что в 30-дневном проекте приемочного тестирования после нескольких лет разработки все чувствовали дискомфорт, не имея способа оценить прогресс тестирования. Я не могла полностью отдаться сессионному тест-менеджменту, так как это был бы не очень удачный выбор для замены существующего подхода: пришлось бы потратить много сил, чтобы познакомить бизнес-специалиста с этой методологией.

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

В течение первого 30-дневного приемочного тестирования меня начало напрягать то, что я считаю наивысшим риском использования тест-кейсов как метрики: качество выполненного тестирования. Когда тесты составлены заранее, вы генерируете идеи о тестировании, не зная практически ничего. У вас нет ПО, есть только требования. Кейсы создавались на основании старой версии продукта: мы думали о том, как нововведения его затронут, и создавали сценарии, чтобы проверить эти нововведения.

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

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

Когда мы проводили 30-дневное приемочное тестирование для другого продукта, то сильнее углубились в исследовательское тестирование. У нашей системы была сложная логика процессов, которые в том числе обращались к сторонней системе и включали ручную обработку данных. Мы снова создали наборы тестовых данных в качестве тест-кейсов, а также шаблоны для повторного использования шагов, где 7 шаг из 12 был той информацией, которую нам отдавала сторонняя система. Групповое тестирование было привычным делом для бизнес-процесса, раньше кейсы в процессе не использовались, и метод отлично подошел.

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

Третье тридцатидневное приемочное тестирование под моим руководством экспериментировало с вторичным риском использования кейсов как метрики прогресса тестирования – отражение природы тестирования как вида деятельности. Первые пару раз я осознавала, что "пройденные" и "упавшие" тесты создают иллюзию. Когда мы выявляли проблему, выкатывалась новая версия системы. Если мы находили критический кросс-системный баг, требующий внесения изменений, а 80% тестов уже успешно прошли – оставшихся 20% было недостаточно для тестирования. Идея этой метрики не просто базировалась на убеждении, снижающем качество возможного тестирования – она поощряла ложь насчет тестового покрытия, так как предполагалось, что изменений не было.

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

Зачем считать тест-кейсы в проекте?

Я не сторонник подсчета тест-кейсов, однако когда мне приходится их считать, я умею делать это так, чтобы подсчет шел на пользу качественному тестированию:

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

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

Когда я начала рассматривать тестирование как вложение времени и отчетность по нему, все стало значительно проще. Если у меня есть неделя, я всегда могу сказать, что если прошло четыре дня – остался всего один. Исследуя, я могу объяснить, что я за это время обнаружила, и что я буду использовать на следующей неделе. Это могу как я, так и команды исследовательского тестирования, но это умеют не все специалисты, временно переведенные в тестировщики.

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

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

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

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