Привет, меня зовут Лилия, я QA TeamLead в финансовом маркетплейсе Одобрим.ру.
У нашей команды нет разделения на разработку и поддержку, и мы работаем по Kanban. Данная методология позволяет нам совмещать поддержку (т.е. задачи, которые появляются неожиданно и которые нужно выполнить срочно) и задачи из бэклога, которые запланированы заранее.
Процесс тестирования является частью процесса разработки. Он должен быть эффективен для того, чтобы не задерживать выпуск готового функционала в продуктивную среду. Для этого мы стремимся его постоянно совершенствовать.
Для правильной оценки эффективности процесса тестирования и его улучшения, он должен быть описан и доведен до сведения команды. Описание процесса тестирования помогает сделать процесс тестирования понятным и прозрачным для всей команды и снизить количество неопределенности в повседневной работе. В ходе выполнения задач в процесс тестирования вносятся изменения по методу PDCA (это аббревиатура, образованная словами Plan-Do-Check-Act, также известная как Цикл Деминга):
Для визуализации процесса разработки используется доска в Jira, в каждой колонке есть лимит по задачам, одновременно взятым в работу. При появлении срочной задачи или блокера по задаче, ее можно вернуть в бэклог и взять более приоритетную задачу в данный момент.
В Kanban есть daily — ежедневное обсуждение, которое проводят, рассматривая задачи, а не работу конкретных людей, как в Scrum. Начинается обсуждение с самой важной – правой колонки, затем переходим левее, отвечая на вопрос “Что нам мешает передвинуть задачу в следующую колонку?”. Самые ценный задачи находятся в правой части.
Итак, перейдем к самому процессу тестирования:
У нас есть несколько тестовых стендов, а также фича-стенды, где происходит тестирование нового функционала. Тестирование срочных задач происходит на фича-стенде с последующей выкладкой в прод.
Для запланированных задач карточки с задачами/багами переходят с левой части в правую.
По шагам это происходит следующем образом:
P.S. Если у Вас возникли вопросы по процессу тестирования, с удовольствием отвечу на Ваши вопросы в комментариях!
У нашей команды нет разделения на разработку и поддержку, и мы работаем по Kanban. Данная методология позволяет нам совмещать поддержку (т.е. задачи, которые появляются неожиданно и которые нужно выполнить срочно) и задачи из бэклога, которые запланированы заранее.
Процесс тестирования является частью процесса разработки. Он должен быть эффективен для того, чтобы не задерживать выпуск готового функционала в продуктивную среду. Для этого мы стремимся его постоянно совершенствовать.
Для правильной оценки эффективности процесса тестирования и его улучшения, он должен быть описан и доведен до сведения команды. Описание процесса тестирования помогает сделать процесс тестирования понятным и прозрачным для всей команды и снизить количество неопределенности в повседневной работе. В ходе выполнения задач в процесс тестирования вносятся изменения по методу PDCA (это аббревиатура, образованная словами Plan-Do-Check-Act, также известная как Цикл Деминга):
- Планируй изменения в работе или испытания, направленные на улучшение.
- Делай. Опробуйте запланированные действия на небольшом по своему значению участке работы.
- Изучай. Изучай результаты. Что нам удалось выяснить?
- Действуй. Внедряй изменения или отменяй их. Повторяй цикл, возможно, в условиях меняющейся внешней среды.
Для визуализации процесса разработки используется доска в Jira, в каждой колонке есть лимит по задачам, одновременно взятым в работу. При появлении срочной задачи или блокера по задаче, ее можно вернуть в бэклог и взять более приоритетную задачу в данный момент.
В Kanban есть daily — ежедневное обсуждение, которое проводят, рассматривая задачи, а не работу конкретных людей, как в Scrum. Начинается обсуждение с самой важной – правой колонки, затем переходим левее, отвечая на вопрос “Что нам мешает передвинуть задачу в следующую колонку?”. Самые ценный задачи находятся в правой части.
Итак, перейдем к самому процессу тестирования:
У нас есть несколько тестовых стендов, а также фича-стенды, где происходит тестирование нового функционала. Тестирование срочных задач происходит на фича-стенде с последующей выкладкой в прод.
Для запланированных задач карточки с задачами/багами переходят с левой части в правую.
По шагам это происходит следующем образом:
- При работе над задачей на этапе грумминга или на этапе реализации QA пишет чек-лист проверок для функционала, который находится на этапе реализации/обсуждения.
- При переходе Bug (ошибки)/Task (задачи) по доске Kanban в статус Verify(проверка) тестировщик назначает задачу на себя, чтобы ее не взял в работу другой тестировщик.
Проверка производится на фича стенде (отдельный стенд для разработчика) или dev стенде (общий стенд разработки), который указан в Bug (ошибки)/Task (задачи). В случае, если ничего не указано, нужно посмотреть приложенный merge_requests и по нему определить, куда выложен код. - Если в процессе проверки обнаружены ошибки, то задача переводится в статус Reopen (переоткрыта) c указанием комментария + принтскрин + шаги воспроизведения (по необходимости) + логи (по необходимости).
- 4. Если в процессе проверки ошибок не выявлено, то:
- В TestRail (система управления тестовой документацией) добавляется тестовый сценарий/тест кейсы.
- Проверяемая Bug (ошибки)/Task (задачи) переводится в статус Business acceptance (приемка бизнес-заказчиком).
- После проверки бизнес-заказчиком задача переходит в статус Done(готово). В случае, если бизнес-заказчик переводит задачу в Reopen(переоткрыта), цикл тестирования повторяется.
- После появления в статусе Done (готово) более 4-х Bug (ошибки)/Task (задачи), разработчики производят выкладку релиз кандидата на UAT — приемочный стенд.
- Проводится смок тестирование по чек-листу и запускаются автотесты регресс тестирования.
- Проверяются Bug (ошибки)/Task (задачи) в статусе Release (задача готова к релизу), вошедшие в релиз-кандидат на UAT — приемочный стенд.
- После проверки Bug (ошибки)/Task (задачи) переводим в статус Closed (закрыта).
- Проверяем версию на моб. устройствах — Android, iOs (особое внимание уделяем верстке).
- Если багов со статусом Blocker (блокирующая) и Critical (критическая) при проверке релиз-кандидата не обнаружено, то релиз-кандидат выкладывается на PREPROD (препрод стенд) разработчиком/DevOps.
- На PREPROD (препрод стенд) проверяется выключенный на UAT (приемочном стенде) функционал. Если все хорошо, то происходит выкладка на PROD (прод стенд).
- После получения сообщения о выкладке релиз кандидата на PROD, QA (команда тестирования) производит смок тестирование (быстрая проверка основного функционала) на промышленном контуре.
P.S. Если у Вас возникли вопросы по процессу тестирования, с удовольствием отвечу на Ваши вопросы в комментариях!
