К основному контенту

Что нужно знать о рисках

Риски используются для определения того, где начинать тестирование и каким аспектам уделить большее внимание.
Риск (risk): Фактор, который может привести к негативным последствиям в будущем, обычно выражается через вероятность и влияние. (ISTQB)
Анализ рисков (risk analysis): Процесс оценки идентифицированных рисков для вычисления их вероятности и влияния. (ISTQB)
Контроль рисков (risk control): Процесс, в результате которого выносятся решения и принимаются защитные меры для уменьшения рисков до определенного уровня или поддержанию рисков в оговренных рамках. (ISTQB)
Определение рисков представляет собой  процесс идентификации  рисков с использованием таких методик как мозговой штурм, контрольные списки и история отказов.
Процесс оценки определенного риска проекта или продукта с целью определить его уровень называется оценка риска. По каждому риску даётся оценка представляемой им угрозы и приводятся варианты выхода из ситуации. Например:
- Персонал (вероятность низкая): в случае нетрудоспособности какого-либо из участников команды можно обратиться к представителям проекта «Каталогизатор» для предоставления временной замены (договорённость с менеджером «Каталогизатора» Джоном Смитом достигнута).
- Время (вероятность высокая): заказчиком обозначен крайний срок сдачи 01.06, потому время является критическим ресурсом. Рекомендуется приложить максимум усилий к тому, чтобы фактически завершить проект 28.05 с тем, чтобы один день (29.05) остался в запасе.
- Иные риски: иных специфических рисков не выявлено
Существует предполагаемый перечень действий для оценки рисков.
Первым делом составить список всех рисков, какие, по вашему мнению, представляют угрозу выполнению графика работ по тестированию. Проведите анализ статистических данных, таких как оценки выполнения проектов или информация о необычных случаях сбоев, имевших место при выполнении предыдущих проектов. Получите оценку зависимости от других групп, обсудив с ними вероятность того, что они выполнять предложенные вами критерии вхождения в испытания.
Следующим шагом необходимо дать оценку вероятности осуществления каждого выявленного риска и дать оценку последствий осуществления риска в отношении выполнимости плана испытаний. Для описания этого влияния воспользуйтесь шкалой критическое, высокое, среднее, малое.
Послу оценки рисков, необходимо разработать план снижения вероятности осуществления рисков или их влияния, начиная с тех из них, которые обладают высокой вероятностью осуществления или чреваты тяжелыми последствиями. Риски могут описываться в таблице, в которой указываются риски, вероятность овеществления этого риска, влияние этого риска и план мероприятий по снижению от овеществления рисков. Пример приведен на рисунке 1.
Рисунок 1. Таблица описания рисков.
Риски группируют по одному или нескольким общим факторам, таким как атрибут качества, причина, местонахождение, или потенциальные последствия риска. Определенный набор типов рисков относится к тому типу тестирования, который может смягчить (или проконтролировать) данный тип риска. Выделяют такие риски, как риск качества, связанный с атрибутом качества, риск продукта, непосредственно связанный с объектом тестирования, риск проекта, относящийся к управлению и контролю проектом или тестированием в проекте. 
Важность риска определяется по его характеристикам: влияние  и вероятность. Уровень риска может быть использован для определения интенсивности тестирования. Уровень риска может быть выражен как качественно (например: высокий, средний, низкий), так и количественно.
Тестирование, основанное на рисках – это подход к тестированию с целью минимизирования уровня рисков продукта и информирования заинтересованных лиц о текущем состоянии рисков с начальных стадий проекта. Подразумевает под собой управление процессом тестирования, исходя из идентифицированных рисков продукта и использования уровней риска.
Риски проекта – это риски, которые влияют на способность проекта достигнуть его целей, и включают:
- Организационные факторы
·       Недостаток квалификации, подготовки и сотрудников;
·       Личные проблемы сотрудников;
·       Политические проблемы, такие как: 
-Тестировщики в недостаточной степени сообщают о своих проблемах и результатах тестирования;
- Неспособность следовать информации, полученной во время тестирования или рецензирования (например, не улучшать практики разработки или тестирования);
- Неверное отношения к тестированию или ложные ожидания (например, не принимать во внимание значение найденных во время тестирования дефектов);
- Технические проблемы:
·       Проблемы в определении верных требований;
·       Объем, при котором требования не могут соответствовать заданным ограничениям;
·       Вовремя не готово тестовое окружение;
·       Позднее преобразование данных, планирование миграции и разработки тестовых данных и средств преобразования\миграции тестовых данных;
·       Низкое качество проектирования, кода, конфигурационных и тестовых данных и тестов;
- Проблема поставщика:
·       Отказ третьей стороны;
·       Проблемы контракта.
Риски продукта – это потенциальные области сбоя (неблагоприятные будущие события или опасность) в ПО или системе, т.к. они подвергают риску качество продукта, например:
- Поставка потенциально ненадежного ПО;
- Возможность того, что программное\аппаратное обеспечение может нанести вред человеку или компании;
- Плохие характеристики ПО (например, функциональность, надежность, удобство использования или производительность);
- Неполнота и низкое качество данных (например, проблемы миграции, преобразования и перемещения данных, отклонение от стандарта данных);
 - ПО, которое не выполняет предполагаемых функций.
Риски, возникающие при использовании средств тестирования:
- Нереалистичные ожидания от использования средства (включая функциональность и простоту использования).
- Недооценка времени, стоимости и объемов работ на первоначальное внедрение средства (включая обучение и получение экспертизы извне).
- Недооценка времени и объемов работ, необходимых для получения значимого и устойчивого результата от использования средства (включая необходимость изменений в процессе тестирования и постоянного улучшения методики работы со средством).
- Недооценка затрат на поддержку тестов, генерируемых средством.
- Возложение излишних надежд на средство (замена проектирования тестов или использование автоматизированных тестов там, где ручное тестирование было бы уместней).
- Пренебрежение контролем версий тестов внутри средства.
- Пренебрежение вопросами взаимодействия между критическими средствами, такими как средства управления требованиями, средства контроля версий, средства управления инцидентами, средства управления дефектами, а особенно если эти средства от разных производителей.
- Риск того, что поставщик средства перестанет существовать, откажется от средства или продаст его иному поставщику.
- Слабая поддержка со стороны поставщика, в том числе по вопросам обновлений и исправлений дефектов.
- Риск приостановки бесплатного продукта или продукта с открытым кодом.
- Непредвиденные риски, как например, невозможность поддержки новой платформы.
Риски, которые оказывают влияние на график работ по тестированию:
• Аппаратные средства, необходимые для проведения тестирования, отсутствуют на начальной стадии испытаний
• Тестируемый программный продукт не поступил на испытания
• Тестовые случаи не готовы к началу испытаний
• Исполнители, которым поручено проведение испытаний, не могут приступить к тестированию
• Внесение изменений в требования в процессе разработки тестов или во время испытаний
• Изменение пользовательских интерфейсов в процессе разработки тестов или во время испытаний
• Освоение персоналом новых средств тестирования не завершено к началу испытаний.
Тестирование не поможет обойти все возможные риски, но позволит сократить риски возникновения неблагоприятных эффектов или их последствий.


Комментарии

Популярные сообщения из этого блога

Дымовое, критического пути и расширенное тестирование

Из приведенной ранее классификации тестирования (в статье " С чего начинать изучение тестирования? Конечно же с методов! ") нам осталось рассмотреть «по степени важности тестируемых функций». Но, на этом теория еще не заканчивается) Итак, по степени важности тестируемых функций разделяют следующие виды: - «Дымовое» (smoke) - тестирование, которое состоит из минимального набора тестов на явные ошибки. Дымовое тестирование на начальном этапе выявляет основные критические дефекты. Исходя из того, что данные проверки практически всегда одинаковы и редко претерпевают изменениям, целесообразно будет их автоматизировать. Ежедневная сборка продукта и smoke тестирование являются передовыми практическими методами. Программу, не проходящую "дымовой тест", не имеет смысла отдавать для более глубокого тестирования. - Критического пути ( critical path test ) — основной тип тестовых испытаний, во время которого значимые элементы и функции приложения проверяются н...

Тест план и тестовая модель - что это?

Test Plan (тест план)  — это документ или совокупность документов, расписывающих всю тестовую активность (цели, подходы, ресурсы и график запланированных тестовых активностей)  в пределах одного проекта, все работы проводимые командой тестирования или одним тестировщиком. В стандарте IEEE 829 перечислены пункты, из которых должен состоять тест-план:   1) Test plan identifier (идентификатор);   2) Introduction (описание/цель) - Предельно краткое описание цели разработки приложения (частично это напоминает бизнес-требования);   3) Features to be tested (Области, подвергаемые тестированию) - Перечень функций и/или нефункциональных особенностей приложения, которые будут подвергнуты тестированию. В некоторых случаях здесь также приводится приоритет соответствующей области. 4) Features not to be tested (Области, не подвергаемые тестированию) - Перечень функций и/или нефункциональных особенностей приложения, которые не будут по...

Советы для молодых тестировщиков или как составлять тест - кейс =)

Тест (test) представляет собой набор операций, предназначенных для получения одного или большего числа ожидаемых результатов в некоторой программной системе. Тест-кейсы должен помочь тестировщику (даже начинающему) провести проверку продукта без ознакомления со всей документацией. В тест – кейсе желательно избегать зависимостей от других тест – кейсов. Тест кейс в основном состоит из * Основных параметров - id (номер) - уникальный идентификатор тест-кейса. Его удобно использовать для одинакового понимания, о какой проверке идет речь (например, дать ссылку в баге). - Автор – имя и фамилия тестировщика, который написал тест – кей. - Название — краткое описание сути проверки. - Предусловие – предварительные шаги. - Шаги – что нужно сделать, чтобы что-то получить. - Ожидаемый результат – тот результат, который соответствует документации или здравому смыслу =). - Фактический результат – то, что получилось в итоге действия в шаге. - Постусловия ...