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

В предыдущей статье этой серии подробно описывалось тестирование через призму Намерения, Дисциплины, Тестируемости и Реализации:

Заманчиво расположить эти фреймы, начиная с верхнего правого угла, и упорядочить их в аккуратную, линейную последовательность:

Говоря об этом, обычно имеют в виду нечто иное, однако можно рассматривать это как своего рода end-to-end тестирование. Большую часть времени люди вроде бы думают об end-to-end тестировании продукта или системы с точки зрения явного рабочего процесса, бизнес-процесса или транзакции. Когда мы принимаем за основу расширенное понятие продукта — то, к которому я постоянно возвращаюсь в этой серии (и собираюсь сделать это снова) — каждый продукт заслуживает определённого end-to-end (сквозного) тестирования как минимум по трём измерениям.

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

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

Тестирование и разработка — это нелинейные процессы.

Джерри Вайнберг заметил, что любую линию можно принять за прямую, если рассматривать достаточно небольшой её участок. Это справедливо и в случае, если смотрящий находится очень далеко. Модель водопада — и V-модель, которая насильно впихивает туда тестирование — может быть очень привлекательной для тех, кто не слишком внимательно следит за тем, что происходит в процессе разработки программного обеспечения.

Я только что упомянул «всю систему», но ещё раз (я же предупреждал, что сделаю это!) обратите внимание, что под «всей системой» или «готовым продуктом» не обязательно подразумевается полностью готовое, работающее программное приложение. Скорее, это наивысший уровень того, с чем мы сейчас работаем: завершённый компонент; полный документ с требованиями; сформированная идея; внятная идея, требующая дальнейшей доработки; пользовательская история; план спринта; однострочное исправление ошибки… Всё, что мы создаём или делаем, в любом масштабе и с любой степенью глубины, может быть протестировано сквозным образом.

Разработка продукта, который будет создан и выпущен для пользователей, включает создание множества элементов, из которых он состоит и которые его поддерживают. Каждый полноценный продукт состоит из десятков, сотен других элементов, созданных людьми. Разработка программного обеспечения — это нелинейный процесс. Это даже не просто циклы — это фрактал, самоподобный как сверху вниз, так и снизу вверх. То же самое относится и к тестированию. Что бы мы ни создавали, писали или реализовывали, мы можем применять тестирование в рамках каждого из четырёх фреймов, на любом уровне и в любое время.

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

Когда мы проектируем, создаём и тестируем функциональность, мы можем:

• Исследовать и анализировать идеи, требования и дизайн, проводить мысленные эксперименты, затрагивающие их (фрейм Намерения).
• Быстро и без вмешательств проверять каждый модуль и компонент в дисциплинированном порядке, чтобы убедиться, что то, что мы делаем, соответствует нашим намерениям (фрейм Дисциплины).
• Анализировать продукт и общую ситуацию в проекте, чтобы выявить факторы, усложняющие или замедляющие тестирование (фрейм Тестируемости).
• После создания функциональности проводить тщательное тестирование, взаимодействуя с остальной системой, получая опыт и выполняя эксперименты для обнаружения трудноуловимых проблем (фрейм Реализации).

Вероятно, кто-то покритикует идею глубокого тестирования после разработки. Те, кто так думает, обычно предлагают два варианта решения:

1. Настаивать, чтобы вся работа по текущей версии функционала была завершена до начала работы над следующей версией. Это звучит разумно, пока разработчики и менеджеры не начнут жаловаться на необходимость выполнения тестирования или ожидание его завершения.
2. Утверждать, что на исследование, изучение и эксперименты с готовым продуктом просто нет времени; поэтому исключить эту работу, осторожно и консервативно выпускать функциональность и полагаться на автоматические проверки — преимущественно из фреймов Намерения и Дисциплины — чтобы минимизировать риски трудноуловимых и важных проблем. Если проблемы всё же появляются, откатить функциональность, провести диагностику и выпустить хотфикс.

На первый взгляд идея часто кажется неплохой, и при низком уровне риска и небольшом масштабе проекта такой подход может быть вполне подходящим решением. Тем не менее, стоит учитывать, что некоторые проблемы могут иметь серьёзные последствия, а откатиться может быть непросто. Конечно, откат к более старой версии кода при хорошем управлении версиями — относительно простая задача. Но время назад не вернешь. Достаточно серьёзный баг может привести к потере или повреждению данных, прервать работу пользователей, открыть дорогу уязвимости безопасности… Исправление таких последствий может быть трудоёмким и дорогостоящим.

Но есть и третий вариант, который можно комбинировать с вышеописанными (особенно с вариантом 2):

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

Третий подход даёт возможность выполнять глубокое тестирование без прерывания работы разработчиков — что позволяет им уверенно двигаться вперёд. Если намерения ясны, разработчики дисциплинированы (активно выполняют тестирование в рамках Дисциплины) и практическая тестируемость высока, то глубокое тестирование может быть проведено эффективно, снижая риск того, что разработка чересчур опережает тестирование готовых версий продукта.

Использование фреймов для оценки нашей работы

Существует ещё одно, более глубинное измерение тестирования — рефлексивное. Мы можем исследовать не только продукт, но и собственную работу.

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

• Первый шаг — прояснить наши намерения: Как должна выглядеть эта диаграмма? Что именно она должна отображать? Кто будет её использовать? Кто ещё может её использовать? Чего каждый из этих пользователей может ожидать? Что может пойти не так; каким образом диаграмма может быть неполной или вводящей в заблуждение? Как мы можем обнаружить это как можно раньше? Что нам нужно сделать, чтобы признать диаграмму готовой и удовлетворяющей нашим потребностям?
• Дисциплина: Делам ли мы свою работу достаточно усердно и аккуратно? Вовлекаем ли нужных людей? Используем ли соответствующие инструменты? Сохраняем ли мы черновики там, где это полезно и необходимо, чтобы не потерять работу?
• Тестируемость: При подготовке к завершению и публикации диаграммы — как мы должны подготовиться к её тестированию, то есть к тщательной и глубокой критике? В чём разрыв между тем, что мы знаем, и тем, что нам нужно узнать? Готовы ли и квалифицированы ли нужные люди для её обзора?
• Реализация: Теперь, когда диаграмма готова, пора её проверить. Отражает ли она всё, что мы планировали? Какие проблемы в ней могут ещё оставаться? Что мы могли пропустить? Чьи точки зрения могли быть забыты? Каков риск неправильного понимания диаграммы и каким образом это может произойти?

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

До сих пор в этой серии я в основном воздерживался от ответа на вопрос, кто именно занимается тестированием. Это тема для следующего выпуска.

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