Все мы знаем, что для тестировщика документация является неотъемлемой частью его повседневных задач. Часто артефактов тестирования становится слишком много. Особенно – когда они всё время создаются, рассматриваются, утверждаются, используются, поддерживаются и распространяются. В этой статье мы собираемся пролить свет на небольшую, но важную тему – как проводить ревью тестовой документации.
Ревью (или рецензирование) – это тоже форма тестирования – верификационная часть процесса 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”