2. Инна Слизовская
Инженер по автоматизации тестирования
Управление
тестированием

3. Содержание
• Этапы тестирования
• Результаты тестирования
• Работа с рисками

4. Этапы тестирования
Тестирование
программного продукта
Проектирование тестов
Анализ требований
Планирование
процесса тестирования
Изучение информации о системе. Получение и анализ
данных для составления плана тестирования
Определение объемов тестирования,
подходов, ресурсов и календарного плана
Определение цели тестирования,
входных данных, архитектуры тестов

5. Этапы тестирования (продолж.)
Отладка тестов
Выполнение
тестов (testing cycles)
Интеграционное
системное тестирование
(System Integration Testing)
Приемочные испытания
(Acceptance Testing)
Эксплуатация и
поддержка
Непосредственная проверка тестов,
анализ всевозможных тестовых случаев
Функциональная проверка, тестирование
интеграции систем и модулей для
определения рабочих характеристик
Альфа-тестирование,
Бета-тестирование
Проверка результатов,
исправление дефектов
Пересмотр и отладка тестовых случаев

6. Планирование тестирования
• объем работ
• сроки выполнения
• подходы к решению задач
• команда
• календарный план

7. Цели плана тестирования
• Определить объекты тестирования
• Проанализировать архитектуру системы на
полноту и тестопригодность
• Создать перечень инструментов и ресурсов,
используемых в проекте
• Перечислить список отчётных документов

8. Основные разделы плана тестирования
• Введение
• Тестовые требования
• Стратегия тестирования
• Материалы, подлежащие сдаче
• Расписание

9. Стратегия тестирования
• Типы тестирования
Тестирование бизнес-циклов
Тестирование пользовательского интерфейса
Нагрузочное тестирование
Тестирование безопасности
Инсталляционное тестирование
....
• Инструментальные средства
Jira
Crucible
Pytest
…

10. Проектирование тестирования
• Определить и описать тестовые сценарии
• Подготовить анализ рабочей нагрузки
• Определить и структурировать тестовые
процедуры
• Просмотреть и оценить тестовое покрытие

11. Функциональное требование
Значение в поле «Сумма» должно
рассчитываться как сумма значений из
полей «A» и «B».

12. Плохой тест-кейс
...
Действия:
Ввести значения в поля «A» и «B».
Ожидаемый результат:
Значение в поле «Сумма» должно
рассчитываться как сумма значений из
полей «А» и «B».

13. Хороший тест-кейс
...
Действия:
1. В поле «А» ввести значение 2
2. В поле «B» ввести значение 3
3. Нажать на кнопку «Рассчитать»
Ожидаемый результат:
В поле «Сумма» отобразилось значение 5

14. Содержание тест-кейса
• Title/Goal
• PreConditions
• Test Case Description
• Expected Result
• Actual Result

15. Пример 1
• do A1, verify B1
• do A2, verify B2
• do A3, verify B3
Action Expected Result Test Result
(passed/failed/blocked)
PreConditions
do A1 verify B1
do A2 verify B2
Test Case Description
do A3 verify B3

16. Детализация описания тест кейсов
Проверка отображения страницы
Действие Ожидаемый результат Результат теста
Открыть страницу Логин - Окно Логин открыто
- Название окна - Логин
- Логотип компании
отображается в правом
верхнем углу
- На форме 2 поля - Имя
и Пароль
- Кнопка Логин доступна
- Линк забыл пароль -
доступен
...
Пример 2.1

17. Детализация описания тест кейсов.
Пример 2.2
Название: Проверка отображения
страницы
Действие: Открыть страницу Логин
Проверка: Проверьте, что отображаемая
страница соответствует странице на
картинке 1 (и прилагаем screenshot
страницы Логин)

18. Структура тест-кейса
• Тест-кейсы необходимо писать по
требованиям
• Тест-кейсы должны не повторять требования,
а проверять их
• Один тест-кейс - одна проверка
• Не зависящие от данных, ситуаций и объектов
Action > Expected Result > Actual Result

19. Выполнение тестирования
• Выполнить тестовые процедуры
• Оценить выполнение тестирования
• Исправить провалившиеся тесты
• Исправить, если нужно, тестовые процедуры
• Проверить результаты
• Проанализировать неожиданные результаты
• Занести дефекты

20. % тестирования продукта
Сколько тестовых сценариев прошло хотя бы раз?
Сколько тестовых сценариев еще ни разу не
запускалось?
0
20
40
60
80
100
120
week1 week2 week3 week4
executed not exec'd
Известное качество
Неизвестное качество

21. Работа с дефектами
Баг / ошибка / дефект / неисправность
1. Известен ожидаемый результат;
2. Известен фактический результат;
3. Известно, что результат из пункта 2 не равен
результату из пункта 1.

23. Важность и Приоритет Ошибки
Важность (Severity) – это атрибут,
характеризующий влияние бага на
работоспособность приложения.
Blocker –> Critical -> Major -> Minor ->Trivial
Приоритет (Priority) – это атрибут,
указывающий на очередность выполнения
задачи или устранения бага.
High -> Medium -> Low
Priority = Impact + Users portion + Stability

24. Типичные проблемы отчетов об ошибках
• Тестирование устаревшего билда
• Изобретение собственных требований
• Использование нечетких формулировок
• Попытка определить причину ошибки
• Завышение приоритета ошибки
• Самовольное сужение тестового покрытия

25. Оценка тестирования
• Оценить покрытие функциональности
тестовыми сценариями
• Оценить покрытие кода
• Проанализировать дефекты
• Определить, были ли достигнуты критерии
завершенности и успешности тестирования

26. Ключевые метрики тестирования ПО
• Метрики покрытия (Coverage Measures)
 Тестовое покрытие, основанное на покрытии
требований (Requirements-based Test Coverage)
 Тестовое покрытие, основанное на покрытии кода
приложения (Code-based Test Coverage)
• Метрики достигнутого качества (Measuring Perceived
Quality)
• Отчеты, основанные на ошибках (Defect Reports)
• Метрики производительности (Performance Measures)

27. Отчеты, основанные на ошибках
(Defect Reports)
Плотность ошибок

28. Отчеты, основанные на ошибках
(Defect Reports)
Изменение количества ошибок (Defect
Trend Reports)

29. Отчеты, основанные на ошибках
(Defect Reports)
Дефекты, предсказанные, найденные, закрытые
0
100
200
300
400
500
600
wk1 wk2 wk3 wk4 wk5 wk6 wk7 wk8
predicted found closed
Все дефекты
закрыты но не все
найдены

30. Отчеты, основанные на ошибках
(Defect Reports)
Доля отклоненных дефектов
Declined defects ratio
0,0%
5,0%
10,0%
15,0%
Actual Threshold

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

32. Оценка рисков
0,1 0,3 0,5 0,7 0,9
1 0,1 0,3 0,5 0,7 0,9
2 0,2 0,6 1 1,4 1,8
3 0,3 0,9 1,5 2,1 2,7
4 0,4 1,2 2 2,8 3,6
5 0,5 1,5 2,5 3,5 4,5

33. Реакция на риски
• Избежание (Avoid) – не делать то, что может привести
к возникновению риска
• Смягчение, сокращение (Mitigate) – проведение
мероприятий по сокращению влияния риска
• Принятие, удержание (Accept) – сохранение
ответственности за риск
• Передача (Transfer) – перевод ответственности за
риск другой стороне

34. Типичные риски
…
• Планирование
• Неправильное определение границ
работ
• Неправильный выбор архитектуры
• Неправильная оценка ресурсов
• Организационные
• Частое и противоречивое изменение
требований заказчиком
• Текучесть кадров

35. Принципы тестирования
• Каждый тест должен быть связан с
требованием
Каждое требование тестируемо и имеет тест
• Тестирование проводится планово
• Принцип Парето 20/80
Все проверить нельзя
• Начинать с малого и наращивать
Взаимосвязь с другими тестами
• Независимо от разработчиков
• Не забыть о «подразумевающихся» и не
функциональных требованиях

36. Q & A