ݺߣ

ݺߣShare a Scribd company logo

доклад на SQADays 2011 в Казани

•
•
M
margo-qa
1 of 28
Аудит процессов тестирования при смене проектной команды Маргарита Сафарова. КРОК
Что делать?!
Аудит поможет! Аудит — процедура независимой оценки деятельности организации, системы, процесса, проекта или продукта. Цель аудита: выявить проблемные места и позволить оперативно принять меры для их устранения, а также наметить план оптимизации.
Типы аудита • Внешний – Компания предоставляет независимую оценку • Внутренний – Эксперт в области тестирования и обеспечения качества – Участники проектной команды Анализ:  На соответствие стандартам  На основе 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.ru http://www.margo-qa.blogspot.com/

More Related Content

доклад на SQADays 2011 в Казани

  • 1. Аудит процессов тестирования при смене проектной команды Маргарита Сафарова. КРОК
  • 3. Аудит поможет! Аудит — процедура независимой оценки деятельности организации, системы, процесса, проекта или продукта. Цель аудита: выявить проблемные места и позволить оперативно принять меры для их устранения, а также наметить план оптимизации.
  • 4. Типы аудита • Внешний – Компания предоставляет независимую оценку • Внутренний – Эксперт в области тестирования и обеспечения качества – Участники проектной команды Анализ:  На соответствие стандартам  На основе best practices  Комбинирование подходов
  • 5. Стандарты тестирования • 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
  • 7. Откуда брать информацию Старички Бывшие Стейк- члены холдеры проектной команды МЫ Пользо- Руково- ватели дители
  • 8. Нам нужен ПЛАН!  Определить состав участников аудита и их взаимодействие  Собрать информацию от всех заинтересованных лиц  Определить ключевые области проверки  Определить критерии  Сформировать TODO List  Определить сроки  Провести анализ и выявить ключевые проблемные моменты  Подготовить заключение по результатам проведения аудита  Разработать предложения об оптимизации
  • 9. ЧТО мы тестируем? • Объект тестирования • КАКАЯ ЦЕЛЬ? • Как система помогает конечным пользователям решать их задачи • Архитектура системы • Какие артефакты имеются – концепция – спецификации – руководства пользователей • Насколько они актуальны?
  • 10. КТО тестирует? • разработчики • независимая группа тестировщиков • совместно • аналитики • техписатели • техподержка • внедренцы
  • 11. Проектная команда • Менеджер проекта • Аналитики • Разработчик • Тестировщик • Внедренец • Техподдержка Какая роль отсутствует? Есть пересечения ролей? Области компетенции внутри роли?
  • 12. Роли в тестировании Тест менеджер Специалист Инженер по (ручное Тест дизайнер Тест аналитик автоматизации тестирование)
  • 13. КАК тестируется? • Статическое тестирование (static) – Анализ кода – Анализ документации • Динамическое тестирование (dynamic) – Черный ящик (Boundary Value Analysis, Equivalence Partitioning, Decision Tables, State Transition, Use Case testing) – Белый ящик (statement coverage, decision, condition…) – На основе опыта (error guessing, exploratory testing)
  • 14. КОГДА тестируется продукт? Концепция Архитектура Реализация Внедрение
  • 15. Артефакты тестирования • Стратегия тестирования • Тест план • Тест кейсы • Чек листы • Приемочные тесты • Тестовые данные • Матрица покрытия требований тестами • Программа и методика испытаний • Баг репорты
  • 16. Инструменты тестирования • Система учета дефектов (BugZilla, JIRA) • TMT система для управления процессом тестирования (Testopia) • Инструменты автоматизации тестирования (TestComplete, Selenium и др.) • Инструменты нагрузочного тестирования (Jmeter и др.) • Специфические инструменты обновления (тул для обновления плагинов, js скриптов, кастомизации и др.)
  • 17. Управление изменениями • Есть согласованные и подписанные заказчиком документы требований? • Документы требований обсуждались с конечными пользователями, от них получены и зафиксированы комментарии? • Есть описанная и согласованная с заказчиком процедура управления изменениями? • Требования категоризированы? (потребности заинтересованных лиц, функциональные требования, бизнес-правила)
  • 18. Управление изменениями • Есть ли согласованная с заказчиком и зафиксированная приоритизация требований? • Участники проекта знают, где и в каком виде хранятся требования к системе? • Есть маппинг требований на документы проектирования? • Есть процедура оповещения при изменении требования?
  • 19. Конфигурация проекта • Какие стенды есть в наличии? • Описана конфигурация стендов проекта? • Команда ознакомлена с конфигурацией стендов? • Совпадает ли предрелизный стенд с боевым конфигурацией? • Контроль версий и релиз менеджмент • Исходники проекта хранятся в специализированном хранилище (TFS)
  • 20. Процедуры передачи релиза в тестирование • Процедура передачи релиза в тестирование – Сборка билда – Выкладка дистрибутиваобновленных файлов на сервер • Процедура обновление стендов • Процедура приемки билда в тестирование
  • 21. Процедура передачи релиза заказчику • Принятие решения о внедрении на бой – кто отвечает, когда, какие действия перед этим совершают? • План отката - это важно! • Приемка заказчиком (Программа и методика испытаний)
  • 22. Количественная оценка процесса тестирования Метрики на основе дефектов: • Количество ошибок (открытые, закрытые,… ) • Степень серьезности (critical, major, minor,…) • Плотность дефектов = Общее количество найденных дефектовколичество тестов на функцию • Коэффициент обнаружения ошибок = Общее количество найденных дефектовколичество выполненных тестов
  • 23. Количественная оценка процесса тестирования Покрытие кода тестами (Code Coverage) T = (Lt/Lc) * 100% T - тестовое покрытие Lt - кол-ва строк кода, покрытых тестами Lc - общее кол-во строк кода. Покрытие требований (Requirements Coverage) T = (Lt/Ltotal) * 100% где: T - тестовое покрытие Lt - количество требований, проверяемых тест кейсами Ltotal - общее количество требований
  • 25. Планирование • Релизы разработки спланированы и отмечены в плане? • Учтены риски? • В плане-графике учитываются затраты на тестирование? • Определены критерии завершения тестирования? • Активности по тестированию планируются тест лидом? • План-график находится в актуальном состоянии?
  • 26. Удовлетворенность заказчиков • Есть срывы сроков поставок проектных продуктов? • Есть претензии от заказчика(электронные письма, факсы, официальные документы) • Есть что улучшать? (фидбэки о пользователей по продукту)
  • 27. Отчет о проведении аудита Артефакт Статус Решение Приоритет Стратегия тестирования Нет Надо Средний написать Тест план Есть ОК Тест кейсы Нет ОК Чек листы Есть ОК Приемочные тесты Есть ОК Тестовые данные Есть ОК Матрица покрытия Есть ОК требований тестами Программа и методика Нет Надо Высокий испытаний написать Баг репорты Есть ОК