DUMP-2015: «Тестирование постановок в Naumen Contact Center» Константин Беклемишев, Ангелина Рыбасова, Naumen

Тестирование постановок

в Naumen Contact Center

Константин Беклемишевруководитель отдела разработкиNaumen Contact [email protected]

Ангелина РыбасоваСтарший тестировщик гр. ручного тестированияNaumen Contact [email protected]

Naumen Contact Center

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


Как мы делали раньше...

● Крайне общее описание хотелки● Дата релиза


Что делаем дальше?● Программист из своих соображений делает оценку● Большинство подробностей выясняются в процессе

выполнения● Они остаются зачастую в головах, либо в громадных

обсуждениях задачи● Такую задачу не получается разбить сразу● Могут делать максимум 1-2 человека● Срок растягивается


Правильно сделали или нет?Автотесты

Ручное тестирование

В постановке никакой конкретики, а результат пестрит деталями.Как это должно вообще работать? Кто-нибудь знает?

Тестировщику приходится выяснять все подробности заново!Тратим время специалистов по качеству, программистов и аналитиков еще раз.

Разобравшись пишем тесткейсы на будущее!


Утвердим в релиз

DEMO/ПриемкаАналитики имели ввиду совершенно другое!Переделываем!

Аналитики согласны.Сервисный центр - “Этим нельзя пользоваться”.

Переделываем!



Тестирование=корректировкапостановок

Тестировщик - драйвер постановки!

Задача тестировщика - написать на фичу набор тесткейсов до реализации.

Скорее всего в процессе возникнут вопросы!

Полнота постановки увеличится.


Требования к требованиям!Кроме “полноты” есть еще два формальных наборак проверке:

● Общие● По типам задач


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


Требования к Feature(Новый функционал, улучшение/оптимизация текущего функционала)

1. Бизнес-ценность

2. Кто заказчик?

3. Клиентская формулировка

4. Какие варианты решения проблемы назвал клиент?

5. Используют ли клиенты какие-либо обходные пути (workaround)?

6. Какие варианты решения рассмотрены?

7. Описание - основная часть постановки.


Чем мы пользуемся

● Redmine

● Плагин Impase


Поле Testcase Author


Фильтр my requirements


Состояние “No requirements”


Feature test


Постановка на старую версию


Постановка на новую версию:первый diff


Постановка на новую версию: итог











Практика меняет теорию

Общие требования

Чек-листы


Мои впечатления: шероховатости

● Переписывание тест-кейсов

● Проблема синхронизации групп

разработки

● Накладывающиеся изменения в версии


Мои впечатления: плюсы

● Больше информации

● Больше активности

● Программисты спокойнее :)


Достижения

● Подробные проработанные постановки● Больше не тратим время на каждом этапе на

выяснение деталей● Задачи дробятся● Разработка параллелится● Программист почти знает, как задачу будут проверять● Не приходится переделывать работу заново● Все понимают задачу одинаково


Вопросы



Новая сущность

TestCase Author


Краткий список проблем из-за некачественной постановки

● Программисты, тестировщики тратят лишнее время на выяснение одних и тех же вещей много раз

● Задачи плохо параллеляться в разработке независимо от их размера● Требования возникают по ходу задачи● Требования могут поменяться на противоположные, когда задача уже

выполнена● Сроки разработки могут отличаться от плановых в разы● Программисту неизвестно, как будет проверяться его задача● Тестировщику это тоже неизвестно!● Тесткейсы готовятся постфактум тем же человеком, что проводит

тестирование.● Планировать тестирование невозможно● Ввести метрики в работу группы контроля качества - затруднительно


Требования к Bug(Ошибка в функционале, поведение системы, которое отличается от заявленного)

1. Версия ПО, где найдена проблема.

2. Есть ли проблема в последних версиях ПО?(например последняя версия в рамках установленного у клиента релиза,nsp последней версии)

3. Описание проблемы(заказчик часто озвучивает не исходную проблему, а уже готовый план решения)

4. Что именно не работает?(Какой бизнесс-функционал задет?)

5. Как часто проявляется проблема?(количество обнаружений в единицу времени.Использование «часто», «очень часто» недопустимо)

6. Как воспроизвести проблему?


Требования к Bug7. Есть ли дополнительная информация для решения проблемы?(лог-файлы, коредампы, сетевые дампы)

8. Какое поведение по мнению постановщика должно быть правильным?(Как должно быть?)

9. Какое решение проблемы видит постановщик?(Что нужно сделать?)

10. Есть ли обходные пути?(описание, либо ссылка на xwiki)

11. Установлены ли какие-либо сроки решения проблемы?

12. Есть ли аргументация таких сроков?




Современный workflowКопируем тикет из проекта Roadmap в проект разработки

Выставляем трекер Discussion (тестирование постановки)

Автоматически появляется у старшего тестировщика в фильтрах на домашней странице

Старший тестировщик назначает на тикет роль TestCase Author

У назначенного в почту приходит уведомление и появляется в фильтре на домашней странице

TestCase Author тестирует постановку: корректировки вносятся аналитиком и тестировщиком


TestCase Author начинает писать тесткейсы и оформлять их в тестсьют

Подшивает тестсьют к тикету с готовой постановкой

Тикету с готовой постановкой выставляется трекер Feature, статус New.

С этого момента Разработка может брать его в работу и дробить на подзадачи

Тестировщики связывают подзадачи с готовыми тесткейсами из тестсьюта

Задачи распределяются между членами групп разработок на планировании

Программисты оцениваются подзадачи и корректируется общий срок


Если итоговая оценка превышает первоначальную на 40ч, то комитет решает что исключить из Роадмапа или требований к задаче

Разработка приступает к реализации

Автотесты

Тестирование по готовым тесткейсам другим человеком (поле Tester)

Закрытие задачи

Демонстрация

Приемка (непубличное мероприятие через неделю после Демо)

Internet

DUMP-2015: «Тестирование постановок в Naumen Contact Center» Константин Беклемишев, Ангелина Рыбасова, Naumen