[Перевод] Непрерывное тестирование: разработка выигрышной стратегии тестирования
Сегодня специалистам по тестированию и менеджменту необходимо достичь оптимального баланса между скоростью и качеством при поставке программного обеспечения для современного бизнеса. Если вы стремитесь пересмотреть процесс обеспечения качества с целью ускорить выпуск продукта и внедрить непрерывное тестирование (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-тесты? Когда вы переходите в тестовую среду, какие тесты проходить там? Собираетесь ли вы проводить системное тестирование там, где есть целая интегрированная система? Нужно ли вам переходить в какую-то другую среду для тестирования, если вы подключили несколько десятков мобильных устройств и разные браузеры? Предлагаю посмотреть на каждую среду, в которой вы работаете, и проанализировать, какие тесты вы в них запускаете.
Тесты производительности и безопасности
«Проводить тестирование производительности и безопасности по завершении системного или функционального тестирования — все равно что приносить прохладительные напитки после окончания вечеринки»
Одним из ключевых моментов непрерывного тестирования является то, что кроме проваленных тестов, нам, возможно, придется взять на себя тесты производительности и безопасности. Возможно, нам потребуется взять на себя выполнение любых тестов в рамках стратегии тестирования полного жизненного цикла, которую мы собираемся автоматизировать. И это будет включено в наш непрерывный процесс тестирования и запускаться повторно каждый раз при изменениях. Обоснованность заключается в том, чтобы не ждать перехода в продакшен, чтобы провести тесты производительности и выявить проблемы. Вы можете выполнять тесты производительности как можно раньше, когда устранение неполадок обходится дешевле.
Для непрерывного тестирования важно:
Устранение проблем с Agile — нужно убедиться, что у вас уже есть отличный Agile процесс.
Процесс CI уже работает– непрерывное тестирование существует за счет CI, поэтому мы используем CI настолько, насколько это возможно, а затем начинаем повышать качество.
Устранение проблем со средой и данными.
Какие тесты и в каком окружении вы запускаете?
Тестирование на каждом шагу.
Тестирование со сдвигом влево.
Как определить регрессию?
«Пересчитать все деревья — не значит увидеть лес»
Так много продуктов/проектов должны перейти к эффективному набору регрессионных тестов, однако большинство из них используют старые и трудоемкие решения. Поэтому, когда мы говорим о регрессии, нам нужно обсудить понятие «дешево и сердито». Благодаря непрерывной доставке и непрерывному развертыванию не потребуется много дней, чтобы выполнить регрессию. У меня есть пара клиентов/проектов, у которых были такие проблемы с автоматизацией, когда они пытались использовать непрерывную интеграцию и непрерывное тестирование (Continuous Integration/Continuous Testing); они отказались от своей автоматизации и построили ее с нуля, ориентируясь на наборы для автоматизации тестирования «дешево и сердито».
Когда мы говорим о регрессии, мы можем разделить ее на множество регрессионных наборов. Одно из ключевых изменений в стратегии тестирования заключается в том, что нам нужно определить регрессию и сосредоточиться на подходах дешево и сердито, а не на всем, что включено в единую регрессию; определить входит ли каждый отдельный тест, который мы запускаем, в регрессию, или мы автоматизируем все тесты, потому что можем.
У нас могут быть smoke-тесты, которые являются частью набора регрессионных тестов, а также может быть полная регрессия, но мы можем запускать ее только один или два раза в течение цикла разработки.
Кроме того, нам может понадобиться регрессия по счастливому пути, которая представляет собой скорее сквозную или множество функций, а не небольшие отдельные тесты. Они больше и длиннее, и эти комплексные функции касаются каждой интегрированной системы. Итак, допустим, у нас есть API и различные базы данных. Если у нас есть различные подсистемы, небольшие изолированные регрессионные тесты не помогут — нам могут понадобиться сквозные тесты, которые затрагивают каждую подсистему, каждый API, которые последовательно затрагивают каждую форму по порядку, чтобы убедиться, что интегрированная система работает. И мы обнаруживаем проблемы с потоком данных и дефекты, которые можно было бы обнаружить только при выполнении более полных тестов-сценариев, а не небольших изолированных приемочных тестов или валидационных тестов. Таким образом, нам, возможно, потребуется пересмотреть регрессию и создать несколько наборов регрессий, которые запускаются в различных средах. Это одно из ключевых изменений, которое приходится вносить многим командам, когда они переходят к непрерывному тестированию и переопределяют, какие тесты должны выполняться и где — полный набор регрессионных тестов больше не подходит. Именно так DevOps и непрерывное тестирование меняют то, как мы определяем наборы регрессионных тестов.
Тестирование на продакшене получило плохую репутацию
«Как правило, программные системы работают плохо до тех пор, пока их не начали использовать, и они неоднократно ломались в реальных приложениях»
Наилучшая практика никогда не была опробована в продакшене. В DevOps, не имеет значения, называем ли мы это непрерывным мониторингом (Continuous Monitoring) или у нас есть автоматизация, которую запускают на продакшене, сейчас это очень распространено. Существует целый тип тестов, в которых, если у вас хорошая практика тестирования, имеется опыт с непрерывным тестированием и конкурентоспособность, эти проблемы возникают только тогда, когда вы находитесь на продакшене. Мы должны сдвинуть эти тесты влево и запустить их раньше или запустить как часть CM, чтобы убедиться, что мы отслеживаем то, что происходит в реальном продакшене. Но команда должна быть очень осторожна: не стоит запускать тесты, которые могут вызвать проблемы с многопоточностью, однако нужно запустить некоторые тесты мониторинга на продакшене как часть стратегии тестирования всего жизненного цикла.
Шесть советов и хитростей для построения эффективной стратегии тестирования для непрерывного тестирования:
Стоит пересмотреть всю стратегию тестирования в рамках непрерывного тестирования.
У вас должен быть отличный Agile / Scrum-процесс с автоматизацией спринта.
Непрерывное тестирование начинается с процесса непрерывной интеграции и дополняет ее.
Проверяйте качество на каждом этапе. Необходимо пополнять непрерывное тестирование каждый раз, когда вносите изменения, переходите в другое окружение, интегрируете новый контейнер, новый API, что угодно новое — тестирование должно проходить на каждом этапе.
Запуск чужих тестов важен, потому что, возможно, они не запускались ранее. Нам нужно получше изучить такие тесты и сделать их частью вашей автоматизации. Вы определяете регрессию и идете к тому, чтобы автоматизация регрессии была «дешевой и сердитой», а не «дорогой и медленной».
Существуют автоматизированные тесты, которые могут выполняться на продакшене как часть непрерывного процесса мониторинга или просто как часть процесса тестирования. Убедитесь, что они не мешают работе пользователей вашей системы.
