Sqa.days.2010.beskov.system.analyst.and.test.engineers.interaction
Download as PPTX, PDF0 likes497 views
Доклад Дениса Бескова на SQA Days 2010 в Санкт-Петербурге охватывает проблемы взаимодействия между аналитиками и тестировщиками в процессе разработки требований. Обсуждаются основные проблемы качества требований, такие как недостаточная полнота и детализация, а также временные ограничения, приводящие к конфликтах между специалистами. Предлагаются принципы эффективного сотрудничества и совместного планирования для улучшения процесса разработки требований.
Sqa.days.2010.beskov.system.analyst.and.test.engineers.interaction
- 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. КАК БЫВАЕТ Организовано взаимодействие аналитиков и тестировщиков
- 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. Возможные принципы • Клиентоориентированность аналитика • Предварительные договорённости о качестве требований с тест-дизайнером • Рентабельность разработки требований • Выбор глубины проработки требований на основе сложности тестирования • Выбор ширины проработки требований на основе стоимости проработки
- 15. Но как?
- 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
- 22. Разработка требований. Подход 1. Способы применения (use cases) как основной формат требований, удобный для тестировщика 2. Аналитик передаёт требования на изучение порционно — и по глубине и по ширине (3-5 UC)
- 23. Разработка требований. Цикл 1. Аналитик разрабатывает основной поток способа применения и выявляет точки расширения 2. Тест-дизайнер изучает основной поток, даёт замечания, выявляет исключения 3. Аналитик описывает обработку исключений и расширений 4. Тест-дизайнер вычитывает исключения и расширения 5. Аналитик обрабатывает замечания тест- дизайнера
- 25. Согласование требований НЕ нужно ! Если мы (почти) всё делали вместе
- 27. ЗАКЛЮЧЕНИЕ
- 28. Начинайте сотрудничество! 1. Договаривайтесь с главным аналитиком о необходимости совместного планирования качества требований 2. Пробуйте планировать вместе 3. Продавайте менеджеру проекта выгоды вашей совместной работы 4. Работайте вместе, а не по очереди
- 29. Благодарности Спасибо за идею, доклада и обсуждения! •Юлии Нечаевой •Тимуру Хайрулину