Путаница с таблицей нефункциональных требований для конфиденциальности данных

У меня есть приведенная ниже таблица для нефункционального анализа требований, мне интересно, подходит ли приведенная ниже таблица для моего проекта. Предположим, что это очень важный сценарий качества, и его следует рассматривать как NFR (раздел нефункциональных требований). Интересно, как тестер проверит это, поскольку для успеха проекта должно быть обеспечено допущение. Должен ли я перенести это в QA или NFR?

NFR_01: Безопасность: конфиденциальность персональных данных пользователей

<сильный>1. Описание: Конфиденциальность личной информации, предпочтений и истории пользователей должна быть очень высокой. Система должна максимально защищать конфиденциальность данных.

<сильный>2. Окружающая среда: система уже запущена, имеет место нежелательный доступ к конфиденциальным данным.

<сильный>3. Стимул: внешний объект или внутренний неавторизованный объект.

<сильный>4. Ответ: система должна защищать конфиденциальность данных, а несанкционированный доступ должен быть запрещен.

<сильный>5. Измерение: [Конфиденциальность персональных данных пользователей] = [100 - [количество успешных атак злоумышленника] / [общее количество атак]]

<сильный>6. Разрешение: [Конфиденциальность персональных данных пользователей] >= 99,999


testing attributes qa software-quality
person Sazzad Hissain Khan    schedule 05.02.2019    source источник

Ответы (1)


arrow_upward
1
arrow_downward

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

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

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

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

  2. Допущение: ни один QA не может гарантировать отсутствие дефектов на 99%. Если не ошибаюсь лучшее, что может дать независимый аудит, это 95% - но это очень дорого и крайне тщательное тестирование

person Val Kalinichenko    schedule 05.02.2019
comment
Спасибо за ваше предложение. Когда конфиденциальность данных является функциональным требованием, как обычно тестер проверяет это требование, когда продукт готов? Известна ли вам какая-либо общая процедура проверки конфиденциальности данных? - person Sazzad Hissain Khan; 06.02.2019
comment
Не тот, о котором я знаю. Но в Интернете должно быть много контрольных списков, таких как этот cyber.harvard.edu/ecommerce/privacyaudit .html. Как правило, тестировщик проверяет функции, перечисленные в требованиях и генеральном плане тестирования — все это следует обсудить и указать на этапе планирования до выполнения теста. - person Val Kalinichenko; 07.02.2019