Тестирование - это процесс, он не стоит на месте, а нуждается в непрерывном улучшении. Мы приходим к ним на ретроспективах, из собственного и чужого опыта и ошибок, интуитивно или на основании некоторых данных. В своем докладе я расскажу, как провести оценку процесса тестирования на проекте: с чего начать, на что обратить внимание, поделюсь практическим опытом и отвечу на ваши вопросы. До встречи на докладе!

1. Как оценить процесс
тестирования на проекте
Андрей Ладутько

2. Andrey Ladutko Minsk, Belarus
QA Lead, QA Trainer
9+ years experience
Testing processes, test design, personal
effectiveness
SQA Days Program Committee member
ISTQB Full Advanced Level
ladutko_andrey@tut.by, andrey.ladutko@pandadoc.com
ladutko_andrey
sof_minsk
http://qastugama.blogspot.comp://qastugama.blogspot.
com

3. План доклада
• Теория
o Аудит 1.0 и 2.0
o Цели аудита
o Модели аудита
o Процесс аудита
• Практика
o Примеры запросов
o Примеры анализа

4. Аудит 1.0
Независимая оценка программных продуктов или процессов с целью проверки
соблюдения стандартов, руководств, спецификаций и / или процедур,
основанных на объективных критериях, в том числе документов, которые
определяют:
(1) Форму или содержание
производимых продуктов
(2) Процесс разработки
продуктов
(3) Соответствие стандарту и
то, как оно измеряется
IEEE 1028

5. Аудит 2.0
• Тестирование – как зеркало отражает все проблемы
• Вместо проверки по чек-листам, ищет наиболее эффективное
решение конкретной проблемы
• Покрывает весь жизненный цикл процесса, чтобы найти и
исправить реальную причину
• Использует факты, дает прозрачность «сверху вниз», не «shift to
green»

6. Цель аудита 2.0
• Не стандартизация процесса, а нанесение непоправимой пользы
• Выяснить, что болит сильнее
• Определить, что хотим оптимизировать
• Избегать категоричных оценок (разобраться с контекстом,
первичная причина может оказаться не главной)

7. Почему не внутренний аудит
Искажение Мало опыта Еще ресурсы!

8. Почему люди ошибаются
Врут Заблуждаются
Не владеют
информацией

9. Модели аудита
TMMI – Test Maturity Model Integration

10. Модели аудита
TPI Next– Test Process Improvement

11. Треугольник качества

12. Что изучаем во время аудита
• Требования
• Тест-план
• Тест-кейсы
• Отчеты
• Архитектура и код автотестов
• Метрики и KPI (Ключевые показатели
эффективности)
• Тестирование
• Управление проектами
• Управление требованиями
• Разработка
• Управление конфигурациями
• Развертывание сборки
ПРОЦЕССЫ АРТЕФАКТЫ & СТАТИСТИКА

13. Процессы: инициация
Инициация
План встреч
Анализ
Гипотеза
Встречи
Отчет
• Понять цель аудита – не запрос, а причину запроса
• Интервью с ключевыми лицами
• Определить планы и сроки аудита
• Запросить артефакты (план тестирования, проектный план, экспорт дефектов,
тест-кейсы, отчеты, логи времени, …)

14. ВАЖНО! Заручиться поддержкой

15. План встреч
Инициация
План встреч
Анализ
Гипотеза
Встречи
Отчет
• Кого интервьюируем: менеджера проекта, тест-лида, тестировщика (желательно
для каждого из подпроектов)
• Агенда:
– Процесс тестирования от начала до конца
– Итерации /фазы тестирования
– Рутина – кандидаты на автоматизацию
– Регрессия
– …

16. Анализ
Инициация
План встреч
Анализ
Гипотеза
Встречи
Отчет

17. Анализ - важно
Instead of studying and learning from every bug, you can save a lot of time by counting
and aggregating bug reports.
That’s a good thing in its way, because if you don’t study and learn from every bug,
you’ll need all the time you can get to deal with problems that seem to keep happening
over and over again.
Michael Bolton, “Very short blog post” №27
Инициация
План встреч
Анализ
Гипотеза
Встречи
Отчет

18. Гипотеза
Инициация
План встреч
Анализ
Гипотеза
Встречи
Отчет

19. Повторные встречи
Инициация
План встреч
Анализ
Гипотеза
Встречи
Отчет

20. Снова к анализу
Инициация
План встреч
Анализ
Гипотеза
Встречи
Отчет

21. Отчет
Инициация
План встреч
Анализ
Гипотеза
Встречи
Отчет

22. Отчет
Инициация
План встреч
Анализ
Гипотеза
Встречи
Отчет
•Обнаружение
•Рекомендация
•Результат

23. Анализируем запросы

24. 1. Тестирования с нуля
• Нужно: тест-лид или тест-менеджер, который установит процесс
• Не нужно: аудит
«У НАС ЕСТЬ ПРОЦЕСС, НО НЕТ ТЕСТИРОВАНИЯ»

25. 2. Нам нужна автоматизация
«МЫ НЕ УСПЕВАЕМ ВСЕ ТЕСТИРОВАТЬ ВРУЧНУЮ, ПОЭТОМУ НАМ НУЖНЫ АВТОТЕСТЫ»
ПОНЯТЬ, КАКАЯ
АВТОМАТИЗАЦИЯ НУЖНА
ПОСЧИТАТЬ ROI
ПЛАНИРУЕМОЙ
АВТОМАТИЗАЦИИ
НАВЕСТИ ПОРЯДОК В
РУЧНОМ ТЕСТИРОВАНИИ

26. 3. У нас все по процессам
ЕСТЬ ПРОЦЕСС, ЧТО-ТО БОЛИТ, НО НЕПОНЯТНО ЧТО, ГДЕ И КАК

27. 4. Очень большая регрессия
• Ввести тестирование основанное на рисках (Risk-Based)
• Исследовать влияние изменений (Impact Analysis)
• Мини-регрессии (если процесс итеративный)
• Оптимизировать тест-кейсы
• Кандидаты на автоматизацию
«У НАС РЕГРЕССИЯ ЗАНИМАЕТ 2 НЕДЕЛИ И КАЖДЫЕ 3 МЕСЯЦА ОНА УДВАИВАЕТСЯ»

28. Анализируем артефакты

29. Пример 1. Приоритеты и статус
Row Labels Cancelled Verified Resolved Open Grand Total
None 9 1 2 13 25
P0 1 1 2
P1 2 16 12 30
P2 15 24 2 63 104
P3 4 52 1 70 127
P4 3 3
Grand Total 31 93 5 152 281
ТАБЛИЦА БАГОВ: PRIORITY VS STATUS

30. Пример 2. Лучший охотник за дефектами
Row Labels Cancelled Verified Resolved Open Grand Total
Алекс 1 45 58 104
Борис 14 1 68 73
Влад 17 1 38 56
Григорий 1 11 15 27
Денис 6 6
Елена 1 4 5
Total 16 74 2 179 271
ТАБЛИЦА БАГОВ: REPORTER

31. Пример 2. Лучший охотник за дефектами
Row Labels Cancelled Verified Resolved Open Grand Total
Алекс 1 45 58 104
Борис 14 1 68 73
Влад 17 1 38 56
Григорий 1 11 15 27
Денис 6 6
Елена 1 4 5
Total 16 74 2 179 271
ТАБЛИЦА БАГОВ: REPORTER
• Борис работает на проекте «part-time» (20 часов в неделю)
• Елена пишет тест-кейсы и не участвует в прогоне тестов
• Денис– заказчик
• Григорий - автоматизатор

32. Пример 3. Дефекты за неделю
Row Labels Антон Сергей Наталья Ольга Grand Total
11/25/2014 - 12/1/2014 3 6 11 20
12/2/2014 - 12/8/2014 4 5 16 25
12/9/2014 - 12/15/2014 11 1 6 18
12/16/2014 - 12/22/2014 8 6 26 28 68
12/23/2014 - 12/29/2014 14 14
1/6/2015 - 1/12/2015 6 9 4 23 42
1/13/2015 - 1/19/2015 4 1 10 16 31
1/20/2015 - 1/26/2015 3 1 4
Grand Total 50 19 53 100 222
ТАБЛИЦА БАГОВ: REPORTER VS PERIOD

33. Пример 4. Платформы.
Row Labels Critical Major Minor Grand Total
Android 15 23 38
iOS 3 26 81 110
iOS - iPhone 5 1 1
iOS - iPhone 5C 4 2 6
iOS - iPhone 5S 1 1
Windows Mobile 101 101
Grand Total 3 45 209 257
ТАБЛИЦА БАГОВ: CONFIGURATIONS VS PRIORITIES

34. Пример 5. Отклоненные дефекты
Reject Reason Count
Already Fixed 4
Duplicate 10
Not Reproducible 8
Testing Error 2
Will not fix 9
Works as Designed 10
Grand Total 43 (from 250)
ТАБЛИЦА БАГОВ: CONFIGURATIONS VS PRIORITIES
Reject Ratio = Total Rejected / Total
Reject Ratio = 43 / 250 * 100% = 17.2%
Normal ≤10%

35. Выводы
• Благодаря аудиту мы не проверяем на соответствие стандартам,
но и делаем процесс тестирования эффективнее
• Изучайте контекст, от этого зависит эффективность рекомендаций
и следовательно аудита
• Чем сложнее проект, тем интереснее (искать, что не работает,
смотреть на работающие best practices)

36. СПАСИБО ЗА ВНИМАНИЕ!
ВОПРОСЫ?
ladutko_andrey@tut.by, andrey.ladutko@pandadoc.com
ladutko_andrey
sof_minsk
http://qastugama.blogspot.comp://qastugama.blogspot.
com