18
Дефектные дефекты Александр Александров УЦ Luxoft

Александр Александров -- Дефектные дефекты

Embed Size (px)

Citation preview

Page 1: Александр Александров -- Дефектные дефекты

Дефектные дефекты

Александр АлександровУЦ Luxoft

Page 2: Александр Александров -- Дефектные дефекты

2

Немного о себе

1963-1999 – Вычислительный центр Московского Государственного университета им. М.В. Ломоносова (студент, сотрудник)

1999-2005 – Luxoft (руководитель группы тестирования, тест-менеджер)

2006-2007 – Auriga (директор по качеству)

С 2008 – Luxoft (эксперт по управлению качеством ПО)

C 2010 – член коллегии ISTQB

Кандидат физико-математических наук, доцент, старший научный сотрудник

Сертифицированный инструктор университета Carnegie Mellon по тематике Quality Assurance

Page 3: Александр Александров -- Дефектные дефекты

3

Опыт работы

Более 30 лет работы в области тестирования и обеспечения качества (МГУ, Luxoft, Auriga)

Более 5 лет работы в области управления качеством (Luxoft, Auriga)

Опыт cертификации ISO 9001 (Luxoft), CMM, CMMI (Luxoft, Auriga)

Опыт внедрения процессов в рамках модели CMMI (Luxoft, Auriga)

Сертификат обучения Project Management от Project Management Institute (2000)

Сертификат обучения Introduction to Capability Maturity Model Integration v. 1.2 от ProceXpert (2007)

Page 4: Александр Александров -- Дефектные дефекты

4

Дефекты программного продукта

Определения дефекта, вытекающие из определения тестирования:

– Дефект есть несоответствие между фактическими и требуемыми характеристиками объекта тестирования

– Дефект есть несоответствие фактического поведения системы разумным ожиданиям пользователя

Г. Майерс «Надежность программного обеспечения»

Page 5: Александр Александров -- Дефектные дефекты

5

Дефекты – основная продукция тестировщиков

Примеры дефектов:

–поведение программы, не соответствующее спецификациям

–поведение программы, противоречащее разумным ожиданиям пользователя

Page 6: Александр Александров -- Дефектные дефекты

6

ЖЦ дефекта по ролям

Дефект закрыт

Tester

Закрывает

Дефект зарегистрирован

Регистрирует

Дефект открыт

Переоткрывает

Дефект отклонен

Дефект отложен

Дефект отождествлен

Project Manager

Обрабатывает

Принимает

Отклоняет

Откладывает

Объединяет

Дефект устранен

Проверяет

Определение задания на исправление

Назначает/изменяет ответсвенного за

исправление

Developer

ИсправляетПолучает задание

Page 7: Александр Александров -- Дефектные дефекты

7

Типы дефектных дефектов, или Правило четырех «П»

Пропущенные– Почему

– Как избежать повторения

Придуманные– Почему

– Как избежать повторения

Плохо описанные– Почему

– Как избежать повторения

неПодходящие по ситуации– Почему

– Как избежать повторения

Page 8: Александр Александров -- Дефектные дефекты

8

Критерии качественных требований

Тестирование возможно лишь при наличии требований к программе. Если от системы ничего не требуется, она может делать все, что угодно, и это нельзя считать неправильным.

Полнота - полно описывать функциональность.

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

Согласованность (непротиворечивость)

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

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

Page 9: Александр Александров -- Дефектные дефекты

9

Критерии качественных требований

Назначение приоритетов

Однозначность – возможность интерпретировать их одинаково. Естественный язык зачастую грешит многозначностью. Четко понимать каждое положение. Все специальные и запутанные термины разъяснены в словаре.

Проверяемость - неполные, несогласованные (противоречивые), невыполнимые или неоднозначные требования также не проверяются.

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

Page 10: Александр Александров -- Дефектные дефекты

10

Типы дефектов

Дефекты на этапе оформления ТЗ Дефекты формирования спецификации требований Дефекты новых требований (CR/Enhancement) Дефекты в архитектуре Дефекты кода Дефекты в тест-сценарии

Page 11: Александр Александров -- Дефектные дефекты

11

Выявленные аспекты при описании дефекта

Какие есть проблемы? Какова важность проблемы? Когда проблема была обнаружена? Кто сообщает о проблеме? В какой версии системы зафиксирована проблема? При каких действиях в системе была обнаружена

проблема? Какие действия выполнялись в системе перед тем, как

была обнаружена проблема? Как повлияют изменения в системе на ее работу?

Page 12: Александр Александров -- Дефектные дефекты

12

Рекомендации при описании дефекта

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

– Длинное, непонятное описание не читают разработчики

Отчет о тестировании также не должен содержать необязательных слов или шагов

– Замедляет процесс работы над дефектом

Page 13: Александр Александров -- Дефектные дефекты

13

Рекомендации при описании дефекта

Описание должно быть достаточно полным, чтобы после прочтения другими людьми не возникало дополнительных вопросов

– Тормозит работу с дефектом, может привести к неполному или некорректному исправлению дефекта

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

– Времени будет потрачено гораздо больше.

– Риск потери важной информации

Page 14: Александр Александров -- Дефектные дефекты

14

Рекомендации при описании дефекта

Не открывать повторно старые описания дефектов для новых дефектов с похожими признаками

– Описание старого дефекта может еще пригодиться (дефект может вновь появиться)

– Запутывает работу с дефектами

Page 15: Александр Александров -- Дефектные дефекты

15

Рекомендации при описании дефекта

Объективность, корректность и нейтральность Никогда не давать диагноз, лучше описывать симптом

– Можно ошибиться в поставленном диагнозе

– Нарушается правило корректности описания дефекта

При описании дефекта не делать поспешных предположений. Необходимо протестировать область дефекта с достаточным покрытием тестовых данных

– Может быть неправильно понята функциональность или спецификация

Page 16: Александр Александров -- Дефектные дефекты

16

Рекомендации при верификации дефекта

Проверка исправления дефекта и изменение статуса проверенной ошибки

– При появлении новой сборки сначала выполнить верификацию исправленных дефектов, затем заводить новые

Важны своевременность и актуальность дефекта Проверка функциональности, связанной с ошибкой

(«посмотреть вокруг»)

Page 17: Александр Александров -- Дефектные дефекты

17

Пример метрики дефектных дефектов

Declined defects ratio

0,0%

5,0%

10,0%

15,0%

Actual Threshold

Page 18: Александр Александров -- Дефектные дефекты

18

Спасибо за внимание!

Вопросы?