Гибкий подход в разработке программного обеспечения - это метод итеративной разработки ПО, цель которого - частый выпуск обновлений ПО. Такой подход стал очень популярным в последнем десятилетии, так как позволяет командам быстро реагировать на изменяющиеся требования. Вместе с тем, Agile-методология предназначена не только для программистов, но и для тестировщиков - это помогает им эффективно работать вместе. Тестировщики могут внести ценный вклад в разрабатываемый продукт, ведь их идеи и предложения помогут убедиться, что конечный продукт соответствует всем ожиданиям.
Agile-тестирование - это способ тестирования программного обеспечения с использованием коротких итераций. В каждой итерации специалисты по обеспечению качества тесно сотрудничают с разработчиками для тестирования новых функций или изменений в существующем коде. Они также обеспечивают разработчикам обратную связь, которую затем включают их предложения в следующую версию программного обеспечения.
Чтобы успешно внедрить гибкое тестирование, нужно сначала хорошо понимать текущие процессы вашей организации. Возможно, у вас уже есть какой-то инструмент управления тестированием, который помогает отслеживать дефекты и назначать их QA-специалистам. Если нет, тогда можно рассмотреть возможность использования этого метода.
В Agile-манифесте сказано, что «программное обеспечение должно создаваться людьми для людей». Это означает, что нужно работать с конечными пользователями, чтобы создавать полезное ПО. И так же, необходимо привлекать их на протяжении всего процесса создания продукта.
Agile-тестирование участвует во всех этапах работы над проектом. На этапе планирования - помогает команде понять, что и как нужно тестировать. Затем, на этапе реализации, проверяет прогресс и может предложить улучшения в дизайне. Наконец, когда программное обеспечение будет выпущено, его будет использовать конечный пользователь и сообщать обо всех обнаруженных ошибках.
- Своевременное и частое тестирование
- Сотрудничество с другими участниками команды
- Предоставление оценки при первой возможности
Waterfall-тестирование — это традиционный подход к разработке программного обеспечения, при котором вся система проектируется до начала разработки. Этот тип тестирования проводится в конце проекта. Когда тесты завершены, результаты анализируются, и разработчик вносит необходимые коррективы. Как только все будет готово, программное обеспечение будет запущено в производство.
Такой подход может вызвать проблемы, потому что конечный продукт не всегда соответствует тому, что задумывалось изначально. Например, если клиенту не нравятся цвета, используемые на веб-сайте, разработчик может решить внести изменения, не задумываясь о том, повлияют ли эти изменения на удобство использования сайта.
С другой стороны, Agile-тестирование предполагает итерации. Вся система разрабатывается поэтапно. Каждый раз, когда команда закончила работать над задачей, они обсуждают свои идеи с остальными членами команды. По мере того, как становится больше известно о требованиях, план корректируется соответствующим образом.
Когда программное обеспечение, наконец, готово, команда анализирует результаты и вносит необходимые изменения. Однако, в отличие от Waterfall-тестирования, код никогда не дорабатывается. Вместо этого, вся система постоянно обновляется, пока клиент не одобрит ее.
Этот метод фокусируется на написании тестов до разработки фактического кода, который позволит пройти тест. Такой подход делает упор на написание тест-кейсов перед написанием кода.
Одним из преимуществ этого метода является то, что он побуждает разработчиков правильно проектировать свой код и думать о возможных ошибках, входных и выходных данных. Еще одно преимущество заключается в том, что тесты охватывают все функции продукта.
Этот метод обычно используется для модульного тестирования (Unit testing). Однако некоторые тестировщики применяют его к более сложным типам, например, тестирование пользовательского интерфейса (UI testing).
Этот метод меньше фокусируется на написании тестов и больше на наблюдении за пользователями. Он разработан, чтобы помочь тестировщикам понять, как пользователи взаимодействуют с системой.
Этот метод похож на TDD. Основное отличие в том, что фокусируется он на поведении, а не на структуре. Преимущество этого метода в том, что он позволяет тестировщикам тестировать всё приложение одновременно. Это экономит время, поскольку устраняет необходимость запуска нескольких версий приложения.
Этот метод сочетает в себе приемку и разработку через тестирование. Он использует те же основные концепции, но применяет их по-разному. Основное различие между ATDD и TDD заключается в том, что ATDD фокусируется на критериях приемлемости, а не на функциональных требованиях.
Исследовательское тестирование похоже на приемочное пользовательское тестирование (User Acceptance Testing, UAT). Но включает в себя больше, чем просто наблюдение за пользователями. То есть, например, понадобится изучить, как программа ведет себя при определенных условиях: не произойдет ли сбой, когда время ожидания подключения к базе данных истекло. Преимущества исследовательского тестирования включают в себя изучение поведения приложения и обнаружение проблем до их возникновения. Исследовательское тестирование можно использовать, чтобы найти любые проблемы в приложении. Чтобы провести его, не нужно знать заранее, в чем проблема.
Сессионное тестирование состоит из нескольких сеансов, в которых QA-специалист взаимодействует с системой. Каждая сессия включает в себя разные задачи. Они помогают определить, работает ли система должным образом, а также, является ли она надежной и пригодной для использования.
Жизненный цикл Agile-тестирования состоит из трех этапов: планирование, исполнение и мониторинг. На этапе исполнения Agile-тестировщики работают в командах. Здесь они выполняют различные действия: сбор информации от клиентов, создание тест-кейсов, выполнение тестов, анализ результатов, документирование результатов и выпуск продукта.
На этом этапе команда создает подробный план тестирования, который должен включать следующие детали:
- Список функциональных областей, которые будут протестированы
- Оценка времени, необходимого для выполнения каждой задачи
- Оценка количества тест-кейсов, необходимых для каждой области
На этапе исполнения команда работает с самим планом. Члены команды выполняют тест-кейсы, используя свои навыки и опыт. Также, могут использовать различные инструменты, такие как - наборы автоматизированной регрессии или генераторы нагрузки.
На этапе контроля команда анализирует результаты тестирования и документирует их. А также оценивает эффективность тестирования и соответствующим образом корректирует план.
Гибкий процесс тестирования подходит для любой команды, которая хочет быстрее реагировать на изменения и выпускать более качественное программное обеспечение.