Ответ
Самые ранние и дешевые для исправления дефекты обнаруживаются на стадиях Анализа требований и Проектирования (архитектуры и дизайна).
Какие дефекты ищут на ранних стадиях:
-
Дефекты в требованиях:
- Неполнота: Упущены важные сценарии или бизнес-правила.
- Неоднозначность: Формулировки, которые можно трактовать по-разному.
- Противоречивость: Разные требования конфликтуют между собой.
- Нетестируемость: Невозможно создать объективный критерий проверки.
-
Дефекты в архитектуре и дизайне:
- Масштабируемость: Система не сможет выдержать прогнозируемую нагрузку.
- Безопасность: Заложены уязвимости на уровне проектных решений.
- Технологический выбор: Неподходящий стек технологий для задачи.
Методы раннего обнаружения (превентивное тестирование):
- Статическое тестирование (Review): Ревью требований (SRS), пользовательских историй (User Stories), архитектурных диаграмм и API-спецификаций (OpenAPI/Swagger).
- Моделирование и прототипирование: Создание wireframes или clickable-прототипов для проверки логики интерфейса.
Пример дефекта в требовании и его последствия:
ИСХОДНОЕ ТРЕБОВАНИЕ: "Пароль пользователя должен быть не менее 6 символов."
ПРОБЛЕМЫ (дефекты требования):
1. Неоднозначность: Какие символы допустимы? (только буквы? цифры? Unicode?)
2. Неполнота: Есть ли ограничение по максимальной длине?
3. Нетестируемость: Как проверить "символ" для эмодзи?
ПОСЛЕДСТВИЯ: Разработчики и тестировщики будут трактовать требование по-разному,
что приведет к дефектам в коде и спорам при приемке.
ИСПРАВЛЕННОЕ ТРЕБОВАНИЕ: "Пароль должен содержать от 8 до 64 символов,
допустимы буквы латинского алфавита (a-z, A-Z), цифры (0-9) и символы !@#$%&*."Вывод: Раннее вовлечение QA-инженеров в процессы анализа и проектирования (Shift-Left) значительно снижает стоимость исправления дефектов и риски срыва сроков.
Ответ 18+ 🔞
Да ты послушай, какая история-то интересная вырисовывается! Прямо как в том анекдоте про архитектора и говно в проекте — только тут про нас, айтишников.
Вот смотри, вся соль в том, что самые жирные косяки, которые потом обходятся в овердохуища денег и нервов, закладываются ещё на берегу. Прямо когда все умные такие в пиджаках рисуют квадратики и стрелочки на доске, попивая латте. И знаешь, где они прячутся, эти гадёныши?
Во-первых, в этих ваших «требованиях». Там просто раздолье для пиздеца:
- Неполнота. Забыли прописать, что будет, если пользователь — конченый долбоёб — нажмёт все кнопки разом? Забудьте, потом получите баг на продакшене.
- Неоднозначность. Написали «система должна работать быстро». А что это значит, ёпта? Для кого быстро? Для черепахи или для гепарда? Разработчик сделает «быстро» по-своему, тестировщик проверит «быстро» по-своему, а заказчик получит «быстро» по-своему. И все потом будут охуевать друг с друга.
- Противоречивость. В одном месте говорят «кнопка должна быть зелёная», в другом — «все кнопки в этом модуле синие». И кто прав? Пизда, вот кто прав. Мартышлюшка, которая требования писала.
- Нетестируемость. Любимая фраза: «должно быть удобно». А как это проверить, блядь? Пригласить фокус-группу хипстеров и спросить, удобно ли? Да ну нахуй.
Во-вторых, в архитектуре и дизайне. Тут уже страшнее. Это не баг в кнопке — это пиздец всему проекту.
- Выбрали технологию, которая с нагрузкой в 10 пользователей уже ляжет и не встанет. Накрылся медным тазом весь сервис.
- Спроектировали так, что любая школьница с ноутбука за 15 минут выцепит все пароли. Вилкой в глаз безопасности.
- Нарисовали дизайн, где чтобы оплатить заказ, нужно пройти 15 экранов. Пользователь просто убьётся, блядь.
И как с этим бороться-то, спросишь? Да вот же, методы, проще пареной репы:
- Ревью этих самых требований. Садится вся команда — и разработчик, и тест, и даже этот, продакт — и начинают друг другу мозги ебать вопросами: «А что если?..», «А как понять?..», «А где написано?..». Сначала все бесятся, потом понимают, что спасают себя же от будущего ада.
- Прототипы. Сделали кнопочки, по которым можно пощёлкать, ещё до того, как код написан. И сразу видно, что нахуй никуда не годится. Дешевле в сотню раз перерисовать макет, чем переписать всю логику.
Вот тебе наглядный пиздец в требовании:
БЫЛО: "Пароль от 6 символов."И что мы имеем? А имеем мы полный пиздец и разброд в рядах.
- Разработчик сделает валидацию на 6 любых символов, хоть смайликов.
- Тестировщик начнёт ломать голову, как это тестировать.
- А потом придёт злой дядя-хакер и ебанёт простеньким скриптом, потому что пароли из шести цифр — это смех.
СТАЛО: "Пароль от 8 до 64 символов, только латиница, цифры и !@#$%&*."Видишь разницу? Теперь всем понятно. И разработчику ясно, что писать, и тестировщику есть что проверять, и безопасность не на нуле. Волнение ебать сразу спадает.
Вывод, Карл! Тащите своих тестировщиков (ну, или себя, если вы он) в самое начало — на все эти совещания, где рисуют квадратики и пьют латте. Один вовремя заданный тупой вопрос «А как это будет работать?» спасёт потом тысячи часов на переделку, тонну кофе и тонну нервов. Это и есть та самая магия «Shift-Left» — не ждать, пока говно попадет в вентилятор, а не дать ему туда даже приблизиться.