Синергия ручных проверок и автоматизации: как мы улучшили тестирование и ускорили запуск продуктов

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

Меня зовут Катя Сергеева, я старший инженер тестирования в компании 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. Присоединяйтесь?.

Что еще почитать в блоге:

• Что нового слышно о шине CXL: заметки с саммита по вычислениям, памяти и хранению данных

• Математика прекрасного. Как создать красивую картинку, если ты дилетант, художник или нейросеть?

• Зачем нужна R&D-команда: взгляд разработчика