Когда в ИТ-среде речь заходит о тестировании, то, как правило, говорят о тестировании цифрового продукта. И многие считают, что если продукт протестирован и избавлен от багов, то он уже имеет ценность для потенциальных пользователей. При этом упускают из виду, что ценность продукта реализуется через услугу. Цифровой продукт и услуга – это две стороны одной медали. Эта тема подробно разбирается в статье Цифровые продукты и услуги: вместе лучше – Digital Enterprise. И когда подготовке услуг не уделяется должное внимание, то они при начале использования могут парализовать работу поддержки и вызывать ступор у пользователей.
Тестирование цифрового продукта vs тестирование услуги
В тестировании цифрового продукта и тестировании услуги есть отличия, приведенные ниже.
| Аспект |
Тестирование цифрового продукта |
Тестирование ИТ-услуги |
| Объект проверки | Код, конфигурация, интерфейс, API, производительность железа | Процесс создания ценности для пользователя (включая поддержку, SLA, документацию, обучение) |
| Главный вопрос | «Соответствует ли система спецификации и не падает ли она?» | «Может ли Service Desk обслужить запрос по новой услуге? Готовы ли процессы?» |
| Кто проводит | Инженеры QA, разработчики | Владелец услуги, менеджер внедрения услуги, эксплуатационная команда |
| Что считается дефектом | Ошибка в коде, сбой, утечка памяти | Отсутствие сценариев, необученная поддержка, отсутствие метрик SLA, невозможность зарегистрировать инцидент |
Продукт может быть полностью исправен, но услуга непригодна для использования. Почему? Потому что услуга включает в себя людей, процессы, инструменты поддержки и документацию. Если обучение поддержки не было проведено, то значит услуга не готова к работе.
Тестирование в едином жизненном цикле продуктов и услуг
Современный ITSM оперирует единым жизненным циклом продуктов и услуг, состоящим из 8 основных этапов.
Давайте посмотрим, как тестируется услуга на этих этапах.
| Этап жизненного цикла |
Тестирование услуги (что делаем) |
| Выявление продукта и услуги |
Концептуальное тестирование: проверяем гипотезу «А сможем ли мы поддерживать эту услугу имеющимися ресурсами?» |
| Проектирование продукта и услуги |
Валидация требований к поддержке: закладываем в дизайн проверяемость и наблюдаемость (мониторинг, логи, трейсы). |
| Приобретение и распределение ресурсов |
Тестируем услуги внешних поставщиков на готовность взаимодействия с локальной поддержкой. |
| Создание и тестирование продукта и услуги |
Непрерывное тестирование: каждая КЕ новой услуги в CMDB проверяется на связи с процессами. |
| Внедрение (преобразование) |
Основная фаза тестирования услуг. Проводятся тесты операционной готовности (ORT), тесты пользовательской приемки (UAT), нагрузочное тестирование, регрессивное тестирование, проверка сценариев, аттестация поддержки. |
| Эксплуатация |
Пост-имплементационное тестирование: проверяем, совпадает ли поведение в продуктовой среде с тестовой средой. Непрерывный мониторинг SLA. |
| Предоставление и поддержка |
Тестирование гипотез изменений и инициатив по улучшению. |
Основные виды тестирования услуг: классификация и применение
Как видим, поддержка услуги должна быть вовлечена в разработку цифрового продукта с самого первого этапа жизненного цикла. Какие же виды тестирования проводятся на разных этапах? Можно разделить виды тестирования услуг на две категории: по цели тестирования (проверочное / выявляющее) и характеру тестирования (функциональное, нефункциональное, регрессивное).
По цели: проверочное и выявляющее
| Вид | Суть |
Когда применять |
| Проверочное (Verification) |
Подтверждаем соответствие спецификации (SLA, OLA, UC). |
На этапе внедрения, после сборки услуги. |
| Выявляющее (Validation) | Понимаем, действительно ли услуга приносит ценность бизнесу и пользователям и не несет ли скрытые риски. | UAT, пилотная эксплуатация, после внесения изменений. |
Наилучший результат дает сочетание проверочного и выявляющего тестирования для услуги. При чем сначала проводят проверочное (всё работает как надо), потом выявляющее (действительно ли это нужно бизнесу).
По характеру: функциональное, нефункциональное, регрессивное
Функциональное тестирование услуги
Что проверяем: Способность услуги выполнять ровно то, что обещано в каталоге услуг.
Методы: позитивные и негативные сценарии.
Пример: «Пользователь может открыть заявку → получить ответ → закрыть её». И альтернатива: «Пользователь ввел неверные данные → система выдала корректную ошибку и предложила решение».
Нефункциональное тестирование услуги
Что проверяем: Как услуга работает (или будет работать) под нагрузкой, в стрессовых условиях, насколько она доступна, безопасна, удобна.
Нефункциональное тестирование может проверять такие параметры как:
Нагрузка (Performance) — держит ли услуга пиковые нагрузки?
Доступность (Availability) — что происходит при отказе одного узла?
Поддерживаемость (Supportability) — может ли L2 найти причину инцидента за 10 минут?
Безопасность (Security) — способна ли услуга противостоять различным видам угроз ИБ?
Регрессивное тестирование услуги
Возможно это самое недооцененное тестирование в ITSM.
Что проверяем: Не сломали ли мы изменением в одной услуге другие (смежные) услуги.
Пример: Изменили процесс сброса пароля (убрали ручную проверку). Регресс: не перестали ли автоматически создаваться учетные записи новым сотрудникам в Active Directory? (Сюрприз — перестали).
Когда проводить: Всегда при любом изменении услуги, а также при развертывании новой услуги в ландшафте, где есть зависимости в CMDB.
Основные метрики тестирования услуг
Проводить тестирование услуг — это пол дела. Как и в любой деятельности нужно понимать, дает она ожидаемый результат или это просто бесполезный ритуал. Вот ключевые метрики, которые помогут понять, насколько эффективно работают процессы тестирования.
| Метрика | Смысл |
| Покрытие тестами процессов поддержки |
Доля процессов (Incident, Request, Problem, Monitoring), проверенных в ORT, % |
| Количество дефектов услуги |
Количество выявленных дефектов услуги (отсутствие сценариев, необученная поддержка) на этапе внедрения. |
| Время от обнаружения дефекта до закрытия |
Среднее время исправления ошибок в процессах поддержки |
| Процент успешных внедрений с первого раза |
Услуги, принятые в эксплуатацию без возврата на доработку |
| Количество критических инцидентов по услуге в первые 2 недели после релиза | Прямой индикатор плохого тестирования услуги |
| Дефицит знаний поддержки |
% запросов, которые L1 не смог решить из-за отсутствия инструкции |
Здесь важно отметить, что если измерять только «количество тест-кейсов», то это будет измерение активности, а не результата. Для объективной оценки нужны метрики, привязанные к бизнес-результатам: снижение инцидентов, рост удовлетворенности, соблюдение SLA.
На что обратить внимание для повышения эффективности и результативности тестирования услуг
Чтобы процесс тестирования услуг приносил ожидаемые результаты необходимо обратить внимание на следующие моменты:
Вовлечение эксплуатации на этапе дизайна
Самая эффективная метрика — «количество замечаний от поддержки до начала тестирования». Если первый раз эксплуатация видит услугу на тесте операционной готовности, то вы опоздали. Вовлекайте сервис-деск и поддержку в демо и ревью дизайна продукта.
Отказ от «тестирования ради галочки»
Внедрите строгий чек-лист приемки в эксплуатацию, где каждый пункт — это подтверждение (скриншот, лог, протокол). Без согласования всех сторон (Бизнес, Владелец услуги, Эксплуатация) услуга не должна стартовать.
Непрерывное тестирование услуги
Как уже было отмечено ранее различные виды тестирования услуги проводятся на всех этапах жизненного цикла. Тестирование услуги после этапа внедрения дает постоянное подтверждение того, что услуга остается пригодной.
Как реализовать непрерывное тестирование услуги во время эксплуатации:
Синтетические транзакции: регулярная проверка ключевых сценариев услуги.
Автоматические проверки SLA: Автоматический контроль выполнения условий SLA системой мониторинга.
Регулярные аудиты документации: Регулярная проверка документации, не устарели ли сценарии (не изменилась ли версия системы, не уволился ли эксперт).
Здесь не следует пренебрегать возможностями ИИ для автоматизации некоторых видов тестирования, проверки версионности документации и т.п.
Резюме
Тестирование продукта не равно тестирование услуги. Можно иметь идеальный продукт, но он не будет нести ценность для потребителя если его поддержка провалена.
- Основной этап тестирования услуги — Внедрение, но начинается оно в Проектировании и никогда не заканчивается (непрерывное тестирование).
- Чтобы улучшить процесс автоматизируйте проверки эксплуатации услуги, вовлекайте поддержку раньше, требуйте чек-лист приемки.
- Услуга, не прошедшая тест эксплуатационной готовности, не имеет права появляться в каталоге услуг.
