Что такое непрерывное тестирование?

Что такое непрерывное тестирование?

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

Непрерывное тестирование - это ответ, но что это такое и как мы можем достичь такого состояния в нашей стратегии развития?

В тестировании по стратегии Agile мы основывали нашу модель на двух фундаментальных принципах:

  1. Предотвращение дефектов, а не обнаружение дефектов
  2. Быстрая обратная связь

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

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

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

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

Одна вещь, котор нужно иметь в виду, состоит в том, что непрерывное тестирование НЕ касается автоматизации тестирования.

Непрерывное тестирование в Agile

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

Пользовательская история

Это первый этап, на котором можно определеить дефекты. Как минимум, мы должны обеспечить такие условия, чтобы истории пользователей проверялись и содержали хороший набор критериев приемлемости. Это обычно делается на собрании Three Amigos (Dev, QA, PO), где детали пользовательских историй вырисовываются подробнее.

Дизайн

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

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

Ветвление

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

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

Код

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

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

Сборка

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

Интеграционное, сквозное и исследовательское тестирование новых функций - все это важные функции, и все они имеют разные цели.

Выпуск

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

Вывод

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

Непрерывное тестирование дает нам уверенность в том, что на каждом этапе наша работа выполнена хорошо. Тестирование на каждом этапе служит другой цели, поэтому мы можем получить целостное представление о качестве продукта. Эффективный тестировщик очень ценен на рынке труда, поэтому стать успешным в этой сфере Вам помогут наши курсы тестировщиков.