Ревью тестовой документации

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

Ревью (или рецензирование) – это тоже форма тестирования – верификационная часть процесса V&V (Verification and validation), также называемая статическим тестированием.

Виды ревью

Подпишитесь на наш ТЕЛЕГРАМ КАНАЛ ПО АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ

В зависимости от того, кто проводит ревью тестовой документации, можно выделить три вида этой проверки:

Ревью своей собственной работы – самопроверка
Ревью коллег
Супервизия

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

Если валидация – это одна половина практики тестирования, то верификация – вторая. Часто правила ревью не ясны – так давайте изменим это СЕЙЧАС. Начнем по порядку с вопросов “Что? Почему? Как?”

Что подвергается ревью?

Все созданные артефакты должны проверяться. Чаще всего проверяются:

план тестирования
сценарии тестирования
шаблоны тестирования
тест-кейсы
тестовые данные
отчеты… и т.д.

Зачем нужно ревью?

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

Как проводить ревью тестовой документации?

Список необходимых действий:

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

Теперь мы рассмотрим каждый шаг отдельно.

(Большинство из нас, тестировщиков, не любят работу с документами, не так ли? Для нас это означает либо гораздо больше работы, либо какую-то менеджерскую задачу высокого уровня, которую мы должны выполнять, даже если не хотим – ради какого-то соответствия, о котором мы понятия не имеем. Но, поверьте мне, когда вы придумаете процесс, который работает и достаточно прост, чтобы было понятно, почему нужно выполнять такие задачи, это может быть легко и просто! Просто попробуйте).

Шаг 1: Определите критерии

1. Что вы ожидаете найти? Вы можете искать такие вещи, как:

Орфографические ошибки (Звучит слишком глупо? Я так не думаю. Однажды я написал “Wed Object” вместо “Web Object” в одной из своих статей – это полностью меняет смысл. Из-за этого статья выглядит непрофессионально и ее сложно воспринимать всерьез).
Соответствие формату/шаблону
Охват функциональности и корректность
Простота понимания
Соблюдение стандартов – соглашения об именах, последовательная нумерация и т.д.

2. Составьте чек-лист. Чек-листы очень разнообразны. Это может быть как сложный список со многочисленными проверками, так и простой список продуктов для похода в магазин. Все, что нужно, это немного времени, чтобы его составить, а использовать его будет просто: просто отмечать пункты галочками.

3. Как сообщать о результатах? Выберите любой удобный способ, предпочтительно тот, который можно записать и отследить.

Иногда достаточно просто добавить колонку в лист excel с тест-кейсами и все несоответствующее выделять красным цветом
Это может быть “сарафанное радио”
Список в электронном письме

Шаг 2: Выполните проверку

Используя чек-лист, который вы составили ранее, проверьте документ и дайте свой отзыв.

Шаг 3: Зафиксируйте результаты

Снова, используя метод, выбранный на шаге 1, запишите и сообщите о своих результатах.

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

Шаг 4: Обсудить и внедрить необходимые изменения

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

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

2. Получите подпись/подтверждение.

3. Внесите изменения.

Шаг 5: Обновите версию соответствующих документов

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

Шаг 6: Подпишите и используйте документ по назначению

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

Еще один вопрос, который может возникнуть, – перепроверяем ли мы документ после внесения изменений? Сколько раз будет продолжаться этот процесс – “работа-ревью-исправление”, а затем снова ревью? До какого момента?

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

Вот и все. Этот процесс довольно прост, не так ли?

Что нужно помнить

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

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

Заключение

Итак, ревью тестовой документации – не такой уж сложный процесс. А вы проводите ревью в своих проектах? Пожалуйста, поделитесь своим опытом, проблемами и вопросами в комментариях!

Перевод статьи Swati Seela “How to Perform Test Documentation Reviews in 6 Simple Steps – QA Process”