Привет, Хабр! Меня зовут Анфиса Одинцова, я — наставница в Яндекс Практикуме на курсе «Инженер по тестированию». Сейчас работаю в JoomPay, а раньше — в Яндекс Дзене и ВК. В этой статье разберём, что такое гибкая модель разработки и какова в ней роль тестировщика на каждом этапе создания продукта.
Современная индустрия производства программного обеспечения всё чаще прибегает к использованию гибких методологий разработки. В последние годы эти методологии стали широко распространены и продолжают набирать популярность.
В гибкой модели разработки ПО роль тестировщиков отличается от линейной модели.
В линейной тестировщики специализируются на фазе тестирования после завершения разработки, уделяют большее внимание документации и могут быть менее вовлечены в ранние стадии производства продукта.
В гибкой модели они:
проводят раннее и непрерывное тестирование,
активно участвуют во всех этапах разработки,
работают в команде с другими участниками проекта,
адаптируются к изменениям требований.
Акцент в гибких методологиях сделан на итеративность, коллаборации и быстрое реагирование на изменения требований. Для тестировщика важно иметь глубокое понимание функциональности, дизайна и потенциальных рисков разрабатываемого продукта, поэтому тестировщик начинает работать с продуктом или фичей в самом начале создания.
Что делает тестировщик на каждом этапе гибкой разработки
Разберемся, как раннее тестирование устроено на практике, в какой момент стоит подключить тестирование, какой вклад может внести тестировщик и как построить свою работу внутри каждого этапа.
Этапы могут меняться в зависимости от методологии разработки, но основными являются:
Анализ (требований или фичи)
Планирование
Дизайн
Разработка
Тестирование
Запуск
Давайте разберём, что входит в задачи тестировщика на каждом из этих этапов.
Этап 1. Анализ
Команда уточняет требования у заказчика или менеджера, идет активное обсуждение задачи, и команда разработки старается полностью понять ожидания от продукта. Они задают вопросы, уточняют детали и участвуют в обсуждениях. Что делает тестировщик:
Определяет причастных к проекту. Нужно понять, кто является заказчиком продукта, кто из разработки будет реализовывать задачи, кто является менеджером и есть ли завязанные на проекте смежные сервисы или команды. Определяет, будет ли функциональность пересекаться с другими частями сервиса и с другими членами команды тестирования. Это нужно, чтобы быстро решать возникающие вопросы, уточнять детали и чинить баги.
Определяет цели фичи или продукта. Важно выявить, какие основные цели, чтобы правильно приоритизировать и распределить работу на следующих этапах.
Изучает требования к системе или продукту. Тестировщик собирает всё описание продукта — требования, спецификации, описания архитектуры и интеграции. В их числе функциональные и нефункциональные требования, бизнес-правила и ограничения. На этапе анализа важно собрать и изучить всю начальную документацию и информацию о продукте.
Анализирует и визуализирует требования, чтобы определить потенциальные проблемы или несоответствия. Нужно проверить, что требования полные, однозначные, достижимые и соответствуют ожиданиям заказчика. Тестировщик изучает уже существующие требования и выделяет серые зоны. На данном этапе стоит применить техники тест-анализа.
Участвует в обсуждениях и делится обратной связью. QA принимает участие в обсуждениях требований для их уточнения и выявления потенциальных проблем. Тестировщик может предвидеть невозможность реализации или противоречия с уже существующими фичами. Поэтому на этом этапе ему важно принимать участие в грумминге и давать обратную связь команде.
Начинает составлять тестовую документацию. На этапе анализа тестировщик может начать писать тестовую документацию: составлять чек-листы и тест-кейсы, применяя техники тест-дизайна для декомпозиции требований.
Этап 2. Планирование
Команда разработки и менеджер продукта совместно расписывают задачи и составляют план, когда будет реализована каждая часть продукта.
QA отвечает за следующие моменты:
Приоритизирует задачи по тестированию и определяет, как связаны задачи между собой, смотрит на все зависимости между частями разработки.
Определяет сроки тестирования и закладывает время на проверки фич, исходя из задач на спринт.
Планирует редактирование и написание тестовой документации. Чтобы после релиза фича была покрыта проверками в ручном регрессе.
Планирует время и задачи на автоматизацию тестовых сценариев, чтобы повысить скорость и эффективности регрессионного тестирования. Например, сразу заводит задачу на автотестирование для себя или для разработчика.
Этап 3. Дизайн
Команда разрабатывает архитектуру приложения и рисует макеты, правит их и согласует с менеджером или заказчиком. В чём задача инженера по тестированию:
Анализирует дизайн. Тестировщик может принять участие в этом процессе и предложить идеи относительно тестируемости и удобства использования предлагаемых дизайн-решений. Также стоит запросить недостающие макеты и подсветить серые зоны в дизайне.
Изучает архитектуру приложения, чтобы понимать, как и из чего строится продукт.
Дополняет тестовую документацию и редактирует её в случае необходимости.
Этап 4. Разработка
Команда разработчиков берёт задачи из списка, создает необходимый код и функциональность продукта. Тестировщик на этом этапе занимается следующими задачами:
Делится документацией с разработчиками, чтобы убедиться, что ожидания от продукта у тестировщика и программистов одинаковые. Это может упростить процесс разработки и предусмотреть реализацию неочевидных пользовательских сценариев, а также помочь при отсутствии полных требований к проекту.
Настраивает и запрашивает необходимое для тестирования окружение. Тестер оценивает, какие тестовые данные и окружения нужны будут для проведения быстрой проверки на этапе тестирования, и заранее запрашивает их у разработки или смежников.
Создает базу знаний о продукте, пока он находится в разработке. В будущем это позволит не потерять важную информацию о новых фичах и эффективно работать с ними.
Этап 5. Тестирование
После завершения разработки тестировщик проводит проверку фичей, отладку и репортинг багов. Вот что делает QA:
Тестирует фичу. QA использует все знания и информацию, которую получил и составил на предшествующих этапах.
Отлаживает и репортит баги. При обнаружении ошибки она воспроизводится, а её подробное описание отправляется разработчикам. Это помогает последним устранить проблему
Анализирует причины появления багов и предлагает способы их устранения.
Проводит ретест исправленных ошибок. Нужно убедиться, что проблемы были успешно решены и исправления не привели к возникновению новых багов.
Оценивает и выносит решение, можно ли включить фичу в релиз.
Проводит регрессионное тестирование всей функциональности и оценку релиза.
Этап 6. Запуск
На этом этапе разработчики выкатывают релиз или включают проект в продакшене. Команда проводит демо и ретроспективу, в которых презентует результат работы и обсуждает, что в спринте прошло хорошо, что можно усовершенствовать, с какими проблемами столкнулись. На этом этапе тестировщик занимается следующим:
Проводит смоук-тестирование на продакшене. Оно помогает воспроизвести сценарии, доступные только на проде, или проверить правильность включенных экспериментов, если фича экспериментальная.
Наравне с командой следит, что фичи в продакшене дошли до пользователя в соответствии с ожиданиями.
Участвует в презентации продукта — демонстрирует работу фичи смежным командам, коллегам и заказчику, рассказывает и отвечает на вопросы о реализации фичи.
Подводит итоги работы тестирования в спринте: выявляет проблемы и отмечает достижения.
Новый цикл разработки
После завершения одной итерации разработки команда приступает к следующей, повторяя описанные выше этапы. Итерации могут включать в себя и другие этапы, в зависимости от продукта и команды, но участие тестировщика в каждом из них поможет в повышении и поддержании качества продукта.
Заключение
Наличие тестировщика на каждом этапе позволяет обнаруживать дефекты и проблемы на ранних стадиях разработки. Это помогает снизить затраты на исправление ошибок, ускорить разработку и тестирование, а также помочь разработчикам сосредоточиться на написании кода и снизить количество багов.
Для самого QA погружение в продукт с самого начала дает возможность отлично знать свой продукт, как он работает, его цели и ожидания от него. Также это даст возможность обнаружить баг и предусмотреть все риски задолго до начала процесса разработки и тем самым уменьшить количество времени на исправление дефектов и ретест.