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

Баланс конкретики и общности

Сравните два кейса на одну и ту же проверку загрузки фото:

  • Кейс А: «Открыть C:/test/photo1.jpg размером 2 371 008 байт, загрузить в альбом "Отпуск-2026"…»
  • Кейс Б: «Загрузить фотографию в альбом».

Оба плохие — по противоположным причинам.

Слишком конкретный (А) при каждом прогоне выполняет строго одни и те же действия с одними и теми же данными — а значит, из прогона в прогон проверяет одну и ту же точку. Вероятность найти новую ошибку падает: всё вокруг этой точки остаётся непроверенным. Плюс его дольше писать, читать и поддерживать.

Слишком общий (Б) каждый исполнитель поймёт по-своему — и фактически выполнит другой кейс, не тот, что задумал автор. Новичок перед таким кейсом просто растеряется.

Золотая середина: «Загрузить фотографию допустимого формата и размера, имя файла — с пробелами и кириллицей». Всё необходимое для выполнения есть, а конкретные значения будут немного меняться от прогона к прогону — и это плюс: вариативность данных повышает шанс зацепить ошибку, особенно когда кейс выполняют разные люди.

Показательность: кейс должен уметь находить ошибку

Кейс тем лучше, чем выше вероятность, что он обнаружит проблему. Сравните:

  • «Запустить приложение. Ожидаемый результат: приложение запускается» — непоказательный кейс. Это действие и так выполнится сотни раз при любой работе с продуктом; отдельная проверка почти ничего не добавляет.
  • «Запустить приложение, когда путь к рабочей папке указывает на несуществующий диск. Ожидаемый результат: сообщение с сутью проблемы, корректное завершение» — показательный: он проверяет ситуацию, в которой ошибка вероятна, и которую никто не заденет случайно.

Показательные кейсы выполняют «интересные действия»: сохранить файл на носитель без свободного места, отправить форму с истёкшей сессией, ввести имя из одних пробелов. Тривиальные же сценарии и так покрываются мимоходом. Если весь ваш набор состоит из «открыть — посмотреть — закрыть», он создаёт видимость тестирования, а не тестирование.

Правила формулировок

Ремесленные мелочи, которые отличают опрятный кейс:

  • Безличная форма глаголов: «открыть», «ввести», «нажать» — не «откройте», «введите». Личная форма читается как чужие команды и утомляет.
  • Настоящее время в ожидаемых результатах: «введённое значение отображается в поле» — не «отобразилось» и не «отобразится».
  • Названия элементов, а не их описания: «системная кнопка "Закрыть"», а не «маленький крестик справа вверху»; «двойной щелчок», а не «быстро-быстро дважды нажать».
  • Без слова «проверить» в чек-листах: весь чек-лист — уже список проверок. «Запуск приложения» вместо «Проверить запуск приложения», «деление на ноль» вместо «попытаться поделить на ноль» — короче и информативнее.
  • Не ссылаться на другие кейсы и их шаги. Тот кейс изменят или удалят — ваш молча сломается. Всё нужное — в своих предусловиях.

Два железных правила

Ожидаемый результат всегда описывает корректную работу приложения. Не бывает кейса с ожидаемым результатом «приложение падает с потерей данных» — даже в самом жёстком негативном сценарии. При этом корректная работа вполне может означать сообщение об ошибке: «Невозможно сохранить файл: недостаточно места» — это не баг, это правильное поведение. Багом было бы отсутствие такого сообщения или потеря данных.

Проблема в приготовлениях — не баг приложения. Всё, что описано в предусловиях, готовится без участия тестируемого продукта. Если не удалось подготовить окружение (нет тестового пользователя, сервер недоступен) — это блокирует выполнение кейса, но заводить баг на приложение нельзя: вы ещё не начали его проверять. Как с дегустацией: если магазин закрыт и конфеты купить не удалось — это не значит, что конфеты невкусные.

Типичные логические ошибки

  • «Выдумывание» поведения. В требованиях сказано «отображается каталог по умолчанию», а какой именно — нигде не написано. Нельзя вписать в ожидаемый результат «отображается C:/SavedDocuments» из головы — нужно задать вопрос. Кейс, построенный на догадке, проверяет вашу фантазию, а не продукт.
  • Детализация не по уровню. В smoke-наборе не место проверке каждой кнопки, а сложному редкому сценарию не место в smoke. Кейсы от уровня к уровню должны развиваться («запуск приложения» → «запуск из командной строки, через ярлык, из меню»), а не копироваться дословно.
  • Кейсы не о том приложении. Тестируем фотогалерею на сайте — а в наборе «файл с сетевого диска», «файл, заблокированный другим приложением». Эти кейсы проверяют браузер и операционную систему, но не наш продукт. Спросите себя: чей код здесь может сломаться?
  • Проверка стандартной системной функциональности. Сворачивание окна, системные кнопки, прокрутка — если продукт не делает с ними чего-то особенного, вероятность найти там ошибку близка к нулю, а время на кейсы уходит реальное.

Где это применяется

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

Где спотыкаются начинающие:

  • Гонятся за количеством. Пятьдесят непоказательных кейсов «открыть-закрыть» хуже десяти показательных. Метрика «сколько кейсов написано» без вопроса «что они ловят» — пустая.
  • Прибивают все данные гвоздями. Кейс с жёстко зашитыми значениями из прогона в прогон проверяет одну точку. Оставляйте осмысленную свободу.
  • Пишут ожидаемый результат «приложение выдаёт ошибку» — без указания, какую именно и где. Завтра приложение упадёт с системной ошибкой, и исполнитель честно отметит «пройдено».

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