"Тестирование зависит от контекста"
Вы даже не представляете сколько раз за курс, я упоминаю этот базовый принцип тестирования своим студентам.
Сейчас как раз закончили модуль по тестовой документации и там просто 1000 и один вариант написания чек-листов, кейсов и отчетов о дефекте.
Кто-то объединяет тестовые наборы по функциям, кто-то по ключевым событиям на проекте.
Где-то ожидаемые результаты в чек-листах есть, а где-то их не используют.
На каких-то проектах тестовые данные хранят в отдельных файлах, а где-то только внутри кейса.
Кто-то создает 100 отдельных кейсов на каждую негативную проверку, а кто-то делает один, но использует параметры, которые автоматом создают отдельную проверку на каждый из них при тестовом прогоне.
И еще куча всего, что зависит от конкретного подхода компании, тестировщика и выбранного инструмента по управлению документацией.
И самое удивительное, что каждый по своему прав.
Поэтому не стесняйтесь задавать вопросы в новой команде: а как у вас управляют документацией, есть ли шаблоны, специфические требования.
Не бойтесь сами предлагать улучшения, если знаете: как может быть лучше.
И обсуждайте с командой и разработчиками: какой они хотят видеть документацию и баг-репорты, чтобы всем было одинаково комфортно работать с ними.
Это только один пример, а ведь тестирование не останавливается только на документации.
Поэтому еще и к интервьюеверам, которые профессионально деформировались на своем рабочем месте, ИНДУСТРИЯ НЕ РАБОТАЕТ ТОЛЬКО ПО ПРАВИЛАМ ВАШЕЙ МАЛЕНЬКОЙ КОМАНДЫ.
Слушайте и принимайте альтернативные подходы :)
YouTube | Odysee (без VPN) | Мои курсы | Запись на встречу | Все ТГ-каналы | Поддержать на boosty
