При работе над проектом задавались ли вы хоть раз вопросами: как быть уверенным в качестве покрытия тестами продукта? Как максимально эффективно организовать свою работу и обработку задач? Как подружить ручные проверки и автоматизацию? Если ответ — да, то привет и добро пожаловать под кат!
Меня зовут Катя Сергеева, я старший инженер тестирования в компании Cloud.ru. В статье расскажу, как небольшие изменения в процессе комбинации ручных проверок и автоматизации помогли повысить эффективность тестирования в нашей команде, обеспечить высокое качество продуктов и сократить время их выпуска.
Почему мы решили изменить процесс
При проверке задач, наполнении системы тест-менеджмента тест-кейсами и приоритизации процесса тестирования, у любого QA-лида в проекте нет-нет да появляются вопросы:
как выстроить процесс подсчета тестового покрытия с учетом, что в начале работы уже есть какое-то количество описанных тест-кейсов?
что брать за 100% при сборе статистики? как выявлять пробелы?
что и как стандартизировать? какие паттерны использовать?
как вести документацию и онбордить новых сотрудников?
А ведь в каждом проекте свои особенности и требования: где-то тестирование полностью обеспечивают ручные тестировщики, где-то есть команды автоматизации, где-то смешанные команды, где-то работа ведется фулстеками. И когда ручные тестировщики и автоматизаторы работают вместе, стратегия тестирования нередко становится разрозненной и нечеткой.
В нашей компании достаточно много команд тестирования — каждая работает над своим проектом, но иногда подключается и к смежным. Поскольку на каждом проекте своя специфика, то и в командах тестирования разный состав и процессы. При этом мы придерживаемся единых инструментов тестирования, методологии и правил автоматизации.
На одном из проектов мы внедряли автоматизацию, причем не на начальном этапе. Уже был некоторый набор фич и ручных тест-кейсов, но не было уверенности в полноте покрытия продукта. Мы создавали автотесты, а параллельно возникали все новые ручные сценарии. В какой-то момент в уже написанную автоматизацию нужно было вносить изменения с учетом изменений продукта. Количество вопросов стало возрастать в геометрической прогрессии:
как все держать под контролем, не тратя на это 100% времени? и есть ли на все это время и ресурсы?
достаточно ли только налаженной коммуникации между командами либо внутри команды?
как сделать нашу синхронизацию максимально гладкой и эффективной в условиях использования различных форматов и инструментов тестирования, а возможно и разных подходов?
Стало очевидно — пришло время построить мостик между ручным тестированием и автоматизацией. Мы использовали уже знакомые команде инструменты: текущую внутреннюю систему управления проектами, систему тест-менеджмента Allure TestOps и фреймворк для автоматизации. По сути мы оптимизировали каждый этап в рамках уже устоявшегося рабочего процесса. Расскажу, как это повлияло не только на нашу, но и на другие команды.
Разбираем задачи
Рассмотрим стандартный рабочий процесс: к нам в систему управления проектами попадает задача, мы назначаем исполнителя и занимаемся тестированием, затем оставляем в задаче фидбэк и переводим ее дальше. И тут у нас снова появляются вопросы:
написали ли тест-кейсы сразу или нет? может, передали задачу сразу в автоматизацию?
а если была пачка задач на спринт? была ли возможность обработать все задачи сразу?
и как мы узнаем, что задача точно была обработана и не потерялась? может быть к ней надо будет вернуться, но есть большой шанс забыть об этом...
Как взять процесс под контроль и все это учесть?? Мы приняли решение, которое лежало на поверхности — использовать метки (labels). Мы придумали три варианта меток, которые помогают быстро понять, в каком статусе находится задача:
tests_exist — задача обработана тестировщиком, заведены тест-кейсы в системе тест-менеджмента;
tests_required — нужно написать тест-кейсы по задаче или внести изменения в существующие кейсы;
tests_not_reqiered — тест-кейс для этой задачи не требуется.
Удобно, когда в каждой задаче есть своя метка. С помощью запросов можно отслеживать, насколько полно наше покрытие и быстро находить непроработанные задачи:
Пример запроса по метке tests_required за год:
project = "ProjectName" AND Sprint in closedSprints() AND resolved >= startOfYear() AND type in (Story, Task, Bug) AND labels = tests_required
Чтобы процесс не прерывался, теперь пару раз в спринт ответственный сверяет статистику по меткам и напоминает команде о пробелах. Кстати, эту практику можно ввести и непосредственно в рабочий scrum-процесс.
Создаем тест-кейсы
Какие изменения мы ввели на этапе создания тест-кейсов? Помимо различных практик тест-дизайна решили использовать стиль написания Behavior-Driven Development (BDD) и человеко-читаемый язык Gherkin. Он включает в себя ключевые слова Given, When, Then для описания поведения системы или продукта.
Когда мы начали писать тестовые сценарии на Gherkin, вся продуктовая команда, включая бизнес и разработку, заговорила на одном языке. Это сильно облегчило этап переговоров, на котором идет обсуждение требований и функциональности. Приведу простой пример, как это работает:
Помимо других атрибутов, мы стараемся прикладывать к тест-кейсу ссылку на задачу-исходник в системе управления проектами. Затем с помощью API- системы тест-менеджмента можно создавать интересные выборки для анализа. И теперь мы можем использовать этот формат вне зависимости от того, будут ли тесты автоматизированы в конечном итоге или нет.
Пишем автотесты
Благодаря изменениям на предыдущих шагах, на этапе написания автотестов мы стали опираться на уже созданные тест-кейсы в стиле BDD и заметили, насколько они просто ложатся под логику кода. Независимо от того, какой подход для автоматизации мы использовали — BDD с feature файлами или TDD.
BDD (Given-When-Then) — это по сути тот же паттерн ААА (Arrange-Act-Assert), который нужен при написании кода тестов:
BDD — довольно простой подход, который предполагает: входные данные (нужен ли тесту какой-то объект или настройки), выполняемые шаги (покрывается ли основной функционал) и ожидаемый результат (финальное решение — проходит ли тест или падает). И несмотря на простоту, этот подход очень мощный. Что мы получили в итоге его использования:
сместили фокус на независимость и индивидуальное поведение тестов;
разграничили подготовительные и основные действия — добились порядка и чистоты в коде, логической завершенности, возможности переиспользования шагов;
теперь с помощью тестов мы действительно проверяем функциональность и находим то, что не работает.
Конечно, формулировки шагов могут меняться: какие-то системы тест-менеджмента самостоятельно подтягивают шаги из автоматизации, какие-то этого не делают. В нашем варианте автоматизация переписывает шаги в системе тест-менеджмента. Мы делаем акцент именно на ID тест-кейса и следим, чтобы автоматизация в своем сценарии содержала именно этот ID. Так мы точно уверены, автоматизирован кейс или еще нет. А еще мы придерживаемся унифицированного описания шагов и стараемся использовать одинаковые формулировки.
Итоги и выводы
Итак, что получили мы и другие команды благодаря новому процессу:
стандартизацию тест-кейсов и возможность их переиспользовать;
помощь в устранении дублирования шагов;
более простую поддержку тестовой документации;
командный дух — участники продуктовых команд работают на единой волне и быстрее понимают друг друга;
быстрый поиск пробелов и слабых мест в процессе тестирования;
экономию времени — чем быстрее и эффективнее проверки, тем быстрее выпуск продукта и в работу быстрее попадает новый проект;
эффективный онбординг новичков — теперь нам не нужна отдельная документация, обучение проводим сразу на тест-планах с тест-кейсами и быстро погружаем новичков в регрессию.
А еще мы получили хороший контроль над тестовым покрытием. Думаю, все понимают, что даже обновленный процесс не даст 100% тестовое покрытие, поскольку его процент относится только к тем идеям, которые мы придумали, пока писали кейсы по задачам (ориентируясь на критерии приема работы). Всегда существует что-то, о чем мы еще не подумали. Но когда есть структура и тест-кейсы (или хотя бы чек-листы) — это всегда своего рода приглашение оценить незатронутые и не протестированные области.
В качестве заключения хочу напомнить, что тестирование — это не просто сверка результата с ожидаемым поведением продукта, когда мы знаем или только думаем, что знаем, как все должно работать. Тестирование — это непрерывный процесс исследования, анализа рисков, критического осмысления и качественной подготовки отчетности.
Надеюсь, информация была полезной и побудила вас к размышлениям. Буду рада, если в комментариях вы поделитесь собственными историями и опытом объединения ручного тестирования и автотестов.
А еще больше про наши процессы и внутрянку облачных решений можно послушать 24 октября онлайн и офлайн в Москве на конференции GoCloud Tech. Присоединяйтесь?.
Что еще почитать в блоге: