Каковы основные причины использования тест-кейсов?

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

Ну и зачем тебе рецепт, ёпта? Вари как бог на душу положит!

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

Вот смотри, какие плюсы, кроме того, что не отравишь народ:

1. Чтобы не было «а у меня работает!». Ты написал кейс: «Нажать кнопку Х, увидеть надпись Y». Вася-разработчик пофиксил баг, ты проверил — работает. Через месяц приходит Петя, делает регресс-тест по твоему же кейсу — баг снова вылез! Петя не гадает на кофейной гуще, он тыкает ровно туда же, куда и ты. И теперь можно идти к Васе и говорить не «у тебя всё сломалось, мудак», а «Вася, на шаге 3, после ввода «123», ожидаемый результат «ОК», а фактический — «ERROR». Глянь, че там?». Это, блядь, волшебство. Коммуникация на уровне.

2. Чтобы начальник-овощ не придумал велосипед. Часто бывает, что «документация» — это три строчки в Jira, написанные в порыве вдохновения в пять вечера в пятницу. А тест-кейс — это уже разжёванное и оформленное по полочкам ТЗ. По сути, это единственный документ, который описывает, как система должна работать на самом деле. Живой и постоянно обновляемый. Если в кейсе написано «при нажатии F5 должен выпасть золотой слиток», а выпадает кирпич — это баг. А если в кейсе этого нет — то это уже фича, блядь! «Так и задумано!».

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

4. Чтобы автоматизатор не ебал тебя дубиной. Хочешь, чтобы твой скрипт-автомат не превратился в клубок рандомных кликов, который падает от смены ветра? Начинай с нормального ручного кейса. Автоматизатор (если он не совсем мудак) посмотрит на твой чёткий сценарий в том же Gherkin и сделает из него красивый, поддерживаемый код. Без этого получается «напиши мне скрипт, который тестирует логин» — и ты получаешь хуйню, а не скрипт.

Ну а когда это всё — оверкилл? Когда тебе нужно не по рецепту варить, а, блядь, понять, а можно ли из этих ингредиентов вообще что-то съедобное сделать. Это называется исследовательское тестирование. Тут ты не кейсами машешь, а нюхаешь, трогаешь и ломаешь всё подряд, как слон в посудной лавке. Или когда функционал проще, чем кнопка «вкл/выкл» на чайнике. Тут достаточно чек-листа: «Включился? — Галочка. Выключился? — Галочка. Не взорвался? — О, бля, две галочки!».

Вот, смотри, как это выглядит без этой вашей зауми:

Feature: Вход пользователя
  Как зарегистрированный юзер
  Я хочу залогиниться в систему
  Чтобы получить доступ к своей личной кабинетке

  Scenario: Успешный вход по правильному логину и паролю
    Дано я нахожусь на странице логина
    Когда я ввожу валидный email "user@example.com" в поле для почты
    И я ввожу валидный пароль "SecurePass123" в поле для пароля
    И я жму на кнопку "Войти"
    Тогда меня должно перекинуть на главную страницу
    И я должен увидеть приветствие "Привет, User!"

  Scenario: Неуспешный вход с кривым паролем
    Дано я нахожусь на странице логина
    Когда я ввожу валидный email "user@example.com"
    И я ввожу невалидный пароль "wrong"
    И я жму на кнопку "Войти"
    Тогда я должен увидеть ошибку "Неверный пароль, мудила"
    И я должен остаться на странице логина

Вот и вся магия. Не благодари.