🍀BitBitGo🍀 Системный Анализ

📜 Пост : ТРЕБОВАНИЯ, КОТОРЫЕ НЕ ВРУТ: КАК КОД ПОМОГАЕТ ПРОВЕРИТЬ

Привет, коллеги! 👋 Как часто вы слышали: «Всё сделали по ТЗ, а на проде не работает»? Проблема часто в том, что требования не проверяемы или неоднозначны. Сегодня покажу, как простой код помогает аналитику валидировать требования ещё до разработки. Реальные кейсы внутри. 🚀

📌 Кейс: «Скидка при сумме от 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 включительно». Требование стало однозначным, а тест — частью критериев приемки.

📌 Кейс: «Пароль должен содержать спецсимвол»

В ТЗ: «Пароль должен содержать хотя бы один спецсимвол». Разработчик написал проверку на !@#$%. Через месяц выяснилось, что пароль с символом © (копирайт) не принимается, а клиент из Германии не может ввести ß.

Как аналитик мог предотвратить это? Уточнить набор символов и добавить примеры.

import re

def validate_password(pwd):
    # Явно описанный набор спецсимволов
    pattern = r'[!@#$%^&*()_+\-=\[\]{};:"\\|,.<>\/?]'
    return bool(re.search(pattern, pwd))

# Тесты на граничные случаи
assert validate_password("pass") == False
assert validate_password("pass!") == True
assert validate_password("pass©") == False   # © не входит в набор
# Если бизнес требует ©, нужно добавить в требование и код

Такой подход заставил бизнес либо принять ограниченный набор, либо расширить его. В итоге в требованиях появился список символов, и разработчики получили чёткий ориентир.

🎯 Что даёт такой стиль?

Выявление неоднозначностей на этапе анализа.
Готовые критерии приемки для тестировщиков.
Примеры для разработчиков — они видят, как именно должны работать границы.
Снижение рисков — баги не уходят в прод.

Запомните: Хорошее требование — это не просто текст. Это текст, который можно переложить в проверяемый код. Если вы не можете написать простой assert, требование не готово. 💡

#REQUIREMENTS

207 views07:25