Работа с багами
Флоу такое:
- тестировщик что-то тестирует
- описывает баг и как его воспроизвести
- потом задача идет на доработку
- если разработчику не получается воспроизвести по описанному сценарию → баг закрывается и пишется «не удалось воспроизвести»
- потом опять уходит на тестирование и описывается баг
Это не тормозит разработку, что вот есть баг и всеми силами пытаемся его воспроизвести и одновременного дресирует тестеров хорошо (ну это потом ) описывать сразу (как воспроизвести и т.д.). Т.к. это уже их работа, сказать при какой ситуации и действиях возникает баг ) Пока у нас «по лайту» ))
Сейчас принято - кто завел баг, того и просим проверить, после исправления (предоставляем ссылку для проверки)
Программисту желательно использовать информацию о приоритетах что-бы делать разбивку багов на группы для ускорения закрытия затянувшейся задачи, способом выноса части багов в отдельную задачу "Доработки .." или ускорения попадания фиксов релиза в мастер ветку
Работа с Новым функционалом
- После выполнения задача отдается на проверку реализации функционала продуктовому дизайнеру (Максим)
- После этапа правки функциональных багов, задача отдается на кодеревью - программист формирует описание пулла, и запрашивает ревью у программистов следящих за чистотой кода (сейчас Олег Вилков и Женя)
- После этапа правок, программист запрашивает тестирование (сейчас Саша) для того чтобы убедиться что задача не сломалась после правок по ревью, и что задача не поломала другой функционал (программист сам должен стараться следить чтобы задача осталась работоспособна после этапа правок по ревью!)
- Если на этапе тестирования вдруг возникло много правок, задача повторно отдается на кодеревью
- После этапа тестирования, задача закрывается. Помечается "Complete" в Asana, переводится в колонку выполненных, делается merge в master и ветка git удаляется (и ура, программист молодец 🙂)
Тестирование задачи - обязательно
Бывают случаи когда тестировщику протестировать задачу затруднительно, в силу различных обстоятельств.
Например, тестирование задачи по аналитике - передается аналитическому отделу после релиза. В описании задачи необходимо пометить сверху, что-бы после релиза уведомили аналитиков.
Задача функционального плана который трудно проверить (например задачи исполнение которых можно проверить только в консоле), повторно тестируется самим программистом в предрелизе/релизе, либо дается подробное описание как проверить задачу.
Если задача не может быть проверена в предрелизе в силу настроек staging, тогда необходимо сделать пометку об этом в шапке задачи, что особое внимание проверке необходимо уделить после релиза.
Подробности об этом необходимо выделить в верху описания задачи. Например: Важно: при предрелизезе уведомить меня для повторной проверки. Важно: при предрелизезе см. инструкцию(ссылка на подзадачу) по проверки задачи.
Работоспособность всех выполненных задач должна быть проверена.
Общее
Программист следит что-бы задача не разросталась, если программист видит что задача затягивается по каким-то причинам, то старается разбить задачу. Например, вынести какой-то функционал в отдельную задачу (посовещавшись с продуктовым дизайнером), задача без выносимого функционала должна оставаться полноценной, т.е. что-бы после попадания в главную ветку продукта, могла функционировать без выносимого элемента.
В случае с багами, можно вынести группу багов в отдельную задачу, или какой-то сложный баг, который затягивается по каким-то причинам.
Цель программиста что-бы код как можно скорей попадал в ветку git master.
Если программист видит что задача затягивается, но не находит как можно ее разбить, то нужно затронуть эту тему и посовещаться прямо в карточке Asana.