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

Для приложений, которые оказывают или могут оказать прямое влияние на жизнь и здоровье пациентов, обязателен формальный процесс приёмочного тестирования. Результаты приёмочного тестирования вместе с остальным пакетом документации предоставляются для аудита в FDA (Food and Drug Administration, США). FDA выдаёт разрешение на использование приложения в качестве инструмента контроля и проведения клинических исследований. В общей сложности в моей команде разработано, протестировано и отправлено в продакшен более тридцати приложений. В данной статье я коротко расскажу о приёмочном тестировании и развитии инструментов в одной отдельно взятой маленькой группе.

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

FDA

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

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

Что такое FDA для нас и как это влияет на процесс разработки и релизный цикл?

Управление по санитарному надзору за качеством пищевых продуктов и медикаментов (англ. Food and Drug Administration, FDA, USFDA, букв. “Управление еды и лекарств”) — агентство Министерства здравоохранения и социальных служб США, один из федеральных исполнительных департаментов. Управление занимается контролем качества пищевых продуктов, лекарственных препаратов, косметических средств, табачных изделий и некоторых других категорий товаров, а также осуществляет контроль за соблюдением законодательства и стандартов в этой области. Википедия

FDA практически не касается собственно процесса разработки, мы работаем по обычному SCRUM (вернее, не совсем SCRUM — говорят, сейчас модно называть такое «модифицированный SCRUM») с неспринтовым релизным циклом. Мы не уходим на прод в конце спринта (и даже в конце трёх спринтов, и даже десяти, если таймлайн предполагает 15 спринтов), то есть с точки зрения доставки конечному пользователю у нас нечто водопадообразное.

Тестирование в нашем случае делится на две независимые части, с разным таймлайном, разными эстимейтами и разными процессами. Первая часть — это обычное тестирование во время разработки (in-dev testing), где тестировщик является неотъемлемой частью команды разработки и финиширует спринты вместе с разработкой. Вторая часть — собственно приёмочное тестирование и сопровождение (когда это требуется). Процесс построен по V&V методологии: на входе пользовательские и функциональные требования, на выходе тесты и пакет сопроводительной документации.

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

V&V

Что же это за зверь такой, V&V, и как это отражается на процессе приёмки.

“In software project management, software testing, and software engineering, verification and validation (V&V) is the process of checking that a software system meets specifications and that it fulfills its intended purpose. It may also be referred to a software quality control. It is normally the responsibility of software testers as part of the software development lifecycle. In simple terms, software verification is: «Assuming we should build X, does our software achieve its goals without any bugs or gaps?» On the other hand, software validation is: «Was X what we should have built? Does X meet the high level requirements?» Википедия

Вольный перевод:

«В управлении проектами, тестировании и разработке программного обеспечения, верификация и валидация (V&V) — это процесс проверки того, что разработанное программное обеспечение соответствует спецификациям и выполняет заложенную функцию. Также это может быть отнесено к контролю качества в целом. В обычном случае в рамках жизненного цикла разработки программного обеспечения за верификацию и валидацию отвечают инженеры по тестированию. Простыми словами верификацию программного обеспечения можно охарактеризовать как: «Предположим, мы должны разработать систему X. Достигли ли мы цели без каких бы то ни было багов и допущений?» С другой стороны, валидация программного обеспечения — это «Разработанная система X — это действительно то, что мы хотели получить? Удовлетворяет ли система X требованиям высокого уровня?»

Другими словами:
Верификация: Мы делаем продукт правильно?
Валидация: Мы делаем правильный продукт?

Это означает, что мы должны с необходимой и достаточной полнотой покрыть тестами функциональную и пользовательскую спецификации. Для нас первая V превращается в приёмочное тестирование (SIT), вторая — в сопровождение (UAT), где:

• SIT — System Integration Testing
• UAT — User Acceptance Testing

Визуализация покрытия требований ведётся в Traceability Matrix (обычная таблица в Excel или Word, дальше остановлюсь подробнее), которая позволяет осуществлять трассировку от требования к тесту и обратно. В случае использования электронного документооборота матрица строится автоматически, тесты линкуются к требованиям, которые хранятся вместе с тестами (вместе = HP ALM, хранятся естественно не кучей). В случае, если требование не покрыто и не будет покрыто, объясняем почему.

Когда покрытие требования не обязательно?

Например, CFR Part 11 (правила, установленные FDA в отношении электронных записей и электронных подписей) содержит огромное количество требований, которые уже покрыты Microsoft и, если мы используем Windows AD для аутентификации, нам не надо покрывать их заново.

В конечном счёте суть приёмочного тестирования сводится к тестированию продукта на соответствие требованиям и требований на соответствие продукту.

Роли

В процессе принимает участие достаточно большое количество ролей, которые в том или ином виде знакомы каждому, кто занимается разработкой ПО: Developer (Junior, Middle, Senior, Lead), Unit Tester, SIT Tester, Technical Product Owner, Business Product Owner, Scrum Master, Project Manager, Business Analyst, Technical Lead, SIT Test Lead, UAT Test Lead, Global QC, Support, Deployment Engineer и другие.

Специфичная для нас роль — Global QC. Это человек на стороне заказчика, который отвечает за соблюдение и выполнение требований, предъявляемых к процессу — Software Lifecycle и всяческие Standard Operational Procedures (SOP) на стороне заказчика — в ходе разработки и приёмки, и в дальнейшем предоставляет пакет документов внешнему аудиту.

Приёмочная документация

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

Validation Plan и Team Roster — за написание и утверждение документа отвечает PM. Документ обычно включает в себя описание системы, список артефактов, которые будут созданы в ходе разработки и тестирования, стратегию валидации, список ролей с указанием ответственных.

Test Strategy — документ, который не относится к конкретному приложению, но создаётся для отдельной ветки продуктов или для отдельной ветки тестирования. Например, как и почему мы определяем, что будем автоматизировать, а что нет; какими технологиями; как будем оформлять ручное тестирование (чек-листы или тест-скрипты, или то и другое вместе, или что-то совсем иное); как решаем, будем гонять нагрузку или нет; и так далее, и тому подобное.

Test Plan — общий для команд UAT и SIT, включает в себя краткое описание объекта тестирования, возможные ограничения, требования к окружениям, сроки, наборы тестов и так далее.

Test Suite — набор тестов или чек-листов, сформированный по функциональной области, типу тестирования или любому другому признаку.

Traceability Matrix — матрица трассирования от требования до теста. Трассирование как подтверждение покрытия — важная часть процесса. По идентификатору любого требования можно найти конкретный шаг, в котором подтверждается выполнение этого требования и предоставить проверяющему evidence (скриншот, файл и т. д.) для конкретной версии приложения (или для каждой из версий, в которых это требование формально покрывалось). Поэтому линковать, линковать и ещё раз линковать тесты к требованиям (таскам), на основании которых вы получаете ожидаемый результат, даже если от вас этого не требуют. Если невозможно в силу использования разных не интегрирующихся между собой тулов, всегда можно оставлять комментарии в тасках/тестах, либо сделать матрицу (упоминаемый выше Excel), либо запилить примитивную базу из трёх таблиц.

PDS — Product Design Specification, документ разрабатывается техлидом или архитектором проекта, по сути комбинация высокоуровневой и низкоуровневой архитектуры приложения (HLA и LLA).

FRS & URS или BRS — функциональные и пользовательские требования, обычно в виде двух отдельных документов, но иногда объединённые в Business Requirements Specification.

Defect Log — журнал дефектов, выявленных в ходе тестирования (дефекты приложения и требований).

Minor Issues Log — журнал минорных ошибок в тестах (опечатки, пропущенные/лишние требования и так далее — любые ошибки, которые принципиально не меняют смысл теста).

Test Summary Report — отчёт по результатам тестирования. TSR является закрывающим документом для тест плана и содержит в себе:

• Информацию о сборках, на которых проводилось тестирование (в том числе номера билдов и даты деплойментов), количестве циклов тестирования и результатах выполнения тестов.
• Описание нарушений, допущенных относительно тест плана и процедур тестирования (SOP), утверждённых к исполнению в компании.
• Список открытых дефектов с объяснением причин переноса на следующий релиз.
• Ссылку на журнал дефектов или сам журнал.
• Ссылку на журнал ошибок тестов или сам журнал.
• Рекомендацию к вынесению решения об установке в продакшен.

Deployment Plan — документ, за который отвечает поддержка и интеграция, составляется в ходе установок на SIT окружение и в дальнейшем используется для разворачивания версии на продакшене.

Validation Summary Report — закрывающий документ для плана валидации.

Утверждение документации

Любой процесс утверждения документации условно делится на 3 этапа:

• Подготовка документа.
• Ревью.
• Утверждение.

Рассмотрим на примере Test Suite.

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

Составные части тестового набора:

• Название проекта и приложения.
• Релизная версия.
• Название и уникальный идентификатор набора.
• Описание (что тестируем, какие виды тестирования применяем).
• Тесты.
• Список утверждающих.

В свою очередь, каждый тест включает в себя:

• Название и уникальный в рамках набора идентификатор.
• Описание.
• Предусловия.
• Постусловия.
• Трассирование (номера требований, покрытых в тесте).
• Особенности выполнения (например, инструкция по маскировке sensitive данных).
• Шаги (требуемые действия, ожидаемый и фактический результаты).
• Результат выполнения теста.
• Выполнивший.
• Ревьювер.

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

1. Написание
   Анализ требований. Определение и применение техник тест-дизайна для наиболее адекватного покрытия функциональности. Написание шагов.
2. Пробный проход/проходы на дев окружении
   На данном этапе оценивается, насколько приложение соответствует требованиям, и выгребается основная масса возможных багов, в том числе багов требований.
3. Ревью ответственного за проект (SIT Team Lead)
   Стилистическое и логическое ревью.
4. Пробный проход/проходы на SIT окружении
   На данном этапе отлавливаются ошибки, связанные с инсталляцией, окружением и конфигурацией окружения (по умолчанию считается, что SIT окружение в точности или практически полностью повторяет PROD). Успешное окончание этого этапа означает, что версия, которая находится на окружении, стабильна и может быть признана релиз кандидатом.
5. Ревью на стороне заказчика (Global QC)
   Global QC проверяет полноту покрытия требований и соответствие написанных тестов SOP, принятым в компании.
6. Утверждение (Global QC, Technical PO, Business PO).
7. Формальное выполнение теста на SIT окружении (релиз кандидат версия)
   После утверждения тестов на проход (п.6) и успешного окончания пробных проходов на SIT окружении (п.4) происходит формальное выполнение теста на SIT окружении с формальной фиксацией результата. Если баги, найденные на пробных проходах, не оформляются формально и просто заносятся в Jira аналогично тому, что происходит в процессе разработки, то под каждый баг, найденный на формальном проходе, создаётся отдельная дефект форма, которая включается в выходной пакет документации к продукту.
8. Ревью результатов прохода ответственным за проект (SIT Team Lead).
   Аналогично пункту 3, проверяется стилистика заполнения и проводится анализ результатов.
9. Ревью на стороне заказчика (Global QC)
   Global QC проверяет правильность и полноту заполнения результатов, возможные ошибки, наличие подтверждений (например скриншотов). Важный момент, потому что именно Global QC отвечает за предоставление пакета документов внешнему аудиту (со стороны FDA или заказчиков).

Работа с персональными данными

С учётом того, что исследования проводятся по double blind* методологии, это меньшая из наших проблем. Но данные врачей, названия компаний, номера протоколов исследований и т. д., и т. п. должны быть изменены. С формальной точки зрения, если мы не можем избавиться от sensitive данных, нам приходится их маскировать на скринах, но это довольно стандартная и понятная ситуация.

*double blind — двойной слепой метод. Пациенты случайным образом делятся на две группы, одна из которых получает исследуемый препарат, а вторая плацебо или препарат с доказанной эффективностью. При этом ни врач, ни пациент не знают, к какой группе отнесли пациента. Таким образом исключается предвзятость врача и эффект плацебо. В контексте работы с персональными данными это означает, что в большинстве случаев личность пациента невозможно идентифицировать на основании данных, которые хранятся в БД или доступны пользователю.

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

История, претендующая на забавность: «Глобус»

В одном из приложений для создания вау эффекта и не только нам очень нужно было сделать интерактивный глобус, который можно вращать мышкой, переключать день/ночь и так далее. На глобусе есть отметки по адресам, которые раскрашиваются в зависимости от значений и диапазонов, в которые эти значения попадают (color coding такой). После анонимизации базы на демо окружении, за два часа до демо, благодаря анонимизирующему скрипту, мы остались без zip-кодов со всеми вытекающими.



Мораль: не стоит трогать данные за два часа до демо.

История номер два: «Про анонимизацию»

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

История: в хранилище загрузили данные и анонимизировали их перед использованием в тестовых целях. Выяснилось, что данные загрузили не из всех необходимых источников. Потом догрузили недостающую часть. Связать вторую часть данных (ещё не анонимизированную) с уже анонимизированной первой частью не представлялось возможным. В результате старт работ на SIT окружении отложили на две недели, за которые deployment и support команды поправили данные.

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

Электронный vs бумажный документооборот на практике

Тот, кто работал с HP ALM, в цирке не смеётся.

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

Плюсы:

• Легко поддерживать актуальность последней версии.
• Меньше ручной работы.
• Все члены команды в любой момент времени имеют доступ к текущему состоянию того или иного теста.
• История изменений.
• История проходов.
• Можно отслеживать время прохождения теста.
• Проще планировать время на дальнейшие проходы.
• Надо постараться, чтобы использовать не ту версию теста для прохода.
• Электронная подпись.

Минусы (конкретно для HP ALM):

• Много времени тратится на форматирование тестов.
• Периодические проблемы с самим тулом.
• Отсутствие нормального spell checker-а.
• Неудобный интерфейс.
• Время, затрачиваемое на написание и ревью тестов, практически не отличается от тестов в Word.
• Стоимость.

История из практики, связанная с бумажным документооборотом и ручными подписями: «Кошмар перед релизом»

За один вечер я 450 раз написал «цвет точек на графике соответствует заявленному в требованиях, фамилия имя дата» и поставил подпись — просто потому, что мы распечатались на ч/б принтере, а цвет точек на графиках имел значение.



Мораль: выбор средств должен соответствовать целям.

История номер два: «Тяжесть — это хорошо, тяжесть — это надёжно»

Бумажный документооборот — это бумага (кто бы сомневался). За приёмку одного далеко не самого большого приложения может получиться в районе пяти килограммов.



Вывод, который напрашивается из историй выше (и многих нерассказанных): несмотря на перечисленные и не перечисленные недостатки электронного документооборота — если есть возможность выбирать, то однозначно выбирайте электронный, пусть даже HP ALM (уже не HP).

Автоматизация

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

Как и почему мы пришли к хотя бы частичной автоматизации?

Первой задачей было объяснить себе, что в некоторых случаях мы реально выиграем время. Да, вполне объяснимо: далеко не все верят в автоматизацию и зачастую её использование не оправдывает себя — потому что применяют не так, не там и не для того, но это тема для отдельного доклада, коих чуть меньше чем «автоматизация маст хэв!!!», но всё равно в количестве.

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

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

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

Список вопросов в нашем случае:

1. Возможно ли автоматизировать тестирование в данном конкретном случае?
2. Стабилен* ли компонент, тестирование которого предполагается автоматизировать?
3. Как часто мы должны выполнять написанные для компонента тесты?
4. Эта функциональность является критичной для бизнеса?**
5. Насколько сложно автоматизировать тестирование?

* Стабилен = компонент не менялся некоторое время и изменения компонента не запланированы на ближайшие релизы.
** Проставляется в зависимости от значения поля, добавленного к требованиям бизнес-аналитиком.


В общем виде процесс принятия решения выглядит следующим образом:

1. На вход поступают требования FRS.
   Составляется матрица принятия решений (Design Matrix), где каждая строка — требование из FRS. В качестве столбцов:
   
   • Описание требования
   • Вопросы 1-5
   • Решение команды
   • Приблизительная оценка по времени написания
   • Утверждение
   • Комментарии
2. Команда проставляет ответы на вопросы и на основании полученных данных определяет, стоит ли автоматизировать тестирование конкретного требования/группы требований полностью или частично.
3. Заказчик проводит ревью предложенного решения и утверждает конечный вариант.
4. После утверждения Design Matrix пишутся автотесты. Сценарии для автотестов описываются на Gherkin и проходят ревью, аналогичное ревью для ручных тестов (Global QC, Technical Owner, Business Owner). Step definitions, page objects и так далее ревьювятся на пул реквестах, в том числе техническим специалистом со стороны заказчика. Результаты выполнения автотестов и сгенерированные репорты проходят постревью на стороне Global QC.

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

Заключение

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