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