Тестовая документация помогает структурировать работу и фиксировать информацию, которая нужна заинтересованным сторонам на финальном этапе тестирования.
Тестовая документация нужна, чтобы:
- видеть уровень покрытия проекта тестами, не забывая про функционал;
- быстро привлечь к работе новые кадры, если тестировщик внезапно покидает проект – временно или навсегда;
- автоматизировать тестирование: писать скрипты по готовым тест-кейсам куда проще и быстрее.
Кроме того, документация позволяет оценить сроки и реальный объём работ.
Виды тестовой документации
1. Тест-план
Это документ, с которого всё начинается и где описан весь объём работ по тестированию. Удачный тест-план:
- помогает людям вне тестирования понять детали;
- устанавливает объект тестирования, график работы, критерии начала и окончания тестирования, стратегию, риски и список необходимых работ;
- выставляет приоритеты и подчёркивает важные аспекты.
Полноценным считается тест-план, в котором мы подробно прописали все вышеуказанные пункты. Составляет его либо тимлид, либо один из самых опытных тестировщиков, а после тест-план согласовывается со всей командой.
Создать тест-план можно на основе международного стандарта IEEE 829 или разработать документ, максимально исчерпывающе отвечающий на все важные вопросы. А именно:
- объект тестов, используемая веб-среда;
- полный перечень системных функций с указанием необходимого оборудования;
- типы проверок;
- процесс теста, анализ полученной информации по отношению к запланированным фазам разработки на проекте;
- риски и пути их разрешения.
Тест-план зачастую используется на долгосрочных проектах и помогает выстроить доверительные отношения с клиентом, показывая, что именно будет делать команда тестирования.
2. Тестовая стратегия
В целом определяет, как продукт будет тестироваться. Дополняет тест-план и содержит общий подход к тестированию. На краткосрочных проектах стратегия может заменить объёмный тест-план.
При формировании данного документа необходимо разложить весь процесс на следующие пункты:
- подготовка информации;
- разбор информации;
- вынесение решения;
- презентация.
По большому счёту правильная тестовая стратегия:
- обозначает цели;
- показывает, что нужно предпринять для достижения результата.
Тестовая стратегия помогает организовать процесс, понять, какими ресурсами мы обладаем, и как целесообразно ими распоряжаться даже в ограниченных условиях.
3. Тест-кейс
Это один из самых популярных артефактов (у нас в Qualitica уж точно). В нём описывается последовательность действий, как проверить определённую часть функционала и прийти к фактическому результату.
Тест-кейсы составляются, как только готов тест-план. Мы с коллегами всегда следим за актуальностью этой документации, так как благодаря тест-кейсам члены команды могут ознакомиться с программой, не изучая весь код.
Тест-кейсы можно разделить на позитивные и негативные. Позитивные проверяют правильность поведения функций, используя корректные данные. Негативный тест-кейс должен вмещать как минимум один некорректный параметр и проверяет чрезвычайные ситуации.
При написании тест-кейсов, мы, как правило, применяем следующие техники тест-дизайна:
- Эквивалентное разделение. Данный метод позволяет сократить число тестов. Так как для целого класса можно выбрать только одно значение, приняв, что для всех значений в группе результат будет аналогичным.
- Граничные значения. Эта техника тесно связана с предыдущей и основана на предположении, что многие ошибки могут возникать на границах эквивалентных классов.
- Матрица или таблица принятия решений. Эту технику мы применяем для более сложных систем. К примеру, двухфакторной аутентификации. Метод хорош тем, что показывает сразу все возможные сценарии.
- Попарное тестирование (Pairwise testing). Такие кейсы позволяют обнаружить большое количество ошибок при минимуме проверок, потому что мы убираем дублирующие друг друга тесты.
- Причина и следствие. Относится к проверке базовых действий и получению результата. Так мы проверяем все возможности системы, находим дефекты и делаем нашу техническую документацию ещё лучше.
Исчерпывающего тестирования не существует, но опытные тестировщики Qualitica вплотную приближаются к нему, применяя все вышеуказанные техники, потому что мы умеем верно подбирать и комбинировать необходимое в тест-дизайне.
4. Чек-лист
Список, содержащий ряд необходимых проверок для какой-либо работы. В плотной работе команды тестирования чек-лист помогает помнить о важных деталях. Создаём мы его на этапе готовности тест-плана и определения тестовой стратегии.
Он нужен, чтобы:
- организовать рабочий процесс;
- легко проверить выполненную работу.
5. Баг-репорт
Технический документ, без которого не обходится ни одна проверка. Он содержит полное описание дефекта. Включает информацию как о самом баге (короткое описание, серьёзность, приоритет и т. д.), так и об условиях его возникновения.
В зависимости от проекта баг-репорт может составляться в разных баг-трекинговых системах. В Qualitica мы чаще всего пользуемся Jira, Redmine, YouTrack, Trello или просто инструментами для работы с таблицами.
Баг-репорт помогает:
- отследить и описать ошибки в работе проекта;
- воспроизвести проблему;
- понять суть проблемы, её приоритет и важность;
- эффективно избавляться от багов.
6. Отчёт о результатах тестирования
Здесь обобщаются все результаты работ по тестированию. В том числе:
- наглядно показаны проблемы и достижения, дефекты и статистика;
- даются выводы и рекомендации.
Тестовая документация облегчает жизнь проектной команде, а также экономит время на этапах тестирования, сводя их к проверкам, анализу и передаче результатов. Благодаря этому клиенты быстро получают качественно работающий продукт.
Нужно тестирование, за которое можно не переживать? Пишите нам на hello@qualitica.ru, и мы подберём вам лучших специалистов команды. А ещё не забывайте читать блог Qualitica – с нами интересно!
