Приём IT-проекта: критерии качества и чек-лист для бизнеса

Что приём обязан подтвердить до того, как вы подпишете акт

Самая частая ошибка при приёме заказной разработки - оценивать результат по одному измерению. Экраны работают, значит проект сделан. Через четыре месяца тот же проект оценивают заново: уже по стоимости каждой мелкой доработки, по времени, которое поддержка тратит на ручную сверку записей, и по тому, что разворачивать систему умеет один человек. Обе оценки относятся к одной и той же поставке. Но только первая делалась, пока у вас ещё были рычаги влияния.

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

Пригодность для бизнеса, техническое качество и способность эксплуатировать

Пригодность для бизнеса означает, что процесс можно пройти от начала до конца силами тех людей, которые занимаются им каждый день, включая случаи, которые они не любят. Частичное наличие товара на складе, клиент, которому нужна нестандартная скидка, заказ, отменённый после того, как склад уже начал сборку. Счастливый путь - самая простая для реализации часть любой системы и самая неинформативная для проверки.

Техническое качество означает, что согласованные свойства выполняются в согласованных условиях: время отклика на операциях, которые действительно важны, разграничение доступа между клиентами, кодовая база, способная безопасно принять изменение. Качество продукта многомерно по самой своей конструкции - именно поэтому международная модель качества продукта, опубликованная как ISO/IEC 25010, описывает качество набором характеристик, а не единым вердиктом. Мы работали с публичной аннотацией стандарта, а не с полным платным текстом, и не заявляем здесь ни о соответствии, ни о сертификации. Полезный вывод структурный: если ваши критерии приёма описывают только функции, вы записали одну характеристику, а остальные оставили на волю случая.

Способность эксплуатировать означает, что ваша сторона может развернуть, отслеживать, поддерживать и восстанавливать систему. Именно это измерение заказчики чаще всего обнаруживают у себя отсутствующим, потому что оно невидимо, пока подрядчик ещё в проекте и отвечает на звонки.

Что доказывают приёмочное тестирование, техническая оценка и передача системы

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

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

Мы разделяем эти три части, чтобы ответственность и доказательства распределялись понятно, а не потому, что они друг другу противоречат. Программа ISTQB Certified Tester Acceptance Testing формулирует то же самое со стороны тестировщика: приёмочные работы держатся на ранней и непрерывной совместной работе бизнес-аналитиков, владельцев продукта и тестировщиков, причём критерии определяются до разработки, а не восстанавливаются после неё. На практике именно эта совместная работа превращает ожидание бизнеса в то, что два разных человека могут проверить и о чём могут договориться.

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

Как превратить ожидания бизнеса в критерии приёма ПО, которые действительно можно проверить

Большинство спорных поставок упирается в требование, записанное как намерение. «Заказы оформляются на портале» - это намерение. Два честных человека прочитают эту формулировку, посмотрят на одну и ту же систему и придут к противоположным выводам о том, выполнена ли она. Подрядчик видит заказ, дошедший до ERP. Менеджер по продажам видит заказ, по которому всё равно нужен звонок, чтобы подтвердить дату поставки.

Критерий проверяем тогда, когда кто-то, кроме его автора, может выполнить проверку и получить тот же результат. Вся планка - в этом. Не нужна ни формальная нотация, ни инструмент тестирования, ни отдел QA. Нужны конкретное условие, конкретное действие и конкретный ожидаемый результат, который можно наблюдать где-то ещё, кроме головы того, кто его написал.

Свяжите требование, проверку и подтверждение в одной матрице приёма

Самый полезный артефакт приёма - матрица, которая связывает каждое бизнес-требование со способом проверки и с человеком, отвечающим за вердикт. Это трассируемость требований в самом простом виде: каждое требование прослеживается вперёд до проверки и до подтверждения, а каждое подтверждение - назад до требования. Подтверждение проверки - это наблюдаемая запись о том, что проверка была выполнена, и о том, что она дала.

Строки ниже взяты из сквозного примера с оптовой компанией. Они написаны как образец формы, а не как описание проекта конкретного клиента Webdelo.

Обратите внимание, что считается подтверждением в этой таблице. Скриншот зелёного экрана подтверждения - самый слабый вид, потому что он показывает, что система сказала о себе сама. Запись в принимающей системе и строка в журнале обмена сильнее, потому что показывают, что на самом деле произошло дальше по цепочке. Когда есть выбор, предпочитайте подтверждения, которые порождает сама проверяемая система и которые может прочитать человек, не проводивший проверку.

Заполнение этой матрицы до старта тестирования меняет тон всей работы. Разногласия переезжают с конца проекта, где они дорогие и переходят на личности, в начало, где они дешёвые и технические.

Как восстановить критерии, которые никто не записал

Реальная ситуация обычно менее опрятна: проект почти сдан, а критерии никто никогда не согласовывал. Это частый случай, и он поправим. И это не повод принимать то, что привезли.

Разберите его в три шага. Первый: соберите то, о чём действительно договаривались, - исходное техническое задание, утверждённые запросы на изменение, решения встреч, по которым обе стороны фактически действовали. Второй: ранжируйте критичные бизнес-операции по ущербу от их отказа и напишите критерии сначала для них. В нашем примере этот список короткий: оформление заказа, ценообразование и согласование, передача на склад, разделение данных клиентов. Третий: всё оставшееся разложите на два списка, которые нельзя смешивать никогда.

• Новые запросы. То, что никто не обязывался делать. Это может быть ценно и может быть срочно, и всё равно относится к следующему этапу со своим бюджетом.
• Спорные ожидания. То, что одна сторона считала включённым, а другая нет. Здесь нужно решение, а не тикет о дефекте.

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

«Я рекомендую обсуждать критерии приёма с тем, кто ведёт процесс ежедневно. В требовании вроде „заказ оформлен“ важные правила часто остаются невидимыми: кто согласует нестандартную скидку, что происходит при частичном наличии товара, в какой момент заказ считается переданным на склад. Если эти правила не записаны, можно успешно проверить функцию и всё равно получить процесс, который сотрудникам приходится доводить вручную».

Дмитрий Черчел

Архитектор

Практическая инструкция внутри этой цитаты - о том, кого именно опрашивать. Спонсоры описывают процесс таким, каким он задуман. Человек, который ведёт его каждый день, описывает исключения, а именно в исключениях живут незаписанные правила. Заложите два-три часа на разговор с этим человеком до того, как критерии будут зафиксированы, и спрашивайте не о том, что он делает обычно, а о том, что он делает, когда что-то пошло не так.

Кто что проверяет и на какой сборке

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

И то и другое предотвращается решениями, принятыми до начала тестирования, и почти не лечится после.

Кто подтверждает пригодность, кто проверяет требования и кто принимает остаточный риск

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

• Владелец бизнес-процесса подтверждает, что сценарии отражают реальный порядок работы и что результатом может пользоваться его команда. В нашем примере это руководитель отдела продаж, а не ИТ-директор.
• QA и техническая команда проектируют проверки и производят подтверждения, в том числе нефункциональные: замеры, тесты доступа, результаты развёртывания.
• Уполномоченный руководитель принимает остаточный риск. Остаточный риск - это известная и описанная незакрытая зона, которую вы сознательно соглашаетесь нести: интеграция, которую не удалось проверить на реальной смежной системе; уровень нагрузки, который никто не замерял; модуль без автоматических проверок. Он никогда не становится нулевым, а попытки сделать вид, что стал, просто убирают его из поля зрения.

Впишите три фамилии в план приёма. «ИТ подтвердит» - это не ответственный, и на практике это значит, что вердикт вынесет тот, кому труднее всего отказаться.

Зафиксируйте сборку, окружение, данные и известные ограничения

Релиз-кандидат - это конкретная сборка, предложенная к приёму и обозначенная настолько точно, чтобы любой мог понять, на неё он смотрит или нет. Зафиксируйте четыре вещи до того, как кто-либо начнёт тестировать.

• Сборка. Точная версия или идентификатор сборки, применённая конфигурация, состояние всех функциональных флагов. Если посреди приёма появляется новая сборка, это решение, которое принимают открыто, а не фоновое событие.
• Окружение. Какие внешние системы реальные, какие имитируются, какие просто недоступны. Это определяет, на что вообще может распространяться ваш вывод.
• Данные. Реалистичные обезличенные или синтетические данные с объёмом и неудобными формами продуктива: длинные названия клиентов, многопозиционные заказы, просроченные прайс-листы. Три строки с названием «тест» не доказывают ничего.
• Ограничения. Что этот круг приёма не покрывает и почему. Названные заранее ограничения не превращаются позже в обвинения.

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

Проверка целых бизнес-процессов, включая неудобные сценарии

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

Сценарий ниже иллюстративный: оптовая компания с B2B-порталом для клиентов, ERP для заказов и остатков и отдельной складской системой для сборки и отгрузки. Формы проверок переносятся и на другие конфигурации, даже когда системы другие.

Проведите один заказ от B2B-портала через ERP на склад

Проследите один заказ по всему маршруту и проверьте бизнес-результат на каждом переходе. Клиент оформляет заказ на портале. Применяются правила ценообразования, включая договорные цены клиента и объёмные ступени. Применяются правила согласования там, где скидка превышает порог. Заказ доходит до ERP и становится реальным документом с реальным номером. Складская система получает задание на сборку. Статусы возвращаются обратно, и клиент с менеджером по продажам видят одно и то же состояние одного и того же заказа.

На каждом переходе проверяйте результат, а не сообщение. Корректные цены в ERP, а не просто успешно доставленное сообщение. Задание на сборку с нужными позициями в нужном количестве. Статус, который видит клиент, совпадает со статусом, который видит менеджер. Специально включите ветку согласования: именно на согласованиях обычно и заканчивается «в демо всё работало», потому что демо записывают на маршруте, где согласования нет.

Отмены, повторные отправки и недоступные интеграции

Это та часть приёма, которая окупает себя, и единственное место в этом чек-листе, где разбираются отказы интеграций. Разберите их здесь полностью.

• Отмените поздно. Отмените заказ после того, как он дошёл до ERP, затем ещё один - после того, как началась сборка. Проверьте, что после этого считает каждая система: портал, ERP, склад и резерв на остатках. Отмена, после которой товар остаётся зарезервированным в одной системе и свободным в другой, через неделю даёт недостачу, которую никто не может объяснить.
• Повторите отправку. Отправьте один и тот же заказ дважды: двойным кликом, обновлением страницы и сетевым таймаутом с последующим повтором со стороны клиента. Дубли - классический ущерб для среднего бизнеса: второй документ в ERP превращается во второе задание на сборку, второе задание - во вторую физическую отгрузку, и цена этого ложится на отношения с клиентом не меньше, чем на логистический бюджет.
• Разорвите связь посреди процесса. Отключите ERP, пока заказ в пути. Операция встанет в очередь и повторится, упадёт громко - с видимым сообщением и ответственным, - или исчезнет молча? Тихая потеря - худший исход и самый частый. Затем верните ERP и проверьте, что обмен восстанавливается и сверяется, а не переигрывает всё подряд с дублированием проводок.
• Проверьте частичный случай. Остатков хватает на половину заказанного количества. Система разделит заказ, придержит его или отгрузит то, что есть? Каким бы ни был ответ, это должен быть тот ответ, который бизнесу действительно нужен, и записан он должен быть заранее.

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

Сверьте перенесённые данные

Совпадение количества строк - это не сверка. Миграция может перенести все строки и при этом сломать связи, которые делают эти строки осмысленными. Проверьте четыре вещи прицельно: связи клиентов с договорами, прайс-листы и клиентские скидки, открытые заказы, которые были в работе на момент перехода, и исторические итоги, на которых держится ваша отчётность. Затем возьмите выборку реальных записей и проведите каждую от начала до конца: из старой системы в новую и дальше в отчёт, который её использует.

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

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

Технические свойства, которые определяют, во что система обойдётся потом

Функциональная корректность определяет, можно ли запускаться. Свойства из этого раздела определяют, сколько вы заплатите за следующие три года: в счетах за инфраструктуру, в цене каждого запроса на доработку и во времени, которое ваши люди тратят на обходные пути. Это те характеристики, которые модель качества продукта ISO/IEC 25010 рассматривает как самостоятельные измерения: производительность, безопасность, сопровождаемость. Их сложнее проверить, чем функции, - именно поэтому их обычно и пропускают.

Производительность на согласованной нагрузке

Определите замер до того, как что-либо замеряете: какие операции, на каком объёме данных, при скольких одновременных пользователях, в какой момент рабочего дня. Результат по производительности без этих четырёх параметров - это число без смысла.

Откажитесь от универсальных требований ко времени отклика. «Каждая страница быстрее двух секунд» звучит строго и не решает ничего, потому что правильная цель вытекает из операции и процесса вокруг неё. В нашем примере два замера важнее всех остальных: оформление заказа в сезонный пик, когда портал держит трафик в несколько раз выше обычного, и отчёт, который отдел продаж строит каждое утро понедельника за двенадцать месяцев истории. Если эти два замера держатся на данных продуктивного объёма, системой можно пользоваться. Если их делали на пустой базе, они не значат ничего. Там, где у портала есть публичные страницы, те же времена отклика влияют и на сео продвижение сайтов в России, поэтому замеряйте и публичную часть.

Разграничение доступа и относящиеся к делу требования безопасности

Проверяйте те требования безопасности, о которых вы договорились, с приоритетом на межклиентский доступ и изоляцию данных разных арендаторов. В B2B-портале это отказ с самой высокой ценой для бизнеса: один клиент, увидевший договорные цены другого, - это конец коммерческих отношений. Прогоните проверку через интерфейс и через API, потому что именно API обычно пропускают. Интерфейс, который прячет кнопку, не останавливает запрос, который просит данные напрямую.

В качестве структурированного списка требований, из которого можно выбирать, практичным публичным ориентиром служит OWASP Application Security Verification Standard: на странице проекта стабильной версией указана 5.0.0. Используйте его, чтобы выбрать требования, уместные для вашего продукта и его рисков, и указывайте версию каждый раз, когда ссылаетесь на отдельное требование в документах приёма-передачи.

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

Сопровождаемость, поддерживаемые зависимости и стоимость эксплуатации

Четыре вещи, на которые стоит посмотреть, и у каждой есть бизнес-последствие, которое формулируется одним предложением.

• Зависимости. Получают ли фреймворки и библиотеки обновления и нет ли среди них уже снятых с поддержки? Неподдерживаемая зависимость превращается в вынужденную миграцию по чужому графику.
• Технические ограничения. Какие предсказуемые изменения текущая архитектура делает дорогими? Второй склад, вторая валюта, второе юридическое лицо. Задайте этот вопрос, пока подрядчик ещё доступен и может на него ответить.
• Автоматические проверки. Покрыта ли автотестами критичная для бизнеса логика - конкретно правила ценообразования, маршрут согласования и обмен с ERP? Покрытие тривиального кода здесь ни при чём.
• Допущения по стоимости. Какой объём данных, какой трафик и какой срок хранения заложены в оценку инфраструктуры и что произойдёт со счётом, если реальные цифры окажутся вдвое больше?

Мы не согласны с распространённой практикой оценивать сопровождаемость по комментариям в коде и по его оформлению. Единообразное форматирование легко получить, и о стоимости изменений оно не говорит почти ничего. Судите о сопровождаемости по тому, может ли изменение в критичной логике быть внесено и безопасно проверено человеком, который не писал исходный код.

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

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

Проверка того, что систему в принципе можно принять

Передача системы и готовность к запуску - это разные проверки с разными подтверждениями, и их слияние приводит компании к системе, которой они владеют на бумаге и не могут коснуться на практике. Передача доказывает, что ваша сторона получила средства и знания для работы с системой. Готовность к запуску, о которой следующий раздел, доказывает, что компания может эксплуатировать систему и пережить её сбои.

Репозитории, сервисные учётные записи и технические материалы

Проверяйте фактический доступ, а не список обещанного доступа. Разница в том, что человек с вашей стороны заходит в систему, пока кто-то смотрит на экран.

• Код и конвейеры. Репозиторий с полной историей коммитов, а не с одним схлопнутым импортом. Конфигурация CI/CD, сборочные конвейеры, реестры артефактов.
• Инфраструктура и учётные записи. Облачные и хостинговые аккаунты, домены, TLS-сертификаты, ключи сторонних API, сервисные учётные записи и их секреты.
• Принадлежность. Аккаунты зарегистрированы на адреса и платёжные реквизиты вашей компании, а не на личную почту разработчика. Это пункт, который чаще всего обнаруживают спустя месяцы и в худший из возможных моментов.
• Материалы. Реестр зависимостей, инструкции по сборке и выпуску, справочник конфигурации с объяснением каждой настройки и обзор архитектуры, достаточно подробный, чтобы спланировать изменение.

Чек-лист передачи, который перечисляет документы, но не проверяет доступ, описывает намерение. Зайдите под своей учётной записью в каждый пункт до того, как закончится участие подрядчика.

Можно ли развернуть систему без незадокументированных знаний разработчика

Есть одна проверка, которая закрывает этот вопрос, и занимает она полдня. Инженер принимающей стороны разворачивает согласованную сборку в отдельном окружении, пользуясь только переданными инструкциями. Без звонков, без демонстрации экрана, без «спроси у Андрея, где лежит конфиг».

Записывайте каждую точку, где ему пришлось обратиться к автору. Каждая такая точка - задокументированный пробел с ответственным и сроком, и каждая из них иначе всплыла бы во время вашего первого инцидента в промышленной эксплуатации. Передача завершена тогда, когда переехали знания, а не когда количество документов выглядит убедительно.

«Я бы завершал любую передачу репетицией развёртывания: сотрудник принимающей команды разворачивает согласованную версию в отдельном окружении по предоставленным инструкциям. Если ему нужно спросить у автора, где найти конфигурацию или какой шаг выполняется вручную, этот пробел должен быть закрыт до того, как передача будет считаться завершённой. Такая проверка показывает, насколько хорошо передались эксплуатационные знания, но она не доказывает качество архитектуры в целом».

Дмитрий Черчел

Архитектор

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

Подготовка компании к запуску и к тому, что пойдёт не так

Проверка перед запуском разбирает зависимости, запас мощности и сценарии отказов до того, как система понесёт на себе реальный бизнес. Практика подробно описана в главе Google SRE о надёжных запусках продуктов в большом масштабе, и сам принцип аккуратно масштабируется вниз, даже если инфраструктура - нет. Средняя оптовая компания не переносит к себе операционную модель Google. Она заимствует один вопрос: от чего эта система зависит, что происходит при отказе каждой зависимости и кто об этом узнаёт.

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

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

• Ответственность за поддержку. Названный ответственный за входящие обращения, работающий канал приёма, к которому у пользователей реально есть доступ, и согласованное ожидание по времени реакции в рабочие часы. «Напишите подрядчику на почту» перестаёт быть каналом приёма, как только проект закрыт.
• Мониторинг, который доходит до человека. Решите, о каких отказах и кого уведомлять. Конкретный случай, под который нужно проектировать: обмен с ERP перестал работать в 09:00, и кто-то узнаёт об этом раньше, чем в 11:00 позвонит первый клиент. Оповещение, падающее в почтовый ящик, который никто не читает, равносильно отсутствию оповещения.
• Подготовка пользователей. Инструкции на языке, на котором люди работают, короткая сессия для команды владельца процесса по сценариям, которые они будут выполнять ежедневно, и известный контакт на первую неделю. Операционная готовность включает людей, и это самая дешёвая её часть.

Отрепетируйте восстановление и запишите, чего откат не вернёт

Резервная копия, которую ни разу не восстанавливали, - это допущение, а не мера контроля. Отрепетируйте восстановление в отдельное окружение, засеките, сколько оно занимает, и проверьте, что восстановленные данные действительно пригодны к работе. Полученное число и есть то, на чём в реальности держится ваш план непрерывности бизнеса.

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

На выходе - два коротких документа: план запуска и план на случай сбоя. В каждом названы ответственные, точка принятия решения и предельное время, к которому решение должно быть принято. План на случай сбоя, написанный во время сбоя, написан плохо.

Как превратить результаты проверок в решение: принять или дорабатывать

Решение - это не процент пройденных тестов. Это самая цитируемая метрика приёма и одна из наименее информативных, потому что она взвешивает съехавшую подпись на экране настроек так же, как заказ, пропавший между двумя системами. «Пройдено 94 процента» может описывать и здоровую поставку, и непригодную.

Ранжируйте дефекты по ущербу для бизнеса, а не по количеству тикетов

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

• Блокирующий. Заказ, принятый на портале, не доходит до ERP, и никто об этом не уведомлён. Бизнес теряет выручку и доверие и узнаёт об этом от клиента. Обходного пути, который масштабируется, нет.
• Серьёзный. Клиент может увидеть договорные цены другого клиента через API. Редко встречается при обычной работе, тяжёл по последствиям, и его нельзя нейтрализовать просьбой к пользователям быть внимательнее.
• Незначительный. Съехавшая подпись на внутреннем экране настроек, которым пользуются дважды в месяц. Реальный дефект, стоит исправления и не является причиной что-либо откладывать.

Одно правило заслуживает прямой формулировки, потому что его нарушают постоянно: непроверенная область - это не пройденная область. Если процесс возвратов никто не проверял, в акте приёма-передачи так и написано: процесс возвратов не проверялся, ответственный такой-то, срок такой-то. А не «система прошла проверку».

Подтвердите исправления и перепроверьте затронутые процессы

Слово «исправлено» от разработчика - это утверждение. Подтверждающее тестирование превращает его в доказательство: перезапустите исходную упавшую проверку на новой сборке, в исходных условиях, и запишите результат. В идеале подтверждает тот же человек, который нашёл дефект, и по той же карточке сценария.

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

Всегда записывайте, на какой сборке выполнялось подтверждение. Подтверждение без идентификатора сборки ни к чему не привязано и не может быть использовано в решении двумя неделями позже.

Фиксируйте статус приёма отдельно от разрешения на запуск

Используйте три технических статуса и ничего более мягкого: готово, готово с зафиксированными ограничениями, не готово. Реальное содержание несёт средний, поэтому по каждому открытому вопросу записывайте пять полей: влияние, ответственный, срок, обходной путь и условие, при котором его перепроверят.

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

Проверенная сборка вполне законно может подождать. Раздельные записи - это именно то, что превращает ожидание в решение с ответственным, а не в задержку, которую никто не хочет объяснять.

Что пересмотреть после первого полного бизнес-цикла

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

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

Сравните реальную эксплуатацию с допущениями, на которых принимали

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

• Какие отказы действительно произошли, как часто и как их обнаружили? Обнаружение по жалобе клиента указывает на пробел в мониторинге, а не только на дефект.
• Какую нагрузку система реально несла по сравнению с той, которую тестировали?
• Сколько инфраструктура стоила на самом деле по сравнению с оценкой и какое допущение оказалось неверным?
• Где пользователи обходят систему вручную?

Последний пункт - самый ценный сигнал во всём обзоре. Таблица, которую кто-то параллельно ведёт, статус, который уточняют по телефону, бланк заказа, который перебивают руками в ERP: за каждым из этих случаев обычно стоит незаписанное правило процесса - ровно того сорта, о котором говорилось в первом мнении эксперта. Найдите правило, запишите его и решите, относится оно к стабилизации или к следующему этапу.

Закройте оставшиеся дефекты и отделите действительно новые потребности

Составьте два списка и держите их порознь по той же причине, что и раньше. Пункты стабилизации относятся к сданному объёму и к текущему договору. Новые бизнес-потребности относятся к следующему этапу со своей оценкой и своим решением. Смешение делает подрядчика оборонительным по отношению к реальным дефектам, а ваш бэклог - непланируемым.

Тщательный приём не гарантирует, что ничего не придётся переделывать. Системы меняются, потому что меняется бизнес. Что приём действительно делает - сокращает число сюрпризов, за которые вы платите дважды, и переводит оставшиеся в список, у которого есть владелец.

Когда привлекать независимого технического аудитора

У большинства средних компаний нет своего специалиста, способного оценить поставку, которую он не делал. Это нормальная ситуация, а не управленческий провал, и привлечение третьей стороны - разумный на неё ответ.

Четыре основания оправдывают независимый аудит достаточно ясно, чтобы защитить его стоимость.

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

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

Следите за характерным провалом. Аудит, который читается как список стилистических претензий к коду, не говорит вам ничего о готовности и портит отношения с подрядчиком без всякой пользы. Спросите любого кандидата в аудиторы, как он будет связывать каждую находку с бизнес-последствием, до того как заключите с ним договор.

Webdelo работает со средними B2B-компаниями в США и Германии: согласование требований, QA и техническая оценка сданных систем. Если вы подходите к приёму конкретного проекта, мы готовы обсудить критерии, важные для ваших критичных бизнес-процессов, и реалистичный объём проверки, отталкиваясь от материалов, которые у вас уже есть.

Частые вопросы

Как организовать приём при поэтапной сдаче?

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

Как недоступные смежные системы влияют на объём заключения?

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

От чего зависит длительность приёмочного тестирования ПО?

Срок задают четыре фактора: количество критичных для бизнеса процессов в объёме проверки, доступность людей и окружений, нужных для их проверки, качество исходных требований и то, сколько циклов «исправление - перепроверка» в итоге потребует поставка. Последний фактор наименее предсказуем и обычно доминирует, потому что каждый цикл добавляет исправление, подтверждение и регрессионную проверку. Универсального срока не существует, и любая цифра, названная без знания вашего объёма и ваших требований, - это догадка, поданная как график. Оценивайте так же, как любую другую работу: перечислив проверки, участников и циклы, которых вы реалистично ожидаете.