Home

Автор статьи: Аарон Ходдер (Aaron Hodder)

Оригинал статьи: http://testerkiwi.blogspot.ru/2017/05/phased-vs-threaded-testing.html#more

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

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

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

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

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

Тестирование по фазам

Тестирование традиционно моделировалось и организовывалось, как серия этапов, более или менее следующих друг за другом. Это характерно для «Водопада» и крупных корпораций, в которых эта традиция и образовалась. Если речь заходит о «традиционном» тестировании, обычно имеется в виду «водопад». Выглядит это примерно так:

• Стадия сбора требований
  • Чтение требований
  • Сбор полезных артефактов
  • Учреждение критериев приемки
• Стадия кодирования
  • Кодирование идей тестирования в формат таких артефактов, как тест-кейсы
  • Кодирование идей тестирования в формат автоматизированных тестов
  • Кодирование тестового покрытия в матрицу отслеживаемости.
• Стадия выполнения
  • Тестировщики запускают тесты, описанные в тест-кейсах
  • Машины прогоняют автотесты.
• Конец / Заключительная стадия
  • Пишутся финальные отчеты о тестировании
  • Ведутся политические споры о покрытии и найденной информации.

Все это звучит довольно логично, и IEEE-829 стандарт для документации тестирования ПО подробно определяет полную модель водопада, основанную на фазах и документации. Эта модель может быть также использована в подходах Agile.

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

Итак, подобную модель тестирования мы назовем «тестированием по фазам», так как она рассматривает тестирование как серию фаз, линейно переходящих одна в другую. Возврат к предыдущей фазе воспринимается как недостаток, как плохое планирование, контроль или выполнение тестов.

Рефрейминг тестирования по фазам

Поразительно, но если рассматривать реальное предназначение и реальную цель деятельности каждой фазы, можно выделить следующее:

• Сбор требований – стадия обучения
• Планирование – стадия моделирования
• Выполнение – стадия исполнения
• Выход / отчетность – стадия коммуникации

Держа это в уме, давайте вновь рассмотрим эти фазы.

Стадия обучения

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

Стадия моделирования

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

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

Тест-кейсы – это модели. Это модели взаимодействия тестировщика или машины с ПО и того, что они хотят получить на выходе. Я хотел бы переименовать фазу планирования в более общую – «моделирование», потому что успех этой фазы зависит не от количества успешно созданных кейсов, а от разработки полезных моделей, упрощающих взаимодействие с продуктом и его оценку.

Выполнение

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

Успех этой фазы зависит не от прогона всех созданных скриптов, а от того, насколько удовлетворительно продукт был изучен и оценен.

Коммуникация

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

Зачастую тестирование – это некая черная дыра проекта, пока не наступает время финальной фазы отчетности, и (нехотя) в дело вступает коммуникация.

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

Явный абсурд

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

Тестирование по фазам полностью игнорирует любые перемены, но тестирование состоит из постоянных перемен!

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

Давайте рассмотрим альтернативную модель тестирования – ту, которая признает и принимает неизбежность перемен.

Тестирование по цепочкам

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

Это также стратегический элемент, который, как оболочка кабелей, направляет и поддерживает эту деятельность.

Итак, мы можем говорить о тестировании как о «фазах» или «цепочках» в соответствии с уровнем взаимного влияния цепочек друг на друга и уровня итеративности подхода.

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

Раньше я говорил о «lean-тестировании», и сейчас я считаю тестирование по цепочкам краеугольным камнем в достижении lean-подхода к тестированию. В моих глазах это практически синонимы.

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

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