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

Post on 12-Jun-2015

2.179 views 2 download

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

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

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

2

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

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

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

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

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

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

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

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

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)

4

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

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

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

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

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

5

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

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

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

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

6

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

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

Tester

Закрывает

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

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

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

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

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

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

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

Project Manager

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

Принимает

Отклоняет

Откладывает

Объединяет

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

Проверяет

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

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

исправление

Developer

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

7

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

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

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

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

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

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

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

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

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

8

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

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

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

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

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

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

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

9

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

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

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

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

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

10

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

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

11

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

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

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

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

12

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

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

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

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

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

13

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

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

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

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

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

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

14

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

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

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

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

15

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

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

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

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

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

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

16

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

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

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

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

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

17

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

Declined defects ratio

0,0%

5,0%

10,0%

15,0%

Actual Threshold

18

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

Вопросы?