Тестовая документация: какая бывает, зачем нужна, и как мы её создаём

Тестовая документация помогает структурировать работу и фиксировать информацию, которая нужна заинтересованным сторонам на финальном этапе тестирования.

Тестовая документация нужна, чтобы:

  • видеть уровень покрытия проекта тестами, не забывая про функционал;
  • быстро привлечь к работе новые кадры, если тестировщик внезапно покидает проект – временно или навсегда;
  • автоматизировать тестирование: писать скрипты по готовым тест-кейсам куда проще и быстрее.

Кроме того, документация позволяет оценить сроки и реальный объём работ.


Виды тестовой документации

1. Тест-план

Это документ, с которого всё начинается и где описан весь объём работ по тестированию. Удачный тест-план:

  • помогает людям вне тестирования понять детали;
  • устанавливает объект тестирования, график работы, критерии начала и окончания тестирования, стратегию, риски и список необходимых работ;
  • выставляет приоритеты и подчёркивает важные аспекты.

Полноценным считается тест-план, в котором мы подробно прописали все вышеуказанные пункты. Составляет его либо тимлид, либо один из самых опытных тестировщиков, а после тест-план согласовывается со всей командой.

Создать тест-план можно на основе международного стандарта IEEE 829 или разработать документ, максимально исчерпывающе отвечающий на все важные вопросы. А именно:

  • объект тестов, используемая веб-среда;
  • полный перечень системных функций с указанием необходимого оборудования;
  • типы проверок;
  • процесс теста, анализ полученной информации по отношению к запланированным фазам разработки на проекте;
  • риски и пути их разрешения.

Тест-план зачастую используется на долгосрочных проектах и помогает выстроить доверительные отношения с клиентом, показывая, что именно будет делать команда тестирования.

2. Тестовая стратегия

В целом определяет, как продукт будет тестироваться. Дополняет тест-план и содержит общий подход к тестированию. На краткосрочных проектах стратегия может заменить объёмный тест-план.

При формировании данного документа необходимо разложить весь процесс на следующие пункты:

  • подготовка информации;
  • разбор информации;
  • вынесение решения;
  • презентация.

По большому счёту правильная тестовая стратегия:

  • обозначает цели;
  • показывает, что нужно предпринять для достижения результата.

Тестовая стратегия помогает организовать процесс, понять, какими ресурсами мы обладаем, и как целесообразно ими распоряжаться даже в ограниченных условиях.

3. Тест-кейс

Это один из самых популярных артефактов (у нас в Qualitica уж точно). В нём описывается последовательность действий, как проверить определённую часть функционала и прийти к фактическому результату.

Тест-кейсы составляются, как только готов тест-план. Мы с коллегами всегда следим за актуальностью этой документации, так как благодаря тест-кейсам члены команды могут ознакомиться с программой, не изучая весь код.

Тест-кейсы можно разделить на позитивные и негативные. Позитивные проверяют правильность поведения функций, используя корректные данные. Негативный тест-кейс должен вмещать как минимум один некорректный параметр и проверяет чрезвычайные ситуации.

При написании тест-кейсов, мы, как правило, применяем следующие техники тест-дизайна:

  • Эквивалентное разделение. Данный метод позволяет сократить число тестов. Так как для целого класса можно выбрать только одно значение, приняв, что для всех значений в группе результат будет аналогичным.
  • Граничные значения. Эта техника тесно связана с предыдущей и основана на предположении, что многие ошибки могут возникать на границах эквивалентных классов.
  • Матрица или таблица принятия решений. Эту технику мы применяем для более сложных систем. К примеру, двухфакторной аутентификации. Метод хорош тем, что показывает сразу все возможные сценарии.
  • Попарное тестирование (Pairwise testing). Такие кейсы позволяют обнаружить большое количество ошибок при минимуме проверок, потому что мы убираем дублирующие друг друга тесты.
  • Причина и следствие. Относится к проверке базовых действий и получению результата. Так мы проверяем все возможности системы, находим дефекты и делаем нашу техническую документацию ещё лучше.

Исчерпывающего тестирования не существует, но опытные тестировщики Qualitica вплотную приближаются к нему, применяя все вышеуказанные техники, потому что мы умеем верно подбирать и комбинировать необходимое в тест-дизайне.

4. Чек-лист

Список, содержащий ряд необходимых проверок для какой-либо работы. В плотной работе команды тестирования чек-лист помогает помнить о важных деталях. Создаём мы его на этапе готовности тест-плана и определения тестовой стратегии.

Он нужен, чтобы:

  • организовать рабочий процесс;
  • легко проверить выполненную работу.

5. Баг-репорт

Технический документ, без которого не обходится ни одна проверка. Он содержит полное описание дефекта. Включает информацию как о самом баге (короткое описание, серьёзность, приоритет и т. д.), так и об условиях его возникновения.

В зависимости от проекта баг-репорт может составляться в разных баг-трекинговых системах. В Qualitica мы чаще всего пользуемся Jira, Redmine, YouTrack, Trello или просто инструментами для работы с таблицами.

Баг-репорт помогает:

  • отследить и описать ошибки в работе проекта;
  • воспроизвести проблему;
  • понять суть проблемы, её приоритет и важность;
  • эффективно избавляться от багов.

6. Отчёт о результатах тестирования

Здесь обобщаются все результаты работ по тестированию. В том числе:

  • наглядно показаны проблемы и достижения, дефекты и статистика;
  • даются выводы и рекомендации.

Тестовая документация облегчает жизнь проектной команде, а также экономит время на этапах тестирования, сводя их к проверкам, анализу и передаче результатов. Благодаря этому клиенты быстро получают качественно работающий продукт.

Нужно тестирование, за которое можно не переживать? Пишите нам на hello@qualitica.ru, и мы подберём вам лучших специалистов команды. А ещё не забывайте читать блог Qualitica – с нами интересно!

 

Заказать тестирование
Правила обработки персональных данных

1. Персональные данные Посетителя обрабатываются в соответствии с ФЗ «О персональных данных» № 152-ФЗ.

2. При отправке формы обратной связи Посетитель предоставляет следующую информацию: имя, контактный номер телефона, адрес электронной почты.

3. Предоставляя свои персональные данные Владельцу сайта, Посетитель соглашается на их обработку Владельцем сайта, в том числе в целях выполнения Владельцем сайта обязательств перед Посетителем.

4. Под обработкой персональных данных понимается любое действие (операция) или совокупность действий (операций), совершаемых с использованием средств автоматизации или без использования таких средств с персональными данными, включая сбор, запись, систематизацию, накопление, хранение, уточнение (обновление, изменение), извлечение, использование, передачу (в том числе передачу третьим лицам, не исключая трансграничную передачу, если необходимость в ней возникла в ходе исполнения обязательств), обезличивание, блокирование, удаление, уничтожение персональных данных.

5. Владелец сайта вправе использовать технологию «cookies». «Cookies» не содержат конфиденциальную информацию. Посетитель настоящим дает согласие на сбор, анализ и использование cookies, в том числе третьими лицами для целей формирования статистики и оптимизации рекламных сообщений.

6.Владелец сайта получает информацию об ip-адресе Посетителя. Данная информация не используется для установления личности посетителя.

7.Владелец сайта вправе осуществлять записи телефонных разговоров с Покупателем. При этом Владелец сайта обязуется: предотвращать попытки несанкционированного доступа к информации, полученной в ходе телефонных переговоров, и/или передачу ее третьим лицам, не имеющим непосредственного отношения к взаимодействию между Владельцем сайта и Посетителем, в соответствии с п. 4 ст. 16 Федерального закона «Об информации, информационных технологиях и о защите информации».

Письмо отправлено

Наш менеджер свяжется с вами в ближайшее время