2. Коротко обо мне
Варфоломеева Александра
• Общий опыт в тестировании – более 6 лет
• Проектная работа
• Специалист по тестированию, ИТП-Град
• Старший специалист-тестировщик в
проектах для Boeing, Luxoft
• Начальник отдела тестирования, Бинбанк
• Консультант в проекте по внедрению
системы контроля качества (HP ALM),
Федеральное казначейство
• Руководитель группы тестирования, Helios
Information Technologies
3. План доклада
• О государственных заказчиках
• 5 причин внимания к качеству в госсекторе
• Общая специфика разработки ПО для
госсектора
• Особенности тестирования ПО в
госсекторе
• Алгоритм ведения проектов по внедрению
тестирования
• Пошаговое описание алгоритма на
конкретном проекте
• Наш опыт, советы и рекомендации
4. О государственных заказчиках
85 субъектов Российской Федерации
600 подразделений
200 приложений
от 30 Исполнителей на разных архитектурных
платформах
40 приложений – критические!
6. Ограничения законодательства
• Гос. органы обеспечивают и отвечают за
сопровождение ПО, но не могут
самостоятельно разрабатывать или
изменять ПО
• Изменение ПО только через
государственный контракт
• Все работы независимые. Комплекс работ
вызывает вопросы у ФАС.
• Нецелевое использование средств:
проверки со стороны Счетной палаты
7. Ресурсы и взаимодействие в
«команде»
• Нет ИТ-специалистов,
только чиновники!
• Отсутствие эффективных
способов взаимодействия
• Команда?! Специалисты
Заказчика не понимают,
зачем и как им говорить с
Исполнителем
8. Высокий уровень бюрократизации
• Политическая расстановка сил: «Кто не с нами – тот
против нас!»
• Тяжелая атмосфера в организации
• Устаревшая нормативная база (ГОСТы 1989 года)
• Мнимая эффективность старого
«стандарта»: «Мы вам заплатили –
делайте качественно! А мы
проверим!»
• Классическое
планирование
малоэффективно
9. Сложность систем в госсекторе
• Огромное
количество систем
• Сложная многоуровневая
интеграция
• «Устаревшие» системы
• Информацию об
архитектуре не
успевают собирать
10. Процесс тестирования в
государственных организациях
• Процедура тестирования?
– Есть у Исполнителя: «Зачем
платить дважды?»
– Тестирования нет ни у
Исполнителя, ни у Заказчика
• ПСИ по ПМИ ≠ Тестирование
– Регрессионное тестирование?
– Тестирование интеграции?
– Нагрузочное тестирование?
• ПМИ готовит Разработчик
11. Процесс тестирования в
государственных организациях
• Требования?
– Нет требований, есть формальное ТЗ
– ТЗ согласуется на «выходе» версии
параллельно с приемкой
– ТЗ описывает только изменения
– Документация хранится в ФАП. Доступ?
• Окружение:
– Нет стендов для испытаний
– Стенд есть, но на нем «пасутся» все
– Актуальный стенд есть, но
«Мы вас туда не пустим!»
12. Процесс тестирования в
государственных организациях
• Дефекты:
– Дефекты с «боя» не тестируются
Заказчиком
– Дефекты при ПСИ регистрируются и
хранятся только на бумаге
– Нет регрессионного тестирования
13. Тестирование для гос. заказчиков
Возможные проблемы для проектов
(резюме):
• Особенности законодательства
• Бюрократизация процессов
• Сложность систем
• Полное отсутствие процесса
тестирования
• Требования для тестирования?
• Окружение для тестирования?
• «Ведение» дефектов?
Решение:
• Решение должно быть уникальным,
адаптированным под конкретного
Заказчика
• Общий алгоритм ведения проектов
15. Проект по обеспечению
контроля качества для ФТС
Стоимость ошибки:
• Урон дипломатическим
отношениям с другими
государствами
• Остановка бюджетных поступлений
по всей стране
• 1 день простоя = >25 млрд. руб.
Обеспечение дохода в федеральный бюджет
ФТС = 4329,88 млрд. руб.
16. Шаг №1. Сформировать
потребности заказчика
Мы хотим:
– …чтобы «старый» функционал не
падал после обновления
– …чтобы можно было независимо
от разработчика проводить
испытания
– …ускорить процесс приемки
– …иметь возможность
смоделировать любой из пунктов
пропуска, расположенных по всей
стране
17. Шаг №2. Идея, стратегия,
этапы проекта -1
Стратегия:
1. Процесс и нормативное обеспечение
(регламенты).
2. Тестовое окружение: стенд.
3. Автоматизация процесса (инструмент).
4. Регрессионное тестирование.
5. Формирование знаний в области
тестирования у Заказчика.
6. Команда тестирования для Заказчика.
Идея: Создание независимой
(самостоятельной) процедуры
тестирования на стороне Заказчика.
18. Шаг №2. Идея, стратегия,
этапы проекта -2
Оценить задачи и провести
пошаговую этапизацию работ.
У каждого этапа должен быть ПОНЯТНЫЙ и конкретно
ПОЛЕЗНЫЙ результат для Заказчика.
Этап 1 – Анализ текущего состояния
и варианты решения (НИР)
Этап 2 – Разработка и внедрение платформы для
тестирования, тестовые модели для
критичных систем
Этап 3 – Проведение регрессионного тестирования
Этап 4 – Тиражирование подхода
19. Шаг №3. Проектирование и
создание прототипа
Прототип:
1. Регламент
2. Стенд (железо и экземпляры
систем)
3. Тестовые модели для
критичных систем
4. Инструменты и система
хранения (автоматизация
процесса – HP ALM)
5. Скрипты (демо)
20. Шаг №4. Внедрение прототипа
• Команда!
• Планирование работ
• Создание покрытия
• Участие в ПСИ
• Вовлечение новых
сотрудников
Заказчика
21. Шаг №5. Контроль
• Регламент закреплен внутренним
приказом
• Создан тестовый стенд с шестью
критичными системами
• Запущена эксплуатация HP ALM
• Покрытие функционала
требованиями с 0% до 40%
• Созданы тестовые модели
(более 3000 тестовых сценариев)
• Автоматизированы основные бизнес
сценарии для регрессионного
тестирования
Результаты внедрения прототипа:
22. Шаг №6. Улучшение
Планы:
1.Проведение регрессионного
тестирования для
проанализированных систем
2.Доработка и оптимизация
скриптов
3.Добавление новых систем в
контур
4.Проведение интеграционного
тестирования
5.Работа с дефектами
23. Наш опыт
Недостижимый результат:
– Осознать и смириться с тем,
что только 20% работы будет
«жить» и приносить пользу
Большие объемы работ в
короткие сроки:
– Выделять людей на
персональные крупные задачи,
выделять «малышей» на
«зачистки»
– Выделять основную цель на
встречах внутри команды
24. Наш опыт
• Работа с документами:
– ГОСТ. Учиться читать «по
диагонали»
– ГОСТ. Проанализировать
основные разделы стандартов
– Вносить предложения для
расширения стандартов
• Терминология и бизнес
процессы:
– Учить новичков с первого дня
– Собирать информацию по
кусочкам
25. Наш опыт
Политические игры:
– Пережидать и быть тактичными
Сложные бюрократизированные
процессы:
– Отрисовывать регламенты в виде
схем
– По кусочкам обсуждать со
специалистами Заказчика
Непринятие новых процессов:
– Обучение Заказчика
– Общение на языке Заказчика
– Учиться слушать и слышать
Заказчика
26. Резюме
Работа с государственными органами:
• Очень много «подводных камней»:
– сложившиеся процессы ЖЦ ПО
во многом уникальны;
– привычные для бизнес Заказчиков
практики и подходы требуют
значительной адаптации;
– нужно доказать эффективность
тестирования без функционального заказчика.
• Возможность построить или улучшить
рабочие процессы
• Очень прокачивает коммуникативные
навыки ;)