Что нужно знать тестировщику о рецензировании и как его использовать в работе
Давайте знакомится, я, Ольга Борзенко, занимаюсь мануальным тестированием в IT более 5 лет, и я, Федорова Татьяна, занимаюсь тем же более 7 лет. У нас есть опыт успешного тестирования и хотим им поделиться. В этой статье поговорим о рецензировании как одной из составляющих различных проектов. После прочтения статьи как начинающий, так и опытный тестировщик, сможет найти ответ на вопрос, как и когда применять рецензирование в работе. Устраивайтесь поудобнее, и мы начинаем!
Вначале определим, что же такое рецензирование. Согласно IEEE 1028 Standard for Software Reviews and Audits, рецензирование (Review) — это оценка состояния продукта или проекта с целью установления расхождений с запланированными результатами и выдвижения предложений по совершенствованию.
Мы будем рассматривать процесс рецензирования с позиции тестирования и своего опыта. Чем конкретно полезно рецензирование тестировщику? Чем оно помогает?
Рецензирование — это не только часть тестирования, но и отдельный пласт процесса разработки проекта. И тестировщик в нем выполняет важную роль. Применение рецензирования помогает более эффективному обнаружению дефектов.
Типы рецензирования
Проанализировав литературу Standard Glossary of Terms used in Software Testing (Version 3.3), ISO/IEC 20246:2017 Software and systems engineering — Work product reviews, ISTQB CTFL Syllabus 2018, мы схематично отобразили структуру типов рецензирования.
Рисунок 1. Типы рецензирования
Как видно на Рис. 1, рецензирование делится на формальное и неформальное.
Формальное рецензирование характеризуется участием команды, документированием процесса и результата.
Неформальное рецензирование — отсутствием необходимости соблюдения конкретного процесса и формальной документации.
Исходя из нашего опыта, можем сказать, что решение о выборе типа рецензирования зависит от проекта. Формальное рецензирование подойдет больше для крупных долголетних проектов, на которых используются классические методологии разработки программного обеспечения, применяется различная документация (не только тестовая, но и проектная, техническая, руководство пользователя и так далее), требуется отчетность о каждом действии, присутствуют юридические или нормативные требования. Например, проекты, связанные с медицинским оборудованием, документооборотом, программным обеспечением для автомобилей.
Неформальное рецензирование, на наш взгляд, будет более актуально на небольших проектах или проектах с использованием гибких методологий разработки, с отсутствием или неполным набором документации. Например, сайты-визитки, небольшие e-commerce проекты.
Процесс рецензирования
Что подлежит рецензированию, решается в зависимости от целей и задач на текущий момент. Например, это может быть обсуждение документации, введение в проект новых участников команды (рассказ о проекте или, наоборот, «свежее» мнение «человека со стороны» и т.д.).
Рисунок 2. Процесс рецензирования рабочего продукта
Обратите внимание, что процесс рецензирования для выбранной области начинается с запроса о рецензировании, который делает автор — тот, кто непосредственно создает продукт и исправляет в нем дефекты.
Теперь рассмотрим основные стадии этого процесса и расскажем, как применяем рецензирование на своем проекте (см. рис. 2).
На стадии планирования, чтобы правильно начать процесс рецензирования продукта, необходимо определить весь объем работ и критерии входа/выхода, проверить соответствия ранее установленных критериев входа/выхода.
Первая стадия рецензирования непроста для понимания, однако это неотъемлемая часть каждого проекта. Часто тестировщиков привлекают уже не на ранних стадиях. Поэтому не всегда сразу понятны цели заказчика, оценка трудозатрат и установленные критерии входа.
Следующая стадия — инициирование рецензирования. Как правило, тут подключаются тестировщики, которым дают спецификацию или гейм-дизайн документ, в зависимости от типа проекта. В это же время команде объясняют цели и распределяют роли на проекте. Все участники рецензирования получают ответы на возникшие вопросы.
Затем переходим к индивидуальному рецензированию. Эта стадия подразумевает индивидуальную подготовку, в которой принимают участие и тестировщики. То есть проведение рецензирования всего рабочего продукта или его части и определение потенциальных дефектов. Задача тестировщика состоит в том, чтобы не только выявить потенциальные дефекты, но и обдумать рекомендации по улучшению.
Вслед за индивидуальным рецензированием идет коммуникация по вопросам и анализ. Тестировщики оповещают команду о выявленных и потенциальных дефектах, анализируют их, устанавливают статус и «выбирают жертву», того, кто это будет исправлять.
Завершающая стадия — внесение изменений и отчетность. На этой стадии происходит создание отчетов о дефектах, их обсуждение и исправление; обновляются данные о дефектах, проводится сбор метрик и проверка критериев входа и выхода.
Например, у нас на одном из небольших проектов было так: на тестирование зашел новый функционал с целым паком UI-дизайна и технической документацией. Мы это изучили, составили список вопросов, продумали, в каких местах вероятнее всего встретить дефекты. Затем на митинге обсудили их, приоритизировали и назначили на разработчиков.
Методы рецензирования
В ходе процесса рецензирования применяются методы, которые представлены на рисунке 3. Каждый из них может использоваться для любого типа рецензирования.
Рисунок 3. Методы рецензирования
Факторы успеха рецензирования
Стоит также упомянуть о факторах успешного рецензирования. Для определения того, успешно ли тестировщики это сделали, справились ли со всеми поставленными задачами, разделим факторы на две группы: организационные и технические (см. табл. 1).
Таблица 1. Факторы успеха рецензирования
| Организационные факторы успеха | Технические факторы успеха |
| Все цели четко определены (зачем и для чего проводим рецензирование) | Правильный выбор типа ревью |
Доступные и качественные артефакты | Найденные дефекты признаются, оцениваются и обрабатываются объективно |
| Люди с опытом (особенно при проведении инспекции) | Использование чек-листов и ролей (каждый участник понимает, за что он ответственный) |
| Тестировщик вносит свой вклад и узнает о работе продукта | Поддержка процессов рецензирование менеджером |
| Рецензирование проводится на основе доверия | Члены команды имеют разный набор навыков и точку зрения |
| Участники избегают психологических аспектов | Обучение участников более формальным типам рецензирования |
В рамках данной статьи, мы хотим показать примеры рецензирования, исходя из собственного опыта. По большей части нами проводились различные виды неформального рецензирования.
Например, при получении нового функционала на тестирование сначала изучаем документацию по нему (если ее нет, описание задачи). После этого анализируем, каких кейсов и информации не хватает, не противоречат ли какие-либо пункты нового функционала тому, что уже реализовано, в каких местах есть вероятность возникновения дефекта. Затем обсуждаем это с командой.
Считаем хорошей практикой после написания одним из наших тестировщиков тест-кейсов или чек-листа просматривать и обсуждать этот документ всей командой тестировщиков. Это помогает быть в курсе изменений и заодно делиться опытом. Ведь, как известно, на один и тот же пункт в документации (задании) более опытный тестировщик напишет больше проверок и более корректно поставит для них severity (серьезность).
Кроме этого, привлекаем к обсуждению тест-кейсов или чек-листа разработчиков. Работа в небольших группах из двух тестировщиков и одного разработчика считается эффективной с точки зрения рецензирования. Это способствует более глубокому пониманию тестировщиком процессов, происходящих во время разработки. И это возможность девелоперу проверить себя, например, везде ли он добавил необходимые проверки на валидацию данных.
Еще одна хорошая практика, которую применяем, — «поставить» себя на место потенциальных пользователей продукта и оценить работу тестируемого функционала с их точки зрения. В ходе тестирования примеряем на себя различные роли, например, для e-commerce проектов это может быть покупатель, продавец, администратор; для проектов в сфере образования — ректор, деканы, преподаватели, студенты; директора, учителя, ученики. Продумываем, а достаточно ли очевидны различные кейсы, понятен и удобен ли в использовании продукт и так далее.
Как видно из вышесказанного, в рецензировании нет ничего сложного. Так или иначе каждый из нас применяет его у себя в работе.
Рецензирование — полезная «штука», поскольку помогает разложить по полочкам непонятные и спорные моменты в тестировании продукта. Дает возможность узнать точку зрения других участников разработки. Ввести более быстро и продуктивно нового члена команды. Кроме того, поскольку рецензирование относится к статическому тестированию, оно позволяет обнаруживать дефекты до проведения динамического тестирования, что, в свою очередь, способствует снижению затрат на исправление найденных дефектов.
Подводя итог, отметим, что рецензирование можно использовать по-разному, но все же основная его цель — нахождение дефектов.
Теперь вы знаете, что ответить на вопрос, как и когда применять рецензирование. Спасибо за внимание! Надеемся, что статья была полезна для вас!
