Доклад Дениса Бескова на SQA Days 2010 обсуждает проблемы взаимодействия аналитиков и тестировщиков в процессе разработки требований. Основные проблемы включают недостаток качества требований, нехватку времени и конфликты между аналитиками и тестировщиками. Для улучшения сотрудничества автор предлагает принципы совместного планирования и разработки требований, акцентируя внимание на клиенториентированности и оценке рисков.

1. ПОСЛАНИЕ
АНАЛИТИКОВ
ТЕСТИРОВЩИКАМ
Денис Бесков
Chief Systems Analyst, Kaspersky Lab
19 ноября, SQA Days 2010, Санкт-Петербург

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. Что теперь со всем этим делать?

4. КАК БЫВАЕТ
Организовано взаимодействие
аналитиков и тестировщиков

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

12. На шкале времени
Разработка
требований
Согласование
требований

13. КАК МОЖНО РАБОТАТЬ
Вместе?

14. Возможные принципы
• Клиентоориентированность аналитика
• Предварительные договорённости о
качестве требований с тест-дизайнером
• Рентабельность разработки требований
• Выбор глубины проработки требований на
основе сложности тестирования
• Выбор ширины проработки требований на
основе стоимости проработки

15. Но как?

16. Цикл сотрудничества

17. СОВМЕСТНОЕ
ПЛАНИРОВАНИЕ
ТРЕБОВАНИЙ

18. Планирование требований

19. Цикл совместного планирования
1. Аналитик уточняет формулировки (F) фич
2. Заказчик выставляет приоритеты (P) фич
3. Ведущий тест-дизайнер оценивает
рискованность (R) тестирования (неопр, N искл.)
4. Аналитик оценивает трудоёмкость (C) запрошенной
проработки требований пофично (N UC)
5. Менеджер проекта выбирает
ширину и глубину проработки требований,
оперируя как трудоёмкостью, так и рисками,
обсуждая решение с аналитиком и тестировщиком
6. Заказ на детализацию требований
сформирован и согласован

20. Рентабельная глубина
Формат Ф1 Ф2 Ф3 Ф4 … … … ФN
User Story X X X X X X X X
Основной поток
Use Case
X X X X X X
Все потоки
Use Case
X X X

21. СОВМЕСТНАЯ
РАЗРАБОТКА
ТРЕБОВАНИЙ

22. Разработка требований. Подход
1. Способы применения (use cases)
как основной формат требований,
удобный для тестировщика
2. Аналитик передаёт требования
на изучение порционно —
и по глубине и по ширине (3-5 UC)

23. Разработка требований. Цикл
1. Аналитик разрабатывает основной поток
способа применения и выявляет точки
расширения
2. Тест-дизайнер изучает основной поток,
даёт замечания, выявляет исключения
3. Аналитик описывает обработку исключений и
расширений
4. Тест-дизайнер вычитывает исключения и
расширения
5. Аналитик обрабатывает замечания тест-
дизайнера

24. СОВМЕСТНОЕ
СОГЛАСОВАНИЕ (?)
ТРЕБОВАНИЙ

25. Согласование требований
НЕ нужно ! 
Если мы (почти)
всё делали вместе

26. Новая шкала времени
Совместная
разработка
требований
«Согласование»
требований
Планирование
требований

27. ЗАКЛЮЧЕНИЕ

28. Начинайте сотрудничество!
1. Договаривайтесь с
главным аналитиком о необходимости
совместного планирования
качества требований
2. Пробуйте планировать вместе
3. Продавайте менеджеру проекта
выгоды вашей совместной работы
4. Работайте вместе, а не по очереди

29. Благодарности
Спасибо за
идею доклада и обсуждения:
•Юлии Нечаевой
•Тимуру Хайруллину