Тестовая документация

Тестовая документация:
Внешняя
Внутренняя
Что это?

Документация, которая выходит за пределы департамента качества
Внешняя документация
Замечание/Вопрос (Note, Question)
BUG REPORT
CHANGE REQUEST
USER STORY
SPECIFICATION
Test report

Документация, которая используется внутри департамента качества
Внутренняя документация
TEST PLAN
USE CASE
TEST CASE
CHECK LIST

TEST PLAN
Тест план (Test Plan) — это документ, описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования и заканчивая указанием необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.
Стандарт IEEE829-1998 описывает шаблон Тест плана и пункты, входящие в стандартную структуру документа

TEST PLAN
Хороший тест план должен как минимум описывать следующее:
Что будет тестироваться?
Как будет тестироваться?
Когда будет тестироваться?
Критерии начала тестирования
Критерии окончания тестирования
Необходимое для тестирования оборудование и программные средства
Риски и пути их разрешения

TEST PLAN
В виде традиционного документа с использованием Microsoft Excel или Microsoft Word, Google docs и т. д.
Используя методики визуализации с помощью mind map, таблиц, диаграмм, коротких схем
С помощью профессиональных инструментов – систем для управления процессами на проектах, в том числе этапом тестирования (EasyQA, TestCaseLab, TestLodge)
Способы отображения:

TEST PLAN
Пример использования графической диаграммы для отображения тест-плана

USE CASE
Use case (сценарий использования/пользовательский сценарий) - описание действий, которые может осуществлять система в ответ на внешние воздействия пользователей или других программных систем.
Текстовая форма может состоять из следующих пунктов:
Имя сценария
Цель
Актеры
Предварительные условия
Активаторы
Порядок Событий
Альтернативные пути и дополнения
Диаграмма:
Имя
Актеры
Варианты использования
Комментарии
Текcт
Диаграмма

USE CASE

USE CASE

USE CASE

TEST CASE
Test Case (Тестовый случай) — это последовательность действий направленная на проверку какого-либо функционала, описывающая как придти к фактическому результату
Позитивный тест кейс использует только корректные данные и проверяет, что приложение правильно выполнило вызываемую функцию.
Негативный тест кейс применяется для тестирования, в рамках которого применяются сценарии, что соответствует внештатному поведению тестируемой системы.
Набор тест-кейсов называется тест-комплектом (test suite)

ЖИЗНЕННЫЙ ЦИКЛ
TEST CASE
Test case result:
1. Положительный исход (PASS), если ФР равен ОР, либо
2. Отрицательный исход (FAIL), если ФР не равен ОР: найден баг!

TEST CASE
Стандартные атрибуты тест-кейса
Test case number (ID)*
Приоритет Тест-кейса (Test Case Priority)
Связанное с тест-кейсом требование (requirement)
Модуль и подмодуль приложения
Test case name (Summary/Title) *
Preсonditions*
Steps*
Expected Result*
История редактирования (Revision History)

TEST CASE

TEST CASE
Чего не должно быть в тест-кейсе
Зависимостей от других тест-кейсов
Нечеткой формулировки шагов или ожидаемого результата
Отсутствия необходимой для прохождения тест-кейса информации
Излишней детализации

TEST CASE
В виде традиционного документа с использованием Microsoft Excel или Microsoft Word
Online документы - Google docs, Google spreadsheets
Профессиональные инструменты (TestRail, VersionOne)
Способы хранения

CHECK LIST
Check list (чек-лист) — это документ, описывающий что должно быть протестировано в тезисной форме без обращения к деталям и четко сформулированным шагам
Основные элементы чек-листа:
список необходимых проверок
сборка проекта на которой производилась проверка (Build)
тестовое окружение (Win/MC OS/browser/etc.)
ресурс (QA Engineer)
статус (результат) проверки

CHECK LIST
Status
Skipped – проверяться не будет по какой-либо причине
Not run – еще не проверено
Blocked – невозможно проверить, т.к. один из багов блокирует текущую проверку
In Progress – текущий пункт, над которым работает тестировщик
Passed– проверка пройдена успешно, багов не найдено
Failed – найден
один или более
багов

CHECK LIST
В виде традиционного документа с использованием Microsoft Excel или Microsoft Word, Google docs
Используя методики визуализации с помощью mind map, таблиц, диаграмм
С помощью профессиональных инструментов (например, Sitechco)
Способы отображения:

CHECK LIST
Полезные советы при оформлении чек-листа:
Сокращайте. Это не сочинение. Это просто набор пунктов. Чёткость формулировок!
Удаляйте ненужное. Включайте только то, что вы можете забыть.
Выделяйте важное. Капслоком или жирным шрифтом. Главное — не переборщите.
Постоянно редактируйте. Чек-лист должен быть актуальным.

TEST CASE vs CHECK LIST

TEST CASE vs CHECK LIST
Выбор в пользу одного из этих типов документов зависит от следующих факторов:
Длительность проекта
Сроки на выполнение тестирования
Запрос менеджмента
Вид тестирования
Выбор команды
Наличие и формат требований

Источники информации для тестировщика
Внешняя документация (User story, спецификация, change request)
Личное общение с участниками проекта (менеджерами, программистами, бизнес аналитиками и т.д.)
Исследование (результат собственного опыта, полученного
в ходе экспериментов над программой)
Аналогичные проекты
Черновики руководства пользователя, заметки разработчиков, макеты, e-mails и т.д.)