Тестовая документация
Типичные ошибки в тестовой документации: чек-лист, тест-кейс, баг-репорт
Чаще всего в чек-листе нет негативных проверок или их склеили в одну строку, формулировки слишком короткие, а шапки, статусов и деления на модули нет. В тест-кейсе открытие страницы выносят в предусловие, шаги пишут от первого лица, объединяют несколько проверок и не дают тестовых данных. В баг-репорте заголовок не отвечает на вопросы где, что и когда, а на скриншоте непонятно, куда смотреть, и разработчику трудно воспроизвести дефект.
- Сначала позитивные
- негативные проверки идут следом, и каждая отдельной строкой
- Где, что, когда
- три вопроса, без ответа на которые заголовок бага плохой
- Бесплатно
- урок в моём базовом курсе
Ошибки в чек-листе
Я собрал эти ошибки, проверяя домашние задания своих учеников. Чек-лист – самый свободный по форме документ, но и у него есть правило: им должно быть удобно пользоваться всем участникам процесса.
Только позитивные проверки
Пользователь не всегда идёт по сценарию из требований, поэтому без негативных проверок чек-лист неполон. Перекос в другую сторону, одни негативные проверки, тоже ошибка.
Негативные проверки раньше позитивных
Времени на тестирование часто мало, и первым делом проверяют, что основные функции работают по позитивному пути. Негативные проверки идут следом.
Много проверок в одной строке
За пунктом "Регистрация пользователя" стоят и валидные данные, и бесконечные варианты невалидных. Указывают, с какими данными идёт проверка, а негативную называют по результату, например "Сообщение об ошибке при регистрации с уже занятой почтой".
Все негативные проверки вместе
Каждую негативную проверку пишут отдельной строкой. Объединённые проверки мешают локализовать дефект: непонятно, какая из них упала, и статус не проставить.
Слишком короткая формулировка
Пункт "Авторизация" не говорит, о каком механизме речь: логин и пароль, вход через соцсети, токен. Механизм указывают явно, и каждый становится отдельной проверкой.
Нет шапки
Окружение, дата и имя тестировщика нужны, чтобы прогон можно было проследить. Удобно вести один чек-лист и на каждый прогон заводить в нём новую вкладку.
Нет статусов и деления на модули
По каждой проверке должно быть видно, прошла она или упала. Сплошной список делят на модули: по пользовательским историям, по расположению на экране или по функциям.
Нетехническая терминология
"Галочки" и "крестики" выдают слабую подготовку. Названия элементов смотрят в макетах Figma и во вкладке Elements в DevTools, а лучше уточняют у фронтенд-разработчиков, которые за эти названия отвечают.
Ошибки в тест-кейсе
Атрибутов у тест-кейса больше, чем у чек-листа, и ошибиться в нём проще. Номер в системе управления тестированием обычно присваивается сам, а заголовок, шаги и ожидаемый результат к каждому шагу пишет тестировщик, при необходимости добавляя приоритет и ссылки на пользовательские истории.
Навигация в предусловии
Открыть нужную страницу – это первый шаг кейса. В предусловие выносят то, что готовят заранее, например зарегистрированного пользователя.
Лишние слова в заголовке
Слово "тест-кейс" в заголовке не нужно, в системе и так видно, что это кейс. "Проверить" я тоже не люблю, хотя критичной ошибкой это не считаю.
Шаги от лица человека
Шаги пишут инфинитивом: "открыть", "ввести", "перейти", "нажать", без "открой", "открыл" и "открываем". В английском шаг начинается с глагола: Open, Go to, Verify.
Несколько проверок в одном кейсе
Один кейс – одна проверка, и негативные проверки не объединяют. Исключение дают параметры в TMS, например в QASE и Test IT: кейс с набором значений при запуске прогона превращается в отдельную проверку на каждое значение. Если же разложить значения по шагам одного кейса, результат каждого проследить трудно.
Заголовок не отражает суть
"Покупка товара" не говорит, одного товара или нескольких, через какой модуль и с какими данными. Документация любит законченность, поэтому формулировку доводят до конца.
Нет тестовых данных
После шага "ввести невалидный пароль" остаётся вопрос, какой именно. Данные указывают в поле шага в TMS или отдельным столбцом в таблице. Их нужно обновлять: одни и те же данные со временем перестают находить дефекты, как при парадоксе пестицида, а в TMS их удобно задать переменными, как в Postman.
Дублирование
Регистрацию незачем повторять в каждом кейсе. Её выносят в предусловие "Пользователь зарегистрирован" со ссылкой на кейс регистрации, а проверку того, что кнопка нажимается, делают частью проверки функциональности. Меру при этом держат: кейс, в который сложили всё подряд, превращается в тестовый набор.
Одинаковые заголовки
Заголовки кейсов в системе должны быть уникальными, иначе нужный кейс не найти.
Пример: тест-кейс до и после исправления
Ниже кейс на вход в систему, в котором собраны ошибки из разбора, и тот же кейс после правки.
До правки. Заголовок "Проверить авторизацию". Предусловие "Открыта страница входа". Шаги "Вводим логин и пароль" и "Жмём кнопку", ожидаемый результат "Работает". Навигация здесь вынесена в предусловие, шаги написаны от первого лица и склеены, данных нет, кнопка не названа, по заголовку непонятно, какой вход проверяют, а ожидаемый результат ничего не сообщает.
После правки. Заголовок "Вход зарегистрированного пользователя по логину и паролю". Предусловие "Пользователь зарегистрирован" со ссылкой на кейс регистрации, в тестовых данных логин и пароль этого пользователя.
Шаг 1. Открыть страницу входа
Адрес страницы указывают прямо в шаге. Ожидаемый результат: открывается страница входа.
Шаг 2. Ввести логин в поле "Логин"
Ожидаемый результат: логин отображается в поле.
Шаг 3. Ввести пароль в поле "Пароль"
Ожидаемый результат: пароль отображается в поле.
Шаг 4. Нажать кнопку "Войти"
Ожидаемый результат: пользователь авторизован и попадает на главную страницу личного кабинета.
Негативные проверки
Неверный пароль, пустые поля и незарегистрированный логин оформляют отдельными кейсами, каждый со своими данными и ожидаемым сообщением об ошибке.
Ошибки в баг-репорте
Баг-репорт читают разработчик, менеджер и аналитик, и любая неточность стоит им времени. Ниже ошибки, которые я чаще всего встречаю в отчётах о дефектах.
Заголовок без где, что, когда
"Ошибка при покупке товара", "Баг в корзине", "Добавление ученика на курс" не отвечают на эти три вопроса. Если не хватает хотя бы одного ответа, заголовок плохой. В заголовке "Корзина: итоговая сумма не пересчитывается после удаления товара" видно место (корзина), сам дефект (сумма не пересчитывается) и момент, когда он проявляется (после удаления товара).
Нет обязательных атрибутов
Шаги, фактический и ожидаемый результат, окружение, серьёзность и приоритет должны быть на месте.
Личные оценки и глаголы
В отчёте никого не обвиняют и не пишут "открываем", "найду", "перейду". Действия описывают инфинитивом: "открыть", "перейти", "ввести".
Скриншот без указания на дефект
По кадру должно быть понятно, куда смотреть. Место выделяют рамкой и стрелкой из встроенных фигур скриншотера, от руки не рисуют.
Длинное видео со звуком
Видео обрезают до фрагмента, который относится к дефекту, а микрофон при записи экрана отключают.
Дубли вместо одного бага
Допустим, сообщение об ошибке не появляется при вводе кириллицы, латиницы и спецсимволов, а отвечает за всё одна валидация. Тогда заводят один баг, например на кириллицу, и в комментарии пишут, для каких ещё данных он воспроизводится. Графические дефекты одной страницы тоже можно собрать в один отчёт для фронтенд-разработчика. Дефекты разной природы не объединяют. А двадцать одинаковых минорных багов, заведённых по отдельности, только искажают статистику.
Нет ссылок
На требование, макет или связанную задачу. Без них теряется прослеживаемость.
Пропущенные или склеенные шаги
Пропущен ввод пароля, или вместо отдельных действий написано "зарегистрироваться". Шаги расписывают так, чтобы дефект воспроизвёл любой человек: в какое поле что ввести и какую кнопку нажать.
Нет тестовых данных
Если дефект вызвали конкретные данные, их прикладывают к отчёту, а если есть готовый скрипт, то и его.
Дефект не локализован
Написать, что "что-то случилось", мало. Тестировщик заглядывает в DevTools, в базу данных и в логи, если к ним есть доступ, и добавляет найденное в отчёт. Например, в интернет-магазине после нажатия "Оформить заказ" появляется "Что-то пошло не так". На вкладке Network видно, что POST-запрос оформления вернул 500, а в теле ответа сервер пишет, что не нашёл адрес доставки. Запрос и ответ идут в отчёт, и разработчик сразу знает, где искать.
Что уточнить на проекте, чтобы не переделывать
Многие ошибки появляются оттого, что новичок пишет документацию по своему разумению, хотя на проекте уже есть свой порядок. Поэтому в первые дни стоит задать команде несколько вопросов.
Какую документацию используют
Чек-листы, тест-кейсы или то и другое, и есть ли система управления тестированием.
Есть ли шаблоны
Изобретать велосипед, который уже придумали, незачем, и готовый шаблон проекта берут за основу. Если шаблонов нет, их придумывают и согласовывают с командой, чтобы документацией было удобно пользоваться всем.
Есть ли примеры и учебные задачи
Иногда новичку сначала дают только смоук, учебную часть приложения или отдельное окружение, чтобы набить руку.
Где хранится документация и как её оформляют
Где лежат документы, в каком формате их пишут и кто расставляет приоритеты проверок.
Отличается ли документация для фронтенда и бэкенда
На некоторых проектах их документируют по-разному, и у каждой части свои особенности.
Видеоурок, шпаргалки и тренажёры
Эти ошибки я разбираю в ролике "Тестовая документация для тестировщика. Типичные ошибки" на YouTube и иду по схеме, которую собрал после проверки работ учеников. В бесплатном базовом курсе по тестированию тема идёт уроком "Типичные ошибки в тестовой документации".
Шпаргалки по чек-листу, тест-кейсу и баг-репорту показывают, как выглядит каждый документ без этих ошибок, а в шпаргалке по тест-кейсу можно ещё и поискать ошибки в плохом кейсе. В тренажёрах нужно собрать чек-лист, ничего не забыв, написать кейс, по которому пройдёт другой человек, и найти ошибки в чужих баг-репортах.
Курсы по теме
Вопросы и ответы
Какие ошибки чаще всего делают в тест-кейсах?
Выносят открытие страницы в предусловие, пишут шаги от первого лица ("открываем" вместо "открыть"), объединяют несколько проверок в одном кейсе, не дают тестовых данных и пишут заголовок, который не отражает суть проверки. Ещё одна частая ошибка – повторять одни и те же шаги во многих кейсах, хотя их можно вынести в предусловие со ссылкой на отдельный кейс.
Можно ли объединять негативные проверки в один тест-кейс?
Нет, каждая негативная проверка идёт отдельным кейсом или отдельной строкой чек-листа, иначе дефект трудно локализовать. Исключение – параметры в TMS: кейс с набором значений при запуске прогона превращается в отдельную проверку на каждое значение.
Нужно ли выносить открытие страницы в предусловие?
Нет. Открыть нужную страницу – первый шаг тест-кейса. В предусловие выносят то, что готовят заранее, например зарегистрированного пользователя или тестовые данные.
Почему в чек-листе сначала идут позитивные проверки?
Времени на тестирование часто мало, и первым делом проверяют, что основные функции работают по позитивному пути. Негативные проверки идут следом, и без них чек-лист неполон.
Можно ли завести один баг-репорт на несколько похожих дефектов?
Можно, если у них одна причина, например одна и та же валидация не срабатывает для кириллицы, латиницы и спецсимволов. Баг заводят на один случай и в комментарии перечисляют, для каких ещё данных он воспроизводится. Дефекты разной природы объединять нельзя.
Как правильно писать шаги в тест-кейсе и баг-репорте?
Инфинитивом и без привязки к человеку: "открыть", "ввести", "нажать". На английском шаг начинается с глагола: Open, Go to, Click. Каждое действие пишут отдельным шагом и указывают, какие данные вводить и какую кнопку нажимать.
Посмотреть программы курсов
Программа каждого курса открыта целиком: видны все модули, уроки и число шагов.