📜 Пост : ТРЕБОВАНИЯ, КОТОРЫЕ НЕ ВРУТ: КАК КОД ПОМОГАЕТ ПРОВЕРИТЬ Привет, коллеги! 👋 Как часто вы слышали: «Всё сделали по ТЗ, а на проде не работает»? Проблема часто в том, что требования не проверяемы или неоднозначны. Сегодня покажу, как простой код помогает аналитику валидировать требования ещё до разработки. Реальные кейсы внутри. 🚀 📌 Кейс: «Скидка при сумме от 1000» Заказчик написал в требованиях: «Скидка 5% при сумме заказа от 1000 рублей». Разработчик реализовал if sum > 1000, тестировщик проверил для 1001 — скидка есть, для 999 — нет. На проде клиент с суммой ровно 1000 скидку не получил и ушёл к конкуренту. Что сделал бы проактивный аналитик? Написал бы тест ещё до передачи в разработку. def test_discount(): # Граничные значения — зона неоднозначности assert apply_discount(999) == 0, "999 → скидки нет" assert apply_discount(1000) == 50, "1000 → скидка 5% (или нет?)" assert apply_discount(1001) == 50.05, "1001 → скидка 5%" Запустил — и сразу увидел, что для 1000 результат не определён. Заказчик уточнил: «от 1000 включительно». Требование стало однозначным, а тест — частью критериев приемки. 📌 Кейс: «Пароль должен содержать спецсимвол» В ТЗ: «Пароль должен содержать хотя бы один спецсимвол». Разработчик написал проверку на !@#&#036;%. Через месяц выяснилось, что пароль с символом © (копирайт) не принимается, а клиент из Германии не может ввести ß. Как аналитик мог предотвратить это? Уточнить набор символов и добавить примеры. import re def validate_password(pwd): # Явно описанный набор спецсимволов pattern = r'[!@#&#036;%^&*()_+&#092;-=&#092;[&#092;]{};:"&#092;&#092;|,.<>&#092;/?]' return bool(re.search(pattern, pwd)) # Тесты на граничные случаи assert validate_password("pass") == False assert validate_password("pass!") == True assert validate_password("pass©") == False # © не входит в набор # Если бизнес требует ©, нужно добавить в требование и код Такой подход заставил бизнес либо принять ограниченный набор, либо расширить его. В итоге в требованиях появился список символов, и разработчики получили чёткий ориентир. 🎯 Что даёт такой стиль? Выявление неоднозначностей на этапе анализа. Готовые критерии приемки для тестировщиков. Примеры для разработчиков — они видят, как именно должны работать границы. Снижение рисков — баги не уходят в прод. Запомните: Хорошее требование — это не просто текст. Это текст, который можно переложить в проверяемый код. Если вы не можете написать простой assert, требование не готово. 💡 #REQUIREMENTS