В SmartHead мы активно обмениваемся опытом и я хочу поделиться некоторыми подходами к организации рабочих процессов для начинающих тестировщиков.
Представь, что к тебе подошел руководитель проекта и сказал, что нужно протестировать автомобиль. Что будешь проверять в первую очередь?
Открывается ли дверь?
Корректно ли спидометр определяет скорость?
Срабатывает ли подушка безопасности при боковом столкновении?
А может вообще стоит проверить амортизаторы на работоспособность?
Хорошо, если у нас есть некий план по тестированию, но самым лучшим подходом в данном случае будет понять что мы тестируем, как мы тестируем и зачем.
Не бойся спрашивать
Даже если это уже 500 вопрос за день, все равно спроси еще, если непонятно. Это сократит количество ненужных проверок. Важно знать и понимать как это должно работать, а не проверять, что это работает так, как реализовал разработчик. Один из вопросов, которые можно задать себе: «Правильно ли разработчик понял задачу?»
В проектной команде взаимодействие между участниками играет важную роль, поэтому коммуникация должна быть прозрачной и доступной для всех. Если у тебя возникли сомнения относительно функциональности продукта, не стесняйся выносить их на обсуждение. Даже если предложенное решение не будет принято, это поможет улучшить понимание задачи и получить обратную связь. Также подобные дискуссии способствуют выявлению скрытых проблем.
Составь план тестирования
Это поможет лучше понять проект, над которым мы работаем, и представить процесс тестирования. План можно составить в виде таблицы, диаграммы, схемы или обычного текстового документа. Обычно он содержит следующее:
Основная информация о проекте, включая его цели, особенности и требования;
Информация об окружениях, в которых будет проводиться тестирование;
Что мы тестируем и что не является объектом тестирования, чтобы четко определить область покрытия;
Виды проводимого тестирования и способы его выполнения, включая использование инструментов и типы проверок;
Этапы процесса тестирования с указанием последовательности;
Критерии приемки задач и определение, какие результаты тестирования считаются успешными;
Ссылки на другие тестовые артефакты, такие как тестовые сценарии, тестовые случаи или другую документацию;
Состав команды и роли участников, чтобы определить ответственности и распределить задачи.
Если у тебя есть возможность, проведи ревью тест-плана с более опытным коллегой. Это поможет улучшить качество плана и выявить недостающие моменты.
Составь тест-кейсы
Хороший тестировщик пойдет проверять фичу, а отличный тестировщик сначала пойдет и составит тест-кейсы.
При написании тест-кейсов всплывают моменты, о которых не задумываешься, пока не пройдешь путь пользователя. Можно предположить, как пользователь будет вести себя в системе, подумать, что он может делать, что он захочет сделать и, опираясь на это, составить тест-кейсы не только по общим сценариям, но и по редким.
Хорошей практикой является написание тест-кейсов в самом начале проекта. Не нужно ждать пока всю работу доделают, начинай составлять примерные проверки уже на этапе обсуждения задачи. Например, если в проекте будет страница авторизации, то основные шаги и данные уже могут быть известны, а детали можно подкорректировать позднее.
Хорошо, если есть описанные требования, в таком случае процесс написания тест-кейсов будет куда проще. Но иногда бывает так, что требования неполные, и тест-кейсы сами становятся требованиями. Обсуждать и уточнять требования в процессе — это нормально.
Как составить тест-кейсы?
Во-первых, определи что будешь проверять. Новую функциональность? Регресс? Нагрузку? Конечно, все зависит от того, на каком этапе разработки находится проекта: ты можешь присоединиться к проекту в самом начале или уже находиться в середине разработки. Если ты присоединился к готовому проекту, где нет тест-кейсов, то начни с составления отдельных сценариев, пройди весь путь в роли пользователя и изучи систему.
При составлении чаще всего опираются на техники тест дизайна, такие как анализ граничных значений, классы эквивалентности, позитивный и негативный сценарии и т.д. Главное – проверки должны покрывать необходимую функциональность, быть последовательными и воспроизводимыми. Важно помнить, что если ты отсутствуешь, процесс тестирования не должен останавливаться только потому, что документы понятны только тебе.
Можно опираться такую структуру тест-кейсов:
Название блока/кейса;
Приоритет;
Предусловия;
Шаги воспроизведения;
Ожидаемый результат;
Опционально можно добавить тестовые данные в виде валидных/невалидных номеров телефонов, почт и т.д., которые нужно проверить.
Тест-кейсы нужно поддерживать в актуальном состоянии. Если новая функциональность влияет на старые сценарии, их тоже нужно корректировать.
Внимательно работай с задачами
Начни изучение задачи как можно раньше: это даст возможность подумать, как ее протестировать, обсудить это с разработчиком и начать писать тестовую документацию. Такой подход поможет избежать откладывания работы тестировщика на последний этап, когда задача должна быть завершена.
Следует следить за актуальностью статусов задач, сроков и приоритетов. Это обеспечит прозрачность состояния работы для всей команды. Статус задачи может меняться по разным причинам. Например, перевод в Incomplete, когда нашелся баг и нужно переделать что-то. Или, допустим, не работало тестовое окружение и тестировщик перевел задачу туда до момента, когда можно будет ее проверить. Самое главное — не оставлять задачи в неактуальном статусе.
Хорошей практикой будет разделить статус для тестирования на “To test” и “In test”. В первом будут задачи, готовые к тестированию, а во втором — находящиеся в процессе тестирования. Это поможет лучше понять картину тестирования и распределить нагрузку. Не стоит переводить все задачи сразу в “In test”, особенно, если вы не собираетесь ее проверять сейчас. Лучше постепенно разбираться со всеми задачами и последовательно обновлять их статусы.
Как оформить баг репорт?
Описание бага должно быть понятным для всех участников команды. Важно емко описать весь баг, не углубляясь в ненужные детали и четко разделять актуальное и ожидаемое поведения. Понятность должна быть важнее формальности.
Как один из вариантов можно использовать следующую структуру:
Название;
Описание;
Актуальное поведение;
Ожидаемое поведение;
Шаги воспроизведения;
Окружение.
Не обязательно использовать все поля и подробно заполнять каждое. Учитывай, что некоторая информация может быть излишне подробной, что увеличит время понимания и воспроизведения бага.
С другой стороны, если написать слишком мало информации, то тоже возникают проблемы с пониманием задачи. Например, при сравнении двух баг‑репортов с названиями «Меню в табе залезает на интерфейс при скролле» и «Меню сломалось», более понятным окажется первый, так как уже из названия понятно что, где и при каких условиях работает не так.
Кроме правильного оформления названия и описания важно оформление визуальной части, ведь гораздо удобнее сразу видеть скриншот/скринкаст ошибки, чем отдельно открывать его во вложениях.
Шаги воспроизведения тоже могут быть избыточными, например:
Откройте браузер
Зайдите по ссылке
Введите логин
Введите пароль
Нажмите кнопку Войти
…
Описание сильно влияет на скорость и итоговый результат. Иногда писать подробно можно и нужно, например, когда баг сложно воспроизвести. Но когда шаги воспроизведения состоят из простых действий типа авторизации, то можно их объединить:
Авторизуйтесь под пользователем
Перейдите в главное меню
Проскролльте страницу вниз
Авторизация также может быть предусловием, а не шагом воспроизведения.
Такое оформление баг-репортов экономит время и оптимизирует процесс исправления, ведь разработчику нужно время для воспроизведения ошибки и понимания что нужно исправить.
Заключение
Хорошо организованные рабочие процессы помогут эффективно и своевременно выполнять свои задачи и делать это прозрачно. Важно не ограничивать все рамками, действуя исключительно «по инструкции», а, прежде всего, разумно оценивать ситуацию и уметь создать комфортную для работы среду.
Цель тестирования — не найти как можно больше багов, а наоборот — сделать так, чтобы их было меньше.