Процесс Канбан-Тестирования

Здравствуйте, меня зовут Лилия, я QA TeamLead финансовой торговой площадки Одобрим.

ру.

Наша команда не разделена на разработку и поддержку, и мы работаем по Канбану.

Эта методология позволяет нам объединить поддержку (т. е.

задачи, которые появляются неожиданно и требуют срочного завершения) и невыполненные задачи, которые планируются заранее.

Процесс тестирования является частью процесса разработки.

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

Для этого мы стремимся постоянно его совершенствовать.

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

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

По мере выполнения задач в процесс тестирования вносятся изменения методом PDCA (это аббревиатура, образованная словами Планируй-Делай-Проверяй-Действуй (также известный как цикл Деминга):

1. Планируйте эксплуатационные изменения или испытания для улучшения.

2. Сделай это.

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

3. Изучать.

   Изучите результаты.

   Что мы узнали?

4. Действовать.

   Внесите изменения или отмените их.

   Повторите цикл, возможно, в меняющейся внешней среде.

При появлении на задаче срочной задачи или блокировщика вы можете вернуть ее в бэклог и взяться за задачу с более высоким приоритетом в данный момент. В Канбане есть daily — ежедневное обсуждение, которое осуществляется путем рассмотрения задач, а не работы конкретных людей, как в Scrum. Обсуждение начинается с самого главного - правого столбца, затем переходим влево, отвечая на вопрос.

«Что нам мешает перенести задачу в следующий столбецЭ» .

Самые ценные задачи находятся на правой стороне.

Итак, давайте приступим к делу процесс тестирования : У нас есть несколько тестовых стендов, а также стенды для тестирования новых функций.

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

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

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

1. При работе над задачей на этапе подготовки или на этапе реализации QA пишет чек-лист проверок функционала, находящегося на этапе внедрения/обсуждения.

2. Когда Bug (ошибка)/Task (задача) на канбан-доске переходит в статус Verify, тестировщик назначает задачу себе, чтобы ее не взял на себя другой тестировщик.

   Проверка осуществляется на стенде Feature (отдельный стенд для разработчика) или dev-стенде (общий стенд разработки), который указан в Bug (ошибки)/Task (задачи).

   Если ничего не указано, нужно посмотреть прикрепленный merge_requests и по нему определить, где размещен код.

3. При обнаружении ошибок в процессе проверки задача переводится в статус Reopen с указанием комментария + принтскрина + шагов воспроизведения (при необходимости) + логов (при необходимости).

4. 4. Если в процессе проверки ошибок не выявлено, то:
   • Тестовый сценарий/тестовые случаи добавляются в TestRail (систему управления тестовой документацией).

   • Проверяемый Баг (ошибки)/Задача (задачи) переводится в статус Бизнес-приемка (принятие бизнес-заказчиком).

5. После проверки бизнес-заказчиком задача переходит в статус Выполнено.

   Если бизнес-заказчик передает задачу в Reopen, цикл тестирования повторяется.

   
   
   
   
   

6. После появления более 4-х Bug (ошибок)/Task (задач) в статусе Done (готово) разработчики выкладывают релиз-кандидат на UAT - приемочный стенд.
7. Проводится дымовое тестирование по чек-листу и запускаются автоматические тесты регрессионного тестирования.

8. Баг (ошибки)/Задачи (задачи) проверяются в Статусе Релиза (задача готова к выпуску), включены в релиз-кандидат на УАТ - приемочный стенд.
9. После проверки Bug(ошибок)/Task(задач) переводим его в статус Closed.
10. Проверяем мобильную версию.

    устройства – Android, iOS (особое внимание уделяем верстке).

11. Если при проверке релиз-кандидата не обнаружено ошибок со статусами Blocker (блокировка) и Critical (критический), то релиз-кандидат размещается на PREPROD (предварительный стенд) разработчиком/DevOps.
12. На ПРЕПРОДе (подготовочном стенде) проверяется функционал, отключенный на УАТ (приемочном стенде).

    Если все хорошо, то показ происходит на ПРОДЕ (стойке товара).

13. После получения сообщения о выпуске кандидата на ПРОД QA (команда тестирования) проводит дымовое тестирование (быструю проверку основного функционала) на промышленной схеме.

• Привязка Dhcp К Dns

  19 Oct, 24

• Blackbox — Генератор Исходного Кода (Java, C#, C) Для Обработки Двоичного Протокола Вашего Распределенного Приложения.

  19 Oct, 24

• Специальный Шрифт Для Поиска Ошибок После Ocr

  19 Oct, 24

• Talkpad Изнутри

  19 Oct, 24

• Qt Для Мобильной Кроссплатформенной Разработки

  19 Oct, 24

• Иллюзия

  19 Oct, 24

• Golden Site Раздал Слонов Лучшим Интернет-Проектам

  19 Oct, 24

• Бренды Информационных Агентств — Самые Упоминаемые В Рунете

  19 Oct, 24

• Быстрая И Большая Sdhc-Карта От Sandisk

  19 Oct, 24

• Презентовать Свой Стартап, Не Выходя Из Дома? Легко!

  19 Oct, 24