СОЗДАНИЕ СТРАТЕГИИ
ТЕСТИРОВАНИЯ НА ОСНОВЕ АНАЛИЗА ТЗ
ПО ГОСТ 19/34
Варфоломеева Александра
КОРОТКО ОБО МНЕ Общий опыт в тестировании – более 6 лет
Успела поработать:
Тестировщиком в небольших инженерных и студенческих проектах
«Старшим» в проекте для Boeing в Luxoft
Начальником отдела тестирования в Бинбанке
Состояла на госслужбе в Федеральном казначействе
Сейчас Руководитель Департамента обеспечения контроля качества в Helios Information Technologies
«Вводные»:
Готовые документы
Тяжелый язык описания (как для гос.органов)
ТЗ по ГОСТ серии 19/34
«Доступ» к аналитику/разработчику/бизнес-заказчику ограничен
Нет простых и понятных схем
Есть тестовый экземпляр системы
ПОСТАНОВКА ЗАДАЧИ: ФОРМАЛИЗОВАТЬ ТРЕБОВАНИЯ И РАЗРАБОТАТЬ ТЕСТ-ПЛАН И ТЕСТОВУЮ СТРАТЕГИЮ ДЛЯ СУЩЕСТВУЮЩЕЙ СИСТЕМЫ ПО ГОТОВОМУ ТЗ, КОТОРОЕ ПИСАЛ ДРУГОЙ ИСПОЛНИТЕЛЬ
ПОДЗАДАЧИ
• Анализ ТЗ. Как составлять требования?
• Как создавать тест-план/стратегию тестирования на основе ТЗ?
• Как создавать тестовое покрытие?
СТАНДАРТЫ ГОСТ 19.201-78. Единая система
программной документации. Техническое задание. Требования к содержанию и оформлению
Кратко изложено содержание ТЗ Кратко указаны требования к содержанию основных разделов
ГОСТ 34.602-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.
Подробно изложены состав и содержание ТЗ Приведен Порядок разработки, согласования и утверждения ТЗ Шаблоны титульных листов и листов согласования
КАК ВЫГЛЯДИТ ТЗ ПО ГОСТ
Основные разделы:1. Общие сведения
2. Назначение и цели создания системы
3. Характеристика объекта автоматизации
Краткие сведения об объекте автоматизации;
Сведения об условиях эксплуатации АС и
характеристиках ИТ-ландшафта.
4. Требования к системе
Требования к системе в целом;
Требования к функциям (задачам);
Требования к видам обеспечения.
5. Состав и содержание работ по созданию системы
6. Порядок контроля и приемки системы
7. Требования к документированию
ОСОБЕНОСТИ ТЗ ПО ГОСТ• Отвечает на основные
вопросы: КТО? ЧТО? КОГДА? ЗАЧЕМ? КАК?
• Описывает порядок сдачи! ≈ тестирование
• Структура!
• Содержит перечень оснований для изменений (письма, ID изменений, НПА, ссылки)
• Описание системы (функции)
• Нефункциональные требования?
• Трассировка (связь между) требованиями?
ХАРАКТЕРИСТИКИ ХОРОШЕГО ТРЕБОВАНИЯ
НедвусмысленностьТестируемость (возможность проверки)Правдоподобность (реальность, выполнимость)Ясность (краткость, сжатость, простота, точность)НезависимостьЭлементарностьКорректность НеобходимостьПонятностьНезависимость от реализации (абстрактность)
ПРИМЕР ТЗ
«Обособленное программное обеспечение необходимо установить за пределами общего контура, исключив взаимодействие с комплексом основных вычислений, работающим в рамках закрытого доступа, в который не входит выделенный компонент во избежание обмена данными с ядром систем обозначенного ПО и для обеспечения корректной работы распределенного комплекса, за исключением случаев предусмотренных в п.п. 4.1.2.2.5-4.1.2.2.7»
АНАЛИЗ ТЗДобиваемся однозначно интерпретируемых, ясных, атомарных требований, реализация которых проверяема.
Для этого:1. Определяем назначение, бизнес функции и границ
решаемых задач для ПО (см. раздел 3. Характеристика объекта автоматизации);
2. Выписываем модули, задачи, функции; 3. Создаем структуру системных требований (Ехсеl,
графические схемы, каталоги);4. Обнаруживаем и разрешаем конфликты между
требованиями;5. Детализируем системные требования для установления
программных требований (в связке с Руководством пользователя);
6. Назначаем приоритет в соответствии с «весом» требования.
АНАЛИЗ ТЗ
Классифицируем требования:
• функциональные и нефункциональные требования
• внутренние (с другими требованиями) или внешние зависимости
• требования к процессу/продукту
• приоритет требований
• содержание требований в отношении конкретных подсистем создаваемого программного обеспечения (модули)
• изменяемость/стабильность требований
РЕЗУЛЬТАТ АНАЛИЗА•Структура (каталоги) для хранения и детализации
требований
•Формализованные системные требования с привязкой к программным требованиям
•База знаний о системе
•«Дырки»: o конфликтыo не задокументированные требованияo часто меняющийся функционал
• Понимание того, что нужно тестировать!
РЕЗУЛЬТАТ АНАЛИЗА
РЕЗУЛЬТАТ АНАЛИЗА
Рабочие смены
Регистрация сообщения о
прибытии поезда
Регистрация товарной
партии
Внесение информации о
товарах
Контроль товара
Принятие решение по
транспортному средству
Принятие предварительного
решения на основе результатов
контроля
Принятие предварительного
решения по партии
НА ЧТО ОБРАТИТЬ ВНИМАНИЕ!
1. Утвердить структуру каталогов хранения требований
2. Не забывать про НФТ:
•Отслеживать интеграционные связи
•Требования к разграничению доступа (матрицы)
•Требования к производительности и нештатным ситуациям
•Интерфейсы! (2 строчки в ТЗ + Руководство пользователя)
3. Отрисовывать схемы!
4. Исследовательское тестирование параллельно с изучением документации
СОЗДАНИЕ ТЕСТОВОГО ПОКРЫТИЯ
• Творческий процесс
• Декомпозиция• Модульность• Связи с
требованиями
СТРАТЕГИЯ ТЕСТИРОВАНИЯ
1. Бизнес процесс
2. Привязка каждого «кубика» из схемы БП к каталогу требований
3. Перечень проверок по каждому блоку с привязкой к атомарным требованиям
4. «Одно требование – один тест-кейс!»
5. Связь требование-тест-кейс через нумерацию, именование, ссылки, каталоги
СПАСИБО ЗА ВНИМАНИЕ!
КОНТАКТЫ ДЛЯ СВЯЗИПочта:
Соц. сети:
https://www.facebook.com/alexandra.varfolomeeva.50
http://ru.linkedin.com/pub/alexandra-
varfolomeeva/3a/610/546/
Skype: redaap88
ВОПРОСЫ
Recommended
