Что такое проверка и тестирование услуг и сколько проверок достаточно

Зачем проверка и тестирование услуг

Новая или изменённая услуга приносит в рабочую среду риски и неопределённость. ПрактикаПрактикаНабор ресурсов организации для выполнения работы определённого типа.ITIL 4 снижает и то и другое: нужные проверки планируются заранее и проводятся до выпуска 1.

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

Практика даёт уверенность в качестве, а не гарантию безупречности. Уверенность зарабатывают проверками, которые показывают: услуга работает как требуется, значимых дефектов в ней нет 1.

Отсюда следует и то, как разговаривать с заказчиком. Обещать «мы всё протестировали» нечестно. Честно сказать: «мы проверили самое важное — и вот почему именно это».

Когда практика работает

Три вопроса. Ответы на них ищут в плане проверок, а не в отчёте об их результатах.

Критерии приёмки заданы до начала работ. Как проверить: заранее известно, при каких условиях результат будет принят. ГОСТ требует испытывать новое на соответствие согласованным критериям 2.

Объём проверки соразмерен риску. Как проверить: мелкое изменение и крупное проходят разный объём проверок. FitSM прямо требует соразмерности типу релиза и его влиянию 3.

Проверки находят не только поломки. Как проверить: после проверок появляются сведения о рисках и о том, чего команда не знала, а не только список дефектов 1.

Что входит и что рядом

Проверка замысла и проверка результата

В практике две разные работы, и в разговоре обе называют одним словом «тестирование» 1.

Проверка замысла идёт на ранних стадиях, пока услугу обдумывают и проектируют. Она подтверждает, что замысел отвечает согласованным требованиям, и задаёт критерии приёмки для следующих стадий — разработки, развёртывания и выпуска 1.

Тестирование идёт уже по этим критериям: команда составляет стратегию и планы проверок, а затем сверяет результат с тем, о чём договорились 1.

Проверка замысла смотрит на пять сторон услуги: полезность, гарантию, опыт пользователя, управляемость и соответствие требованиям 1. О двух последних вспоминают только в эксплуатации: услугу приняли, а как ею управлять и чем доказывать соответствие — не спросили.

Что на входе и что на выходе

На входе — требования и замысел. На выходе — решение: годится услуга или нет и что именно в ней рискованно. ГОСТ Р ИСО/МЭК 20000-1 задаёт минимум этого обмена: новое и изменённое испытывают на соответствие требованиям, документированному проекту и согласованным критериям приёмки; если критерии не соблюдены, решение принимают вместе с заинтересованными сторонами 2.

Ценно и обратное движение: сведения о найденных рисках возвращаются в проектирование и разработку — там их закрыть дешевле.

Проверка по рискам

Практика строится вокруг рисков продукта, и причина понятна: взгляд через риск показывает, как именно услуга может подвести 1.

Привычная альтернатива — перечень видов тестирования: функциональное, регрессионное, нагрузочное, тестирование безопасности, удобства, совместимости, доступности, сквозное, интеграционное 1. Каждый вид закрывает свой риск. У ITIL здесь трезвое наблюдение: команды обычно знают десять–пятнадцать видов, а в стратегию включают пять–восемь 1. Остальные риски остаются без проверки — просто потому, что для них нет привычного вида тестирования.

Чтобы находить риски заранее, ITIL 4 предлагает четыре шага 1:

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

Найденные риски ITIL советует записывать картой: она легко читается и остаётся полезной и при проектировании, и позже — в исследовательских проверках 1. Там же наблюдение из практики: в гибкой разработке пользовательские истории и критерии приёмки говорят об ожидаемых возможностях и почти никогда — о рисках 1.

Как это работает

В практике три процесса: ведение подхода и моделей проверки, проверка замысла и проведение проверок 1.

Цвет шага: приём, учёт, работа с обращением техническая работа решение и полномочия проверка, разбор, улучшение

Два шага заслуживают отдельного пояснения.

Третий шаг делают до постройки, а не после. Критерии приёмки — результат проверки замысла 1. Договариваться о них, когда всё уже построено, поздно и дорого.

Седьмой шаг питается инцидентами. Дефект, который нашли пользователи, — вопрос к плану проверок: почему его не поймали и что изменить, чтобы поймать похожий.

Что с чем путают

Проверка и тестирование. Первая — про замысел и критерии, второе — про результат 1.

Тестирование и приёмка. Тестирование даёт факты, приёмка — решение. Решение принимают заинтересованные стороны; если критерии не соблюдены, ГОСТ прямо требует их участия 2.

Тестирование и контроль качества. Проверка выпуска — часть работы. А вот почему дефекты повторяются — вопрос к QtMУправление качеством.

Полнота и достаточность. Полная проверка невозможна 1. Достаточная — та, что покрывает значимые риски, а по объёму соразмерна влиянию изменения 3.

Кто участвует

Как измерять

Два показателя стоит смотреть вместе: дефекты после выпуска и время, которое добавляет проверка. По отдельности первый «лечится» бесконечными проверками, второй — их отменой.

Пропущенное проверками считают в деньгах, а не в штуках. ITIL 4 формулирует это прямо: «потери от инцидентовИнцидентНезапланированное прерывание услуги или снижение её качества.ITIL 4, практическое руководство по управлению инцидентами и проблемПроблемаПричина одного или нескольких инцидентов.ITIL в услугах, пропущенных проверками» 1. Разница с привычным счётчиком дефектов принципиальная. Двадцать пропущенных мелочей и один пропущенный сбой в расчёте зарплаты в штуках несопоставимы, а в деньгах — вполне. И сколько вкладывать в испытания, решают по деньгам.

Пригодность и гарантию проверяют раздельно. Среди показателей есть доля продуктов и услуг, которые отвечают требованиям и по пригодности, и по гарантии 1. То есть проверяют и «делает ли оно то, что нужно», и «делает ли достаточно надёжно». Испытания, которые спрашивают только о первом, пропускают ровно тот класс бед, который потом достаётся эксплуатации.

У практики есть один сводный показатель. ITIL называет его показателем продуктивности проверки и тестирования услуг 1. Сводный показатель удобен для разговора наверх и опасен внутри: он скрывает, за счёт чего вырос — команда стала лучше отбирать проверки или просто стала проверять меньше. Держать его стоит вместе с составляющими, а не вместо них.

Зрелость проверки и тестирования

✕

Где ломается чаще всего

Шесть мест, по убыванию частоты.

Критерии приёмки появляются в конце. Что считать годным, выясняют, когда всё уже построено 1.

Объём проверки один для всего. Мелкая правка проходит тот же путь, что переезд системы, — или наоборот, крупное изменение проверяют наспех 3.

Проверяют только функции. Нагрузка, безопасность, доступность и удобство остаются вне плана: для них нет привычного вида проверки 1.

Риски нигде не записаны. Их обсуждают устно и забывают. Нужна карта рисков 1.

Проверяют на рабочей среде. Отдельной среды нет, и пользователи участвуют в тестировании, не подозревая об этом.

После инцидента план проверок не меняется. Дефект исправили, а вопрос «почему не поймали» не задали.

Что говорят своды

69Своды знаний и стандарты — разобраны отдельноЧем ITIL отличается от COBIT и ISO, что из этого обязательно, а что на выбор, и где брать первоисточник. У каждого свода отмечено, развивается он или давно заморожен, и есть ли действующий ГОСТ. По 51 практикам из 62 проставлено соответствие COBIT.Открыть →

ITIL держит проверку и тестирование одной практикой, строит её вокруг рисков продукта и прямо говорит, что полная проверка невозможна 1.

ГОСТ Р ИСО/МЭК 20000-1 требует испытывать новое и изменённое на соответствие требованиям, проекту и согласованным критериям приёмки, а при несоблюдении критериев — принимать решение вместе с заинтересованными сторонами 2.

FitSM добавляет соразмерность: объём проверки соответствует типу релиза и его возможному влиянию 3.

COBIT отдельной цели для тестирования не содержит: проверки входят в разработку решений и в передачу изменений 4.

Вывод для практики: спор «сколько тестирования достаточно» бессмыслен без разговора о рисках. Все своды сходятся на одном — объём проверки определяется тем, насколько значимо то, что может пойти не так.

Где описано

Что почитать дальше

Три соседние практики, между которыми стоит проверка: SDSПроектирование услуги — откуда берутся критерии приёмки, RLSУправление релизами — что происходит после решения «годится», QtMУправление качеством — почему дефекты повторяются.