Сегодня специалистам по тестированию и менеджменту необходимо достичь оптимального баланса между скоростью и качеством при поставке программного обеспечения для современного бизнеса. Если вы стремитесь пересмотреть процесс обеспечения качества с целью ускорить выпуск продукта и внедрить непрерывное тестирование (Continuous Testing), то эта статья для вас.

Почему сейчас качество в бизнесе важнее, чем когда-либо? 

"Время - деньги" 

Мир меняется со скоростью света. Предприятия хотят поставлять новые продукты как можно быстрее. Даже одна задержка может позволить конкурентам завоевать долю рынка. Здесь мы имеем дело с железным треугольником обслуживания клиентов: Скорость – доставка в кратчайшие сроки; Стоимость – бизнес хочет экономить деньги; Качество - должно оставаться на высоте.  

Интересный факт: последние статистические данные о цифровой трансформации уже поразительны, и это только начало. Рассмотрим эти данные: 

• На планете проживает 7,7 миллиарда человек 

• 4,5 миллиарда человек имеют регулярный доступ к туалету 

• 5,5 миллиарда человек владеют мобильными устройствами 

У стейкхолдеров, участвующих в жизненном цикле ИТ-продукта, разные ожидания. Разработчики стремятся к более быстрому времени отклика при сохранении высочайшего качества. Менеджеры по продажам и развитию бизнеса хотят, чтобы “было сделано больше за меньшие деньги”. Продукт оунеры (Product owners) стремятся придерживаться своей “дорожной карты с дедлайнами”. Владельцы бизнеса хотят повысить гибкость, чтобы быстрее соответствовать рыночным условиям. И абсолютно все должно быть высшего качества. Реализация всех этих мандатов с использованием “непрерывного” подхода возможна. 

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

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

Чем отличается стратегия тестирования при построении непрерывного тестирования 

"Маленькая течь может потопить большой корабль"

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

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

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

От непрерывной интеграции к непрерывному тестированию 

"Никогда не откладывай на завтра то, что ты можешь сделать сегодня"

Непрерывное тестирование построено на основе непрерывной интеграции (Continuous Integration). Если мы создадим новую сборку вместе с автоматизированным процессом, запустим юнит и smoke-тесты, мы сможем использовать непрерывную интеграцию и, таким образом, запустить полную регрессию для виртуальной машины или каждой платформы, поддерживаемой вашим продуктом. Созданный вами CI может быть трудозатратным процессом, и это лишь первый шаг в непрерывном тестировании.  

Итак, опять же, у вас должен быть продуманный процесс непрерывной интеграции: автоматические сборки, smoke-тесты и регрессионные тесты уже внедрены. Если мы собираемся перенять опыт CI, то ключевым моментом является бережливый процесс тестирования на каждом этапе. Это включает в себя раннее тестирование, частое тестирование и тестирование со сдвигом влево. Сдвиг влево означает перенос тестирования на как можно более ранний срок, когда поиск проблем обходится дешевле и качество повышается на каждом этапе. Частью этой стратегии является повторный анализ того, какие тесты и в каких окружениях запускать. 

Давайте поговорим о качестве на каждом этапе непрерывного тестирования. Когда речь идет о непрерывном тестировании, это не означает, что вы просто можете непрерывно запускать автоматизированные регрессионные тесты снова и снова. Непрерывное тестирование – это качество на каждом этапе: делаете сборку – тестируете ее. Интегрируете API – тестируете его. Вы переходите на новое окружение, в большую базу данных, на Stage или Production – тестируете и их. Итак: непрерывное тестирование – это скорее качество на каждом этапе и тестирование на каждом шаге, чем повторный запуск одних и тех же регрессионных тестов снова и снова. 

Анализ регрессионных тестов 

"Халатность в мелочах может породить большие неприятности" 

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

Тесты производительности и безопасности 

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

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

Для непрерывного тестирования важно: 

1. Устранение проблем с Agile – нужно убедиться, что у вас уже есть отличный Agile процесс. 

2. Процесс CI уже работает– непрерывное тестирование существует за счет CI, поэтому мы используем CI настолько, насколько это возможно, а затем начинаем повышать качество. 

3. Устранение проблем со средой и данными. 

4. Какие тесты и в каком окружении вы запускаете? 

5. Тестирование на каждом шагу. 

6. Тестирование со сдвигом влево. 

Как определить регрессию? 

"Пересчитать все деревья – не значит увидеть лес" 

Так много продуктов/проектов должны перейти к эффективному набору регрессионных тестов, однако большинство из них используют старые и трудоемкие решения. Поэтому, когда мы говорим о регрессии, нам нужно обсудить понятие "дешево и сердито". Благодаря непрерывной доставке и непрерывному развертыванию не потребуется много дней, чтобы выполнить регрессию. У меня есть пара клиентов/проектов, у которых были такие проблемы с автоматизацией, когда они пытались использовать непрерывную интеграцию и непрерывное тестирование (Continuous Integration/Continuous Testing); они отказались от своей автоматизации и построили ее с нуля, ориентируясь на наборы для автоматизации тестирования "дешево и сердито". 

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

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

Кроме того, нам может понадобиться регрессия по счастливому пути, которая представляет собой скорее сквозную или множество функций, а не небольшие отдельные тесты. Они больше и длиннее, и эти комплексные функции касаются каждой интегрированной системы. Итак, допустим, у нас есть API и различные базы данных. Если у нас есть различные подсистемы, небольшие изолированные регрессионные тесты не помогут – нам могут понадобиться сквозные тесты, которые затрагивают каждую подсистему, каждый API, которые последовательно затрагивают каждую форму по порядку, чтобы убедиться, что интегрированная система работает. И мы обнаруживаем проблемы с потоком данных и дефекты, которые можно было бы обнаружить только при выполнении более полных тестов-сценариев, а не небольших изолированных приемочных тестов или валидационных тестов. Таким образом, нам, возможно, потребуется пересмотреть регрессию и создать несколько наборов регрессий, которые запускаются в различных средах. Это одно из ключевых изменений, которое приходится вносить многим командам, когда они переходят к непрерывному тестированию и переопределяют, какие тесты должны выполняться и где – полный набор регрессионных тестов больше не подходит. Именно так DevOps и непрерывное тестирование меняют то, как мы определяем наборы регрессионных тестов.  

Тестирование на продакшене получило плохую репутацию 

"Как правило, программные системы работают плохо до тех пор, пока их не начали использовать, и они неоднократно ломались в реальных приложениях" 

Наилучшая практика никогда не была опробована в продакшене. В DevOps, не имеет значения, называем ли мы это непрерывным мониторингом (Continuous Monitoring) или у нас есть автоматизация, которую запускают на продакшене, сейчас это очень распространено. Существует целый тип тестов, в которых, если у вас хорошая практика тестирования, имеется опыт с непрерывным тестированием и конкурентоспособность, эти проблемы возникают только тогда, когда вы находитесь на продакшене. Мы должны сдвинуть эти тесты влево и запустить их раньше или запустить как часть CM, чтобы убедиться, что мы отслеживаем то, что происходит в реальном продакшене. Но команда должна быть очень осторожна: не стоит запускать тесты, которые могут вызвать проблемы с многопоточностью, однако нужно запустить некоторые тесты мониторинга на продакшене как часть стратегии тестирования всего жизненного цикла. 

Шесть советов и хитростей для построения эффективной стратегии тестирования для непрерывного тестирования: 

• Стоит пересмотреть всю стратегию тестирования в рамках непрерывного тестирования. 

• У вас должен быть отличный Agile / Scrum-процесс с автоматизацией спринта. 

• Непрерывное тестирование начинается с процесса непрерывной интеграции и дополняет ее. 

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

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

• Существуют автоматизированные тесты, которые могут выполняться на продакшене как часть непрерывного процесса мониторинга или просто как часть процесса тестирования. Убедитесь, что они не мешают работе пользователей вашей системы.