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

1. Дефектные дефекты Александр Александров УЦ 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. Дефект отклонен Дефект открыт Дефект закрыт Отклоняет Переоткрывает Принимает Закрывает Откладывает Обрабатывает Регистрирует Дефект отложен Project Tester Manager Проверяет Объединяет Дефект Назначает/изменяет зарегистрирован ответсвенного за исправление Дефект устранен Дефект отождествлен Исправляет Определение задания Получает задание на исправление Developer ЖЦ дефекта по ролям

7. Типы дефектных дефектов, или Правило четырех «П» • Пропущенные • Почему • Как избежать повторения • Придуманные • Почему • Как избежать повторения • Плохо описанные • Почему • Как избежать повторения • неПодходящие по ситуации • Почему • Как избежать повторения

8. Критерии качественныхтребований Тестирование возможно лишь при наличии требований к программе. Если от системы ничего не требуется, она может делать все, что угодно, и это нельзя считать неправильным. • Полнота - полно описывать функциональность. • Корректность - точно описывать желаемую функциональность. Для соблюдения корректности необходима связь с источниками требований, например с пожеланиями пользователей. • Согласованность (непротиворечивость) • Осуществимость - возможность реализовать каждое требование при известных условиях и ограничениях системы и операционной среды. • Необходимость - отражать возможность, которая действительно необходима пользователям, или которая нужна для соответствия внешним системным требованиям или стандартам.

9. Критерии качественныхтребований Назначение приоритетов Однозначность – возможностьинтерпретировать их одинаково. Естественный язык зачастую грешит многозначностью. Четко понимать каждое положение. Все специальные и запутанные термины разъяснены в словаре. Проверяемость -неполные, несогласованные (противоречивые), невыполнимые или неоднозначные требования также не проверяются. Трассируемость - Связи между требованиями четко трассируемы, изменения в одном требовании должны отражаться на связанных требованиях (при изменении требований не должна нарушаться согласованность набора требований).

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

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

12. Рекомендации при описании дефекта Описание должно быть достаточно простым, доступным в терминах бизнеса и понятных команде. Применяйте короткие однозначные фразы Длинное, непонятное описание не читают разработчики Отчет о тестировании также не должен содержать необязательных слов или шагов Замедляет процесс работы над дефектом

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

14. Рекомендации при описании дефекта Не открывать повторно старые описания дефектов для новых дефектов с похожими признаками Описание старого дефекта может еще пригодиться (дефект может вновь появиться) Запутывает работу с дефектами

15. Рекомендации при описании дефекта Объективность, корректность и нейтральность Никогда не давать диагноз, лучше описывать симптом Можно ошибиться в поставленном диагнозе Нарушается правило корректности описания дефекта При описании дефекта не делать поспешных предположений. Необходимо протестировать область дефекта с достаточным покрытием тестовых данных Может быть неправильно понята функциональность или спецификация

16. Рекомендации при верификации дефекта Проверка исправления дефекта и изменение статуса проверенной ошибки При появлении новой сборки сначала выполнить верификацию исправленных дефектов, затем заводить новые Важны своевременность и актуальность дефекта Проверка функциональности, связанной с ошибкой («посмотреть вокруг»)

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

18. Спасибо за внимание!Вопросы?