Home

Оригинальная публикация

Привет, меня зовут Лилия, я QA TeamLead в финансовом маркетплейсе Одобрим.ру.
У нашей команды нет разделения на разработку и поддержку, и мы работаем по Kanban. Данная методология позволяет нам совмещать поддержку (т.е. задачи, которые появляются неожиданно и которые нужно выполнить срочно) и задачи из бэклога, которые запланированы заранее.

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

Для правильной оценки эффективности процесса тестирования и его улучшения, он должен быть описан и доведен до сведения команды. Описание процесса тестирования помогает сделать процесс тестирования понятным и прозрачным для всей команды и снизить количество неопределенности в повседневной работе. В ходе выполнения задач в процесс тестирования вносятся изменения по методу PDCA (это аббревиатура, образованная словами Plan-Do-Check-Act, также известная как Цикл Деминга):

1. Планируй изменения в работе или испытания, направленные на улучшение.
2. Делай. Опробуйте запланированные действия на небольшом по своему значению участке работы.
3. Изучай. Изучай результаты. Что нам удалось выяснить?
4. Действуй. Внедряй изменения или отменяй их. Повторяй цикл, возможно, в условиях меняющейся внешней среды.

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

В Kanban есть daily — ежедневное обсуждение, которое проводят, рассматривая задачи, а не работу конкретных людей, как в Scrum. Начинается обсуждение с самой важной – правой колонки, затем переходим левее, отвечая на вопрос “Что нам мешает передвинуть задачу в следующую колонку?”. Самые ценный задачи находятся в правой части.



Итак, перейдем к самому процессу тестирования:

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

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



По шагам это происходит следующем образом:

1. При работе над задачей на этапе грумминга или на этапе реализации QA пишет чек-лист проверок для функционала, который находится на этапе реализации/обсуждения.
2. При переходе Bug (ошибки)/Task (задачи) по доске Kanban в статус Verify(проверка) тестировщик назначает задачу на себя, чтобы ее не взял в работу другой тестировщик.
   
   Проверка производится на фича стенде (отдельный стенд для разработчика) или dev стенде (общий стенд разработки), который указан в Bug (ошибки)/Task (задачи). В случае, если ничего не указано, нужно посмотреть приложенный merge_requests и по нему определить, куда выложен код.
3. Если в процессе проверки обнаружены ошибки, то задача переводится в статус Reopen (переоткрыта) c указанием комментария + принтскрин + шаги воспроизведения (по необходимости) + логи (по необходимости).
4. 4. Если в процессе проверки ошибок не выявлено, то:
   
   
   • В TestRail (система управления тестовой документацией) добавляется тестовый сценарий/тест кейсы.
   • Проверяемая Bug (ошибки)/Task (задачи) переводится в статус Business acceptance (приемка бизнес-заказчиком).
5. После проверки бизнес-заказчиком задача переходит в статус Done(готово). В случае, если бизнес-заказчик переводит задачу в Reopen(переоткрыта), цикл тестирования повторяется.
   
   
6. После появления в статусе Done (готово) более 4-х Bug (ошибки)/Task (задачи), разработчики производят выкладку релиз кандидата на UAT — приемочный стенд.
7. Проводится смок тестирование по чек-листу и запускаются автотесты регресс тестирования.
8. Проверяются Bug (ошибки)/Task (задачи) в статусе Release (задача готова к релизу), вошедшие в релиз-кандидат на UAT — приемочный стенд.
9. После проверки Bug (ошибки)/Task (задачи) переводим в статус Closed (закрыта).
10. Проверяем версию на моб. устройствах — Android, iOs (особое внимание уделяем верстке).
11. Если багов со статусом Blocker (блокирующая) и Critical (критическая) при проверке релиз-кандидата не обнаружено, то релиз-кандидат выкладывается на PREPROD (препрод стенд) разработчиком/DevOps.
12. На PREPROD (препрод стенд) проверяется выключенный на UAT (приемочном стенде) функционал. Если все хорошо, то происходит выкладка на PROD (прод стенд).
13. После получения сообщения о выкладке релиз кандидата на PROD, QA (команда тестирования) производит смок тестирование (быстрая проверка основного функционала) на промышленном контуре.