Слайд 2
План занятия:
SDLC (Software Development Life Cycle)
Модели жизненного цикла
ПО
Методологии разработки информационных систем
Определение термина «Тестирование ПО» и
определение необходимости тестирования ПО
QA vs QC, Verification vs Validation
Роли и артефакты в проектной команде
Зачем нужны тестировщики на проекте?
Анализ требований к программному обеспечению
Слайд 3
1. SDLC (Software Development Life Cycle)
Software Development Life
Cycle (Жизненный цикл программного обеспечения ПО) — период времени,
который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации
Слайд 4
SDLC (Software Development Life Cycle)
Основные стадии и этапы
создания программного обеспечения:
Разработка концепции к ПО
Формирование требований к ПО
Разработка
Тестирование
Ввод
в эксплуатацию
Сопровождение
Слайд 5
2. Модели жизненного цикла ПО
SDLC Model (Модель
жизненного цикла ПО) - структура, определяющая последовательность выполнения и
взаимосвязи процессов, действий и задач на протяжении жизненного цикла
Примеры:
Каскадная модель
Итеративная модель
Спиральная модель
Слайд 6
Модели жизненного цикла ПО
Где почитать:
Каскадная модель:
http://bit.ly/1vbhYPx
Итеративная модель:
http://bit.ly/1d6KDKE
Спиральная
модель:
http://bit.ly/1ouQpit
Слайд 7
3. Методологии разработки ИС
Методология - учение о
методах, методиках, способах и средствах познания
В то время, как
SDLC относится к стадиям, через которые система проходит, методология является изобретением человечества. Она показывает подход для контроля событий на стадиях SDLC
Методология - это набор шагов, инструкций, действий и принципов, которыми следует пользоваться в той или иной ситуации
Слайд 8
Методологии разработки ИС
Каскадные методологии:
Waterfall: Предусматривает, что каждая
последующая фаза начинается лишь тогда,
когда полностью завершено
выполнение
предыдущей фазы.
Каждая фаза имеет определенные
критерии входа и выхода: входные
и выходные данные.
Слайд 9
Методологии разработки ИС
Каскадные методологии:
V-model: Разновидность каскадной модели.
Каждая
последующая фаза начинается по завершению
получения результативных
данных
предыдущей фазы.
В ней подчеркнуты
взаимосвязи, существующие
между аналитическими фазами
и фазами проектирования,
которые предшествуют
кодированию, после которого
следуют фазы тестирования.
Слайд 10
Методологии разработки ИС
Итерационные методологии:
Agile: это семейство гибких
процессов разработки(SCRUM, Extreme programming, Kanban, etc).
Ценности и принципы
Agile методологии
закреплены в документе ‘Agile
Manifesto’(http://agilemanifesto.org)
Agile-методы делают упор
на непосредственное
общение лицом к лицу.
Основным результатом
работы по agile-методологии
является работающий программный продукт.
Слайд 11
Методологии разработки ИС
Итерационные методологии:
Rational Unified Process (RUP)
— создана компанией Rational Software. Основные принципы RUP:
Ранняя идентификация
и устранение основных рисков.
Концентрация на выполнении требований заказчиков к исполняемой программе
Компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта
Постоянное обеспечение качества на всех этапах разработки проекта (продукта)
Работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам.
Слайд 12
Методологии разработки ИС
Waterfall - есть документация, требования
будут мало меняться, ведётся вся документация, весь процесс разбит
на стадии и рабочие процессы
http://bit.ly/1vbhYPx
Agile - нет документации в формальных документах, часто меняющиеся требования, короткие этапы жизненного цикла
http://bit.ly/18zgT6F
Waterfall vs Agile?
http://bit.ly/1rBa0dR
Слайд 13
4. Определение термина «Тестирование ПО»
Тестирование ПО – это:
1980
- Процесс выполнения программы с намерением найти ошибки
1987 -
Процесс наблюдения за выполнением программы в специальных условиях и вынесения на этой основе оценки каких-либо ее аспектов
1990 - Интеллектуальная дисциплина, имеющая целью получение надежного программного обеспечения без излишних усилий на его проверку
1999 - Техническое исследование программы для получения информации о ее качестве с точки зрения определенного круга заинтересованных лиц
2004 - Проверка соответствия между реальным поведением программы и ее ожидаемым поведением на конечном наборе тестов, выбранном определенным образом
Слайд 14
Определение необходимости тестирования ПО
В процессе тестирования обнаруживаются дефекты
в работе системы.
Анализ найденных дефектов дает возможность оценить
качество программного продукта.
Таким образом руководство проекта получает необходимую информацию о качестве и тем самым уменьшается общий уровень риска в системе.
Слайд 15
5. QA vs QC, Verification vs Validation
QA aims
to prevent defects with a focus on the process
used to make the product. It is a proactive quality process
The goal of QA is to improve development and test processes so that defects do not arise when the product is being developed
Задача QA – предотвратить ошибки в процессе, который используется для построения программного продукта. Это – выбор подходов, методологий, инструментов, команды, построение процессов
Слайд 16
QA vs QC, Verification vs Validation
QC aims to
identify defects in the finished product. Quality control, therefore,
is a reactive process
The goal of QC is to identify defects after a product is developed and before it's released
Задача QС – нахождение ошибок в готовой версии программного продукта до того, как он попадёт к конечному заказчику (исключение – бета – тестирование)
Слайд 17
QA vs QC, Verification vs Validation
QC включает в
себя:
подготовку, анализ и тестирование требований
написание Use Cases в
случае сложных систем и необходимости более широкой детализации требования (варианты использования)
написание Test Сase headers
заполнение Traceability Matrix – покрытие требований тестами
написание Test Сases
планирование выполнения Test Cases
выполнение Test Cases
занесение ошибок в баг – трекинговую систему
повторное тестирование ошибок
повторное прохождение тест кейсов
составление отчёта о тестировании
Слайд 18
QA vs QC, Verification vs Validation
Полный цикл тестирования
включает в себя:
Verification (верификацию) - проверка того, что система
соответствует установленным требованиям («Делаем ли мы продукт правильно?»)
Validation (валидацию) - подтверждение того, что система соответствует ожиданиям заказчика при ее непосредственном применении («Делаем ли мы правильный продукт?»)
Эти два раздела взяты из CMMi - наборa моделей (методологий) совершенствования процессов создания программного обеспечения.
http://ru.wikipedia.org/wiki/CMMI
Слайд 19
6. Роли и артефакты в проектной команде
Project Manager,
PM — это специалист в области управления проектами, который
несет ответственность за планирование, подготовку и исполнение конкретного проекта
Основные артефакты (документы):
PMP – Project Management Plan
WBS – Work Breakdown Structure
Project Status Report
Где почитать и посмотреть:
http://bit.ly/18ZjTwF
Слайд 20
Роли и артефакты в проектной команде
Business Analyst, BA
— это специалист, использующий методы бизнес-анализа для аналитики потребностей
деятельности организаций с целью определения проблем бизнеса и предложения их решения
Основные артефакты (документы):
Functional Requirements or BRS
Technical Requirements
Use Case documents
Где почитать и посмотреть:
http://bit.ly/1vbpHNE
Слайд 21
Роли и артефакты в проектной команде
Software Architect, SA
— это специалист, определяющий начальную структуру системы, основные элементы
системы, их особенности и поведение. Также он представляет точку зрения пользователя на то, какой должны быть система в разрезе основных бизнес сценариев и моделей поведения
Основные артефакты (документы):
SyRS – System Requirements Specification
TD – Technical design
Где почитать и посмотреть:
http://bit.ly/1sxlSOG
Слайд 22
Роли и артефакты в проектной команде
Разработчик (Developer, Dev)
— это специалист, кодирующий функциональности программного продукта на выбранном
языке программирования с использованием технологий, определённых системным архитектором.
Основные технологии:
Java (Джава)
.Net (дот нет)
Основные артефакты (документы):
Все документы с требованиями (all requirements documents – functional, non-functional)
Technical Design
Coding Guidelines
Исходный код программного продукта
Unit tests
Слайд 23
Роли и артефакты в проектной команде
Руководитель группы тестирования
(Test Lead, Test Manager, TL) — это специалист, отвечающий
за внедрение QA и контроль QC активностей на всех этапах разработки программного обеспечения.
Основные артефакты (документы):
Project Management Plan
Test Plan
Traceability Matrix
Testing Schedule
Test Execution Summary Report
Слайд 24
Роли и артефакты в проектной команде
Тестировщик (Software tester)
— это специалист, отвечающий за QC активности.
Основные артефакты
(документы):
All requirement documents
Requirements Check List
Test Plan
Technical Design
Traceability Matrix
Test Cases
Test Scripts
Defects / Enhancements in bug – tracking system
Test Execution Report
Слайд 25
Роли и артефакты в проектной команде
В зависимости от
сложности проекта и квалификации специалиста, тестировщики могут относиться к
различным группам, а именно:
Testers
Test designers
Automation test engineers (http://bit.ly/1k63Q5i)
QA engineers (http://bit.ly/1lEXARO)
Слайд 26
7. Зачем нужны тестировщики на проекте?
Предоставляют заинтересованным сторонам
информацию, достаточную для принятия обоснованного решения о релизе тестируемого
продукта, передаче на следующий этап разработки или в качестве готовой системы пользователям
Должны найти и задокументировать баги до того как их найдут пользователи
«Смотрят на продукт глазами пользователя» и проверяют основные сценарии использования продукта
Обладают знаниями и навыками позволяющими проектировать и выполнять эффективные тесты
Слайд 27
8. Анализ требований к программному обеспечению
Требования – это
функциональная характеристика системы, необходимая заказчику для того, что бы
решить проблему или достигнуть поставленных целей
Требования – это совокупность утверждений относительно атрибутов, свойств или качеств программной системы, подлежащей реализации
Требования – это точно сформулированное описание совокупности полезных для пользователя характеристик, ожидаемых от программного продукта
Где почитать:
http://slidesha.re/1qGyW8O
Слайд 28
Анализ требований к программному обеспечению
Требования принято разделять по
характеру использования
Функциональный характер:
Бизнес – требования
Пользовательские требования
Функциональные требования
Нефункциональный характер:
Бизнес –
правила
Системные требования и ограничения
Атрибуты качества
Внешние системы и интерфейсы
Ограничения
Слайд 29
Анализ требований к программному обеспечению
Зачем и кому нужны
требования?
Developer – согласно требованиям пишется программный код, который реализует
требуемые функциональные и нефункциональные требования
Tester – согласно требованиям пишутся тест кейсы, которые тестируют функциональные и нефункциональные аспекты работы системы
В целом для проекта:
На основании требований определяются трудоёмкость, сроки и стоимость разработки программного продукта
Слайд 30
Анализ требований к программному обеспечению
Как собрать требования:
Интервью, собрания
(meetings, митинги) с представителями заказчика
Мозговой штурм, использование навыков участников
проекта и их опыта
Наблюдение за производственной деятельностью
Анализ нормативной документации
Анализ моделей деятельности
Анализ конкурентных продуктов
Анализ предыдущих версий системы
Слайд 31
Анализ требований к программному обеспечению
Что делать, если нет
требований?
Запросить соответствующий документ
Запросить источник пожеланий заказчика (backlog)
Провести серию встреч
(митингов) для выяснения требований в телефонном режиме, по Skype или организовать Business trip
Предоставление заказчику своего видения (vision) требований
Предоставление нескольких вариантов с плюсами и минусами каждого
Слайд 32
Анализ требований к программному обеспечению
Правила работы команды тестирования:
Каждый
документ должен утверждаться заказчиком – устно или письменно
После каждого
важного митинга должно быть разослано письмо всем участникам с Minutes of Meeting, где кратко описаны основные темы, которые обсуждались, и решения, которые были приняты
Слайд 33
Анализ требований к программному обеспечению
Критерии требований:
Правильность
Полнота
Понятность
Измеримость
Тестируемость
Непротиворечивость
Как проверять требования:
Для
проверки требований используется Check List, где по колонкам отмечены
основные критерии требований, а в столбик выписаны заголовки требований
Слайд 34
Анализ требований к программному обеспечению
Правильность
Каждое требование должно точно
описывать то, что должно быть разработано
Где проверяется?
На прототипе системы
или в документации
Пример:
Веб – сервисы должны реализовывать функционал передачи данных между клиентскими терминалами
Front – End cайта должен уметь регистрировать пользователя и показывать данные о его посещении
Функциональный модуль «Платёжные карты» должен проводить валидацию кредитной карты клиента
Уровень шума при работе стиральной машины в режиме отжима должен составлять 135 миликельвинов
Слайд 35
Анализ требований к программному обеспечению
Полнота
Все требования задокументированы
Каждое требование
содержит всю информацию, необходимую для проектирования, разработки и тестирования
Где
и как проверяется?
На прототипе системы
На созданной модели системы
Путём опроса конечных пользователей и экспертов
Пример:
Система должна уметь решать уравнение ax2+bx+c=0
Back End банковской системы должен автоматически обновлять курс валют каждые 10 минут и обновлять БД
Функциональный модуль «Платёжные карты» должен проводить валидацию кредитной карты клиента
Слайд 36
Анализ требований к программному обеспечению
Понятность
Одинаковая интерпретация требования (недвусмысленность)
Требование описано - четко, просто, кратко
Все специальные термины
описаны и определены
Где и как проверяется?
Вычитываются все требования в функциональной и нефункциональной спецификации
Пример:
Все данные авторизированных пользователей должны отправлять на сервер по защищенному протоколу https
Сайт должен корректно отображаться в поддерживаемых браузерах: IE9, IE10, IE11, Chrome, FireFox, Safari
При регистрации пользователь должен выбрать пол Male/Female выбрав соответствующий radio-button
Слайд 37
Анализ требований к программному обеспечению
Измеримость
Требование должно быть сформулировано
так, что бы можно было доказать соответствие системы предъявленному
требованию
Требование не должно содержать неизмеримых формулировок
Где и как проверяется?
Вычитываются все требования в функциональной и нефункциональной спецификации на предмет присутствия слов, которые не гарантируют измеримость
Пример неизмеримых формулировок:
Легко, лучше чем, более эффективно, качественно, максимально, минимально
Acceptable, adequate, as much as, between, depends on, better, faster, should work fine, where appropriate
Слайд 38
Анализ требований к программному обеспечению
Тестируемость
Требование должно быть сформулировано
так, что бы тестировщик, прочитав его, смог написать тест
кейс, который протестирует данное требование
Где и как проверяется?
Совокупность измеримости и понятности в сочетанием с доступными механизмами проверки
Пример:
Зерно монитора Samsung SyncMaster S27B350 должно составлять 0,23 мм
Слайд 39
Анализ требований к программному обеспечению
Непротиворечивость
Требование не должно
противоречить другим требованиям
Где и как проверяется?
Вычитывание спецификаций
Пример:
Столешница должна быть
прямоугольной формы
Радиус столешницы в зависимости от модели колеблется от 80 см до 1,5 м
Слайд 40
Домашнее задание
NB! Все, кроме перевода с английского на
русский, выполняется на английском языке
Прочитать про модели жизненного цикла
ПО: Каскадные, Итерационные, Спиральная. Проанализировать методологии и описать:
Waterfall & Agile (сравнительная характеристика)
RUP & V-model (сравнительная характеристика)
Спиральная модель (основные принципы, преимущества, недостатки)
Формат - Microsoft Power Point,имя файла – Methodologies_[Name]_[Surname].ppt
Перевести на английский язык слайды 34 – 39 урока №1
Формат - Microsoft Word, имя файла – Slide_Translation_[Name]_[Surname].doc
Слайд 41
Домашнее задание
Прочитать и проанализировать презентацию по тестированию требований
Testing_The_Requirements.pdf, перевести слайды 24 и 25 на русский или
украинский язык
Формат - Microsoft Word, имя файла – Requirements_Slide_Translation_[Name]_[Surname].doc
Перевести на русский или украинский язык http://bit.ly/1oUuY7M
Формат - Microsoft Word, имя файла –Testing_Introduction_Translation_[Name]_[Surname].doc
Сформулировать пример требований для смартфона, которые
Удовлетворяют всем критериям (3 примера)
Не удовлетворяют ни одному из критериев (по примеру на каждое требование)
Формат - Microsoft Excel, имя файла – smartphone_Requirements_[Name]_[Surname].xls
Слайд 42
Домашнее задание
Установить Tortoise SVN (ссылка на скачивание http://bit.ly/1lJZUEw)
Создать
папку c именем “с:\SVN”, в которой будут храниться файлы
из репозитория
Нажать на неё правой кнопкой и выполнить операцию SVN Checkout
Ввести ссылку на репозиторий svn://134.249.184.92/repo/09092014/trunk
При запросе credentials:
Login: user*(в зависимости от присвоенного номера)
Password: 12
Зайти в свою папку (“User*”), создать папку HomeWork1 и скопировать туда пять файлов, которые будут сделаны в процессе выполнения домашнего задания
Нажать на вашей папке (“User*”) правой кнопкой и выполнить операцию SVN commit
