Едем в продакшн! Тестировать будем потом (с)

Как уже писала, я Светлана, QA-специалист SimbirSoft. В этом году я подключалась на аутстаф к одному из проектов по разработке Web-приложения. Документация оставляла желать лучшего: не дописана, давно не актуализировалась, а правки по задачам обсуждались в личной переписке с членами команды. Но такое бывает, я эксперт, поэтому должна привести всё в порядок, а также указать на пробелы в процессе и помочь их исправить.

Интересное началось дальше – до релиза две недели, backend был готов, а frontend спешно доделывали и пытались успеть к сроку. В итоге на тестирование осталось минимум времени и исполняющий обязанности менеджера проекта принял решение – выпускать в релиз «как есть» и тестировать уже на проде. Все наши совместные с инхаус-командой клиента призывы перенести релиз не увенчались успехом. Ну что? – Баг на проде.

Здесь нужно пояснить, что у каждого релиза на проекте были очень жесткие сроки, которые пристально контролировались бизнесом. А также проектом управлял не профессиональный проджект-менеджер, а временно заменяющий его человек. Нашему PM пришлось отключиться от работы на некоторое время из-за форс-мажора. Возможно, именно поэтому всё так сложилось.

✔ Как должен был выглядеть правильный сценарий выпуска этого релиза со стороны тестирования? QA-специалиста важно было подключать к каждому этапу разработки продукта:

— проанализировать техническое задание;

— настроить процессы работы на проекте;

— подобрать верные стратегии и методы тестирования;

— провести исследование продукта;

— ведение всей тестовой документации и ее поддержание в актуальном состоянии;

— ❗провести полное тестирование продукта до его релиза и после.

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

К чему пришли с клиентом?

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

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

Пересмотрели свой подход к написанию кейсов. Например, при регистрации клиент должен указать свой возраст. Поле имеет ограничения по количеству символов — не более 3-х знаков. Для проверки всех возможных комбинаций нужно более 1000 кейсов. Чтобы упрощать такие ситуации, мы создали тест-анализ, анализ рисков и приоритезацию проверок. Это позволило нам сократить количество тестов, не снижая качество продукта.

Какие выводы можно сделать?

Самое главное – подключение QA на каждом этапе снизит риски и затраты. Вот, например, что дало тестирование нашему проекту:

1. Снизили риски появления дефектов в системе на ранних этапах разработки. Так, процент багов с 44% сократился до 5%. Здесь мы говорим о тестировании технического задания и макетов, а также про тестирование backend-части до появления frontend.

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

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

1. У всей команды изменилось отношение к процессу тестирования и самое главное — пришло осознание его важности.
2. Поняли, насколько важно подключать аналитика на этапе составления технического задания. А также, что нужно тестировать эти требования, так как это влияет на эффективность работы всей команды.
3. Улучшились коммуникации на проекте: команда стала более дружной и понимающей работу каждого специалиста.
4. В итоге все доработки по продукту мы выпустили раньше, чем ожидал бизнес. И всё работало отлично – приложение выполняло все требования без дефектов на 99,9%. Почему не 100%? У пользователя всегда найдется тот редкий кейс, о котором мы и подумать не могли. И это нормально 😉

Ну и напоследок:

«Программа, которая не тестировалась, не является рабочей» – Bjarne Stroustrup.