Home

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

Часть 1
Часть 2
Часть 3

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

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

Вот что в нем на самом деле сказано:

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

Из документа "Основные принципы валидации ПО: финальное руководство для отрасли и персонала FDA", 2002 год.

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

Проблемы в этом документе тоже имеются. Я надеюсь затронуть эту тему в одной из следующих статей.

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

"Тест-планы и тест-кейсы должны создаваться как можно раньше в ходе процесса разработки".

Или вот еще парочка:

"Программный продукт должен испытываться тест-кейсами, основанными на его внутренней структуре, и тест-кейсами, основанными на внешней спецификации".

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

С другой стороны, если заменить "тест-кейсы" на "тесты" или "тестирование", то это отличный совет. Испытывать продукт при помощи тестов и тестирования на основании внутренней и внешней перспективы – это очень хорошая идея.

FDA не определяет, что такое "тест-кейс", в своих нормативах. Это определение есть в Словаре терминологии разработки компьютерных программ (8/95).

Тест-кейс. (IEEE) Документация, определяющая входные данные, ожидаемые результаты и набор условий выполнения для элемента теста. Синоним: спецификация тест-кейса. См. также: тест-процедура.

Ладно, давайте посмотрим на тест-процедуру.

Тест-процедура. (NIST) Формальный документ, разработанный на основании тест-плана и дающий подробные инструкции по настройке, действиям и оценке результатов каждого теста. См. также: тест-кейс.

Нет, все же это ужасный совет.

(Относится ли "8/95" к августу 1995 года? Да. Все источники Словаря терминологии разработки компьютерных программ (8/95) датированы не позднее 1994 года. Для лучшего понимания – еще не вышла Windows 95, не появился Google, смартфоны и планшеты, не создан Манифест Agile, не разработаны принципы контекстно-зависимого тестирования…)

К счастью, в секции 2 Основных принципов валидации ПО, еще до руководств по тестированию, находится Принцип наименее затратного подхода:

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

Этот "Тщательный анализ" произошел где-то до 2002 года, когда был опубликован документ. В тест-сообществе тех лет все, что не было перегруженным процедурами тест-кейсом, рассматривалось с большим подозрением в статьях и докладах на конференциях. Благодаря работе, возглавленной Кемом Кейнером, Джеймсом Бахом и другими выдающимися лидерами тестирования, мир стал дружелюбнее к исследовательскому подходу к тестированию. Также, как отмечалось в предыдущих частях статьи, FDA тоже признает значимость и важность исследовательской работы.

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

Несколько лет назад Джеймс Бах консультировал компанию, производящую медицинские приборы. Они наняли его для анализа, отчета и вклада в тестирование, проводимое для устройства класса III (я тоже кое-что делал для этой фирмы).

Устройство состояло из пульта управления, которым пользовался техник. Пульт соединялся с передатчиком, поставляющим целительную энергию в тело пациента (мы заменили ряд специфичных терминов, чтобы обеспечить конфиденциальность и кратко описать суть приборов). Недостаточная Целительная Энергия – это просто Энергия. Избыточная Целительная Энергия, или достаточное ее количество слишком длительное время, превращаются во Вредящую Энергию или Убивающую Энергию.

Когда Джеймс приступил к работе, он изучил доступную тестировщикам документацию и нашел больше сотни примерно таких страниц:

9.8.1 Для проверки точности уровня мощности

9.8.1.1 Соедините компоненты согласно Общему руководству по настройке.

9.8.1.2. Включите и подсоедините Монитор контроля мощности (вместо электродов).

9.8.1.3. Включите Передатчик.

9.8.1.4. Включите Пульт Управления.

9.8.1.5. Установите стандартные настройки температуры и мощности для передачи энергии.

9.8.1.6. Установите тестовую нагрузку зажима на номинальную величину.

9.8.1.7. Выберите номинальную продолжительность и номинальную настройку мощности.

9.8.1.8. Нажмите "Старт".

9.8.1.9. Убедитесь, что передатчик сообщает о значении уровня мощности +/- 10% на дисплее.

Хорошее ли это формальное тестирование?

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

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

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

"3.1. Общий протокол тестирования

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

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

Затем он описал квалификацию, необходимую тестировщикам для работы над продуктом:

"3.2. Требования к тестировщикам

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

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

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

"3.2.2. Поля и экраны

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

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

3.2.2.3. Установив системные настройки на значения по умолчанию, меняйте содержание любого поля, которое разрешено к редактированию пользователем, в пределах разрешенного интервала для этого поля (например, используйте рукоятку, чтобы изменять продолжительность сессии от 1 до 300 секунд). Визуально убедитесь в появлении соответствующих значений и том, что все происходящее выглядит нормальным и приемлемым.

3.2.2.4. Повторите пункт 3.2.2.3, изменив системные значения на максимально возможные.

3.2.2.5. Выберите как минимум одно поле и используйте экранную клавиатуру, рукоятку, и внешнюю клавиатуру для его редактирования.

3.2.2.6. Просканируйте логи Пульта управления и Монитора контроля мощности в поисках любых ошибок или аномалий".

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

3.5.2. Измерение точности мощности для однократной лечебной сессии.

3.5.2.3. Извлеките из лога Монитора контроля мощности данные для замеряемого электрода. Эти данные должны охватывать всю сессию мощности, включая восстановление, а также стабильный период мощности с как минимум 50 измерениями (то есть с замерами как минимум пять раз в секунду в течение десяти секунд стабильного периода).

3.5.2.4. Извлеките из лога Пульта управления соответствующую информацию за стабильный период замеряемого электрода.

3.5.2.5. Рассчитайте отклонение, вычитая мощность замеряемого электрода из соответствующей записи Монитора контроля мощности (используйте интерполяцию для синхронизации временных отметок монитора и логов выработки).

3.5.2.6. Рассчитайте медиану выборки мощности Х и ее стандартной девиации (s).

3.5.2.7. Найдите доверительный 99% интервал и двухсторонний 99% толерантный интервал k для выборки (используйте таблицу 5 SOP-QAD-10 или уравнение ниже для больших выборок).

3.5.2.8. Уравнение для расчета интервала толерантности k:

где χ²_γ,N-1 – это критическая величина хи-квадрата распределения со степенями свободы N -1, который превышается с вероятностью γ, а Z²_(1-p)/2 – это критическая величина нормального распределения, которая превышается с вероятностью (1-p)/2 (см. Руководство по инженерной статистике NIST)".

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

Что мы можем из этого извлечь? Один из ключевых моментов, по моему мнению, в том, что при работе в контролируемом окружении очень важно изучать нормативы и руководства. Если вы этого не делаете, то рискуете оказаться под пяткой у тех, кто их тоже не читал, и работает на основании мифов и фольклора.

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

Возвращаясь к нашей тренинг-сессии – Фрида, играя роль менеджера, ответила "Но у нас нет времени тренировать тестировщиков делать подобные вещи. Нам нужно, чтобы они как можно быстрее вошли в курс дела".

"Что значит "вошли в курс дела", - спросил я.

Фрида, все еще вжившись в роль, ответила "Мы хотим, чтобы они начали стучать по клавишам как можно быстрее".

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

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

Если же рассматривать тестирование как исследование продукта, то тестировщики должны быть очень опытными исследователями. Прежде чем добраться до продукта и проекта, тестировщики изучают продукт, который они исследуют, и доменную область, в которой этот продукт обитает. Они ведут отличные лабораторные заметки и тщательно документируют свою работу – но не до такой степени, чтобы документация подменяла собой тестирование и поиск проблем. Тестировщики сконцентрированы на риске и обучены распознавать проблемы, с которыми они могут столкнуться (согласно CFR Title 21 Part 820.25 (b)(2)).

Если они недостаточно опытны, когда вы их наняли, то вы будете тренировать их и следить за их работой, пока они не получат нужный опыт. А если они неопытны и научить их нельзя… вы уверены, что хотите, чтобы они тестировали продукт, который может выдавать Убивающую Энергию?

Как еще можно направлять работу тестирования, неважно, в регулируемых условиях или нет? Разберемся в следующий раз.

Обсудить в форуме