2. Кто такой Денис Бесков
• 10 лет в разработке ПО
• 5 лет в разработке БД
• 5 лет в системном
анализе и архитектуре
• Соорганизатор
РИТ-2008/2009,
SQA-II, UML2.ru
• Докладчик на …
• Ведущий блога
http://system-analysis.ru
3. О чѐм речь
1. Как мы обычно работаем (if at all)
2. Какие проблемы возникают
3. Каковы причины этих проблем
4. Как мы могли бы работать
1. Планирование требований
2. Разработка требований
3. Согласование требований
4. Поддержка требований (not today)
5. Что теперь со всем этим делать?
6. Типичные проблемы
1. Качество требований
• Требования недостаточно полны (ширина)
• Часть требований недостаточно подробны (глубина)
• Часть требований избыточна
• В требованиях много ошибок
2. Нехватка времени
• Для исправления ошибок нужно значительное время
• Уже нет времени переделывать требования,
т.к. разработка уже идѐт
3. Результат?
• Взаимное недовольство и конфликт
между аналитиком и тестировщиком
• Плохое качество тестов
7. Причины типичных проблем / 1
Менеджер проекта выбирает
сроки разработки требований
без учѐта их качества
•У менеджера проекта
нет инструмента для оценки
и управления качеством требований
• Аналитик не договорился с потребителями
о качестве требований на базе
стоимости их разработки
8. Причины типичных проблем / 2
Ожидания поставщика и
потребителя требований
не согласованы
• Аналитик выбирает формат
и детализацию требований
без учѐта потребителя
и согласования с ним
• Аналитик пишет требования «для себя», по книжке
• Тест-дизайнер недоступен для раннего вовлечения
9. Причины типичных проблем / 3
Глубина проработки требований
равномерно одинаковая
по всем фичам
• Необходимая глубина проработки
разных фич не определялась
• Фичи не взвешивались по сложности
тестирования
10. Однородность глубины /1
Выбирается один раз на проект
Фиксированная глубина:
1. Либо User Story / Feature (Cost = X)
2. Либо основные потоки способов
применения (Cost = 3X)
3. Либо полные сценарии способов
применения (Cost = 10X)
11. Однородность глубины /2
Формат Ф1 Ф2 Ф3 Ф4 … … … ФN
User Story X X X X X X X X
Основной поток
Use Case
X X X X X X X X
Все потоки
Use Case
14. Возможные принципы
• Клиентоориентированность аналитика
• Предварительные договорѐнности о
качестве требований с тест-дизайнером
• Рентабельность разработки требований
• Выбор глубины проработки требований на
основе сложности тестирования
• Выбор ширины проработки требований на
основе стоимости проработки
22. Разработка требований. Подход
1. Способы применения (use cases)
как основной формат требований,
удобный для тестировщика
2. Аналитик передаѐт требования
на изучение порционно —
и по глубине и по ширине (3-5 UC)
23. Разработка требований. Цикл
1. Аналитик разрабатывает основной поток
способа применения и выявляет точки
расширения
2. Тест-дизайнер изучает основной поток,
даѐт замечания, выявляет исключения
3. Аналитик описывает обработку исключений и
расширений
4. Тест-дизайнер вычитывает исключения и
расширения
5. Аналитик обрабатывает замечания тест-
дизайнера
28. Начинайте сотрудничество!
1. Договаривайтесь с
главным аналитиком о необходимости
совместного планирования
качества требований
2. Пробуйте планировать вместе
3. Продавайте менеджеру проекта
выгоды вашей совместной работы
4. Работайте вместе, а не по очереди