Система генерации чек-листов для регрессионного тестирования на основе анализа рисков

или QA паранойя

Солодов ВладимирSuperjob, Москва, Россия

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

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

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

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

Функционал, не связанный с изменением, 45% критичных багов

Мы хотим

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

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

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

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

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

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

Изменение 1.

Программист поменял код HTML на странице: он обрамил текст ссылки в тег <font color=”red”> и забыл его закрыть. Все работает, ссылка корректно окрашена.

Расширяем контекст.

Ниже в верстке есть поп-ап, который появляется при клике на ссылку «Ссылка3», Текст в попапе окрашивается в цвет, который мы установили для ссылки.

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

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

Изменение 2.

Программист поменял существующий стиль программы, добавил в css-стиль строку color: red и убрал style:linked.

Расширяем контекст.

В шаблонах других странице данным стилем обозначены все ссылки на данную страницу, а их текст мы хотим оставить прежним.

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

Изменение 3.

Программист добавил в css новый стиль, новый идентификатор, для которого корректно указал цвета.

Расширяем контекст.

С данным стилем, идентификатором был связан код JS, который сейчас не работает.

Риски реализации

Риск – вероятное событие, приводящее к негативным последствиям.

Величина риска = (вероятность) x (ущерб) = P x H

Ущерб

Ве

ро

ятн

ост

ь 1 2 3

1 1 2 3

2 2 4 6

3 3 6 9

Риски реализации

Гипотезы, которые мы приняли

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

Одним из таких инвариантов в компьютерной программе является архитектура приложения.

Инициализация. Шаги 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). Логика

Инициализация. Шаги 3,4 из 4

Шаг 3. Для каждого изменения можно определить риски, следующие из здравого смысла и определить им вероятность возникновения 0,5, вред определить из логики приложения.

Шаг 4. Для каждого риска предусмотреть тест-кейсы, которые должны быть выполнены, чтобы данный риск был протестирован.

Риск Симптом

1 Стиль наследует данные, которые конфликтуют с версткой

Верстка нового элемента некорректна

2 Стиль используется другими элементами Верстка сопряженных элементов некорректна

3 Атрибуты наследуются другими элементами Верстка сопряженных элементов некорректна

4 Некорректно работают JS-обработчики Не работают скрипты добавления, модификации элементов DOMa

Алгоритм работы

Шаг 1. Отметить какие изменения были внесены в систему.

Шаг 2. Выбрать риски для изменений, которые отмечены и отранжировать их в порядке убывания параметра P x H, для данных рисков уже заранее определены тесткейсы

Шаг 3. Проверить, риски в порядке убывания параметра

Шаг 4. Отметить риски, которые материализовались, зафиксировать баги в системе.

Шаг 5. Пересчитать вероятности рисков с учетом того, какие материализовались, а какие – нет.

Обучение системы

В режиме обучения необходимо проводить регрессионные испытания, изменения вносятся, если:

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

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

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

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

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

1. Добавлено поле Expirience в таблицу- Изменены запросы на страницах, использующих поле - Меняется валидатор значений - Поле добавляется в фиды- Добавляется проверка на обязательность поля - Поле участвует в полях печати и т.д.

2. Добавлен элемент DOM на страницы Создания, Редактирования, Отображения вакансии- Добавляется клиентская валидация поля- Добавляется серверная валидация поля - Добавляется поле в БД - Добавляется поле в фид поисковой машины - Добавляется поле в админке с валидацией- Добавляется поле в бланк для печати - Добавляется поле с хинтом- Поле добавляется в поисковые запросы и параметры рассылок

3. Изменен обработчик JS для отображения поля в бланке вакансии для соискателя- Изменение DOM, добавление, удаление, изменение элемента- Изменение клиентской логики, отображение с прописной/строчной буквы

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

Преимущества

1. Сокращается время тестирования проекта. Тескткейсы приоретизированы

2. До начала изменений разработчики могут увидеть как будет тестироваться данный функционал

3. До начала проектирования у аналитика есть опорные точки, по которым он может учесть проблемы, которые уже возникали в проекте, а тестировщик может выполнять тестирование требований

4. Появляется «память проекта», в которой учтены проблемы, возникавшие ранее.

5. Формируется модель проекта, позволяющая оценить взаимосвязь архитектурных элементов, таким образом, тестирование переносится в фазу обратной связи

Недостатки

1. На первом этапе обучения не все кейсы получают корректные приоритеты. Эта проблема проявляется в самом начале, но очень быстро устраняется в процессе работы системы. Причем устраняется значительно с меньшими затратами ресурсов и времени, чем, например, в тех же автотестах.

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

3. Изменение архитектуры проекта влечет необходимость изменить поменять набор рисков и тесткейсов. Архитектура проекта меняется не настолько часто и является скорее исключением, чем правилом.

Спасибо за внимание, и помните,

«Работа должна доставлять удовольствие»