Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Почему мы тестируем именно           так? Тестирование как управление рисками продукта          Григорий Сенин, Люксофт
No risk -- no test“Good enough”:•   Если тестировать в области риска становится    дороже, чем нести потери от его осущест...
Язык рисков  Чем мы рискуем, если сейчас прекращаем  тестирование и выпускаем продукт? Чтобы ответить на этот вопрос, нео...
Риски продукта                                    Риск Вероятность (частота)                           Ущерб, потери• кто ...
Дефект – источник риска•   Проявление дефекта    –   неблагоприятное событие, которое может с некоторой        вероятность...
Примеры рисков,        связанных с дефектами• «слишком долгий отклик системы»  – потеря времени поль-ля• «неудобный интерф...
Тестирование на основе               рисков качества– что тестировать,– что тестировать раньше,– насколько тщательно тести...
Тестирование с точки зрения                управления рисками       Измерения,        отчѐты                             ...
Тестирование с точки зрения           управления рисками   Этап управления                                       Деятельно...
Идентификация рисковТри метода1.   от рисков к продукту: ведение общего перечня рисков2.   от продукта к рискам: анализ сл...
От рисков к продукту:                         перечни рисков•     пример    источник риска    код риска      категория    ...
От продукта к рискамСлабости      Угрозы     Ущерб
Идентификация рисков по            характеристикам качества•   Functionality – функциональные дефекты•   Reliability – низ...
Анализ атрибутов рисков    Ущерб    • Катастрофический: крах системы, потеря данных    • Серьёзный: функция отсутствует   ...
Анализ атрибутов рисков2Вероятность – степень «видимости» дефекта• Всегда: пользователь попадает сюда в каждой  сессии• Ча...
Критерии завершения                 тестирования■ минимизировать суммарный остающийся в продукте риск   Пример 1     – Вс...
План сдерживания рисков               продукта• Сдерживание рисков     выявление дефектов  – План тестирования – инструмен...
Сдерживание рисков при               тестировании• Проектирование функциональных тестов =  моделирование угроз продукту («...
Приоритеты при тест-                      проектировании              Глубина проектирования функциональных тестов        ...
Отслеживание рисков• Отслеживание рисков ведѐтся в форме  отслеживания дефектов   – Отчѐты о тестировании, статистика   – ...
Управление риском в                   дефекте• Идентификация риска – обнаружен дефект• Анализ – дефект воспроизведѐн, изол...
Отслеживание рисков –                «судьба дефекта»•   Пока дефект не исправлен, риск в продукте остаѐтся•   “Risk elimi...
Типичное состояние   продукта в конце разработки                         неопределённость                                 ...
Приоритеты помогаютуменьшить риски продукта       не        •   выявить самые высокие риски   проверено         качества в...
Questions?
Upcoming SlideShare
Loading in …5
×

Тестирование как управление рисками продукта

3,694 views

Published on

SQA Days 11. День 1. Стендовая секция
Григорий Сенин
Luxoft Professional
Москва, Россия

Published in: Education
  • Be the first to comment

Тестирование как управление рисками продукта

  1. 1. Почему мы тестируем именно так? Тестирование как управление рисками продукта Григорий Сенин, Люксофт
  2. 2. No risk -- no test“Good enough”:• Если тестировать в области риска становится дороже, чем нести потери от его осуществления, то тестирование нецелесообразно
  3. 3. Язык рисков Чем мы рискуем, если сейчас прекращаем тестирование и выпускаем продукт? Чтобы ответить на этот вопрос, необходимо представлять себе риски продукта Области, таящие риск и НЕ охваченные тестами, трактуются как угроза продукту
  4. 4. Риски продукта Риск Вероятность (частота) Ущерб, потери• кто будет пользоваться системой Что наихудшее может произойти,• что будет с ней делать если в этой функции или свойстве• как часто системы произойдет отказ? Анализ рисков устанавливает приоритеты Больше риска – больше тестирования
  5. 5. Дефект – источник риска• Проявление дефекта – неблагоприятное событие, которое может с некоторой вероятностью случиться при работе с продуктом с каждым дефектом, остающимся в продукте, связан риск• Остающийся в продукте риск мог бы быть вычислен как суммарный риск от всех неисправленных, а также ненайденных дефектов
  6. 6. Примеры рисков, связанных с дефектами• «слишком долгий отклик системы» – потеря времени поль-ля• «неудобный интерфейс» – то же плюс невыполнение полезной функции• «отсутствие нужной функции» – негативное воздействие на бизнес-процесс предприятия пользователя• «крах системы» – потеря данных и др. тяжѐлые последствия вплоть до потери исполнителем репутации• При заказной разработке исполнитель может подвергнуться штрафным санкциям
  7. 7. Тестирование на основе рисков качества– что тестировать,– что тестировать раньше,– насколько тщательно тестировать,– когда завершать тестирование.Управление рисками = определить, что для продукта существенно при нехватке времени суметь пожертвовать несущественным
  8. 8. Тестирование с точки зрения управления рисками  Измерения, отчѐты  Стратегия, подход Выполнение тестов  Анализ и ранжирование требований  Проектирование тестов
  9. 9. Тестирование с точки зрения управления рисками Этап управления Деятельность группы тестирования рискамиИдентификация рисков Получение перечня рисков Стратегия тестирования Приоритеты тестирования;Анализ атрибутов рисков ранжирование требований Тест-проектирование;План сдерживания рисков планирование тест-циклов Прогон тестов;Отслеживание рисков регистрация дефектов,; верификация исправлений, отчѐты Анализ результатов, метрики,Контроль коррекция приоритетов
  10. 10. Идентификация рисковТри метода1. от рисков к продукту: ведение общего перечня рисков2. от продукта к рискам: анализ слабых мест продукта3. от требований к рискам -- атрибуты качества
  11. 11. От рисков к продукту: перечни рисков• пример источник риска код риска категория риск риска Immature vendor CUS-08 Technical Customer-supplied components have poor capability Development Risk quality, resulting in extra testing, design, and integration work and in extra customer- relationship management. Общие источники продуктовых рисков (Дж.Бах): • «новое» • интерфейсы • «сложное» • место поломки -- «где у них гнездо» • «важное» • оптимизация • «интенсивность» • ...
  12. 12. От продукта к рискамСлабости Угрозы Ущерб
  13. 13. Идентификация рисков по характеристикам качества• Functionality – функциональные дефекты• Reliability – низкая производительность• Usability – неудоство пользовательского интерфейса• Efficiency – неэффективная работа с вычислительными ресурсами• Maintainability -- ...• Portability -- ... -- т.наз. FRUEMP-методика (по ISO 9126)• Уровень риска: что случится, если требования данного типа не будут удовлетворены?• Важность (приоритет, ранг) требования можно трактовать как размер потенциального ущерба
  14. 14. Анализ атрибутов рисков Ущерб • Катастрофический: крах системы, потеря данных • Серьёзный: функция отсутствует • Средний: функция отсутствует, но есть обходной путь • Незначительный: неудобный интерфейс Симптом нарушения требования обходные пути, косметические функция неудобство неочевидные замечания, недоступна использования действия пожеланияКритичность требования высокая фатальный серьѐзный серьѐзный средний средняя серьѐзный серьѐзный средний незначит низкая средний средний незначит незначит
  15. 15. Анализ атрибутов рисков2Вероятность – степень «видимости» дефекта• Всегда: пользователь попадает сюда в каждой сессии• Часто: сюда «рано или поздно» попадает каждый пользователь, но не обязательно в каждой сессии• Время от времени: обычно здесь бывают только опытные пользователи• Редко: большинство здесь не бывает никогда – в эту область можно попасть только в результате весьма специфической последовательности шагов ■ частоту функционального сценария нужно учитывать при классификации дефектов
  16. 16. Критерии завершения тестирования■ минимизировать суммарный остающийся в продукте риск Пример 1 – Все критические тесты пройдены – Все критические или серьѐзные дефекты закрыты Пример 2 – Все критические тесты пройдены – Все критические дефекты закрыты – Все незакрытые серьѐзные дефекты проанализированы и величина стоящего за ними риска признана приемлемой
  17. 17. План сдерживания рисков продукта• Сдерживание рисков выявление дефектов – План тестирования – инструмент для этого• Специфика продуктовых рисков: – Риски – рукотворные, дефекты вносятся в продукт! Риск можно «вызвать» в виде дефекта, затем «разоблачить» и устранить
  18. 18. Сдерживание рисков при тестировании• Проектирование функциональных тестов = моделирование угроз продукту («провокация» рисков) – если функциональная область (или компонент) не покрыта тестами, это равносильно принятию риска• Планирование тест-циклов – критичные компоненты/подсистемы тестируются раньшеНа сдерживание рисков направлены также:• Регрессионное тестирование (риск регрессии)• Автоматизированное тестирование (успеть больше)
  19. 19. Приоритеты при тест- проектировании Глубина проектирования функциональных тестов вероятность/частота выполнения сценария высокая средняя низкая высокая глубокоеВажностьсценария средняя низкая неглубокое
  20. 20. Отслеживание рисков• Отслеживание рисков ведѐтся в форме отслеживания дефектов – Отчѐты о тестировании, статистика – Суммарный риск продукта метрики тестирования;• Устранение рисков -- через обнаружение и исправление дефектов – более критичные сценарии прогоняются чаще
  21. 21. Управление риском в дефекте• Идентификация риска – обнаружен дефект• Анализ – дефект воспроизведѐн, изолирован, уточнѐн, обобщѐн, взвешен риск (серьѐзность);• Планирование – уточнены тест-спеки, контролируется статус дефекта (нужно закрыть)• Отслеживание риска = судьба дефекта
  22. 22. Отслеживание рисков – «судьба дефекта»• Пока дефект не исправлен, риск в продукте остаѐтся• “Risk elimination”: риск устраняется в результате исправления и верификации дефекта• “Risk acceptance”: риск принимается, когда обнаруженный дефект решено не исправлять• “Risk sharing”: когда не исправляется серьѐзный дефект, его обычно необходимо разделить: – с менеджером проекта (проектное совещание) – с заказчиком (в ходе сдачи-приѐмки) – с пользователем (описание дефекта в сопроводительной документации ~ Known Bugs/Workarounds)• “Risk avoidance”: иногда мы пробуем избежать риска – переписать фрагмент кода, где коренятся дефекты – урезать код (даже путѐм сокращения функционала)
  23. 23. Типичное состояние продукта в конце разработки неопределённость Ожидаемые характеристики не проверено Рискипроверено, но не остаются исправлено характеристики Реальные проверено и исправлено Риски устранѐны 
  24. 24. Приоритеты помогаютуменьшить риски продукта не • выявить самые высокие риски проверено качества в продукте как можно раньше! проверено, но • Максимальные риски будут не исправлено вовремя устранены • Остающиеся в продукте риски будут на приемлемом уровне • Область неопределѐнности непроверено и будет источником существенных рисковисправлено
  25. 25. Questions?

×