Всем шКодникам привет!
Друзья, мы с вами знаем достаточно много. Мы уже как минимум знаем, кто такие тестировщики, чем они занимаются. Мы узнали большую часть инструментов, которыми они пользуются. Это значит, что мы двигаемся в правильном направлении и не время отступать😊
Напомним себе еще раз про стадии тестирования:
- Test Management (планирование работ).
- Test Design (проектирование тестов).
- Test Execution (выполнение тестов).
- Test Analysis (анализ результатов тестирования).
Одну половину мы уже прошли, а сегодня добьем еще и вторую.
Итак, Test Execution или выполнение тестов.
На этом этапе, как мы и проговаривали ранее, мы проходим тест-кейсы и чек-листы, которые написали на предыдущем этапе. Все вроде бы просто, но есть одна загвоздка. Что если при прохождении тестов, мы нашли какой-то баг/ошибку? Это конечно же значит, что мы должны ее зафиксировать. И для этого есть специальный документ, который называется баг-репорт (Bug report).
Баг-репорт – это документ, который описывает суть самого бага/ошибки и шаги, которые привели к нему с указанием всех возможных причин и ожидаемого результата. В целом баг-репорт может включать (а может и не включать, тут все зависит от компании):
- Номер баг-репорта.
- Название, в котором кратко излагаем суть бага.
- Короткое описание.
- Номер версии.
- Серьезность. Серьезность подразумевает то, насколько серьезная ошибка, как бы это по-дурацки не звучало😊Чтобы стало понятнее, например, опечатка в тексте на главной странице сайта – не серьезная ошибка, а вот нерабочий функционал по авторизации на сайте – уже серьезнее. Т.е. грубо говоря, серьезность показывает, насколько тяжело будет исправить этот баг.
- Приоритет. Приоритет можно легко спутать с серьезностью, но это принципиально разные вещи. Приоритет говорит о том, в какую очередь необходимо исправить баг, но это не обязательно должно быть что-то очень тяжелое. Интересный пример: Опечатка в тексте на сайте apple.com будет расценена, как баг с низкой серьезностью, так как легко исправить текст, но с высоким приоритетом, так как такая ошибка очень сильно может ударить по авторитету компании.
- Автор, кто нашел ошибку.
- Ответственный, на кого назначена ошибка для исправления.
- Шаги воспроизведения. По сути, если мы нашли баг во время прогона тест-кейса, то мы просто копируем шаги из него и вставляет в баг-репорт.
- Ожидаемый результат. Точно также, можем взять из нашего тест-кейса.
- Фактический результат. Т.е. это тот результат, который получился по факту. Он сравнивается с ожидаемым результатом.
- Скриншоты/или короткое видео. Очень желательно добавлять скриншоты, на котором будет явно видно, в чем суть бага.
- И еще любую другую информацию, которая поможет понять в чем суть и причины ошибки. Потом за это вас будут любить разработчики, которые эти баги исправляют😊
Баг репорт служит для того, чтобы любой человек, который открыл его, понял в чем суть бага. В основном, конечно, подробный баг репорт нужен именно разработчикам.
Таким образом, на этапе выполнения тестов (test execution) мы просто прогоняем наши тесты, если нашли баг – фиксируем его в баг-репорт, все просто.
Дальше поговорим про заключительную стадию тестирования – анализ результатов тестирования (Test Analysis).
Данная стадия подразумевает, что мы пишем информацию о результатах проведенного тестирования и, конечно же, для этого есть специальный документ - отчет о тестировании.
Честно говоря, во многих компаниях отчет о тестировании, про который мы будем сейчас говорить, не существует. Однако про него нужно знать и нужно иметь его ввиду, потому что может и не в таком виде, но результат проведенного тестирования так или иначе выдавать мы должны. Так что сейчас будем учиться создавать идеальный отчет о тестировании.
В самом широком понятии, отчет о тестировании – это документ, который описывает результат проведенного тестирования. В идеальном мире, он должен формироваться а) с определенной периодичностью и б) по завершению какого-либо проекта, но на практике случается по-разному.
Отчет для тестирования служит для того, чтобы оценить текущее качество продукта и на основе этой информации принять решение о дальнейшей его судьбе.
В состав отчета может быть включена такая информация (и как и всегда, может и не быть включена😊):
- Состав тестировщиков, проводивших тестирование, и их роли/ответственные зоны.
- Описание процесса тестирования.
- Краткое описание.
- Расписание или график.
- Рекомендации.
- Информация о найденных багах и ошибках.
- И другая полезная информация, которая необходима лицам, которые будут читать ваш отчет.
Ну что, друзья, вот мы и разобрали все основные документы, которые готовит тестировщик:
1) Тест план.
2) Тест-кейсы и чеклисты.
3) Баг-репорты.
4) И отчет о тестировании.
Все это очень важные темы, и вопросами по ним на собеседовании стреляют как из автомата, так что советую вам хорошенько разобраться в этих темах.
Узнавайте о выходе новых статей у меня в telegram канале и конечно же всем продуктивной и насыщенной недели! 😊
Итак, что мы узнали сегодня:
1. Мы узнали, как составлять баг-репорты и отчеты о тестировании.