Комментарии 4
Пара вопросов:
По тексту:
Все? Больше ничего не нужно?
Далее, я не совсем понял, а как появляются баги, откуда они берутся и чем отличаются от фичей?
По тексту:
Для правильной оценки эффективности процесса тестирования и его улучшения, он должен быть описан и доведен до сведения команды.
Все? Больше ничего не нужно?
Далее, я не совсем понял, а как появляются баги, откуда они берутся и чем отличаются от фичей?
Сергей, спасибо за вопросы.
Изменяется продукт и другие процессы в проекте и процесс тестирования так же пересматривается. Если он изначально не описан или, что еще хуже, не доведен до команды — нечего улучшать, процесс будет выстраиваться каждый раз как с нуля, без учета ранее решенных проблем или опробованных и не сработавших решений.
Баги появляются в процессе тестирования нового и ранее реализованного функционала.
Бага это ошибка, фича это новый функционал или доработка.
Изменяется продукт и другие процессы в проекте и процесс тестирования так же пересматривается. Если он изначально не описан или, что еще хуже, не доведен до команды — нечего улучшать, процесс будет выстраиваться каждый раз как с нуля, без учета ранее решенных проблем или опробованных и не сработавших решений.
Баги появляются в процессе тестирования нового и ранее реализованного функционала.
Бага это ошибка, фича это новый функционал или доработка.
Интересная статья, спасибо! Буду рад, если вы ответите на несколько вопросов:
1 — Как вы пишете чек-листы пока задача еще находится на обсуждении? Там же измениться поведение может
2 — Как вы обходитесь без отдельной колонки для реопенов? Как понять, что это реопен?
3 — Вы заливаете с Dev на UAT задачи, когда их там ровно 4 шт накапливается? А по суммарному времени проверок это не регламентируется? Т.е. там же может быть 4 мелких фикса на час, а может быть 4 фичи на 4 дня.
1 — Как вы пишете чек-листы пока задача еще находится на обсуждении? Там же измениться поведение может
2 — Как вы обходитесь без отдельной колонки для реопенов? Как понять, что это реопен?
3 — Вы заливаете с Dev на UAT задачи, когда их там ровно 4 шт накапливается? А по суммарному времени проверок это не регламентируется? Т.е. там же может быть 4 мелких фикса на час, а может быть 4 фичи на 4 дня.
1. Составляя чек-листы тестировщик изучает задачу и записывает, какие проверки он будет делать. Если требования поменяются, чек-лист за ним так же меняется.
2. Статус REOPEN существует. Если мы повторно открываем задачу или баг, то он помещается в колонку IN PROGRESS и разработчик после завершения текущей задачи, возвращается к задаче / ошибке со статусом REOPEN.
3. Для нашей команды мы вывели оптимальное количество задач от 4-х, конечно их может быть и больше. По суммарному времени проверок это не регламентируется. Если нужно выкатить одну задачу срочно — мы выкатываем одну задачу.
2. Статус REOPEN существует. Если мы повторно открываем задачу или баг, то он помещается в колонку IN PROGRESS и разработчик после завершения текущей задачи, возвращается к задаче / ошибке со статусом REOPEN.
3. Для нашей команды мы вывели оптимальное количество задач от 4-х, конечно их может быть и больше. По суммарному времени проверок это не регламентируется. Если нужно выкатить одну задачу срочно — мы выкатываем одну задачу.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Процесс тестирования в Kanban