Представьте, что вы попали в новую команду QA и вам нужно навести порядок в процессах. Если коллеги пользуются системой управления тестированием, то она может стать источником ценной информации об ошибках и проблемах, с которыми сталкиваются тестировщики.
Читайте, по каким признакам можно определить точки роста для команды, и проверяйте себя, если вы уже пользуетесь DoQA.
Тестовая документация давно не обновлялась
Если продукт развивается, релизы есть, а тестовая документация по фичам не появляется, то это проблема, потому что команда очевидно не успевает покрывать тестами растущую функциональность.
Плеер прогонов неактивный
Время на написание тест-кейсов выделяется, а на их прохождение — нет. Это прослеживается по плееру прогонов в системе управления тестированием. Прогоны могут либо вообще отсутствовать, либо быть начатыми, но не выполненными до конца из-за неактуальности или недостаточности документации.
Наличие «сломанных» тест-кейсов в прогонах
Это говорит о том, что тест-кейсы неправильно написаны либо структурированы, и в момент прохождения у тестировщиков возникают к ним вопросы. Обилие сломанных тестов также показывает, что они не актуализируются своевременно.
Тест-кейсы слишком длинные
В идеале каждый тест-кейс должен быть атомарным и выполнять проверку, описанную достаточным, но не избыточным количеством шагов. Частый признак избыточности — добавление в кейс предусловий под видом шагов. Еще один вариант — излишнее дробление простых действий. Количество шагов в тест-кейсе зависит от проекта, главное, придерживаться правила «один тест-кейс — одна проверка»
Отсутствие разграничений уровней доступа
Доступ всех специалистов команды к просмотру и редактированию всех сущностей в TMS — серьезный фактор риска. У каждого сотрудника должен быть только тот уровень доступа, который необходим для выполнения задач, а сами уровни следует периодически актуализировать и пересматривать.
Неясная структура документации и затрудненная навигация по ней
В этом случае важно разложить все по полочкам. В TMS есть ряд инструментов, которые помогают это сделать — можно изолировать документацию разных команд в рамках отдельных проектов или рабочих пространств, выстроить дерево папок в соответствии с логикой проекта, навесить теги на тесты. Нужные документы легко ищутся при помощи поиска и фильтров.
Тест-кейсы неоднородны
Если один тестер пишет короткие функциональные тесты, а второй — подробные, прикладывая макеты и т.д., то, вероятно, в команде тестирования нет регламентов, которые описывают создание тест-кейсов, и процесс не стандартизирован.
В тест-кейсах не хватает информации
В идеале при открытии тест-кейса в TMS специалист должен сразу получать всю необходимую информацию (ссылки на требования, ТЗ, макеты, необходимые доступы и тестовые данные). Если данные приходится искать в других местах и дергать коллег, то это красный флаг.
Большие объемы проверок проводятся за небольшое количество времени
Если за выделенный срок тестировщик физически не мог выполнить указанное количество тестов, то, вероятно, он просто проставил нужные статусы в TMS. За этим нужно следить.
1. Выясните, по каким метрикам работают тестировщики.
Если метрик нет, то первым делом их нужно собрать и проверить, сколько ошибок было пропущено на прод в последних релизах. После нужно выяснить, почему ошибки не были найдены на этапе тестирования. Причина, скорее всего, будет в том, что некоторые требования не были покрыты, либо возникли какие-то другие сложности в процессе тестирования. Эти ошибки и укажут на проблемные места в TMS.
2. Выявите источник проблемы.
Нужно раскрутить цепочку событий до момента возникновения проблемы и понять, почему каждый следующий этап, где ее могли обнаружить, не сработал. После обнаружения причин — продумать, как не допустить повторения ошибки в будущем, например, завести единый для всех регламент ведения тестовой документации в TMS.
3. Попросите нового члена команды поработать в TMS.
По новичкам отлично видно, в каком состоянии находятся процессы. Если при работе в TMS они практически не задают вопросов, сами находят нужные данные внутри системы, понимают, где что находится, и без проблем проходят тест-кейсы, то это хороший знак. Если коллеги постоянно обращаются за помощью, которая связана с TMS, фиксируйте все недочеты ведения системы и добавляйте в бэклог по оптимизации.