1. СОЗДАНИЕ СТРАТЕГИИ ТЕСТИРОВАНИЯ НА ОСНОВЕ АНАЛИЗА ТЗ ПО ГОСТ 19/34
2. КОРОТКО ОБО МНЕ
3. ПОСТАНОВКА ЗАДАЧИ: формализовать требования и разработать тест-план и тестовую стратегию ДЛЯ существующей системы по готовому ТЗ, которое писал другой Исполнитель
4. ПОДЗАДАЧИ
5. СТАНДАРТЫ
6. КАК ВЫГЛЯДИТ ТЗ ПО ГОСТ
7. ОСОБЕННОСТИ ТЗ ПО ГОСТ
8. ХАРАКТЕРИСТИКИ ХОРОШЕГО ТРЕБОВАНИЯ
9. ПРИМЕР ТЗ
10. АНАЛИЗ ТЗ
11. АНАЛИЗ ТЗ
12. РЕЗУЛЬТАТ АНАЛИЗА
13. РЕЗУЛЬТАТ АНАЛИЗА
14. РЕЗУЛЬТАТ АНАЛИЗА
15. НА ЧТО ОБРАТИТЬ ВНИМАНИЕ!
16. СОЗДАНИЕ ТЕСТОВОГО ПОКРЫТИЯ
17. СТРАТЕГИЯ ТЕСТИРОВАНИЯ
18. СПАСИБО ЗА ВНИМАНИЕ!
19. КОНТАКТЫ ДЛЯ СВЯЗИ
20. ВОПРОСЫ
КГТУ Лекция 2: Обеспечение Качества Программного ОбеспеченияIosif Itkin
КГТУ - Костромской Государственный Технологический Университет
Курс Лекций:
Обеспечение Качества Программного Обеспечения
Лекция 2: Жизненный цикл ПО и технологические основы биржевой торговли
Максим Рудовский, Инновационные Трейдинговые Системы
Иосиф Иткин, Exactpro Systems
КГТУ Лекция 2: Обеспечение Качества Программного ОбеспеченияIosif Itkin
КГТУ - Костромской Государственный Технологический Университет
Курс Лекций:
Обеспечение Качества Программного Обеспечения
Лекция 2: Жизненный цикл ПО и технологические основы биржевой торговли
Максим Рудовский, Инновационные Трейдинговые Системы
Иосиф Иткин, Exactpro Systems
Эффективное объектно-ориентированное проектирование и структурное качество пр...LuxoftTraining
Алексей Петров, консультант Luxoft Training в области анализа и моделирования бизнес-процессов и проектирования баз данных, представил доклад «Эффективное объектно-ориентированное проектирование и структурное качество приложений» на Stratoplan TECH&BUSINESS Summit 2013.
В своем выступлении Алексей ответил на ряд важных вопросов:
- Что такое «структурное качество приложения»?
- Что такое «антишаблоны», и какой вред они могут нанести коду?
- Как соотносятся фундаментальные и канонические шаблоны ОО-проектирования и показатели структурного качества?
- Какую помощь в обеспечении качества приложения могут оказать современные языки ОО-программирования?
- Какие организационные мероприятия могут помочь в обеспечении структурного качества в условиях промышленной разработки?
- Реально ли повысить структурное качество уже написанного приложения?
Тезисы доклада:
«Значимой актуальной тенденцией в инженерии ПО является переход от обеспечения качества приложения путем всестороннего тестирования по завершении основной фазы его кодирования к обеспечению качества на всех этапах жизненного цикла разработки ПО. Кроме того, само понятие качества трактуется все более широко и в соответствии с общепринятыми стандартами (напр., ISO/IEC 9126) охватывает на сегодняшний день такие понятия, как безопасность, надежность, масштабируемость, удобство сопровождения.
Сформулировать соответствующие метрики качества нетрудно, гораздо труднее — добиться заданных показателей. И основную роль в этом играют не программисты, которые «изготавливают» исходный или объектный код, а аналитики и архитекторы, которые проектируют будущие артефакты с учетом оп
2. КОРОТКО ОБО МНЕ
Общий опыт в тестировании – более 6 лет
Успела поработать:
Тестировщиком в небольших инженерных
и студенческих проектах
«Старшим» в проекте для Boeing в Luxoft
Начальником отдела тестирования в
Бинбанке
Состояла на госслужбе в Федеральном
казначействе
Сейчас Руководитель Департамента
обеспечения контроля качества в Helios
Information Technologies
3. «Вводные»:
Готовые документы
Тяжелый язык описания (как для
гос.органов)
ТЗ по ГОСТ серии 19/34
«Доступ» к
аналитику/разработчику/бизнес-заказчику
ограничен
Нет простых и понятных схем
Есть тестовый экземпляр системы
ПОСТАНОВКА ЗАДАЧИ:
ФОРМАЛИЗОВАТЬ ТРЕБОВАНИЯ И
РАЗРАБОТАТЬ ТЕСТ-ПЛАН И
ТЕСТОВУЮ СТРАТЕГИЮ ДЛЯ
СУЩЕСТВУЮЩЕЙ СИСТЕМЫ ПО
ГОТОВОМУ ТЗ, КОТОРОЕ ПИСАЛ
ДРУГОЙ ИСПОЛНИТЕЛЬ
4. ПОДЗАДАЧИ
• Анализ ТЗ. Как составлять
требования?
• Как создавать тест-план/стратегию
тестирования на основе ТЗ?
• Как создавать тестовое покрытие?
5. СТАНДАРТЫ
ГОСТ 19.201-78. Единая система программной
документации. Техническое задание. Требования к
содержанию и оформлению
Кратко изложено содержание ТЗ
Кратко указаны требования к содержанию основных разделов
ГОСТ 34.602-89. Информационная технология.
Комплекс стандартов на автоматизированные системы.
Техническое задание на создание автоматизированной
системы.
Подробно изложены состав и содержание ТЗ
Приведен Порядок разработки, согласования и утверждения ТЗ
Шаблоны титульных листов и листов согласования
6. КАК ВЫГЛЯДИТ ТЗ ПО ГОСТ
Основные разделы:
1. Общие сведения
2. Назначение и цели создания системы
3. Характеристика объекта автоматизации
Краткие сведения об объекте автоматизации;
Сведения об условиях эксплуатации АС и
характеристиках ИТ-ландшафта.
4. Требования к системе
Требования к системе в целом;
Требования к функциям (задачам);
Требования к видам обеспечения.
5. Состав и содержание работ по созданию системы
6. Порядок контроля и приемки системы
7. Требования к документированию
7. ОСОБЕНОСТИ ТЗ ПО ГОСТ
• Отвечает на основные вопросы: КТО?
ЧТО? КОГДА? ЗАЧЕМ? КАК?
• Описывает порядок сдачи! ≈
тестирование
• Структура!
• Содержит перечень оснований для
изменений (письма, ID изменений,
НПА, ссылки)
• Описание системы (функции)
• Нефункциональные требования?
• Трассировка (связь между)
требованиями?
8. ХАРАКТЕРИСТИКИ ХОРОШЕГО ТРЕБОВАНИЯ
Недвусмысленность
Тестируемость (возможность проверки)
Правдоподобность (реальность, выполнимость)
Ясность (краткость, сжатость, простота, точность)
Независимость
Элементарность
Корректность
Необходимость
Понятность
Независимость от реализации (абстрактность)
9. ПРИМЕР ТЗ
«Обособленное программное обеспечение необходимо установить за
пределами общего контура, исключив взаимодействие с комплексом
основных вычислений, работающим в рамках закрытого доступа, в который
не входит выделенный компонент во избежание обмена данными с ядром
систем обозначенного ПО и для обеспечения корректной работы
распределенного комплекса, за исключением случаев предусмотренных в п.п.
4.1.2.2.5-4.1.2.2.7»
10. АНАЛИЗ ТЗ
Добиваемся однозначно интерпретируемых, ясных, атомарных требований,
реализация которых проверяема.
Для этого:
1. Определяем назначение, бизнес функции и границ решаемых задач для ПО
(см. раздел 3. Характеристика объекта автоматизации);
2. Выписываем модули, задачи, функции;
3. Создаем структуру системных требований (Ехсеl, графические схемы,
каталоги);
4. Обнаруживаем и разрешаем конфликты между требованиями;
5. Детализируем системные требования для установления программных
требований (в связке с Руководством пользователя);
6. Назначаем приоритет в соответствии с «весом» требования.
11. АНАЛИЗ ТЗ
Классифицируем требования:
• функциональные и нефункциональные
требования
• внутренние (с другими требованиями) или
внешние зависимости
• требования к процессу/продукту
• приоритет требований
• содержание требований в отношении
конкретных подсистем создаваемого
программного обеспечения (модули)
• изменяемость/стабильность требований
12. РЕЗУЛЬТАТ АНАЛИЗА
• Структура (каталоги) для хранения и детализации требований
• Формализованные системные требования с привязкой к
программным требованиям
• База знаний о системе
• «Дырки»:
o конфликты
o не задокументированные требования
o часто меняющийся функционал
• Понимание того, что нужно тестировать!
14. РЕЗУЛЬТАТ АНАЛИЗА
Рабочие смены
Регистрация
сообщения о
прибытии
поезда
Регистрация
товарной
партии
Внесение
информации о
товарах
Контроль
товара
Принятие
решение по
транспортному
средству
Принятие
предварительного
решения
на основе результатов
контроля
Принятие
предварительного
решения
по партии
15. НА ЧТО ОБРАТИТЬ
ВНИМАНИЕ!
1. Утвердить структуру каталогов хранения требований
2. Не забывать про НФТ:
• Отслеживать интеграционные связи
• Требования к разграничению доступа
(матрицы)
• Требования к производительности и нештатным
ситуациям
• Интерфейсы! (2 строчки в ТЗ + Руководство
пользователя)
3. Отрисовывать схемы!
4. Исследовательское тестирование параллельно с
изучением документации
17. СТРАТЕГИЯ ТЕСТИРОВАНИЯ
1. Бизнес процесс
2. Привязка каждого «кубика» из схемы БП
к каталогу требований
3. Перечень проверок по каждому блоку с
привязкой к атомарным требованиям
4. «Одно требование – один тест-кейс!»
5. Связь требование-тест-кейс через
нумерацию, именование, ссылки,
каталоги