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

Представь, что к тебе подошел руководитель проекта и сказал, что нужно протестировать автомобиль. Что будешь проверять в первую очередь?

• Открывается ли дверь?

• Корректно ли спидометр определяет скорость?

• Срабатывает ли подушка безопасности при боковом столкновении?

• А может вообще стоит проверить амортизаторы на работоспособность?

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

Не бойся спрашивать

Даже если это уже 500 вопрос за день, все равно спроси еще, если непонятно. Это сократит количество ненужных проверок. Важно знать и понимать как это должно работать, а не проверять, что это работает так, как реализовал разработчик. Один из вопросов, которые можно задать себе: «Правильно ли разработчик понял задачу?»

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

Составь план тестирования

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

• Основная информация о проекте, включая его цели, особенности и требования;

• Информация об окружениях, в которых будет проводиться тестирование;

• Что мы тестируем и что не является объектом тестирования, чтобы четко определить область покрытия;

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

• Этапы процесса тестирования с указанием последовательности;

• Критерии приемки задач и определение, какие результаты тестирования считаются успешными;

• Ссылки на другие тестовые артефакты, такие как тестовые сценарии, тестовые случаи или другую документацию;

• Состав команды и роли участников, чтобы определить ответственности и распределить задачи.

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

Составь тест-кейсы

Хороший тестировщик пойдет проверять фичу, а отличный тестировщик сначала пойдет и составит тест-кейсы.

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

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

Хорошо, если есть описанные требования, в таком случае процесс написания тест-кейсов будет куда проще. Но иногда бывает так, что требования неполные, и тест-кейсы сами становятся требованиями. Обсуждать и уточнять требования в процессе — это нормально.

Как составить тест-кейсы?

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

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

Можно опираться такую структуру тест-кейсов:

• Название блока/кейса;

• Приоритет;

• Предусловия;

• Шаги воспроизведения;

• Ожидаемый результат;

Опционально можно добавить тестовые данные в виде валидных/невалидных номеров телефонов, почт и т.д., которые нужно проверить.

Тест-кейсы нужно поддерживать в актуальном состоянии. Если новая функциональность влияет на старые сценарии, их тоже нужно корректировать.

Внимательно работай с задачами

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

Следует следить за актуальностью статусов задач, сроков и приоритетов. Это обеспечит прозрачность состояния работы для всей команды. Статус задачи может меняться по разным причинам. Например, перевод в Incomplete, когда нашелся баг и нужно переделать что-то. Или, допустим, не работало тестовое окружение и тестировщик перевел задачу туда до момента, когда можно будет ее проверить. Самое главное — не оставлять задачи в неактуальном статусе.

Хорошей практикой будет разделить статус для тестирования на “To test” и “In test”. В первом будут задачи, готовые к тестированию, а во втором — находящиеся в процессе тестирования. Это поможет лучше понять картину тестирования и распределить нагрузку. Не стоит переводить все задачи сразу в “In test”, особенно, если вы не собираетесь ее проверять сейчас. Лучше постепенно разбираться со всеми задачами и последовательно обновлять их статусы. 

Как оформить баг репорт?

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

Как один из вариантов можно использовать следующую структуру:

• Название;

• Описание;

• Актуальное поведение;

• Ожидаемое поведение;

• Шаги воспроизведения;

• Окружение.

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

С другой стороны, если написать слишком мало информации, то тоже возникают проблемы с пониманием задачи. Например, при сравнении двух баг‑репортов с названиями «Меню в табе залезает на интерфейс при скролле» и «Меню сломалось», более понятным окажется первый, так как уже из названия понятно что, где и при каких условиях работает не так.

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

Шаги воспроизведения тоже могут быть избыточными, например:

1. Откройте браузер

2. Зайдите по ссылке

3. Введите логин

4. Введите пароль

5. Нажмите кнопку Войти

6. …

Описание сильно влияет на скорость и итоговый результат. Иногда писать подробно можно и нужно, например, когда баг сложно воспроизвести. Но когда шаги воспроизведения состоят из простых действий типа авторизации, то можно их объединить:

1. Авторизуйтесь под пользователем

2. Перейдите в главное меню

3. Проскролльте страницу вниз

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

Такое оформление баг-репортов экономит время и оптимизирует процесс исправления, ведь разработчику нужно время для воспроизведения ошибки и понимания что нужно исправить.

Заключение

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

Цель тестирования — не найти как можно больше багов, а наоборот — сделать так, чтобы их было меньше.