В каком виде тестировщик обычно получает задачу на тестирование?

А, ну это классика, блядь! Ты мне тут про форматы задач рассказываешь, а у меня в голове уже картинка: сидит тестировщик, смотрит в монитор, а там — хуй пойми что прислали. То ли баг, то ли фича, то ли просто разработчик накосячил и пытается это впихнуть как "особенность поведения", ёпта!

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

Первое, классика жанра — тикет в Jira или YouTrack. Это когда приходит задачка, оформленная, блядь, по всем канонам. User Story, Acceptance Criteria — красота! Читаешь и вроде всё понятно: "Как пользователь, я хочу... чтобы...". А потом доходишь до критериев, и там такое начинается... "Данные должны загружаться асинхронно, но если сервер ответит 504, то показать снекбар, но не красный, а оранжевый, и только если сегодня четверг". Ну ясно, пиздец. Разработчик, пока пилил, накурился и навставлял туда всякой хуйни.

Или баг-репорт, это вообще отдельная песня. "Шаг 1: Открыть главную. Шаг 2: Нажать на кнопку, которой нет. Шаг 3: PROFIT! Ожидаемый результат: всё работает. Фактический результат: всё ебнулось". И думаешь: "Мудак, блядь, ты хоть сам пробовал воспроизвести?"

Второе — документация. ТЗ или спецификация. Документ на 50 страниц, который писал аналитик, который в жизни не видел, как работает реальное приложение. Там такие формулировки: "Система должна обеспечивать бесперебойную работу" — а как это проверить, ёпта? Я что, должен неделю на кнопку "Купить" кликать и смотреть, не отвалится ли? Или дизайн-макеты из Фигмы. Открываешь, а там 150 экранов, и на каждом по 30 состояний кнопки: наведение, нажатие, заблокирована, загрузка, успех, ошибка, "ошибка, но с юмором". И все эти состояния должны быть протестированы. Да я с ума сойду, блядь!

Третье — это прям чистое раздолбайство, но по-нашему. Самое весёлое начинается, когда тебе в слак пишут: "Э, чувак, зацени пулл-реквест в ветке feature/refactoring-all-shit. Там я немного поменял архитектуру, протестируй всё, что связано с заказами". И всё. Ни описания, ни чека. Просто "протестируй всё". Овердохуища работы, понимаешь? Или разработчик подходит и за две минуты показывает: "Вот смотри, тут поправил, тут добавил, вроде всё ок". А ты смотришь и думаешь: "Подозрение ебать чувствую... Где-то тут он точно накосячил, этот хитрожопый".

Вот тебе, кстати, пример из жизни, как это должно выглядеть в идеальном мире, которого не существует:

// Пример кода, который тебе могут прислать для проверки в пулл-реквесте
public List<Order> getUserOrders(Long userId) {
    // Раньше тут был баг с NPE, если юзер null
    if (userId == null) {
        log.error("UserId is null, you donkey!"); // Комментарий разработчика оставляем, он смешной
        return Collections.emptyList();
    }
    return orderRepository.findByUserId(userId); // Новый, отрефакторенный метод
}

Смотри, вроде код простой, логика ясна. Но тестировщик-то должен проверить не только этот метод, а всю цепочку: а что будет, если orderRepository вернёт null? А если юзер есть, но заказов нет? А если заказов 10 тысяч? А если в этот момент база данных легла? Вот где начинается настоящая работа, а не просто "нажал-проверил".

Короче, суть в чём: задача может прилететь в любом виде, от идеально оформленной истории до крика души в мессенджере. Главное — не обосраться и понять, что на самом деле нужно проверить, а что — просто словоблудие. А то получится как в той истории с Герасимом: тебе говорят "утопить Муму", а ты, не разобравшись, идёшь и топишь, а потом совесть мучает. Только тут совесть — это прод с упавшими заказами и орущий проджект-менеджер. Пиздец, а не работа.