Как выстроить процессы QA с нуля в продукте, где тестирования не было вообще

Smoke-тестирование

Ручное тестирование

Регрессионное тестирование

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

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

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

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

Как работали процессы до внедрения QA

До внедрения QA анализ требований сводился к двум основным сценариям:

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

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

Другие проблемы, которые мы увидели:

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

Этот опыт показал: чтобы улучшить качество, нужно не просто «начать тестировать», а выстроить сквозной процесс QA – от постановки задачи до выхода в прод. Как мы этого добились – рассказываем дальше.

Поэтапное внедрение процессов тестирования

QA начинается с диалога: как мы собирали требования внутри команды

Даже в уже работающем проекте внедрение QA началось с комплексного сбора и анализа требований. Для этого было налажено взаимодействие с текущими сотрудниками, которые исполняли роли обеспечения качества:

продакт-менеджерами (узнали приоритеты бизнеса);
специалистами поддержки (узнали о частых жалобах пользователей и проблемных местах).

Нефункциональные требования: поддержка нескольких языков

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

Анализ в помощь дизайну

Дизайн дополнился анализом и документированием требований – этот симбиоз создал четкие ориентиры для разработчиков и устранил неопределенность на этапе приемочного тестирования.

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

Ручное тестирование: с чего мы начинали

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

Процессам приемочного тестирования теперь предшествовало функциональное, что значительно сократило число возвратов на этапе приемки.

Стандартизация описания дефектов уменьшила неопределенность в процессе их устранения.

Smoke-тестирование: первый шаг к автоматизации и стабильности

Внедрение smoke-тестов для быстрой проверки работоспособности системы и регулярного регрессионного тестирования позволило:

сократить время обнаружения критических дефектов
предотвратить появление старых ошибок в новых версиях
оптимизировать процесс тестирования при частых релизах.

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

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

Для обсуждения сотрудничества пишите нам на aloha@7bits.it — будем рады создать для вас инновационное и технологичное решение!

Итоги