«Недавно, общаясь с инженерными командами, я понял, что у меня созрел новый мысленный образ, более реалистичное отображение QA-процессов.
Я уже не визуализирую тестирование в виде классической пирамиды Майкла Кона. Да, в целом эмпирическое правило «должно быть больше юнит-тестов чем сквозных» все еще как-то работает. Но люди любят уточнять, а что такое уровень, а как их разграничить. Современное QA порождает самые разнообразные визуализации процессов в зависимости от проекта: Кубок, Мороженое, Сота, Песочные часы, Вулкан и так далее.
По теме: Полная классификация уровней, с рисунками
Конечно, эти уровни, или «слои» тестирования — разные в каждой команде, это зависит от проекта, уровня мастерства команды, и особенно от времени, выделенного на тестирование.
Когда моя команда обсуждает конкретный уровень и свои действия, я подталкиваю их к рассмотрению плюсов и минусов (я называя их «компромиссами») на этом уровне. Если понимание командой этого уровня хорошее, мы двигаемся на следующий уровень. Моя цель: побудить команду изучать альтернативные подходы, которые помогут ей хорошо выполнять свои задачи на всех уровнях, а не фокусироваться только на одном.
Итак, в моей классификации шесть уровней.
Каждый уровень выступает эффективной линией защиты, поэтому на production-уровень попадает очень мало дефектов. Решающее значение имеет исследовательское тестирование на протяжении всего жизненного цикла.
Уровень 6: Тестирование на проде
Тестирование на проде может включать в себя исследовательское тестирование, мониторинг с использованием телеметрии, изучение как ведет себя система, инструменты для анализа поведения пользователей, feature-флаги и поэтапное развертывание подсистем и фич.
Преимущества заключаются в том, что это самая реалистичная форма тестирования, без тестовых дублеров и тестовых окружений; это то, как конечные пользователи видят ваш продукт.
Компромисс заключается в том, что это очень живой процесс, а значит довольно опасный, потому что некоторые (все?) пользователи сразу же видят проблемы в системе, что вредит имиджу бренда.
По теме: Баги в проде
Уровень 5: Ручное регрессионное тестирование
Регрессионное тестирование проводится в конце процесса разработки, когда разработчики считают, что фича готова. В данном случае тестирование — это окончательная проверка качества с участием тестировщиков в конце процесса. Наши тестировщики обычно проводят такое тестирование в конце спринта каждые две недели. Тестировщики дают обратную связь разработчикам, если что-то пошло не так.
Преимущества в том, что это «последняя линия защиты» перед тем, как система попадет к конечным пользователям, она наиболее близка к тому, что видят пользователи.
Компромисс в том, что обнаружение бага в этой точке означает возвращение в цикл разработки, что может задержать релиз. Некоторые команды предпочитают вообще ничего не делать, обнаружив баг. Поиск вручную может быть очень утомительным и рассматривается как узкое место.
По теме: Гайд по регрессионному тестированию
Уровень 4: Автоматизированные сквозные UI-тесты
Автоматизированные тесты интерфейса обычно запускаются сразу после того, как разработчики закончили работу над фичами, обычно в конце конвейера. Время обратной связи в данном случае — это время, необходимое для создания и запуска автотеста, обычно 10-30 минут. Такие тесты у нас могут писать или разработчики, или тестировщики.
Преимущества в том, что инженерные команды могут запускать их так часто, как позволяет инфраструктура, и, в зависимости от качества тестов, они могут быть уверены, что продукт будет работать так как ожидается.
Компромиссы в том, что написание и поддержка тестов могут занимать много времени, и когда у вас их 50+, может быть трудно понять, что покрыто, а что нет. Кроме того, как правило, UI-тесты проводятся только в конце цикла разработки, а не во время, поскольку требуется время на настройку, создание, поддержку и интерпретацию результатов, что замедляет цикл обратной связи.
По теме: Тестирование GUI
Уровень 3: Исследовательское тестирование
Исследовательское тестирование может выполняться на любом этапе разработки и, скорее всего, на протяжении всего жизненного цикла. Я отнес его к среднему уровню, но всегда считал, что исследовательское тестирование должно происходить как можно ближе к началу разработки, чтобы dev-команды могли извлечь максимальную пользу из обратной связи.
Поэтому я рекомендую командам проводить такое тестирование уже во время разработки, объединяя тестировщиков и разработчиков, чтобы тестировщики давали непосредственную обратную связь еще в процессе создания фичи.
Преимущество заключается в том, что это наиболее гибкий и информативный тип тестирования, и это один из немногих способов понять, как ваш продукт работает в реальных условиях. Еще он позволяет создавать уникальные ручные тест-кейсы.
Недостаток заключается в том, что он требует серьезных навыков и опыта. Опытные ручные тестировщики лучше всего, но таких специалистов на рынке мало. Кроме того, процесс отнимает много времени и требует повторения.
По теме: Исследовательское тестирование
Уровень 2: Автоматизированные модульные и интеграционные тесты
Автоматизированные тесты нижнего и среднего уровня по Кону запускаются каждый раз, когда разработчик пишет код. Это модульное и интеграционное тестирование по методике TTD (Test-Driven Development), то есть разработчики пишут тесты до написания кода. TDD-подход помогает инженерным командам обеспечить тестируемость. Обратная связь передается так часто, как часто разработчики выполняют эти тесты, что обычно занимает менее секунды.
Преимущества заключаются в том, что тесты выполняются очень быстро, давая мгновенную обратную связь — изменилось ли поведение системы.
Компромисс заключается в том, что тестируется только код, написанный этой командой, а зависимости подменяются дублерами. Из-за очень большого количества тестов бывает сложно понять, что именно сейчас проверяется, даже если тесты написаны по высоким стандартам. Кроме того, в таких тестах, как правило, проверяются только happy paths.
По теме: Большой гайд по юнит-тестам для тестировщиков, и Подробно о TDD
Уровень 1: Тестирование требований
Тестирование требований обычно проводится до написания кода фичи или даже до принятия командой решения о том, будет ли фича создана. Тестировщики, разработчики и менеджеры продукта обсуждают, что это за фича, что она будет делать, как она будет это делать, и какие преимущества она принесет пользователям (мы называем это «предполетной проверкой» или «Три амигос»). Обсуждается не тестирование или код, а смысл фичи.
Преимущество в том, что команда создает общее для всех понимание фичи, и будет поддерживать его на всех остальных этапах.
Компромисс заключается в том, что неожиданные моменты будут обнаружены только на поздних этапах жизненного цикла.»
Quality Engineering Newsletter, автор: Principal Tester for iPlayer and Sounds (BBC)
Еще одна альтернативная концепция — Перевернутая пирамида: интеграционные тесты важнее модульных
