Особенности тестирование safety critical систем. Part 1

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

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

Существует несколько характерных признаков Safety Critical систем, непосредственно влияющих на процесс тестирования.  Давайте поговорим о них

·         Соответствие стандартам отрасли

·         Огромное количество требований

·         Формализация и отчетность

·         Вялая текучесть процесса разработки и тестирования

И так давайте взглянем на эти признаки под большим приближением.

Соответствие стандартам отрасли

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

Огромное количество требований

Повторюсь, когда от действий и логики системы зависит здоровье и жизнь человека, то лучше иметь много требований. Все требования должны быть покрыты тестами, и, глубина покрытия регулируется стандартами отрасли, требованиями заказчика ну и конечно бюджетом. Хорошей стратегией работы отдела тестирования в случае, когда требований очень много (для меня очень много начинается от 5000, предположу, что в большинстве проектов количество требований не пересекает отметку в 1000) считается написание Тест Дизайнов перед написанием тест кейсов.

Формализация и отчетность

Любая активность отслеживается контроль за изменениями и конфигурационный менеджмент это слова, которые должны неотступно следовать за safety critical проектами. В тестировании вся документация обязательно должна быть формализирована так как она практически всегда подпадает под пристальный взгляд внешних  аудиторов. Внешний вид тестовой документации разнится в зависимости от требований стандартов. В своей профессиональной карьере я встречал как тест кейсы размером в несколько сотен шагов (медицинская сфера), так и обычные тест кейсы привычные для взгляда тест инженерам СНГ, размерами до 30 шагов и имеющими как один инпут так и один аутпут.

 Вялая текучесть процесса разработки и тестирования

В большинстве своем safety critical системы разрабатываются следуя Waterfall или Итерационным моделям разработки с длинными итерациями, конечно, везде есть свои исключения (например, я встречал проекты работающие в медицинской сфере работающие по SCRUMу). Такие жизненные циклы разработки не предусматривают быстрой реакции на изменения, да и не претендуют на выпуск продукта через 3 месяца после начала проекта. Можно выделить особенность, что тестирование в начальных стадиях проекта проходить на основе прототипов и симуляторов. А так же в начальных стадиях проекта очень много вкладывается в статическое тестирование.

To be continued…