Аналитик и разработчик в одном лице: опыт применения BDD в стартапе

SECR 2018
Михаил Белов

Мой доклад будет полезен разработчикам, которым приходится работать в условиях нечетких требований или отсутствия аналитика, например, в стартапе. Я расскажу о подходе BDD к разработке требований, остановлюсь на примерах его использования со стороны разработчика, которому нужно вынести максимум из общения с клиентами или feature owner’ами. А еще покажу некоторые нюансы работы с получающимся списком сценариев, которые я сформулировал из личного опыта.

Transcript

1. Аналитик и разработчик в одном лице Михаил Белов Software Engineering Conference Russia 2018 October 12-13 Moscow Опыт применения BDD в стартапе
2. Познакомимся? • .NET, SQL, JavaScript • Desktop и Web приложения • Работал в Microsoft • Сооснователь стартапа 2
3. Крупная корпорация • Приоритеты определены • Задачи описаны • Есть спецификации • Есть аналитики • Есть поставленный процесс QA • Есть документация 3
4. Стартап • Переполненный бэклог • Поверхностная формулировка • Нет спецификаций • Нет документации • Ресурсоемкое регрессионное тестирование • Сам себе тестировщик 4
5. Без BDD 5 Уточнить требования Изменить прототип Сделать прототип Сформулировать требования
6. Результат • Ушло много времени • Забыли про некоторые сценарии • Некоторые сценарии ломают обратную совместимость в UX • Баги, баги, баги 6
7. Behavior Driven Development Приемочные тесты пишут • До начала разработки (как в TDD) • На естественном языке • Составляют люди из бизнеса и разработки • Описывают поведение системы с помощью S.M.A.R.T.* – критериев *Specific – конкретный Measurable – измеримый Achievable – достижимый Relevant – актуальный Time-bound – ограниченный по времени 7
8. Given When Then 8 Given When Then
9. Покрытие • Комбинаторно перемножаем Given * When • В результате получается набор приемочных тестов 9
10. Светофор Given: • Горящий цвет: красный, желтый зеленый • Зеленый мигающий • Желтый мигающий • Стрелки • Оставшиеся секунды 10 When: • Срабатывание таймера • Ручное управление • Кнопка • Датчик в асфальте • Маячки в спец. Транспорте • Камеры
11. Светофор Given When Then Красный Таймер Зеленый Зеленый Таймер Зеленый мигающий Зеленый мигающий Таймер Желтый Желтый Таймер Красный 11
12. Предметная область • Бухгалтерия • Бизнес-процессы 12
13. Нужно слегка поменять образ мыслей BDD поможет разработчикам 13
14. Проектная бухгалтерия • Проекты • Бюджеты проектов • Версии бюджетов 14
15. У вас еще нет ни одной записи. Создать? Да Нет 15
16. Анализировать до разработки, а не во время BDD поможет, если нет опыта 16
17. Сделать “так же, как там” 17
18. Мыслить действиями, а не объектами 18
19. Проектный субподряд 19 Компания А (заказчик) Компания B (исполнитель) Компания C (субподрядчик) Компания D (дочерняя от B)
20. 1 тест – 1 триггер А не набор шагов 20
21. Усложним 21 Компания А (заказчик) Компания B (исполнитель) Компания C (субподрядчик) Компания D (дочерняя от B) USD GBP RUB AED
22. 256 Клиент Исполнитель Субподрядчик Дочерняя компания USD USD USD USD USD USD USD GBP USD USD USD RUB USD USD USD AED USD USD GBP USD … … … … AED AED AED AED 22
23. 8 Клиент – Исполнитель Исполнитель – Субподрядчик Субподрядчик – Дочерняя компания 0 0 0 0 0 1 0 1 0 0 1 1 1 0 0 1 0 1 1 1 0 1 1 1 23 * 0 – валюты разные 1 – валюты одинаковые
24. Не бояться комбинаторики • Задуматься, а все ли правильно? • Больше информации к размышлению • Защита от ошибок 24
25. Главное • С аналитиком лучше, чем без него • Разработчик тоже может анализировать • Анализировать до начала разработки, а не во время • Особенно там, где «и так все понятно» • Мыслить действиями, а не сущностями • Разбивать сложные сценарии на отдельные кейсы • Перебор всех вариантов помогает, а не мешает 25
26. Если есть вопросы mihail_belov mpbelov@gmail.com facebook.com/mikhail.belov.165 26