Выступление на DUMP-2015. Видео доклада: https://youtu.be/YCNfJceX_RE?list=PLRdS-n5seLRp_rmnC69UpyhiPpo1tRYLv Организатор конференции: IT-People.ru Сайт конференции: www.dump-conf.ru

1. Тестирование
постановок
в Naumen Contact Center
Константин Беклемишев
руководитель отдела разработки
Naumen Contact Center
kbeklemishev@naumen.ru
Ангелина Рыбасова
Старший тестировщик гр. ручного тестирования
Naumen Contact Center
arybasova@naumen.ru

2. Naumen Contact Center
Что такое Naumen Contact Center?
● Это 15 лет разработки на C++, Python и Java
● Гибкая масштабируемая архитектура
● Более 20-и серверных компонент
● Три интерфейса пользователя
● Две команды разработки
● Группа тестирования
● Группа разработки средств авто-тестирования

3. Naumen Contact Center
Как мы делали раньше...
● Крайне общее описание хотелки
● Дата релиза

4. Naumen Contact Center
Что делаем дальше?
● Программист из своих соображений делает оценку
● Большинство подробностей выясняются в процессе
выполнения
● Они остаются зачастую в головах, либо в громадных
обсуждениях задачи
● Такую задачу не получается разбить сразу
● Могут делать максимум 1-2 человека
● Срок растягивается

5. Naumen Contact Center
Правильно сделали или нет?
Автотесты
Ручное тестирование
В постановке никакой конкретики, а результат пестрит деталями.
Как это должно вообще работать? Кто-нибудь знает?
Тестировщику приходится выяснять все подробности заново!
Тратим время специалистов по качеству, программистов и аналитиков еще раз.
Разобравшись пишем тесткейсы на будущее!

6. Naumen Contact Center
Утвердим в релиз
DEMO/Приемка
Аналитики имели ввиду совершенно другое!
Переделываем!
Аналитики согласны.
Сервисный центр - “Этим нельзя пользоваться”.
Переделываем!

7. Naumen Contact Center

8. Naumen Contact Center
Тестирование=корректировка
постановок
Тестировщик - драйвер постановки!
Задача тестировщика - написать на фичу набор
тесткейсов до реализации.
Скорее всего в процессе возникнут вопросы!
Полнота постановки увеличится.

9. Naumen Contact Center
Требования к требованиям!
Кроме “полноты” есть еще два формальных набора
к проверке:
● Общие
● По типам задач

10. Naumen Contact Center
Общие требования
Требования, содержащиеся в постановках, должны
быть:
1. Понятными
2. Недвусмысленными
3. Непротиворечивыми
4. Обязательными
5. Проверяемыми
6. Неконтекстными

11. Naumen Contact Center
Требования к Feature
(Новый функционал, улучшение/оптимизация текущего функционала)
1. Бизнес-ценность
2. Кто заказчик?
3. Клиентская формулировка
4. Какие варианты решения проблемы назвал клиент?
5. Используют ли клиенты какие-либо обходные пути (workaround)?
6. Какие варианты решения рассмотрены?
7. Описание - основная часть постановки.

12. Naumen Contact Center
Чем мы пользуемся
● Redmine
● Плагин Impase

13. Naumen Contact Center
Поле Testcase Author

14. Naumen Contact Center
Фильтр my requirements

15. Naumen Contact Center
Состояние “No requirements”

16. Naumen Contact Center
Feature test

17. Naumen Contact Center
Постановка на старую версию

18. Naumen Contact Center
Постановка на новую версию:
первый diff

19. Naumen Contact Center
Постановка на новую версию: итог

20. Naumen Contact Center

21. Naumen Contact Center

22. Naumen Contact Center

23. Naumen Contact Center

24. Naumen Contact Center

25. Naumen Contact Center

26. Naumen Contact Center

27. Naumen Contact Center

28. Naumen Contact Center

29. Naumen Contact Center
Практика меняет теорию
Общие требования
Чек-листы

30. Naumen Contact Center
Мои впечатления: шероховатости
● Переписывание тест-кейсов
● Проблема синхронизации групп
разработки
● Накладывающиеся изменения в версии

31. Naumen Contact Center
Мои впечатления: плюсы
● Больше информации
● Больше активности
● Программисты спокойнее :)

32. Naumen Contact Center
Достижения
● Подробные проработанные постановки
● Больше не тратим время на каждом этапе на
выяснение деталей
● Задачи дробятся
● Разработка параллелится
● Программист почти знает, как задачу будут проверять
● Не приходится переделывать работу заново
● Все понимают задачу одинаково

33. Naumen Contact Center
Вопросы

34. Naumen Contact Center

35. Naumen Contact Center
Новая сущность
TestCase Author

36. Naumen Contact Center
Краткий список проблем из-за
некачественной постановки
● Программисты, тестировщики тратят лишнее время на выяснение
одних и тех же вещей много раз
● Задачи плохо параллеляться в разработке независимо от их размера
● Требования возникают по ходу задачи
● Требования могут поменяться на противоположные, когда задача уже
выполнена
● Сроки разработки могут отличаться от плановых в разы
● Программисту неизвестно, как будет проверяться его задача
● Тестировщику это тоже неизвестно!
● Тесткейсы готовятся постфактум тем же человеком, что проводит
тестирование.
● Планировать тестирование невозможно
● Ввести метрики в работу группы контроля качества - затруднительно

37. Naumen Contact Center
Требования к Bug
(Ошибка в функционале, поведение системы, которое отличается от заявленного)
1. Версия ПО, где найдена проблема.
2. Есть ли проблема в последних версиях ПО?
(например последняя версия в рамках установленного у клиента релиза,
nsp последней версии)
3. Описание проблемы
(заказчик часто озвучивает не исходную проблему, а уже готовый план решения)
4. Что именно не работает?
(Какой бизнесс-функционал задет?)
5. Как часто проявляется проблема?
(количество обнаружений в единицу времени.
Использование «часто», «очень часто» недопустимо)
6. Как воспроизвести проблему?

38. Naumen Contact Center
Требования к Bug
7. Есть ли дополнительная информация для решения проблемы?
(лог-файлы, коредампы, сетевые дампы)
8. Какое поведение по мнению постановщика должно быть правильным?
(Как должно быть?)
9. Какое решение проблемы видит постановщик?
(Что нужно сделать?)
10. Есть ли обходные пути?
(описание, либо ссылка на xwiki)
11. Установлены ли какие-либо сроки решения проблемы?
12. Есть ли аргументация таких сроков?

39. Naumen Contact Center

40. Naumen Contact Center

41. Naumen Contact Center
Современный workflow
Копируем тикет из проекта Roadmap в проект разработки
Выставляем трекер Discussion (тестирование постановки)
Автоматически появляется у старшего тестировщика в фильтрах на домашней странице
Старший тестировщик назначает на тикет роль TestCase Author
У назначенного в почту приходит уведомление и появляется в фильтре на домашней странице
TestCase Author тестирует постановку: корректировки вносятся аналитиком и тестировщиком

42. Naumen Contact Center
TestCase Author начинает писать тесткейсы и оформлять их в тестсьют
Подшивает тестсьют к тикету с готовой постановкой
Тикету с готовой постановкой выставляется трекер Feature, статус New.
С этого момента Разработка может брать его в работу и дробить на подзадачи
Тестировщики связывают подзадачи с готовыми тесткейсами из тестсьюта
Задачи распределяются между членами групп разработок на планировании
Программисты оцениваются подзадачи и корректируется общий срок

43. Naumen Contact Center
Если итоговая оценка превышает первоначальную на 40ч, то комитет решает что исключить из Роадмапа или
требований к задаче
Разработка приступает к реализации
Автотесты
Тестирование по готовым тесткейсам другим человеком (поле Tester)
Закрытие задачи
Демонстрация
Приемка (непубличное мероприятие через неделю после Демо)