Для начала ответим на вопрос: Для чего необходима тестовая документация и что это такое?
Тестовая документация - документ, облегчающий жизнь проектной команде.
Нужна она для:
- Обеспечения стабильности покрытия требований проверками;
- Сэкономить время на этапах тестирования, сводя их к проведению проверок, анализу и передачи результатов;
- Снизаить входной уровень квалификации тестироващика для проведения проверок.
Тестовая документация бывает двух видов: внешняя и внутренняя.
Внутренняя:
- тест- план
- тестовый комплект
- чек - лист
- тест - кейс
Внешняя:
- баг - репорт
- замечание
- запрос на изменение
- отчет о тестировании (тест - репорт)
На практике тестовая документация еще называется тестовые артефакты или артефакты тестирования. Рассмотрим наиболее распрастраненные: чек - листы, тест - кейсы и баг - репорты.
Чек - лис - список, содержащий ряд необходимых проверок для какой- либо работы.
В тестировании чек - лист - список проверок для тестирования продукта.
Чек- листы устроены предельно просто. Любой из них может содержать перечень блоков, секций, страниц, которые необходимо протестировать. Выбранные поля обязательно отмечаются статусами.
Преимущества чек - листов:
- улучшить представление о системе в целом, видеть статус ее готовности
- понимать объем проделанной и предстоящей работы
- не повторяться в проверках и не упустить ничего важного в процессе тестирования
Разновидности
специальные создаются и используются для определнного проектра. Вот примеры пунктов специального чек-листа:
-при наведении курсора на пункт меню “Товары”, должен меняться цвет на синий. Указатель должен менять форму на pointer;
-если пользователь открыл страницу “Ваша корзина” и в корзине присутствует хотя бы один товар, то должно показываться уведомление.
Такие чек-листы не подходят к использованию на других проектах.
универсальные подхлдят для тестирования проектов одного типа. Для универсального чек-листа составляется абстрактный список проверок. Пункты универсального чек-листа могут быть такими:
- пользователь может перейти в раздел “Товары”;
- оплата должна совершаться;
- товар должен добавляться в корзину;
- ссылки при наведении подчеркиваются;
- валидатор верстки показывает отсутствие ошибок и т.п.
Тест - кейсы - это такое описание проверки работы системы, которое может выполнить любой человек из команды, будь то тестировщик, разработчик, аналитик или даже бизнес-заказчик.
Тест - кейс - инструмент тестировщика, предназначенный для проверки и документирования одного или более ожидаемых результатов.
Написать тест - кейс значит создать текстовое описания процесса тестирования какой- либо фукции проекта.
Тест- кейсы нужны, чтобы каждый член команды мог проверить программу и познакомиться с ней, не читая весь код, а изучив только тест - кейс.
Тест - кейс должен быть независим от других тест - кейсов из того же или других тест - комплектов.
Исполнение тест - кейса не считается завершенным, если исполнитель не смог пройти все шаги. Исполнение завершается положительным или отрицательным результатом, причем отрицательный является наиболее желательным, так как мы нашли баг.
Тест - кейсы проверяют не болеет одной идеи. При этом два или более ожидаемых результата легитимны.
К плохому стилю относится:
- зависимость тест - кейсов друг от друга;
- нечеткая формулировка шагов;
- нечеткая формулировка идеи тест - кейса / ожидаемого результата.
Хороший стиль - объединять тест - кейсы в тест - комплекты. (как правило один тест - комплект - один файл. Как правило, один тест - комплект включает в себя тест - кейсы родственные друг другу, что они проверяют определенный уасток интернет- проекта, описанные в определенном спеке.
Баг - репорт: правила составления - документ/случай, в котором описывается ситуация, последовательность шагов приведшая к возникновению ошибки на тестируемом ПО. Чаще всего требуется описание ожидаемого результата для такой конкретной последовательности шагов, который будет являться правильным.
Баг - репорт заводит каждый тестировщик, когда обнаруживает ошибку. Дословно с английского bug report - отчет об ошибке.
Это техничекий документ, поэтому создается по определенной структуре и правилам. Формат такого документа может меняться в зависимости от компании, в которой работает тестировщик, но суть всегда сохраняется.
Значиными полями в системе бег-трекинга яявляются Серьезность (Severity)- это атрибут, характеризующий влияние деффекта на работоспособность приложения. Приоритет (Priority) - атрибут, указывабщий на очередность выполнения задач по устранению деффекта. Чем выше приоритет, тем быстрее неоходимо исправить баг.
Градация серьезности деффекта:
1. Блокирующая (blocker)
Блокирующая ошибка, приводящая прилжение в нерабочее состояние, в рузельтате которого дольнейшая работа с тестируемой системой становится невозможной.
2. Критическая (Сritical)
Критическая ошибка, неправильно работающая ключевая бизнес логика,дыра в системе безопасности, проблема, приведшая к временному падению сервера или приводящая в нерабочее состояние некоторую часть системы, без возможности решения проблемы, используя другие входные точки. Решение проблемы необходимо для дальнейшей работы с ключевыми функциями тестируемой системой.
3. Значительная (Major)
Значительная ошибка, часть основной бизнес логики работает некорректно. Ошибка не критична или есть возможность для работы с тестируемой функцией, используя другие входные точки.
4. Незначительная ( Minor)
Незначительная ошибка, не нарушающая бизнес логику тестируемой части приложения, очевидная проблема пользовательского интерфейса.
5. Тривиальная (Trivial)
Тривиальная ошибка, не касающаяся бизнес логики приложения, плохо воспроизводимая проблема, малозаметная посредствам пользовательского интерфейса, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта.
Градация приоритета деффекта
Высокий (High)
Ошибка должна быть исправлена как можно быстрее, т.к. ее наличие является критической для проекта.
Средний (Medium)
Ошибка должна быть исправлена, ее наличие не является критичной, но требует обязательного решения.
Низкий (Low)
Ошибка должна быть исправлена, ее наличие не является критичной, и не требует срочного решения.
Правила составления
Баг репорт — это технический документ. Поэтому он должен быть написан в техническом стиле: без художественности, четко и понятно.
Хороший баг - репорт позволяет а)воспроизвести ошибку б)понять в чем проблема и степень ее важности.
Хороший баг - репорт должен содержать следующие поля:Defect ID (присваиваемый багу номер), Reporter Name (кто завел баг), Defect Reported Date (дата заведения бага), Who Detected (кто нашел баг), Project Name (название проекта), Release/Build Version (версия билда, в котором найден баг), Defect/Enhancement (сам баг), Environment (среда), Priority (приоритет), Severity (критичность), Status (статус), Description (описание), Steps To Reproduce (шаги воспроизведения), URL (ссылка), Expected Result (ожидаемый результат), Actual Result (действительный результат).
Первое, что необходимо сделать ДО заведения бага — воспроизвести его два-три раза, воспроизвести на различных конфигурациях и выявить наиболее актуальный STR ( шаги воспроизведени).
Чек - лист, который поможет составить правильный баг-репорт:
- Воспроизвел баг 2-3 раза
- Проверил баг на дубликаты в бак - трекре
- Проверил баг на всех возможнй модулях
- Написал подробный и понятный STR
- Сделал подробное и понят ное описание бага
- Приложил поятный сриншот/видео с багом
- Не пропустил никакие указаные поля
Хороший баг - репорт должен быть простым и понятные - весь секрет!