Рабочий процесс тестировщика
2026-02-26 17:12 Diff
https://ru.hexlet.io/courses/qa-engineer-workflow/lessons/test-cases-checklists/theory_unit

Любая программа должна соответствовать всем требованиям, которые мы предъявляем к ней — явным и неявным, функциональным и нефункциональным. В сложных проектах список требований может быть огромным — а на каждое требование нужны какие-то тесты.

Чтобы тестировщику было удобнее работать с таким количеством требований, ему нужны инструменты — чеклисты и тест-кейсы. По своей сути, это разные форматы документации. Записав всю необходимую информацию в чеклист или тест-кейс, тестировщик упрощает себе работу — ему не нужно запоминать все требования и держать в голове другие важные детали.

Чек-листы и тест-кейсы снижают вероятность ошибок, связанных с человеческим фактором — причем это работает даже в проектах с неидеальной документацией. В этом уроке мы ближе познакомимся с чеклистами и тест-кейсами. Вы узнаете разницу между ними и научитесь подбирать инструмент под свой проект.

Чеклисты

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

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

В простом случае чеклист выглядит примерно так:

Тест-кейсы

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

В отличие от чеклиста, тест-кейсы не так просты в составлении. Чтобы составить кейс, нужно четко описать необходимые действия, поля для ввода, кнопки и так далее.

Обычно тест-кейс содержит:

  • Предусловия. Они описывают, что нужно сделать до начала проверки
  • Шаги. Это действия, которые надо выполнить во время проверки
  • Ожидаемый результат. Здесь тестировщик описывает, что должно произойти после выполнения действий для проверки

Так это выглядит на практике:

Плюсы и минусы

У обоих инструментов есть свои преимущества:

Чеклисты проще читать. Представим, что мы хотим быстро объяснить разработчику или менеджеру, как прошло тестирование и в каких тестах обнаружены проблемы. В этом случае чеклист намного удобнее тест-кейса. В нем конкретные проблемы описываются одной строчкой: например, «Не работает регистрация по электронной почте в Google Chrome». Это короткая формулировка, к которой не нужны дополнительные объяснения.

Чеклисты проще писать. Чек-лист — это очень простой инструмент. Его можно свести к простому списку из нескольких строк, который можно составить за несколько минут. А вот написание тест-кейсов — это более трудоемкий процесс, потому что нужно составлять длинные таблицы с подробным описанием каждого шага. Более того, если функциональность приложения изменится, придется переделывать тест-кейсы — а это тоже сложный и ресурсоемкий процесс.

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

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

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

Сочетание чеклиста и тест-кейса

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

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

Еще можно ориентироваться на такие факторы:

Размер команды. Представим, что в команде есть несколько тестировщиков, которые постоянно проводят проверки разных частей системы. В таком случае подойдут тест-кейсы — так удобнее работать в команде. А вот если в проекте есть всего один тестировщик, который хорошо знает систему, тогда можно обойтись только чеклистами и сэкономить время.

Сложность проекта. Тест-кейсы не стоит писать, если речь идет о простом проекте с часто меняющейся функциональностью. Здесь больше подойдет чеклист со всеми основными функциями. Но чеклиста не хватит, чтобы проверить сложный проект с множеством неочевидных требований. В таком случае лучше тщательно проработать тест-кейсы и довериться им.

Как писать чеклисты и тест-кейсы

Лучше составить чеклист и тест-кейсы до начала тестирования, так как это две разные деятельности. При написании чеклиста и тест-кейса фокус внимания должен быть на требованиях, в то время как при тестировании должен быть на продукте. Если эти деятельности выполняются одновременно, то это может отрицательно сказаться на качестве тестирования. Составление тест-кейсов - сложная часть тестирования, однако это не означает, что для этого нужно быть гением. Тест-кейсы могут содержать позитивные и негативные сценарии, и часто одному требованию соответствует несколько тест-кейсов. Чеклисты и тест-кейсы не являются требованиями на то, как должен работать продукт, но для их написания нужны определенные знания и опыт. Важно понимать, что эти деятельности разные, и не стоит выполнять их одновременно.

Рассмотрим на примере, как комбинировать чеклисты и тест-кейсы. Этими двумя инструментами можно провести полное тестирование проекта. Процесс может выглядеть так:

  • Начинаем тестирование по общему чеклисту проекта
  • Идем по чеклисту, пока не столкнемся с проблемами
  • Как только мы обнаружили проблему, обращаемся к соответствующему ей тест-кейсу

Этот подход объединяет плюсы обоих инструментов. С одной стороны, мы экономим время — не тестируем во всех подробностях те пункты чеклиста, с которыми все в порядке. С другой стороны, мы тщательно тестируем проблемные места. За счет тест-кейса мы не просто находим ошибку, но и тщательно описываем ее природу. По этому подробному описанию команда разработки сможет быстро разобраться в проблеме и все исправить.