- Что такое тестовая документация
- В чем ее важность
- Какую тестовую документацию используют QA-команды
- Тест-план
- Чеклист
- Тест-кейс
- Сценарий использования
- Баг-репорт
- Требования
- Как все это работает
Как и в любом другом процессе, документация в QA помогает командам организовать свою работу. С ее помощью мы можем стандартизировать процесс, дать определение терминам, установить основные этапы тестирования и держать всех членов команды в курсе дел.
Что такое тестовая документация?
Тестовая документация — это набор документов, создаваемых перед началом процесса тестирования и непосредственно в процессе. Эти документы описывают покрытие тестами и процесс выполнения тестов, в них указываются необходимые для тестирования вещи, приводится основная терминология и т. д.
В тестовой документации любой член команды может найти полную информацию обо всех действиях, связанных с тестированием (и об уже выполненных, и о запланированных).
В чем важность тестовой документации?
Если тестирование не документируется, это мешает увидеть полную картину проекта. Без четких целей, пошагового плана по их достижению и указания всех важных условий ожидаемый результат будет неясен. В таких условиях у всех может быть разное понимание общей цели и конечного продукта.
Тестовая документация определяет, что для нас важно и почему, какие действия мы должны выполнить и сколько времени у нас есть. Наконец, в документации обозначено, чего должна достичь команда и что сигнализирует об окончании процесса.
И QA-инженеры, и клиенты могут хотеть получить на выходе приложение, вообще не имеющее багов. Но это не достижимая цель, а мечты. Поэтому имеет смысл обсудить, что будет определять конец фазы QA.
Например, мы можем протестировать весь функционал один раз. Или тестировать приложение до тех пор, пока в продакшене не останется критических ошибок. Или быстро проверить критически важные для бизнеса функции, что позволит успеть к дедлайну.
Как правило, попытки оговорить все это в переписке или телефонных переговорах неэффективны. Все дело в человеческом факторе. У кого-то просто слишком много информации, которую нужно обработать и запомнить. Кто-то может неправильно понять договоренности. В результате у каждого появляется своя интерпретация требований и целей.
Отсутствие документации может серьезно повлиять на работу тестировщиков. Это особенно верно при работе со сложными продуктами или при часто меняющихся требованиях.
Непонимание того, как и почему должна вести себя та или иная функция, приводит к большему количеству ошибок. Неправильная расстановка приоритетов может привести к пропуску багов и предоставлению неполных отчетов. Примеры можно продолжать и продолжать.
Какую тестовую документацию используют QA-команды?
Наиболее часто используемые документы — это планы тестирования, чеклисты, тест-кейсы, сценарии использования, баг-репорты и спецификации требований.
План тестирования (test plan)
План тестирования описывает все действия по тестированию в рамках одного проекта. Здесь вы можете найти информацию обо всем, что нужно сделать тестировщику или команде QA в ходе проекта.
В каждом плане тестирования указывается объект тестирования, график работы, критерии начала и окончания тестирования, стратегия, риски и список выполненных работ.
Чеклист (checklist)
Чеклист — это документ, содержащий краткое описание функций, которые должен проверить тестировщик.
Выглядит чеклист как список функций с указанием статуса — результата проверки.
Чеклисты могут использоваться вместо тест-кейсов, поскольку их легче подготовить. Но если вам нужно более конкретное описание процедуры, без тест-кейсов не обойтись.
Тест-кейс (test case)
В тест-кейсе содержатся:
- подробное описание шагов и действий, которые тестировщик должен выполнить для тестирования какой-то одной части функционала,
- критерии прохождения тестов.
Компании могут использовать разные форматы тест-кейсов, но информация в них всегда очень подробная и конкретная.
Сценарий использования (use case)
Use case — это более простой и менее официальный документ. Он описывает сценарий взаимодействия с программным обеспечением.
Каждый юзкейс основан на предположении о том, что пользователь программы будет делать и где он будет кликать. Это позволяет тестировщикам протестировать предполагаемые пути пользователя.
При создании юзкейсов тестировщики учитывают требования и бизнес-цели.
Баг-репорт
Баг-репорт предоставляет полную информацию о баге (его описание, серьезность, приоритет и т. д.) и документирует шаги и условия для воспроизведения этого бага.
Подробный и эффективный баг-репорт значительно увеличивает шансы быстро исправить баг.
Требования (requirements specification)
Спецификация требований или просто требования — это полное описание разрабатываемого программного обеспечения.
В требованиях указываются свойства, качества и особенности разрабатываемой программы. Используя эту информацию, команды могут избежать недоразумений и разногласий.
Как все это работает?
Документы бывают высоко- и низкоуровневые. Все тестировщики могут составлять чеклисты, тест-кейсы и баг-репорты. Это часть их повседневных обязанностей.
А вот подготовка плана тестирования требует дополнительных навыков и опыта. Это задача для опытного специалиста или QA Lead.
Чем крупнее проект, тем больше документации нужно.
Если команда использует для сложного продукта только чеклисты, есть риск неправильного понимания приоритетов и проведения неэффективных тестов. Причина кроется в отсутствии деталей. Чеклист только называет функцию, и каждый тестировщик может интерпретировать объект тестирования и результаты по-своему.
Тестовая документация динамична. Она эффективна только в том случае, если команда QA регулярно ее обновляет.
Если документацию заводят только «чтобы было», никакого смысла в ней нет. В ходе тестирования могут меняться требования и приоритеты. Это влияет на покрытие тестами, необходимые ресурсы и т. д. Если команда не записывает изменения, в результате получаются неэффективные документы и непоследовательность в работе.
Аналогично, со временем устаревают и теряют свою актуальность тест-кейсы и сценарии использования. Может появиться новый функционал, который тоже нужно покрыть тестами. И если вы не будете все тщательно записывать, вы рискуете получить бесполезную документацию.
В заключение
Каждая компания сама определяет, стоит ли создавать тестовую документацию. QA-специалисты могут рекомендовать клиентам это сделать, но последнее слово остается за клиентами.
Что касается преимуществ документирования рабочего процесса, то они вполне очевидны. Описанные нами документы помогают упорядочить имеющуюся информацию. Благодаря этому даже новичок в команде сможет легко разобраться, что к чему. И хотя создание документации требует дополнительного времени, ее отсутствие приведет к куда большим временным затратам.
