🌴 1. Проект-мечта
Это тот самый редкий случай, когда в проекте есть всё: понятные требования, бизнес- и системные аналитики, команда тестирования, строгая приемка и демо.
Тестирование тут не вспоминают в последний день перед релизом, а ведут параллельно с аналитикой и разработкой. Пока требования проектируются, тестировщики уже их читают, задают вопросы, ищут противоречия и готовятся к проверкам.
В общем, это почти идеальный мир и ваша работа оценивается объективно, как написано в требованиях так и работает на проде.
В такой проект высокий отбор и проверяют на собесе больше, чем нужно для работы.
🦆 2. Проект «требования вроде есть, но их нет»
Здесь заказчик есть власть, требования вроде тоже найти можно, но они уже пол года неактуальны.
Проверять приходится по интуиции, здравому смыслу и внутреннему ощущению прекрасного. Здесь экстраверты чувствуют себя комфортно, ведь общаться нужно со всеми по пять раз на дню. При этом очевидные баги могут не исправлять, потому что «заказчик не говорил, что так нельзя». Зато если кнопка на два пикселя больше, чем хотелось бы, это уже почти катастрофа.
На таких проектах тестировщик не просто ищет баги, а пытается выжить между обвинениями пропуска бага и доказательствами, что об этом никто не говорил.
Обычно стараются взять в проект как можно быстрее и расхвалить команду как дружную и коммуникабельную.
💩 3. Проект «сделайте как у конкурентов»
Тут требования обычно звучат просто: «Сделайте как у них, только лучше». А дальше начинается игра "Каждый сам за себя".
Если находишь странное поведение, сначала идешь смотреть, как это работает у конкурентов. Если у них так же — значит, не баг. Если у них иначе — начинается обсуждение, надо ли нам так же или «потом переделаем, никто не заметит».
В итоге сервис конкурента становится сыном маминой подруги, на которого нужно равняться, и не важно, что у них наш годовой бюджет рассчитан на месяц работы.
Тут отбор между как у первой и второй командой: понтов выше крыши, а экспертизы в разработке ноль, все на коленке.
А в какой работаешь ты?