Как адаптировать стратегии ручного тестирования в гибкой разработке: лучшие практики

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

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

Целью данной статьи является изучение лучших практик для успешной интеграции ручного тестирования в среду гибкой разработки.

Читать на Habr

При гибкой разработке роль ручного тестировщика кардинально меняется.
Вместо получения готового продукта для проверки в конце цикла, QA-специалист становится полноправным участником команды с первого дня спринта. Тестировщики должны активно участвовать в планировании спринтов, ежедневных стендапах и ретроспективах, чтобы обеспечить общее понимание целей, требований и прогресса проекта.

Ведущий тестировщик в Авито, рассказывает о внедрении Agile-тестирования в команду: "Мы столкнулись с тем, что мы, QA, не понимаем что именно проверяют unit-тесты
и поэтому не доверяем им, а в дань нашей бдительности пишем тесты уровнем выше". Команда решила эту проблему через тесное сотрудничество с разработчиками.

Конкретные шаги, которые предприняла команда Авито: QA-специалист
с разработчиком провели детальную сессию по объяснению unit-тестов, в результате которой "родилась потрясающая схема сервиса: так нарисовали, что аж сами поняли". Вместо обычного тестирования функциональности по окончании процесса разработки команда начала проводить прогон автотестов всех уровней и только исследовательское тестирование для новых функций.

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

Ручное тестирование в Agile требует принципиально иного мышления. В 2024 году подход shift-left testing стал значительным трендом в agile тестировании в основных проектах разработки программного обеспечения. Этот подход включает перенос тестирования на ранние стадии разработки, обеспечивая непрерывное тестирование
на протяжении всего процесса. Традиционный подход с детальным планированием всех тест-кейсов на несколько месяцев вперед здесь не работает.

QA-инженер в МТС Digital, работающий над проектом WASD.TV, описывает практический подход к гибкому тестированию: "Команда работает n-недельными спринтами, каждый спринт ориентирован на конкретные пользовательские истории. В рамках планирования спринта происходят заведение, проработка задач и историй, определение приоритетов и серьезности задач, их оценка".

Ключевая особенность подхода команды WASD.TV заключается в том, что QA-инженер после этапа планирования уже может начинать создавать тест-кейсы и чек-листы
к задачам, опираясь на функциональные требования. Когда задача попадает
на тестирование, QA-инженер берет ее на выполнение в зависимости от приоритета
и создает тестовую документацию, если её нет.

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

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

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

Тимлид в поисковом портале Яндекса, рассказывает о том, как в компании устроено тестирование интерфейсов: "Мы поговорили о том, что важно покрывать автоматическими проверками все, что только можно. Стоит написать как можно больше дешевых юнит-тестов, которые решают большую часть задач".

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

Специалист отмечает: "Но как бы вы ни покрывали все, как бы ни старались написать интеграционные тесты, все равно потребуется ручное тестирование". Поэтому в Яндексе создали систему, которая помогает тестировщикам не упустить никаких проверок. Помимо проверки тест-кейсов эту же схему можно применить для других видов задач, например, для проверки актуальности документации.

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

Разработка через тестирование (TDD) - это основополагающая практика agile тестирования, при которой тесты пишутся перед самим кодом. Разработчики начинают
с создания небольших автоматизированных тест-кейсов на основе конкретных требований, которые изначально не проходят, поскольку соответствующая функциональность еще не реализована. В Agile-командах это создает уникальные возможности для ручных тестировщиков.

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

Лучшие практики для тестировщиков, следующих методологии ATDD Agile, включают сотрудничество с пользователями и поощрение использования синтаксиса Gherkin, чтобы бизнес-аналитики могли самостоятельно писать и дорабатывать тест-кейсы, улучшая точность и релевантность критериев приемки.

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

При гибкой разработке частые и постепенные обновления программного обеспечения становятся нормой. Треть тестировщиков указали себя как активную часть определения
и поддержания процесса CI/CD, в то время как процесс CI/CD способствует выводу продуктов на рынок быстрее чем когда-либо прежде. Ручные тестировщики адаптируют свои процессы для работы в условиях постоянных изменений.

Автоматизированный конвейер CI/CD в таких условиях становится критически важным инструментом. Каждый commit разработчика автоматически запускает цепочку проверок:
сборку приложения, выполнение unit-тестов, деплой в тестовую среду, запуск автоматизированных интеграционных тестов. Только после прохождения всех автоматических проверок задача попадает к ручному тестировщику.

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

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

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

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

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

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

Эффективное внедрение адаптированных стратегий ручного тестирования в гибкую разработку дает конкретные результаты. Команды, которые агрессивно контролируют Work in Progress (WiP), сокращают время в процессе вдвое и имеют только четверть от количества дефектов, но на треть более низкую производительность. Это показывает важность баланса между скоростью и качеством.

Отслеживая и улучшая Defect Density и Escape Rate, Agile команды могут повысить надежность программного обеспечения и удовлетворенность пользователей, снизить затраты, связанные с исправлением дефектов и обслуживанием, оптимизировать стратегии тестирования и процессы обеспечения качества. Команды, которые успешно перестроили свои процессы, сообщают о существенном сокращении времени релиза при одновременном повышении качества продукта.

Российские компании демонстрируют успешные результаты адаптации. Например, в Авито команда научилась концептуально определять необходимую проверку, автоматизировать её и затем интегрировать кейсы в систему хранения. В Яндексе система управления тестами помогла минимизировать человеческий фактор и исключить устаревание тест-кейсов. Команда WASD.TV из МТС Digital, в свою очередь, наладила четкий процесс тестирования в рамках Agile-спринтов, обеспечивая своевременную обратную связь и гибкое планирование задач.

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

Многие компании приходят к выводу, что привлечение внешних QA-экспертов позволяет значительно ускорить адаптацию и избежать типичных ошибок. Профессиональные команды комплексного тестирования программного обеспечения имеют готовые процессы интеграции в Agile-среду, отработанные инструменты автоматизации и опыт работы с различными технологическими стеками. Это позволяет получить результат быстрее и с меньшими рисками, чем при самостоятельном выстраивании процессов.

Ключевые принципы, подтвержденные реальными кейсами российских компаний Авито, МТС Digital и Яндекса, демонстрируют, что правильная интеграция тестирования в Agile-процессы может кардинально улучшить результаты проектов.