Законы создания IT команд и следствия законов для IT проектов «на пальцах»
Как развить отдел тестирования от палки-копалки до CI
1. 12th CENTRAL & EASTERN EUROPEAN
SOFTWARE ENGINEERING CONFERENCE IN RUSSIA
October 28 - 29, Moscow
Taya Rybak
Как развить отдел тестирования от палки копалки доCI
Organization name or logo
2. О себе
Опыт работы в этой сфере: Более 12 лет.
Прошла путь от инженера по ручному тестированию до
руководителя.
Занимала должность директора по развитию бизнеса в
Hewlett – Packard по Центральной и Восточной Европе .
Занималась ручным, автоматизированным функциональным и
нагрузочным тестированем билинговых систем, банковких
систем и хранилищ данных.
На данный момент работаю консультантом и
специализируюсь на постановке и аудите процессов
разработки ПО
Веду тренинги по тестированию
10. 1.
начальный
Каждый релиз – уникальный процесс
Нет общих политик управления тестированием
Качество сильно варьируется от релиза к релизу
Нет инструментов поддержки тестирования
Конечный пользователь в качестве тестироващика
Цель тестирования показать, что ПО в принципе работает
11. 2.
управляемый
Описаны политики тестирования
Используются точечные инструменты тестирования
Есть выделенные роли тестировщиков
Стабильное качество для проектов одинакового размера и
уровня сложности
Точечная автоматизация тестирования
Цель тестирования- показать что приложение соответствует
требованиям в рамках одного проекта
12. 3.
определенный
Ход реализации проекта измеряется по KPI
Повторное использование артефактов проекта
Частичная интеграция инструментов тестирования
Стабильное качество для проектов разного размера
Выделение подразделения тестирования
Регулярная автоматизация
Подсчет ROI
Цель тестирования- показать что приложение соответствует
требованиям в рамках всей организации
13. 4.
управляемый на
основе
количественных
данных
Расширение KPI и их постоянный мониторинг
Прослеживаемость требований
Интеграция инструментов поддерживающих процесс
Изменения в процесс вносятся на основании ROI
Высокий уровень покрытия автотестами
Выделяется в подразделении тестирования подразделение
автоматизации тестирования
Выделяется подразделение по контролю качества процессов
производства ПО
Цель тестирования – оценка уровня тестирования по KPI
14. Основные KPI
вСI для
тестирования
Количество найденных дефектов в продуктиве пользователями
Время на тестирование/количество дефектов Urgent High
Количество сбоев в автотестах
Время на доработку автотестов
15. 5.
оптимизируемый
Процесс тестирования интегрирован в IT сервисы
Непрерывная разработки приложений
Постоянный мониторинг по качеству процессов IT
Процесс DevOps
Предотвратить дефекты
16. Если процессы выстроены разово – они не будут жить вечно, их
нужно поддерживать.Упс, и
такое
бывает
19. Карта
внедрения
процессов
Карта внедрения процессов
1 2 3 4 5
Непрерывная разработки V
Сервисное и Проектное управление V
DEVOps V
Непрерывное тестирование
BDD V
Нагрузочное тестирование V
Автоматизация функционального
тестирования V
Внедрение KPI по тестированию V
Трассировка требований и тестов V
Управление релизами V
Управление требованиями V
Тестовые сценарии V
Управление дефектами в тестировании V
Управление инцидентами V
21. Фаза 0: Подготовительная
• Версионность
• Хранение исходного кода
• Сервер сборки
• Нужен «обученный» тестировщик
Упс, и
такое
бывает
22. Фаза 1: Развитие тестирования
• Управление требованиями;
• Управление тестированием:
• Создание тестов в виде чек листов
• автоматизация функционального тестирования (Санитарное
тестирование)
• нагрузочное тестирование по 10 операциям;
• Управление запросами на изменение.
23. Фаза 2 :Внедрение
Внедрение тестирования как процесса с повторяемым результатом:
• Проектная команда: 2 человека со стороны Заказчика
• Описание процессов: 3 недели
• Настройка системы: 3 недели
24. Результаты
внедрения
Управление дефектами
– внутренний регламент
– «прозрачный» процесс тестирования
Управление требованиями
– покрытие тестами
– запросы на изменение
Автоматизация тестирования
– сокращение сроков приемки ПО
– раннее обнаружение проблем производительности
25. Фаза 3: Автоматизация тестирования
• Количество тестов: 120
• Временные затраты: 4 недели
• Время на тестирование:
• вручную: 90 минут
• автоматически: 5-10 минут
27. Основные KPI
вСI
Время развертывания (Deployment LeadTime) – время, необходимое
на сборку проекта.
MTTR (MeanTimeTo Repair — среднее время восстановления
работоспособности). Можно измерить время, прошедшее от
сообщения об ошибочной сборке, до исправления.
MTTD (MeanTimeTo Detect – среднее время обнаружения
неисправности). измеряется время, которое прошло от внесения
ошибки, до определения, что возникла проблема и в чем она
заключается.
28. Системы,
которые
позициониру
ются как CI
CruiseControl
CruiseControl.Net
Atlassian Bamboo
Pipeline
Jenkins
MicrosoftTeam Foundation Server
Team City
Git CI
Исходный код и всё, что необходимо для сборки и тестирования проекта, хранится в репозитории системы управления версиями;
Операции копирования из репозитория, сборки и тестирования всего проекта автоматизированы и легко вызываются из внешней программы.
Организация[править | править вики-текст]
На выделенном сервере организуется служба, в задачи которой входят:
получение исходного кода из репозитория;
сборка проекта;
выполнение тестов;
развёртывание готового проекта;
отправка отчетов.
Локальная сборка может осуществляться:
по внешнему запросу,
по расписанию,
по факту обновления репозитория и по другим критериям.
Мем невозможно взять и построить
Добравить слайд с опросом
Разбить на слайды
Требовани это не б ольшой документ, не важно в в каком они виде
5 уровень дорогий и долгий
Добавить временные рамки для переходов с этапа на этап.
Добавить для каких типов компаний.
Есть ли у вас отдельная группа тестировнаия
Есть ли тестовые сценарии
Есть ли система хранения исходного кода
Сервер сбоки
Есть ли требования
Есть ли трассировка и версионность
Примеры KPI добавить к 4 уровню
Если дефектов нет от пользователей, то они и не так важны
Часто слышу автотесте много переделываем, пытались не пошло – это некачественные автотесты!!!
Кино поиск
Impact Mapping
Так бывает
Вопрос: есть ли статистика по сбору инцилентов?
Если интересно посомтрите на Agile Days
Так бывает
Всего 57 модулей больших и маленьких
Добравить слайд с опросом
Разбить на слайды
Требовани это не б ольшой документ, не важно в в каком они виде
5 уровень дорогий и долгий
Добавить временные рамки для переходов с этапа на этап.
Добавить для каких типов компаний.
CALIBER rm mICROfOCUS
VS для Azure
Оповещатся и разработчики и тестировщики
причина сборки — например изменения в репозитории
изменения в исходных кодах — здесь возможны два варианта изменения от последней сборки или от последней успешной сборки
отчеты по статическому анализу кода — все результаты какие есть
лог сборки
лог модульных тестов — какие тесты прошли и, что важнее, какие не прошли
лог регрессионных тестов — аналогично модульным тестам
статистика сборок проекта:
общее число удачных/провальных сборок
распределение удачных/провальных сборок во времени
статистика результатов статического анализа кода
все другие метрики используемые и собираемые в проекте — это поможет менеджеру проекта видеть все и сразу