Сценарный тест: быть или не быть? Методика оценки целесообразности автоматизации функциональных проверок в 1С
Свою очередную публикацию мы решили посвятить сценарному тестированию. Но предлагаем обсудить в ней не технические аспекты или вопросы выбора инструментов тестирования, а принципы и подходы к принятию решений о необходимости разработки тестов по функциональным блокам.
В открытых источниках много теоретической информации об экономике тестирования программных продуктов и мы здесь не изобретаем велосипед, но делаем попытку разработать готовую для применения методику, очередную итерацию которой в настоящее время мы уже опробуем на проектах сопровождения и разработки продуктов 1С.
Принципы, которые мы выделяем как базовые в организации работы по сценарному тестированию:
- В иерархии от простого к сложному ("дымовые -> модульные (юнит) тесты -> сценарные") сценарные тесты, как правило, самые дорогие (чем выше уровень сложности - тем дороже тесты). И чем выше уровень сложности - тем меньше тестов стараемся делать, обязательно ориентируемся на критерии, а не покрываем все подряд;
- Типовой функционал не покрываем тестами. Это задача и ответственность Вендора.
- Сценарные тесты делаем только на основе тест-кейса (плана тестирования);
- Для прозрачности и системности обязательно встраиваем тесты в СI/CD, проводим анализ результатов;
- Храним тесты в репозитории GIT, помещаем тесты в репозиторий обязательно через код-ревью на этапе merge-request;
- Сценарные тесты должны работать на постоянной основе (по регламенту) и в любое время (по запросу);
- Тесты пишем на проектах сопровождения (в основном) и для стабилизированного функционала на проектах внедрения (исключения прописаны ниже);
- Активно применяем «метод бойскаута»: при разработке нового функционала принимаем решение о покрытии этого функционала тестами (ориентируемся на критерии), к принятию решения о тестировании функциональности, внедренной ранее, всегда можно вернуться;
- Стараемся не усложнять тесты, делаем их конкретно для текущего функционала, универсальность будем добавлять после появления новых смежных функциональных блоков;
- Тестовые примеры стараемся делать на существующих данных, генерация тестовых данных - это дополнительные затраты (генерацию новых тестовых данных используем только при необходимости).
В процессе подготовки обоснования для принятия решения о разработки сценарных тестов принимают участие:
- Аналитик, ответственный за задачу разработки / доработки функционального блока;
- Функциональный архитектор проекта;
- ТехЛид проекта и/или QA-инженер;
- Руководитель проекта (РП).
Решение о необходимости подготовки сценарного теста для конкретной задачи (или функционального блока, тут может быть несколько задач) принимают РП совместно с ТехЛидом на основании обоснования и рекомендаций.
Обоснование готовит инициатор разработки сценарных тестов (им может быть может любой из вышеперечисленных участников) с привлечением других участников. Готовится обоснование в формате оценки разрабатываемого функционала по следующим критериям:
Критерии для покрытия функционала сценарными тестами:
*жирным шрифтом выделены критичные критерии. Они имеют наибольший вес в оценке и наличия даже одного критерия достаточно для принятия решения о разработке сценарного теста.
Таблица 1:
|
|
Критерий |
Описание |
Ограничения |
Вес критерия (по 10 балл. шкале) |
Критичный |
|---|---|---|---|---|---|
|
1 |
Покрытие сценарными тестами разработанного функционала быстро окупается (Категория эффективности "Быстрая окупаемость", см. матрицу - таблица 4). Не требует больших трудозатрат (тест легко реализуется "кнопконажималкой") |
Например, проверка печатных форм по конкретным документам, проверка формирования результатов отчетов по стабильным данным. Зачастую в отчеты и ПФ выводятся огромные массивы данных, трудозатратно проверять их вручную. Необходимо 100%-е покрытие тестами при частом использовании этого функционала Заказчиком |
|
4 |
Нет |
|
2 |
Разработка большого функционального блока. Доработка является критичной для бизнеса Заказчика и/или имеет высокую цену ошибки. Высокий риск остановки процессов |
Если есть четкое понимание, что на тестирование данного функционала тратится много времени (часто и много) и что тесты окупятся в ближайшее время (ориентируемся на плановую оценку от Техлида). В процессе анализа и подготовки постановки на разработку функционала аналитику необходимо оценить степень критичности доработки. Не исключено, что не будет возможности покрыть весь связанный функционал, в таком случае тестом покрывается только конкретная критичная доработка (вероятно именно с ней связано большинство проблем, с которыми сталкиваются пользователи во время использования данного функционала, остальное не так критично). |
Возможно, Функционал будет покрыт тестами только частично, про это надо помнить |
10 |
Да |
|
3 |
Для тестирования доработанного функционала необходимо выполнение длительной цепочки документов, которую сложно/ долго воспроизводить при ручном тестировании либо сложно вручную выполнять проверку результата |
Решение о необходимости подготовки сценария(ев) рекомендуется принять на этапе формирования постановки для задачи на разработку функционала |
|
8 |
Да |
|
4 |
Наиболее частое использование Заказчиком доработанного в рамках задачи функционала, ключевая операция |
Наиболее часто используемый функционал является наиболее чувствительным к ошибкам, поэтому необходимы сценарии для его проверок. |
|
9 |
Да |
|
5 |
Функционал с запутанной логикой, с плохой, непродуманной архитектурой (если ресурсов на ее оптимизацию нет), часто меняющийся код, ломающийся код |
При малейших доработках, как правило, всегда что-нибудь ломается, это тяжело отследить при ручном тестировании. Постоянные повторные ошибки в работе функционала, Места, где уже были баги. В таких случаях очень помогают автотесты, они сразу подсвечивают последствия этих небольших отклонений (доработок). Как правило, тест окупается достаточно быстро, через несколько (3-5) итераций прогона. |
|
8 |
Да |
|
6 |
Отсутствие постоянно закрепленного аналитика за определенным функциональным блоком Функционал часто передается от аналитика к аналитику, часто приходится погружать в функционал разных разработчиков, отсутствует документация |
Рекомендуется подготовить базовый набор сценариев для покрытия тестами данного функционала. Тесты сами по факту являются документацией, можно записывать видеоинструкции в Vanessa. |
|
4 |
Нет |
|
7 |
Нетиповой функционал, который по статистике часто ломается при обновлении на новые релизы Вендора |
|
|
7 |
Нет |
|
8 |
Покрываем тестами НОВЫЙ функционал, пока свежи знания- это займет меньше времени. |
Разработка через тестирование |
|
2 |
Нет |
|
9 |
Нет больших рисков, что разработанные тесты будут требовать постоянную адаптацию, изменения |
|
|
1 |
Нет |
|
10 |
Повышение лояльности пользователей, возможное снижение сервисных обращений |
Есть уверенность, что на лояльность эти действия (хотя бы косвенно) повлияют и есть такая необходимость (например, после эскалации) |
|
1 |
Нет |
|
11 |
Доработки, в которых высока вероятность ошибки из - за человеческого фактора. |
Например, высоконагруженная доработанная форма с большим количеством элементов, команд, страниц. Проверка правильности формирования отчета с результирующей таблицей в тысячи строк (при сравнении с результатами отчета в эталонной базе) |
|
4 |
Нет |
|
12 |
Подготовка теста сэкономит время уже сразу в текущей разработке — пишем сразу |
Например, после каждого небольшого изменения требуется заново протестировать длительную цепочку. Идеальный вариант, если тест "окупает" себя уже до передачи разработанного в рамках основной задачи функционала на тест аналитику. |
|
10 |
Да |
Ключевые принципы:
- Приоритет бизнес-риска: Наибольший вес (10 баллов) у критериев, связанных с критичностью для бизнеса, частотой использования и сложностью функционала.
- Экономическая эффективность: Явное стремление избегать автоматизации там, где это дорого (например, типовой функционал) или не окупится.
- Проактивность: Критерии предлагают задумываться о тестах на этапе постановки задачи, а не после возникновения проблем.
- Снижение рутины: Автоматизация используется для замены долгих и скучных ручных проверок.
Введение порогового значения:
Вводим систему ранжирования. Задача должна набрать минимум 8 баллов по сумме критериев, чтобы быть строго рекомендованной для автоматизации проверок разработанного функционала. Это сделает процесс более объективным.
Рекомендации по принятию решения о разработке тестов в зависимости от набранного веса по отобранным критериям:
Таблица 2:
| < 4 |
нет рекомендаций, на усмотрение, по согласованию с ответственными лицами на проекте |
|
4-5 |
рекомендуется при наличии дополнительных факторов: наличие свободных ресурсов, особое внимание заказчика к часто проявляющейся ошибке при явном отсутствии критичности, другие важные причины |
|
6-7 |
рекомендуется |
| > 7 |
строго рекомендуется |
Примеры:
- Новый функционал (вес = 2) критичен для бизнеса (вес = 10) и часто используется (вес = 9) = 21 балл -> готовим сценарные тесты.
- Доработанный функционал для бизнеса некритичен (0), не часто используется (0), реализация автотестов трудозатратна (0), при этом тест легко реализуется "кнопконажималкой" (4) и каждый раз заказчик обращает на это внимание (1) = 5 -> готовим сценарные тесты.
- Для тестирования Нового функционала (2), требуется Повышение лояльности пользователей (1) , функционал не часто используется (0) , не очень критичен для бизнеса (0) = 3 балла -> сценарные тесты не готовим.
Чек-лист (алгоритм принятия решения):
Порядок оценки:
ШАГ 1 → Проверить Cтоп-сигналы
Если хоть один пункт подходит - тест не разрабатываем. Дальше не идем.
ШАГ 2 → Проверить ключевые критерии
Если есть хоть один - подготовка теста строго рекомендована.
Обязательно проверяем категорию эффективности по матрице окупаемости (таблица 4). Если тест относится к категории "Сомнительная ценность", то требуется дополнительное обсуждение с ответственными лицами проекта.
ШАГ 3→ Оценка второстепенных критериев
Обращаемся к Скорингу, если в Шаге 2 нет критических критериев. Считаем баллы, принимаем решение по таблице.
Обязательно проверяем Категорию эффективности по матрице окупаемости (таблица 4), если относится к категории "Сомнительная ценность", то требуется дополнительное обсуждение с ответственными лицами проекта.
Пример принятия решения о разработке сценарного теста:
Тест: Отчет "Справка-расчет амортизации ОС" формируется без ошибок, результат соответствует эталону.
- Cтоп-сигналы: отсутствуют;
- Ключевые критерии: отсутствуют;
- Прочие критерии:
Таблица 3:
| п.п. | Критерий | Оценка |
|
1 |
№1 Покрытие сценарными тестами разработанного функционала не требует больших трудозатрат |
4 |
| 2 |
№7 Нетиповой функционал, который по статистике часто ломается при обновлении на новые релизы Вендора |
7 |
| 3 |
№11 Доработки, в которых высока вероятность ошибки из - за человеческого фактора. |
4 |
| Суммарный вес: | 15 |
Вывод: по набранному суммарному весу (15 баллов) и матрице окупаемости (категория "Быстрая окупаемость") принимается решение о разработке функционального теста.
Матрица окупаемости сценарных тестов:
Таблица 4:
| Категория окупаемости | Коэффициент = Время подготовки теста / Время ручного тестирования (1 проверка) | Пример |
| Быстрая окупаемость |
< 5 |
Время подготовки автотеста * = 4 ч., 1 ручная проверка = 2 ч., Коэфф. = 2 (окупаемость за 2 проверки **) |
| Cредняя окупаемость (Умеренная выгода) |
5-10 |
Время подготовки автотеста * = 12 ч., 1 ручная проверка = 2 ч., Коэфф. = 6 (окупаемость за 6 проверок **) |
| Долгая окупаемость (Долгосрочные инвестиции) |
10-25 |
Время подготовки автотеста * = 20 ч., 1 ручная проверка = 1 ч., Коэфф. = 20 (окупаемость за 20 проверок **) |
| Сомнительная ценность |
> 25 |
Время подготовки автотеста * = 100 ч., 1 ручная проверка = 2 ч., Коэфф. = 50 (окупаемость за 50 проверок **) |
* - Время подготовки автотеста - это время подготовки сценарного теста "под ключ" (от постановки до завершения приемочных проверок);
** - Одна проверка - это один тестовый прогон по сценарию в базе контура Dev, Test или PreProd.
Заключение:
Здесь рассмотрен не окончательный вариант методики принятия решения по сценарным тестам, ее алгоритм корректируется по итогам полученной обратной связи от участников процесса.
Также в наших планах реализовать следующие пункты плана по развитию сценарного тестирования на проектах:
- Обучение ключевых сотрудников проектных команд разработке и анализу результатов сценарных тестов (свой мини-курс);
- Подготовка командных правил работы со сценарными тестами (экспортные сценарии, правила именования, количество тестов);
- Определить и согласовать роли (ответственных) при подготовке, использовании и сопровождении сценарных тестов на проектах;
- Составить общую матрицу покрытия сценарными тестами функционала (какие процессы уже покрыты, какие нет) на проектах.
Публикуя этот материал, ожидаем получить от сообщества обратную связь - будем рады, если вы поделитесь с нами своими наработками и опытом в части оценки необходимости тестирования нового функционала, а также готовы выслушать объективную и конструктивную критику с предложениями по улучшению описанных бизнес-процессов.
Благодарим за интерес к публикации.
Вступайте в нашу телеграмм-группу Инфостарт
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.