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

Итак, стадии.

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

Теперь о каждой стадии подробнее.

Стадия 1. Тестирование выполняет разработчик и\или менеджер

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

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

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

Стадия 2. Тестировщик проверяет проект в самом конце

Проверить весь проект на предрелизной стадии — классический метод при работе по модели Waterfall. Проект разделяется на глобальные этапы (иногда весь проект это один этап). На каждом этапе сначала делается софт, а уже потом тестируется. Тестирование уже есть, и это хорошо. Но проблемы тоже есть, и совершенно конкретные.

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

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

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

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

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

Стадия 3. Все задачи проверяются на соответствие результата изначальной задаче

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

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

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

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

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

Стадия 4. Тестировщики занимаются тест-дизайном

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

Чек-лист — список проверок, необходимых для тестирования функционала. Чек-листы более распространены, так как их проще поддерживать в актуальном состоянии, особенно в рамках большого динамичного проекта.

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

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

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

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

Стадия 5. Внедряется система управления тестированием

Далее компания дорастает до необходимости использования специализированных систем для хранения тест-кейсов (чек-листов) и выполнения тестовых прогонов.

Такая система позволяет:

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

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

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

Стадия 6. Автоматизируются регулярные проверки

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

Разработанные автотесты включаются в процесс непрерывной интеграции (CI/CD), что позволяет команде узнавать об ошибках непосредственно в момент коммита.

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

Стадия 7. Усложняется иерархия, появляются новые роли

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

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

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

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

Выводы

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

Процесс развития тестирования не всегда линейный. Вы можете пропускать, объединять, смешивать определенные этапы или сразу выходить на более высокий уровень. Например, у нас в Qualitica есть система управления тестирования, то есть мы на стадии 5. Сейчас практически одновременно у нас появляются узкие специалисты (новые роли, стадия 7) и автоматизация (стадия 6).

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

7 этапов эволюции тестирования в компании