Quality Assurance vs Quality Control - так в чем же заключается работа специа...COMAQA.BY
Поговорим о том, что такое Quality Assurance и что такое Quality Control. Узнаем в чем заключается принципиальная разница между этими двумя понятиями\подходами. Расскажем как можно и нужно строить карьеру тестировщика. Приведем пример мировой практики от Microsoft.
QA Fest 2015. Владимир Скляр. Организация тестирования встроенных систем в ко...QAFest
Когда наша компания стала поставлять системы на базе ПЛК на рынке атомной энергетики, возник вопрос подтверждения соответствия процессов разработки и тестирования различным стандартам в области безопасности. Мы создали и обучили команду тестировщиков, владеющую практиками статического анализа кода, функционального и структурного тестирования (как для этапа юнит-тестов, так и интеграции), а также симуляции физических сигналов. Вот как мы решили эту непростую задачу.
QA Fest 2015. Алена Черненко-Дыба и Алексей Лупан. Секреты успешного проекта...QAFest
В докладе будут представлены самые важные вопросы, которые должен и может задавать окружающим лидер группы тестировщиков перед началом каждого проекта для того, чтобы проект был успешно запилен.
QA Fest 2016. Андрей Мясников. Тест-дизайн для чайниковQAFest
В своём докладе я расскажу вам о том, кто такие тест-аналитики, тест-дизайнеры и должны ли их роль выполнять обычные тестировщики. Также сделаю обзор основных и проверенных методик тест-дизайна. Расскажу про их плюсы и минусы.
Будем учиться тестировать не 12 часов, а головой!
Quality Assurance vs Quality Control - так в чем же заключается работа специа...COMAQA.BY
Поговорим о том, что такое Quality Assurance и что такое Quality Control. Узнаем в чем заключается принципиальная разница между этими двумя понятиями\подходами. Расскажем как можно и нужно строить карьеру тестировщика. Приведем пример мировой практики от Microsoft.
QA Fest 2015. Владимир Скляр. Организация тестирования встроенных систем в ко...QAFest
Когда наша компания стала поставлять системы на базе ПЛК на рынке атомной энергетики, возник вопрос подтверждения соответствия процессов разработки и тестирования различным стандартам в области безопасности. Мы создали и обучили команду тестировщиков, владеющую практиками статического анализа кода, функционального и структурного тестирования (как для этапа юнит-тестов, так и интеграции), а также симуляции физических сигналов. Вот как мы решили эту непростую задачу.
QA Fest 2015. Алена Черненко-Дыба и Алексей Лупан. Секреты успешного проекта...QAFest
В докладе будут представлены самые важные вопросы, которые должен и может задавать окружающим лидер группы тестировщиков перед началом каждого проекта для того, чтобы проект был успешно запилен.
QA Fest 2016. Андрей Мясников. Тест-дизайн для чайниковQAFest
В своём докладе я расскажу вам о том, кто такие тест-аналитики, тест-дизайнеры и должны ли их роль выполнять обычные тестировщики. Также сделаю обзор основных и проверенных методик тест-дизайна. Расскажу про их плюсы и минусы.
Будем учиться тестировать не 12 часов, а головой!
QA Fes 2016. Анастасия Асеева. Роль тестирования в DevopsQAFest
В своем докладе я расскажу, как мы внедряли devops в банке, а конкретнее какую роль в этом процессе сыграло тестирование. Также расскажу с какими проблемами столкнулись, и как мы их устраняли. И да, каких результатов смогли добиться уже через полгода. А самое интересное, покажу как мы смогли добиться того, чтоб у нас pull request долетал до боя за 3 часа со всеми этапами тестирования.
Доклад будет содержать большое количество лайфхаков и обзоров инструментария, который мы использовали.
Практический доклад о том, как мы внедряли devops в банке, а конкретнее какую роль в этом процессе сыграло тестирование.
В докладе рассмотрены основные проблемы, с которыми команда столкнулась при внедрении и способы их устранения.
Продемонстрированы результаты, которых смогли достичь в течении полугода.
Доклад содержит большое количество лайфхаков и обзоров инструментария, который использовался для достижения цели.
Система управления жизненным циклом разработки программного обеспечения Devpr...Evgeny Savitsky
Devprom - российская компания-разработчик инструментов в области управления проектами
Дата образования: июнь 2008
Количество сотрудников: 9 человек
Количество загрузок дистрибутива: 8600
Количество зарегистрированных пользователей: 4800
Цикл выпуска новых версий продукта: 1 месяц
Главный риск не успешности проекта создания автоматизированной системы - это автоматизированная система не будет удовлетворять ожиданиям ее заказчика.
Главные способы сниженя риска неудовлетворенности проектным внедрением заказчиком:
* создание автоматизированной системы по отработанной технологии;
* документирование процесса ее разработки.
Поплоухина Елена, Руководитель отдела тестирования в Usetech
https://vk.com/lena_flower
Расскажу об опыте организации процесса внутреннего тестирования проекта со строго формализованным техническим заданием от момента получения технического задания для тестирования требований до момента передачи релиза на приемочное тестирование.
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. Сформировать
потребности заказчика
Мы хотим:
– …чтобы «старый» функционал не
падал после обновления
– …чтобы можно было независимо
от разработчика проводить
испытания
– …ускорить процесс приемки
– …показать высшему руководству
модель «земли»
– …иметь возможность
смоделировать любой из 500
пунктов пропуска, расположенных
по всей стране
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. Резюме
Работа с государственными органами:
• Очень много «подводных камней»:
– сложившиеся процессы ЖЦ ПО
во многом уникальны;
– привычные для бизнес Заказчиков
практики и подходы требуют
значительной адаптации;
– нужно доказать эффективность
тестирования без функционального заказчика.
• Возможность построить или улучшить
рабочие процессы
• Очень прокачивает коммуникативные
навыки ;)