Девпром: опыт внедрения процесса контроля качества

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

Можно определить следующую классификацию процессов, внедренных в Devprom (см. рисунок ниже):

• Тестирование новой функциональности.
• Работа с обнаруженными ошибками.
• Работа с задачей типа «Тестирование».

	Процессы контроля качества
Тестирование новой функциональности	Работа с обнаруженными ошибками	Работа с задачей типа «Тестирование»

Тестирование новой функциональности

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

Предварительные действия

1. Разработка новой функциональности выполняется в рамках задачи типа «Разработка». При создании новой задачи:

a. Задаче присваивается статус «Добавлена».

b. Задача связывается с пожеланием, номером итерации.

c. Задача назначается исполнителю: руководителю группы разработки (для дальнейшего распределения) или конкретному разработчику, если исполнитель определен.

d. Составляется подробное описание задачи и (или) приводится ссылка на сформированные требования.

2. В момент реализации задачи разработчиком статус задачи меняется на «В работе».

3. В момент передачи задачи в тестирование разработчик выполняет действия:

a. Статус задач меняет на «Деплой на тест».

b. В поле «Ветка задачи» указывает ветку кода.

Действия тестировщика

1. Как только задача перешла в статус «Деплой на тест», тестировщик может развернуть задачу (нужную ветку кода) на тестовом стенде и начать проверку. При этом статус задачи меняется на:

a. «Тестирование в своей ветке», если разработчик внедрил код в отдельную ветку.

b. «Тестирование (Develop)», если разработчик внедрил код в общую ветку разработчиков.

2. По результатам проверки оформляется отчет о результатах тестирования, который оформляется в виде комментария к задаче, где указывается: окружение, тестовые данные, нумерованный список контрольных сценариев с указанием признака корректности, нумерованный список найденных ошибок.

a. Если в задаче найдены ошибки, её возвращают в статус «В работе». После исправления ошибок задача повторно переводится разработчиком в статус «Деплой на тест», после чего тестировщик переводит её в статус, из которого задачу передали на доработку. Отчет с результатами повторной проверки фиксируется ответом на комментарий, где были описаны ошибки. По результатам повторной проверки, если вновь найдены ошибки, задачу возвращают снова в доработку и повторяются действия, описанные в данном пункте.

b. Если принято решение, что обнаруженные ошибки будут вынесены в отдельные задачи с типом «Ошибка» (ошибки низкого приоритета, не относятся к текущей реализации, требуют длительного анализа, сложны в реализации, исправление можно отложить и т.п.), ссылка на новую задачу с типом «Ошибка» указывается ответным комментарием к комментарию с описанием ошибки, а новая задача с типом «Ошибка» указывается в поле «Следующая задача» текущей задачи разработки. При этом текущая задача считается проверенной.

3. Если при тестировании ошибок нет или они вынесены в отдельные задачи, текущая задача разработки переводится далее по статусам, при этом в модуле Devprom «Контроль качества» фиксируется сценарий проверки в виде отдельного сценария или группы сценариев. Следующим статусом задачи может быть:

a. «Деплой на UAT». Используется, если перед развертыванием на продуктовый стенд функциональность планируется проверить на стенде Заказчика. Если задачу развернули на UAT, статус меняется на «Выведено на UAT». После проверки наличия и корректности работы задачи на UAT статус задачи переходит в «Мерж в develop» и далее.

b. «Мерж в develop». Используется для объединения кода в общую ветку разработчиков («Develop») в случае, если задача проверялась тестировщиком в отдельной ветке в статусе «Тестирование в своей ветке». Как только разработчик объединил код по задаче в ветку «Develop», он же меняет статус задачи на «Тестирование (Develop)». После проверки наличия и корректности работы задачи в ветке «Develop» тестировщик меняет статус задачи на «Деплой на master» и дает команду разработчику объединить задачу в ветку «Master».

c. «Деплой на master». Используется, если задачу проверили в общей ветке разработчиков, и она готова к переносу на продуктовый стенд. Как только разработчик объединил ветку «Develop» в ветку «Master», статус задачи не меняется. Команда тестирования выполняет smoke-тест всего продукта, в особенности обновлений. Статус задачи после проверки на наличие и корректную работу в ветке «Master» переводится в «Протестировано в master».

4. Когда все задачи проверены, smoke-тест завершен, происходит развертывание текущей версии системы в продуктовую среду. По результатам проверки в продуктивной среде статус задачи устанавливается в «Выполнена».

Работа с обнаруженными ошибками

В случае принятия решения выделить ошибки, обнаруженные на этапе тестирования новой функциональности, в отдельные задачи с типом «Ошибка», тестировщик работает с этими артефактами следующим образом:

1. При обнаружении ошибки создается задача с типом «Ошибка», статус «Добавлена».

2. С задачей связывается тестовый сценарий, пожелание; указывается итерация, исполнитель, подробное описание сценария для воспроизведения ошибки; прикрепляются скриншоты, видеозаписи, лог-файлы.

3. Далее работа с задачей типа «Ошибка» выполняется алгоритму задачи с типом «Разработка» (см. раздел Тестирование новой функциональности).

4. Если после создания задачи с типом «Ошибка» выясняется, что сценарий работы функциональности, описанный в задаче, является корректным, тип задачи заменяется на «Не баг», задача не удаляется из системы, а переходит в статус «Выполнена».

Работа с задачей типа «Тестирование»

Задача типа «Тестирование» создается с целью тестирования функциональности, для которой нет задачи с типом «Разработка» или «Ошибка», или для проведения smoke-тестирования.

1. Задача создается в статусе «Добавлена», при этом указывается исполнитель, итерация, описание задачи. В поле «Тестовая документация» указываются тестовые сценарии из раздела Devprom «Контроль качества». Важными статусами данного типа задачи являются «В работе» и «Выполнена». 

2. Внутри задачи в комментариях указываются проверенные сценарии, при этом отмечается их корректность, перечисляются найденные ошибки. Ответом на комментарий указывается исправление ошибок либо ссылка на задачу, в рамках которой ошибка будет исправлена. 

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

Авторы: Пасько Е., Сафин П.

Оригинал статьи