Доклад Егора Сосковца демонстрирует, что отсутствие четких требований не мешает достижению качества продукта, используя тестовую документацию как основной артефакт для работы в условиях неявных требований. Он описывает процесс кастомизации системы CRM+ERP и подчеркивает важность тестового документооборота при изменении требований заказчика. Также приводятся примеры тест-кейсов и чек-листов, что иллюстрирует практическое применение полученных выводов.

1. Минск. 26 февраля 2017
Егор Сосковец
ООО Лаборатории Инвенто. Минск, Беларусь
Процесс тестирования в условиях неявных
требований

2. Процесс тестирования в условиях неявных требований
О себе
• Более 20 лет опыта в IT
• Прошел путь от функционального
тестировщика, через WEB Developer,
Test Manager, Lead Developer и до
Delivery Manager
• Основная специализация: комплексная постановка
процессов разработки, тестирования и доставки
продукта как в рамках отдельного проекта, так и в
компании в целом

3. Зачем этот доклад?
1.продемонстрировать, что отсутствие четких
требований не является блокирующим моментом в
достижении качества продукта, поставляемого
заказчику
2.доказать, что в условиях неявных требований – тест-
документация становится единственным артефактом,
на который можно “опереться”
3.внушить уверенность: тестовая документация может
быть любого формата, именно такого, что-бы
требовать минимального обслуживания и давать
максимальную отдачу, уточняя собой неявные
требования
Процесс тестирования в условиях неявных требований

4. О проекте
• Ранее клиент работал с двумя разрозненными,
которые было необходимо объединить с полным
сохранением исторических и текущих данных
• Принято решение произвести кастомизацию системы
CRM+ERP на основе приложения с открытым кодом
(Odoo) в соответствии с требованиями заказчика
• Помимо внедрения нового приложения требовалось
внести изменения в бизнес-процесс предприятия в
целом
Процесс тестирования в условиях неявных требований

5. Пользовательский интерфейс: было - стало
Процесс тестирования в условиях неявных требований

6. Первые шаги: абстрактные требования
Процесс тестирования в условиях неявных требований

7. Первые шаги: первые проблемы
Процесс тестирования в условиях неявных требований

8. Второе дыхание: уточнение требований
Процесс тестирования в условиях неявных требований

9. Второе дыхание: и всё ещё не ясно…
Процесс тестирования в условиях неявных требований

10. Пример тест-кейса:
Title: CRM / Обработка Клиента: форма "Регистрация платежа“
Description:
Precondition
Пользователи: Администратор КО(ko_admin), Вася Пупкин (vpu)
Steps
1.Войти в систему как Администратор КО -> нажать кнопку Администратор КО -> в выпадающем
списке нажать О программе -> нажать кнопку Активировать режим разработчика -> Главное
меню настройки -> Пользователи -> выбрать пользователя Администратор КО -> Изменить ->
ЮрСпектр Горячая линия поставить роль Сотрудник
2.Главное меню Горячая линия -> Все заявки -> Создать -> Заполнить поля Сохранить -
> Отправить в обработку
3.Expected results: В списке заявок появилась заявка, автор которой Администратор КО
4.Войти в систему как Вася Пупкин -> Главное меню Горячая линия -> Все заявки -> Создать ->
Заполнить поля -> Ответственным указать Администратор КО -> Сохранить -> Отправить в
обработку
5.Войти в систему как Администратор КО -> Главное меню Горячая линия -> Все заявки
6.Expected results: В списке заявок появилась заявка, ответственным на которую назначен
Администратор КО.
Процесс тестирования в условиях неявных требований

11. Столкновение с реальностью: выход в «PROD»
Процесс тестирования в условиях неявных требований

12. Этап три: полёт нормальный?
Процесс тестирования в условиях неявных требований

13. Процесс тестирования в условиях неявных требований
Выходим из пикирования
Процесс тестирования в условиях неявных требований

14. Пример чеклиста
Title: Клиенты / Клиенты / Заявки на счета: проверка позиций заявки типа
«Актуализация»
Description:
1.Создать заявку типа "Актуализация"
2.Добавить позиции заказа(проверить, что в поле "Система" доступны только
необслуживаемые системы, у которых дата окончания подписки не позже 1-ого числа
предыдущего месяца)
3.Проверить, что в поле "Программа" указывается вид услуг:
актуализация,обслуживание,понижение и/или переход
4.Проверить, что программа любого вида услуг соответствует выбранной системе, в
зависимости от текущей системы или ее перехода/понижения
5.Проверить, что в списке программ присутствуют необходимые актуализация и
обслуживание в зависимости от перехода/понижения системы
6.Проверить, что в поле "Количество" значение ограничено 60-ю месяцами
7.Проверить, что при указании начала подписки указывается окончание подписки(начало
подписки+значение поля "Количество")
8.Проверить, что в поле "Величина скидки (%)" тянется скидка, указанная в системе
Процесс тестирования в условиях неявных требований

15. Вывод
Вы можете не иметь четких требований к системе как на
страте проекта, так и при выходе в продакшен.
Ваши заказчики могут менять требования изо дня в день.
В такой ситуации требованиями к системе становится
тестовая документация – это единственный артефакт,
который позволит вам чётко отследить внесенные
изменения в систему и обеспечить её качество.
Процесс тестирования в условиях неявных требований

16. Спасибо за внимание
Вопросы?
Mail: esoskovets@mail.ru
Skype: net-ego.net
Процесс тестирования в условиях неявных требований