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

Почему качество в бизнесе так важно? 

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

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

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

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

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

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

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

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

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

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

Малая течь большой корабль ко дну пустит.

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

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

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

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

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

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

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

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

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

Вторая часть этого - анализ того, какой тест вы запускаете в какой момент. Представьте, что вы находитесь в среде Dev - какой тест вы собираетесь запустить? Может быть, низкоуровневые Unit- или Smoke-тесты? Когда вы перемещаетесь в тестовую среду, какие тесты там запускаются? Собираетесь ли вы проводить системное тестирование, где у вас есть вся интегрированная система? Нужно ли вам переходить в какую-то другую среду для тестирования, если вы подключили несколько десятков мобильных устройств и различных браузеров? Я предлагаю вам посмотреть на каждую среду, в которой вы работаете, и проанализировать, какие тесты вы там запускаете. 

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

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

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

С непрерывным тестированием: 

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

• Процесс CI уже должен быть налажен - непрерывное тестирование расширяется от CI, поэтому мы доводим CI до максимума, а затем начинаем добавлять больше Quality Gates. 

• Устраните проблемы с окружением и данными. 

• Ответьте на вопрос какие тесты вы проводите и где. 

• Тестируйте на каждом этапе. 

• Смещайте тесты влево. 

Как вы определяете регрессию? 

Если вы пересчитали все деревья, это еще не значит, что вы увидели лес

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

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

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

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

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

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

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

• Мы должны пересмотреть всю нашу стратегию тестирования в рамках непрерывного тестирования. 

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

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

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

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

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