Послание аналитиков тестировщикам

ПОСЛАНИЕ АНАЛИТИКОВТЕСТИРОВЩИКАМ

Денис Бесков

Chief Systems Analyst, Kaspersky Lab

19 ноября, SQA Days 2010, Санкт-Петербург

Кто такой Денис Бесков

• 10 лет в разработке ПО• 5 лет в разработке БД• 5 лет в системном анализе и архитектуре

• СоорганизаторРИТ-2008/2009,SQA-II, UML2.ru

• Докладчик на …• Ведущий блогаhttp://system-analysis.ru

О чём речь

1. Как мы обычно работаем (if at all)

2. Какие проблемы возникают

3. Каковы причины этих проблем

4. Как мы могли бы работать1. Планирование требований

2. Разработка требований

3. Согласование требований

4. Поддержка требований (not today)

5. Что теперь со всем этим делать?

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

Типичный рабочий цикл

Типичные проблемы

1. Качество требований• Требования недостаточно полны (ширина)• Часть требований недостаточно подробны (глубина)• Часть требований избыточна• В требованиях много ошибок

2. Нехватка времени• Для исправления ошибок нужно значительное время• Уже нет времени переделывать требования,

т.к. разработка уже идёт

3. Результат?• Взаимное недовольство и конфликт

между аналитиком и тестировщиком• Плохое качество тестов

Причины типичных проблем / 1

Менеджер проекта выбирает сроки разработки требованийбез учёта их качества

•У менеджера проектанет инструмента для оценкии управления качеством требований• Аналитик не договорился с потребителями о качестве требований на базестоимости их разработки

Причины типичных проблем / 2

Ожидания поставщика и потребителя требованийне согласованы

• Аналитик выбирает формати детализацию требованийбез учёта потребителяи согласования с ним• Аналитик пишет требования «для себя», по книжке• Тест-дизайнер недоступен для раннего вовлечения

Причины типичных проблем / 3

Глубина проработки требованийравномерно одинаковаяпо всем фичам• Необходимая глубина проработкиразных фич не определялась• Фичи не взвешивались по сложности тестирования

Однородность глубины /1

Выбирается один раз на проект

Фиксированная глубина:

1. Либо User Story / Feature (Cost = X)

2. Либо основные потоки способов применения (Cost = 3X)

3. Либо полные сценарии способов применения (Cost = 10X)

Однородность глубины /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

На шкале времени

Разработкатребований

Согласованиетребований

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

Возможные принципы

• Клиентоориентированность аналитика• Предварительные договорённости о качестве требований с тест-дизайнером

• Рентабельность разработки требований• Выбор глубины проработки требований на основе сложности тестирования

• Выбор ширины проработки требований на основе стоимости проработки

Но как?

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

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

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

Цикл совместного планирования

1. Аналитик уточняет формулировки (F) фич

2. Заказчик выставляет приоритеты (P) фич

3. Ведущий тест-дизайнер оцениваетрискованность (R) тестирования (неопр, N искл.)

4. Аналитик оценивает трудоёмкость (C) запрошенной проработки требований пофично (N UC)

5. Менеджер проекта выбираетширину и глубину проработки требований, оперируя как трудоёмкостью, так и рисками, обсуждая решение с аналитиком и тестировщиком

6. Заказ на детализацию требованийсформирован и согласован

Рентабельная глубина

Формат Ф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

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

Разработка требований. Подход

1. Способы применения (use cases)как основной формат требований, удобный для тестировщика

2. Аналитик передаёт требованияна изучение порционно —и по глубине и по ширине (3-5 UC)

Разработка требований. Цикл

1. Аналитик разрабатывает основной потокспособа применения и выявляет точки расширения

2. Тест-дизайнер изучает основной поток,даёт замечания, выявляет исключения

3. Аналитик описывает обработку исключений и расширений

4. Тест-дизайнер вычитывает исключения и расширения

5. Аналитик обрабатывает замечания тест-дизайнера

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

Согласование требований

НЕ нужно !

Если мы (почти)всё делали вместе

Новая шкала времени

Совместнаяразработкатребований

«Согласование»требований

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

ЗАКЛЮЧЕНИЕ

Начинайте сотрудничество!

1. Договаривайтесь сглавным аналитиком о необходимости совместного планированиякачества требований

2. Пробуйте планировать вместе

3. Продавайте менеджеру проектавыгоды вашей совместной работы

4. Работайте вместе, а не по очереди

Благодарности

Спасибо за идею,доклада и обсуждения!

•Юлии Нечаевой•Тимуру Хайрулину