1. Система генерации чек-листов для регрессионного
тестирования на основе анализа рисков
или QA паранойя
Солодов Владимир
Superjob, Москва, Россия

2. Постановка задачи

3. Постановка задачи
Функционал, связанный с
изменением, положительные
кейсы,
15% критичных багов
Функционал, связанный с
изменением, кейсы на
предельные значения и
отрицательные кейсы,
40% критичных багов
Функционал, не связанный
с изменением,
45% критичных багов

4. Мы хотим
• получить набор тесткейсов, проведение которых гарантировало бы
нахождение ВСЕХ(!) багов, привнесенных конкретным изменением кода
• получить приоритеты тесткейсов, чтобы сначала обнаружить наиболее
критичные баги, привнесенные с изменениями, а затем находить наименее
критичные баги
Постановка задачи

5. Природа багов
Задание: Вывести
ссылку «Ссылка 10»
красным цветом

6. Природа багов
Изменение 1.
Программист поменял код HTML на странице: он обрамил текст ссылки в тег
<font color=”red”> и забыл его закрыть. Все работает, ссылка корректно
окрашена.
Расширяем контекст.
Ниже в верстке есть поп-ап, который появляется при клике на ссылку
«Ссылка3», Текст в попапе окрашивается в цвет, который мы установили для
ссылки.

7. Природа багов

8. Природа багов
Изменение 2.
Программист поменял существующий стиль программы, добавил в css-стиль
строку color: red и убрал style:linked.
Расширяем контекст.
В шаблонах других странице данным стилем обозначены все ссылки на
данную страницу, а их текст мы хотим оставить прежним.

9. Природа багов
Изменение 3.
Программист добавил в css новый стиль, новый идентификатор, для которого
корректно указал цвета.
Расширяем контекст.
С данным стилем, идентификатором был связан код JS, который сейчас не
работает.

10. Риски реализации
Риск – вероятное событие, приводящее к негативным последствиям.
Величина риска = (вероятность) x (ущерб) = P x H
Ущерб
Вероятность
1 2 3
1 1 2 3
2 2 4 6
3 3 6 9

11. Риски реализации
Гипотезы, которые мы приняли
• изменения, вносимые в систему однозначно определяют риски, которые могут
материализоваться в системе,
• риски, связанные с каждым изменением могут быть устойчивыми (регулярно
повторяющимися), если взаимосвязи элементов, в которых вносятся изменения
будут сохранять инвариантность (постоянство), то есть изменения должны
касаться изменения частей системы, а не характера их взаимосвязей
Одним из таких инвариантов в компьютерной программе является архитектура
приложения.

12. Инициализация. Шаги 1,2 из 4
Шаг 1. На основе архитектуры приложения выделить основные компоненты
(элементы архитектуры: шаблоны, базы данных, модели, таблица стилей)
Шаг 2. Для каждого компонента выделить изменения, которые вносятся
разработчиком
1. Изменения CSS (styles.css, blitz,
ViewModel)
2. Исправление JS (файлы плагинов, blitz,
ViewModel)
3. DOM-HTML (blitz). Добавление элемента
в дерево
4. DOM-HTML (blitz). Изменение
существующего элемента
5. DOM-HTML (blitz). Удаление элемента из
дерева
6. Изменения в БД. Добавление нового поля
7. Изменения в БД. Удаление поля
8. Изменения в БД. Исправлен запрос
9. Изменение PHP скриптов (Контроллер,
VM). Логика

13. Инициализация. Шаги 3,4 из 4
Шаг 3. Для каждого изменения можно определить риски, следующие из здравого
смысла и определить им вероятность возникновения 0,5, вред определить из
логики приложения.
Шаг 4. Для каждого риска предусмотреть тест-кейсы, которые должны быть
выполнены, чтобы данный риск был протестирован.
Риск Симптом
1 Стиль наследует данные, которые конфликтуют с
версткой
Верстка нового элемента некорректна
2 Стиль используется другими элементами Верстка сопряженных элементов некорректна
3 Атрибуты наследуются другими элементами Верстка сопряженных элементов некорректна
4 Некорректно работают JS-обработчики Не работают скрипты добавления, модификации
элементов DOMa

14. Алгоритм работы
Шаг 1. Отметить какие изменения были внесены в систему.
Шаг 2. Выбрать риски для изменений, которые отмечены и отранжировать их в
порядке убывания параметра P x H, для данных рисков уже заранее определены
тесткейсы
Шаг 3. Проверить, риски в порядке убывания параметра
Шаг 4. Отметить риски, которые материализовались, зафиксировать баги в
системе.
Шаг 5. Пересчитать вероятности рисков с учетом того, какие материализовались,
а какие – нет.

15. Обучение системы
В режиме обучения необходимо проводить регрессионные испытания,
изменения вносятся, если:
• обнаруживается новый вид изменений в системе (такое изменение связано
либо с изменением архитектуры, либо с неправильным исходным разбиением),
• для изменения обнаруживается новый риск, который ранее не был учтен, в
этом случае добавляется новый риск

16. Демонстрация работы

17. Демонстрация работы

18. Демонстрация работы

19. Демонстрация работы
1. Добавлено поле Expirience в таблицу
- Изменены запросы на страницах, использующих поле
- Меняется валидатор значений
- Поле добавляется в фиды
- Добавляется проверка на обязательность поля
- Поле участвует в полях печати и т.д.
2. Добавлен элемент DOM на страницы Создания, Редактирования, Отображения вакансии
- Добавляется клиентская валидация поля
- Добавляется серверная валидация поля
- Добавляется поле в БД
- Добавляется поле в фид поисковой машины
- Добавляется поле в админке с валидацией
- Добавляется поле в бланк для печати
- Добавляется поле с хинтом
- Поле добавляется в поисковые запросы и параметры рассылок
3. Изменен обработчик JS для отображения поля в бланке вакансии для соискателя
- Изменение DOM, добавление, удаление, изменение элемента
- Изменение клиентской логики, отображение с прописной/строчной буквы

20. Демонстрация работы

21. Преимущества
1. Сокращается время тестирования проекта. Тескткейсы приоретизированы
2. До начала изменений разработчики могут увидеть как будет тестироваться
данный функционал
3. До начала проектирования у аналитика есть опорные точки, по которым он
может учесть проблемы, которые уже возникали в проекте, а тестировщик может
выполнять тестирование требований
4. Появляется «память проекта», в которой учтены проблемы, возникавшие ранее.
5. Формируется модель проекта, позволяющая оценить взаимосвязь архитектурных
элементов, таким образом, тестирование переносится в фазу обратной связи

22. Недостатки
1. На первом этапе обучения не все кейсы получают корректные приоритеты. Эта
проблема проявляется в самом начале, но очень быстро устраняется в процессе
работы системы. Причем устраняется значительно с меньшими затратами
ресурсов и времени, чем, например, в тех же автотестах.
2. В начале работы системы не все кейсы учтены. Эффективность работы системы
во многом зависит от квалификации инженера, выполняющего разбиение.
Однако, это компенсируется тем, что в дальнейшем для систем с одной
архитектурой база рисков уже полностью готова и требует только
незначительной настройки приоритетов кейсов.
3. Изменение архитектуры проекта влечет необходимость изменить поменять
набор рисков и тесткейсов. Архитектура проекта меняется не настолько часто и
является скорее исключением, чем правилом.

23. Спасибо за внимание, и помните,
«Работа должна доставлять удовольствие»