Медицинские проекты занимают особое место в области разработки программного обеспечения, требуя высокого уровня качества и строгого соответствия медицинским стандартам. Важность тестовой документации в этом контексте трудно переоценить, так как именно она служит ключевым инструментом для обеспечения надежности и безопасности медицинских систем.
Первый шаг в обеспечении качества в медицинских проектах — это соблюдение строгих медицинских стандартов и регуляций. Однако, человеческий фактор присутствует не только при мануальном прохождении тестовых сценариев, валидации результатов автотестов, но и при подготовке тестовой документации, поэтому рецензирование тестовой документации играет здесь ключевую роль.
Давайте сначала разберемся, что такое рецензирование, или, как его чаще называют, ревью, и зачем оно нужно.
Рецензирование тестовой документации — это процесс оценки и проверки таких артефактов тестирования, как планы тестирования, тест кейсы и другие связанные документы.
Цель рецензирования тестовой документации состоит в том, чтобы обеспечить ее качество, полноту, соответствие требованиям и эффективность в контексте тестирования программного обеспечения.
Этот процесс включает в себя анализ документации с точки зрения различных аспектов, таких как правильность, полнота, читаемость, соответствие стандартам, корректность данных и т. д. Рецензирование обычно проводится командой, включающей в себя тестировщиков и других заинтересованных участников проекта: разработчиков, лидов тестирования, заказчиков, менеджеров проекта.
Давайте по полочкам разложим, каким образом процесс рецензирования происходит на медицинских проектах, в частности, на моём, который занимается разработкой ПО для мониторов, отслеживающих состояние здоровья пациента. Для наглядности я хотел бы предложить рассмотреть пример с тест-кейсом.
Всё начинается с планирования, которое производится не для конкретного артефакта, а для всех артефактов одного типа и фиксируется в базе знаний, доступной для всех участников проекта. Оно включает в себя:
определение объекта рецензирования (в нашем случае - тест-кейс),
определение критериев качества артефакта: четкость входных данных, заполненность обязательных полей тест-кейса, полнота покрытия требования, использование определенных методов тестирования для конкретных типов требований.
определение процедуры рецензирования: в какой среде проходит, время на рецензирование одного артефакта, критерий завершения для конкретного артефакта и.т.д.
выбор сотрудников, принимающих участие в рецензировании.
Остановимся на пунктах, требующих более подробного разъяснения.
Для полноты покрытия требования необходимо полностью разобрать его контекст, предполагаемую функциональность и связанные аспекты, далее определить возможные сценарии использования и выделить из них ту часть, что не покрывается другими требованиями. Рецензент должен убедиться, что тест-кейс содержит исчерпывающие проверки конкретного требования, но не более. Подробнее с полнотой покрытия и созданием тест-кейсов в целом можно ознакомиться в данной статье «Записки тестировщика: как написать хороший сценарный тест на основе требований».
Что касается методов тестирования, на нашем проекте всем требованиям присвоена категория, для каждой из которых определены алгоритм и метод тестирования. Например, для отображаемого на мониторе параметра проверяются пограничные значения, а для опций настройки – полный перебор. Хочу заметить, что это – особенность проекта и большая редкость, обычно метод тестирования определяется автором тест-кейса.
Средой для выполнения рецензирования тестовой документации чаще всего является система для выполнения тестов и протоколирования, где можно создавать ревью, составлять отчеты и подписывать их электронной подписью. Ранее использовались бумажные документы, которые вручную подписывались участниками рецензирования.
К участникам рецензирования предъявляются следующие требования:
Знание таких стандартов, как ISO 13485 (устанавливает требования к системе управления качеством в области медицинских изделий), IEC 62304 (устанавливает требования к жизненному циклу ПО в медицинских устройствах), ISO 9001(устанавливает требования к системе менеджмента качества в организации) и других нормативных актов, регулирующих разработку и эксплуатацию медицинских устройств (зависит от тестируемого продукта/компоненты)
Понимание технических аспектов медицинского программного обеспечения, включая архитектуру, базы данных, алгоритмы
Знание теории тестирования и опыт в области тестирования программного обеспечения
Умение анализировать и понимать спецификации, требования и документацию, связанную с медицинским программным обеспечением
Способность эффективно общаться с разработчиками, тестировщиками и другими участниками процесса разработки для выявления проблем и их обсуждения.
Может возникнуть вопрос: “Почему в списке отсутствует стандарт ISO/IEC 20246, описывающий процесс рецензирования?” Для ревью документации необходимо и достаточно знание стандарта ISO 13485, который полностью раскрывает данный процесс для документации на медицинских проектах.
На нашем проекте у участников рецензирования 3 роли:
Автор – создатель артефакта. Должен принимать участие в обсуждении спорных вопросов, вносить правки в рецензируемую документацию.
Рецензент – выявляет неточности и дефекты в рассматриваемой документации, несет ответственность за документацию после рецензирования.
Руководитель-модератор – ответственное лицо за рецензирование, обеспечивает посредничество между различными точками зрения, разрешает спорные вопросы, в которых его слово – последнее.
Кроме перечисленных, существуют еще следующие роли:
Менеджер принимает решение о проведении рецензирования, отвечает за планирование, определяет бюджет, принимает управленческие решения в случае неадекватных результатов.
Секретарь ведет документацию
Руководитель рецензирования решает, кто будет принимать участие, организует время и место, несет ответственность за процесс
Модератор обеспечивает эффективное поведение рецензирования и посредничество между разными точками зрения
После планирования идёт инициирование рецензирования.
Как только артефакт создан и проверен автором, назначается один из рецензентов. В нашем случае данный процесс происходит следующим образом: в среде для управления тестовой документацией в теле тест-кейса имеется вкладка рецензирования. Автор добавляет в данную вкладку двух пользователей: себя и рецензента, чем подтверждает, что артефакт готов для проверки. Весь процесс прозрачен. Каждый инженер, имеющий доступ к артефакту, может прослеживать всю его историю: создание, изменения, рецензии.
Далее происходит непосредственно проверка артефакта в соответствии с определенными на этапе планирования критериями.
В нашем случае рецензент сначала проверяет требование, привязанное к тест-кейсу: его статус готовности, отсутствие возможности трактовать его неверно, ссылки на медицинские стандарты, ссылки на продуктовые/медицинские риски, графические спецификации и.т.д. Затем проверяет заполненность всех обязательных полей, их содержимое, понятность формулировок, последовательность тест-скрипта, полноту покрытия и использование корректного метода тестирования.
Если замечания отсутствуют, то рецензент проставляет веский статус “ОК” и закрывает рецензирование.
В подавляющем большинстве случаев в ходе проверки возникают вопросы из-за трактовки, оформления, упоминания стандартов и.т.д. Тогда тест-кейс отклоняется, и составляется отчет с вопросами и замечаниями, который публикуется во вкладке рецензирования в теле тест-кейса.
Если автор согласен с замечаниями, пропускаем следующий абзац.
После успешной партии в пинг-понг между автором и рецензентом в ревью добавляется модератор, затем организовывается митинг по решению спорных ситуаций, где модератор выслушивает обе стороны и принимает решение относительно правок. Результат фиксируется в ревью. Часто бывает так, что модератор предлагает свой вариант, который в итоге становится эталонным для будущих аналогичных тест-кейсов.
Далее автор исправляет тест-кейс в соответствии с комментарием рецензента/модератора и отправляет на повторное рецензирование.
Если все правки внесены корректно, и артефакту не требуется доработка, рецензент закрывает ревью со статусом “ОК”, и на этом процесс завершается. Тест-кейс можно использовать для тестирования продукта.
Для иной тестовой документации алгоритм рецензирования не отличается, разница заключается исключительно в критериях качества объекта.
Зачем нужна эта, казалось бы, трудозатратная и странная процедура для тестовой документации, и нужна ли?
Что касается медицинских проектов, формальное рецензирование необходимо согласно стандарту ISO 13485 (устанавливает требования к системе управления качеством в области медицинских изделий). Оно помогает минимизировать человеческие ошибки, которые могут сказаться на безопасности пациентов. Кроме того, исполнитель изначально принимает ряд строгих стандартов, им должно соответствовать предоставляемое заказчику ПО. При обнаружении несоответствия постфактум исполнитель понесёт не только репутационные, но и юридические издержки.
Выше описан формальный тип рецензирования, который большинству немедицинских проектов действительно не нужен, так как нет обязательств работать по медицинским стандартам, да и мотивации у заказчика оплачивать данный процесс тоже нет. Однако, существуют гибкие неформальные типы рецензирования, их можно настроить под проект, основываясь на целях, доступных ресурсах, сложности продукта, нормативных и юридических требованиях. При корректном выборе типа и метода рецензирования можно добиться не только повышения качества, минимизации рисков и дополнительных затрат на исправление ошибок, но и вовлечь команду в более углубленное изучение разрабатываемого продукта, что повышает ее экспертизу.
Если вы хотите внедрить рецензирование или глубже изучить тему, можете обратиться к стандарту ISO/IEC 20246.
Спасибо, что дочитали статью до конца, буду рад ответить на ваши вопросы в комментариях.