Ответ
Идеально — как можно раньше, на этапе анализа требований и проектирования. Конкретный момент зависит от методологии:
- Гибкие методологии (Agile/Scrum): Тестировщик участвует с первого дня спринта — в планировании, уточнении требований, ежедневных стендапах. Тестирование ведется параллельно с разработкой.
- Каскадная модель (Waterfall): Формальное тестирование начинается после завершения этапа разработки.
Преимущества раннего вовлечения:
- Снижение стоимости: Дефекты, найденные на этапе требований, исправляются дешевле и быстрее.
- Повышение качества требований: Тестировщик помогает формулировать четкие, проверяемые (testable) критерии приемки.
- Проактивность: Возможность выявить риски и противоречия до начала кодирования.
Пример участия на этапе проектирования: Тестировщик может сразу написать сценарий для проверки требования:
Feature: Валидация email при регистрации
Scenario: Ввод некорректного email
Given Поле "Email" на форме регистрации
When Пользователь вводит "user@invalid"
Then Отображается сообщение об ошибке "Введите корректный email"Ответ 18+ 🔞
О, а вот это интересный вопрос, блядь! Когда тестировщику вваливаться в процесс? Да так, чтобы сразу, с самого начала, как только заикнулись про проект!
Смотри, тут всё просто, как три копейки. Если ты припёрся на тусовку, когда уже всё готово и код пахнет свежей краской, то ты, по сути, приходишь на похороны, чтобы покритиковать покойника за не тот галстук. Поздно, блядь!
Идеал — это впиздюриться в процесс как можно раньше, на этапе, когда эти бизнес-аналитики ещё рисуют свои квадратики и стрелочки, и обсуждают, какую кнопку куда поставить. Конкретика зависит от того, в каком цирке вы работаете:
- Гибкие методологии (Agile/Scrum): Тут тестировщик — это не отдельная профессия, а член банды с первого дня спринта. Сидишь на планировании, на уточнении требований, на стендапах, и пока программисты только начали писать код, ты уже придумываешь, как его сломать. Параллельно, блядь, а не после!
- Каскадная модель (Waterfall): Ну, тут классика жанра, ёпта. Формальное тестирование начинается, когда разработчики уже всё сделали, сдали и пошли пить пиво. То есть ты приходишь на готовенькое, и если там пиздец, то исправлять его — это овердохуища времени и нервов.
А теперь, почему это так важно, блядь? Преимущества раннего впендюривания:
- Дешевле, сука! Найденный косяк в документе с требованиями стоит копейки. Найденный косяк в готовом коде, который уже залили на прод — это пиздец, переделывать всё, блядь, и деньги, и сроки горят. Экономия, мать её!
- Требования становятся адекватными. Без тестировщика бизнес может написать: "ну, чтобы работало". А ты такой: "Подожди, мудак, а что значит 'работало'? Какие конкретные шаги? Какие данные? Что на выходе?" И вот уже вместо хуйни получаются чёткие, проверяемые правила.
- Проактивность, ёбана! Ты не ждёшь, пока тебе принесут говно в тазике. Ты заранее видишь риски, противоречия и бред в логике. "Э, пацаны, а вот эта фича полностью противоречит вот тому, что мы делали в прошлом спринте, вы охуели?"
Вот тебе живой пример, как это выглядит на этапе проектирования:
Пока все спорят, тестировщик уже может набросать сценарий проверки. Смотри, не трогаем код, он священен:
Feature: Валидация email при регистрации
Scenario: Ввод некорректного email
Given Поле "Email" на форме регистрации
When Пользователь вводит "user@invalid"
Then Отображается сообщение об ошибке "Введите корректный email"Вот видишь? Ещё ни одной строчки кода не написано, а мы уже всем намекнули: "ребята, а проверку email-а вы не забудьте, а? И сообщение об ошибке должно быть вот таким". И все сразу понимают, что от них хотят. Красота, блядь, а не работа!
Короче, если тестировщика не зовут на старт проекта — это первый звонок, что всё пойдёт по пизде. Сам от себя охуеешь потом, когда начнёшь разгребать последствия.