Всем привет! Меня зовут Елена Поплоухина. Я — один из авторов Youtube‑канала по тестированию «Багаж тестировщика». На канале выходил выпуск про построение процесса ручного тестирования с нуля. Данная статья содержит основную информацию из этого выпуска — 2 общих совета и 6 первых шагов для организации процесса.

Введение

Представим, что вы оказались на новом проекте. Единственным тестировщиком или в команде QA инженеров. Перед вами стоит задача - организовать процесс ручного тестирования. При этом проект находится в одной из стадий:

• Проект только стартует, команда формируется, процессы строятся с нуля;

• Проект уже развивается, выпускаются публичные релизы. Но присутствуют проблемы с качеством.

Возможно, вы чувствуете себя как ежик в тумане. С чего же начать?

Совет 1 - Начните с выяснения проблем и ожиданий от тестирования

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

Не ждите, что коллеги с энтузиазмом возьмутся за дело и подробно опишут проблемы. Лучше заранее подготовить список самых распространенных проблем и отправить его команде в виде опросника.  Для таких опросов хорошо подходят Гугл формы.

Примеры проблем:

• Ошибки в требованиях обнаруживаются на стадии разработки или тестирования фич;

• Значительные затраты времени на коммуникации между членами команды;

• Баги часто не воспроизводятся по описанию. Разработчикам приходится тратить время на общение с тестировщиком для выяснения деталей бага;

• Нет критериев для выпуска текущей версии приложения в прод;

• и т.д.

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

Ожидания от тестирования укажут направление, с которого стоит начать строить процесс тестирования. Например, ожидание «Снизить в 2 раза% возврата багов между QA и Dev» говорит о том, что нужно внедрить шаблоны для багов и согласовать регламент работы с багами.

Совет 2 - Внедряйте улучшения постепенно

По итогам опроса команды вы получите список проблем и определите ожидания от тестирования. Не стоит исправлять сразу все проблемы. Отсортируйте список по важности в зависимости от ожиданий от тестирования. Берите по одной-две проблемы из сформированного списка. Вносите улучшение, анализируйте результаты, при необходимости делайте корректировки процесса. И приступайте к исправлению следующей проблемы. Так по шагам вы выстроите процесс тестирования.

Далее рассмотрим 6 практических рекомендаций для организации процесса тестирования.

Внедрите шаблон бага

Разработайте шаблон бага и описывайте найденные ошибки по нему. Если на проекте используется система вики - заведите в ней отдельный раздел для тестирования и храните в нем шаблоны документов и регламенты.

Наличие шаблонов для багов несет следующие преимущества:

• Экономия времени на воспроизведении багов как разработчиками, так и тестировщиками. В случае короткого и неинформативного описания не только разработчик, но и сам автор бага может не вспомнить, о чем шла речь.

• Сокращение времени на коммуникации между dev и qa - этот пункт вытекает из предыдущего. Разработчики не будут стучаться к вам в личку со словами - а что имелось в виду в этом баге? А на каком стенде и тестовых данных он воспроизводится? 

• Единый стиль багов - с багами приятно и привычно работать всем членам команды.

Согласуйте список приоритетов багов

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

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

Вы можете установить 5 приоритетов для багов, например: 

• Блокирующий - Blocker

• Критический - Critical

• Важный - Major

• Нормальный - Normal

• Минорный - Minor

Или обойтись более простой версией из трех приоритетов:

• Высокий - High

• Средний - Normal

• Низкий - Low

Согласуйте правила установки приоритетов, оформите в виде регламента и положите в wiki.

Внедрите регламент работы с багами

Согласованный жизненный цикл бага помогает разработчикам не пропускать заведенные баги, а тестировщикам - следить за ходом исправления багов.

ЖЦ бага представляет из себя описание состояний бага и правил перехода по ним в системе управления проектами. 

Для составления регламента выполните следующие шаги:

• Продумайте набор статусов для багов. 

• Определите правила перехода между статусами и порядок назначения исполнителей.

• Согласуйте регламент с менеджером проекта.

Регламент представляется в виде наглядной схемы или текстового описания. После согласования регламента с командой положите его в wiki и следите первое время за его исполнением.

Согласуйте регламент работы с задачами в системе управления проектами

Налаженная работа с задачами в системе управления проектами сокращает время на лишние коммуникации и помогает получить общую картину по выполнению задач в любой момент времени. Система управления проектами - один из основных инструментов тестировщиков. Вы не можете постоянно спрашивать разработчиков - когда будет готова эта задача? Статусы задач вы отслеживаете именно в системе управления проектом.

Вся команда должна придерживаться правил перевода задач по статусам. QA инженерам особое внимание стоит уделить статусам для тестирования задач:

• Ready for test - задача завершена разработчиками и готова к тестированию;

• Testing - задача находится на тестировании у тестировщика;

• Done - задача протестирована в рамках итерации;

• и т.д.

Пишите тест-кейсы или чек-листы… как можно раньше в процессе обеспечения качества

Один из первых навыков, которым учатся тестировщики - проектирование тест-кейсов. Это база. Тем не менее, тестировщики не всегда создают тестовые сценарии «на бумаге».

Одной из главных причин называется «нет времени». Эта проблема решается путем грамотного планирования итерации и оценки времени на тестирование.

При отсутствии чек‑листов или тест‑кейсов вы рискуете качеством своего продукта.

2 основных совета по стадии проектирования тест-кейсов следующие:

• Если нет необходимости в тест-кейсах, пишите чек-листы; 

• Пишите тест-кейсы или чек-листы как можно раньше в процессе обеспечения качества. В идеале - еще на стадии тестирования требований или до разработки.

Преимущества раннего проектирования тест-кейсов или чек-листов:

• Вы не торопитесь, сосредоточены и можете качественно продумать тестовые случаи;

• Ранний поиск ошибок в требованиях;

• Возможность приступить к тестированию сразу после передачи задачи на тест.

Проектирование тест-кейсов после завершения разработки ведет к тому, что разработчик позже получает обратную связь по задаче. Если вы найдете ошибки в требованиях - цена их исправления будет существенно выше, ведь разработка уже завершена.

Минусы тестирования без тест-кейсов или чек-листов:

• Вы придумываете тестовые ситуации на ходу, при этом прерываетесь на тестирование, локализацию и заведение багов, коммуникации;

• Перепроверка одних и тех же ситуаций несколько раз;

• Риск пропуска тестовых случаев повышается из-за спешки или отсутствия задокументированных результатов выполнения;

• Присутствует ощущение, что “вроде вы все проверили”, но “возможно что-то забыли”.

Риск пропуска багов в таком случае гораздо выше, чем при наличии кейсов. А уверенность в качестве продукта - ниже.

Установите критерии выпуска релиза в прод

Как определить, когда текущая версия готова к релизу? Ждать до исправления последнего бага или все же нет?

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

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

Пример критериев:

• По всем фичам проведено тестирование;

• По фичам исправлены баги всех приоритетов, кроме низкого;

• Проведено регрессионное тестирование;

• и т.д.

В результате тестирования вы предоставляете менеджеру проекта решение о готовности продукта к релизу. Критерии помогут вам перейти от варианта “вроде все работает” к обоснованному заключению.

Заключение

Мы рассмотрели 2 общих совета и 6 первых практических шагов для построения процесса ручного тестирования на проекте.

Спасибо за внимание и до встречи в следующей статье!