Аудит процессов тестирования при смене проектной команды

Маргарита Сафарова, КРОК

Что делать?!

Аудит поможет!

Аудит — процедура независимой

оценки деятельности организации,

системы, процесса, проекта или

продукта.

Цель аудита: выявить проблемные

места и позволить оперативно

принять меры для их устранения,

а также наметить план оптимизации.

• Внешний

– Компания предоставляет независимую оценку • Внутренний

– Эксперт в области тестирования и обеспечения качества

– Участники проектной командыАнализ:

На соответствие стандартам На основе best practices Комбинирование подходов

Типы аудита

Стандарты тестирования

• IEEE Std 730-2002 Планирование контроля качества IEEE STD 730-2002, IEEE Standard for Software Quality Assurance Plans

• IEEE Std 829-1998 Стандарт документации тестирования ПО IEEE Std 829-1998 «Standard for Software Test Documentation»

• IEEE Std 1012a-1998. Стандарт по проверке и подтверждении достоверности программного обеспечения (IEEE Standard for Software Verifcation and Validation: Content Map to IEEE/EIA 12207.1-1997)

• IEEE Std 1028-1997. Стандарт по проверке программного

обеспечения посредством просмотров исходного текста

(Standard for Software Reviews)• IEEE Std 1061-1998 Методологии метрик качества

Standard for a Software Quality Metrics Methodology

Как проводить аудит

Формально Неформально

VS

Откуда брать информацию

МЫ

Старички

Бывшие члены

проектной команды

Руково-дители

Пользо-ватели

Стейк-холдеры

Нам нужен ПЛАН!

Определить состав участников аудита

и их взаимодействие Собрать информацию от всех

заинтересованных лиц Определить ключевые области проверки Определить критерии Сформировать TODO List Определить сроки Провести анализ и выявить ключевые проблемные моменты Подготовить заключение по результатам проведения аудита Разработать предложения об оптимизации

ЧТО мы тестируем?

• Объект тестирования • КАКАЯ ЦЕЛЬ? • Как система помогает конечным

пользователям решать их задачи• Архитектура системы• Какие артефакты имеются

– концепция– спецификации– руководства пользователей

• Насколько они актуальны?

КТО тестирует?

• разработчики• независимая группа тестировщиков• совместно

• аналитики• техписатели• техподержка• внедренцы

Проектная команда

• Менеджер проекта • Аналитики • Разработчик• Тестировщик• Внедренец• Техподдержка

Какая роль отсутствует? Есть пересечения ролей? Области компетенции внутри роли?

Роли в тестировании

Тест менеджер

Специалист (ручное

тестирование)

Тест дизайнер

Инженер по автоматизации

Тест аналитик

КАК тестируется?

• Статическое тестирование (static)– Анализ кода– Анализ документации

• Динамическое тестирование (dynamic)– Черный ящик (Boundary Value Analysis,

Equivalence Partitioning, Decision Tables, State Transition, Use Case testing)

– Белый ящик (statement coverage, decision, condition…)

– На основе опыта (error guessing, exploratory testing)

КОГДА тестируется продукт?

Концепция Архитектура

РеализацияВнедрени

е

Артефакты тестирования

• Стратегия тестирования• Тест план• Тест кейсы• Чек листы• Приемочные тесты• Тестовые данные• Матрица покрытия требований тестами• Программа и методика испытаний• Баг репорты

Инструменты тестирования

• Система учета дефектов (BugZilla, JIRA)• TMT система для управления процессом

тестирования (Testopia)• Инструменты автоматизации тестирования

(TestComplete, Selenium и др.)• Инструменты нагрузочного тестирования

(Jmeter и др.)• Специфические инструменты обновления (тул

для обновления плагинов, js скриптов, кастомизации и др.)

Управление изменениями

• Есть согласованные и подписанные заказчиком документы требований?

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

• Есть описанная и согласованная с заказчиком процедура управления изменениями?

• Требования категоризированы? (потребности заинтересованных лиц, функциональные требования, бизнес-правила)

Управление изменениями

• Есть ли согласованная с заказчиком и зафиксированная приоритизация требований?

• Участники проекта знают, где и в каком виде хранятся требования к системе?

• Есть маппинг требований на документы проектирования?

• Есть процедура оповещения при изменении требования?

Конфигурация проекта

• Какие стенды есть в наличии? • Описана конфигурация стендов проекта?• Команда ознакомлена с конфигурацией стендов?

• Совпадает ли предрелизный

стенд с боевым конфигурацией?• Контроль версий и релиз

менеджмент• Исходники проекта хранятся в специализированном

хранилище (TFS)

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

• Процедура передачи релиза в тестирование– Сборка билда – Выкладка дистрибутива\обновленных

файлов на сервер• Процедура обновление стендов • Процедура приемки билда в тестирование

Процедура передачи релиза заказчику

• Принятие решения о внедрении на бой – кто отвечает, когда, какие действия перед этим совершают?

• План отката - это важно!• Приемка заказчиком (Программа и методика

испытаний)

Метрики на основе дефектов:• Количество ошибок (открытые, закрытые,… )• Степень серьезности

(critical, major, minor,…)• Плотность дефектов = Общее количество найденных

дефектов\количество тестов на функцию• Коэффициент обнаружения ошибок = Общее

количество найденных дефектов\количество выполненных тестов

Количественная оценка процесса тестирования

Покрытие кода тестами (Code Coverage)

T = (Lt/Lc) * 100% T - тестовое покрытиеLt - кол-ва строк кода, покрытых тестамиLc - общее кол-во строк кода.

Покрытие требований (Requirements Coverage)

T = (Lt/Ltotal) * 100% где:T - тестовое покрытиеLt - количество требований, проверяемых тест кейсамиLtotal - общее количество требований

Количественная оценка процесса тестирования

Сходимость дефектов

Планирование

• Релизы разработки спланированы и отмечены в плане?

• Учтены риски?• В плане-графике учитываются затраты на тестирование? • Определены критерии завершения тестирования?• Активности по тестированию планируются

тест лидом? • План-график находится в актуальном

состоянии?

Удовлетворенность заказчиков

• Есть срывы сроков поставок проектных продуктов?

• Есть претензии от заказчика(электронные письма, факсы, официальные документы)

• Есть что улучшать? (фидбэки о пользователей по продукту)

Отчет о проведении аудита

Артефакт Статус Решение Приоритет

Стратегия тестирования Нет Надо написать Средний

Тест план Есть ОК

Тест кейсы Нет ОК

Чек листы Есть ОК

Приемочные тесты Есть ОК

Тестовые данные Есть ОК

Матрица покрытия требований тестами

Есть ОК

Программа и методика испытаний

Нет Надо написать Высокий

Баг репорты Есть ОК

msafarova@croc.ruhttp://www.margo-qa.blogspot.com/

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