Тестирование программного обеспечения. (Урок 1)

Сентябрь 7, 2022

Главная
Алгебра
Тестирование программного обеспечения. (Урок 1)

Содержание

2. План занятия: SDLC (Software Development Life Cycle) Модели жизненного цикла ПО Методологии разработки информационных систем Определение
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. Методологии разработки ИС Методология - учение о методах, методиках, способах и средствах познания В то
8. Методологии разработки ИС Каскадные методологии: Waterfall: Предусматривает, что каждая последующая фаза начинается лишь тогда, когда полностью
9. Методологии разработки ИС Каскадные методологии: V-model: Разновидность каскадной модели. Каждая последующая фаза начинается по завершению получения
10. Методологии разработки ИС Итерационные методологии: Agile: это семейство гибких процессов разработки(SCRUM, Extreme programming, Kanban, etc). Ценности
11. Методологии разработки ИС Итерационные методологии: Rational Unified Process (RUP) — создана компанией Rational Software. Основные принципы
12. Методологии разработки ИС Waterfall - есть документация, требования будут мало меняться, ведётся вся документация, весь процесс
13. 4. Определение термина «Тестирование ПО» Тестирование ПО – это: 1980 - Процесс выполнения программы с намерением
14. Определение необходимости тестирования ПО В процессе тестирования обнаруживаются дефекты в работе системы. Анализ найденных дефектов дает
15. 5. QA vs QC, Verification vs Validation QA aims to prevent defects with a focus on
16. QA vs QC, Verification vs Validation QC aims to identify defects in the finished product. Quality
17. QA vs QC, Verification vs Validation QC включает в себя: подготовку, анализ и тестирование требований написание
18. QA vs QC, Verification vs Validation Полный цикл тестирования включает в себя: Verification (верификацию) - проверка
19. 6. Роли и артефакты в проектной команде Project Manager, PM — это специалист в области управления
20. Роли и артефакты в проектной команде Business Analyst, BA — это специалист, использующий методы бизнес-анализа для
21. Роли и артефакты в проектной команде Software Architect, SA — это специалист, определяющий начальную структуру системы,
22. Роли и артефакты в проектной команде Разработчик (Developer, Dev) — это специалист, кодирующий функциональности программного продукта
23. Роли и артефакты в проектной команде Руководитель группы тестирования (Test Lead, Test Manager, TL) — это
24. Роли и артефакты в проектной команде Тестировщик (Software tester) — это специалист, отвечающий за QC активности.
25. Роли и артефакты в проектной команде В зависимости от сложности проекта и квалификации специалиста, тестировщики могут
26. 7. Зачем нужны тестировщики на проекте? Предоставляют заинтересованным сторонам информацию, достаточную для принятия обоснованного решения о
27. 8. Анализ требований к программному обеспечению Требования – это функциональная характеристика системы, необходимая заказчику для того,
28. Анализ требований к программному обеспечению Требования принято разделять по характеру использования Функциональный характер: Бизнес – требования
29. Анализ требований к программному обеспечению Зачем и кому нужны требования? Developer – согласно требованиям пишется программный
30. Анализ требований к программному обеспечению Как собрать требования: Интервью, собрания (meetings, митинги) с представителями заказчика Мозговой
31. Анализ требований к программному обеспечению Что делать, если нет требований? Запросить соответствующий документ Запросить источник пожеланий
32. Анализ требований к программному обеспечению Правила работы команды тестирования: Каждый документ должен утверждаться заказчиком – устно
33. Анализ требований к программному обеспечению Критерии требований: Правильность Полнота Понятность Измеримость Тестируемость Непротиворечивость Как проверять требования:
34. Анализ требований к программному обеспечению Правильность Каждое требование должно точно описывать то, что должно быть разработано
35. Анализ требований к программному обеспечению Полнота Все требования задокументированы Каждое требование содержит всю информацию, необходимую для
36. Анализ требований к программному обеспечению Понятность Одинаковая интерпретация требования (недвусмысленность) Требование описано - четко, просто, кратко
37. Анализ требований к программному обеспечению Измеримость Требование должно быть сформулировано так, что бы можно было доказать
38. Анализ требований к программному обеспечению Тестируемость Требование должно быть сформулировано так, что бы тестировщик, прочитав его,
39. Анализ требований к программному обеспечению Непротиворечивость Требование не должно противоречить другим требованиям Где и как проверяется?
40. Домашнее задание NB! Все, кроме перевода с английского на русский, выполняется на английском языке Прочитать про
41. Домашнее задание Прочитать и проанализировать презентацию по тестированию требований Testing_The_Requirements.pdf, перевести слайды 24 и 25 на
42. Домашнее задание Установить Tortoise SVN (ссылка на скачивание http://bit.ly/1lJZUEw) Создать папку c именем “с:\SVN”, в которой
44. Скачать презентацию

Слайд 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

Тестирование программного обеспечения. (Урок 1)

Содержание

План занятия:SDLC (Software Development Life Cycle)Модели жизненного цикла ПО Методологии разработки

1. SDLC (Software Development Life Cycle) Software Development Life Cycle (Жизненный цикл

SDLC (Software Development Life Cycle)Основные стадии и этапы создания программного обеспечения:Разработка

2. Модели жизненного цикла ПО SDLC Model (Модель жизненного цикла ПО)

Модели жизненного цикла ПО Где почитать:Каскадная модель:http://bit.ly/1vbhYPxИтеративная модель:http://bit.ly/1d6KDKEСпиральная модель:http://bit.ly/1ouQpit

3. Методологии разработки ИС Методология - учение о методах, методиках, способах

Методологии разработки ИС Каскадные методологии:Waterfall: Предусматривает, что каждая последующая фаза начинается

Методологии разработки ИС Каскадные методологии:V-model: Разновидность каскадной модели. Каждая последующая фаза

Методологии разработки ИС Итерационные методологии:Agile: это семейство гибких процессов разработки(SCRUM, Extreme

Методологии разработки ИС Итерационные методологии:Rational Unified Process (RUP) — создана компанией

Методологии разработки ИС Waterfall - есть документация, требования будут мало меняться,

4. Определение термина «Тестирование ПО»Тестирование ПО – это:1980 - Процесс выполнения

Определение необходимости тестирования ПОВ процессе тестирования обнаруживаются дефекты в работе системы.

5. QA vs QC, Verification vs ValidationQA aims to prevent defects

QA vs QC, Verification vs ValidationQC aims to identify defects in

QA vs QC, Verification vs ValidationQC включает в себя:подготовку, анализ и

QA vs QC, Verification vs ValidationПолный цикл тестирования включает в себя: Verification

6. Роли и артефакты в проектной командеProject Manager, PM — это

Роли и артефакты в проектной командеBusiness Analyst, BA — это специалист,

Роли и артефакты в проектной командеSoftware Architect, SA — это специалист,

Роли и артефакты в проектной командеРазработчик (Developer, Dev) — это специалист,

Роли и артефакты в проектной командеРуководитель группы тестирования (Test Lead, Test

Роли и артефакты в проектной командеТестировщик (Software tester) — это специалист,

Роли и артефакты в проектной командеВ зависимости от сложности проекта и

7. Зачем нужны тестировщики на проекте?Предоставляют заинтересованным сторонам информацию, достаточную для

8. Анализ требований к программному обеспечениюТребования – это функциональная характеристика системы,

Анализ требований к программному обеспечениюТребования принято разделять по характеру использованияФункциональный характер:Бизнес

Анализ требований к программному обеспечениюЗачем и кому нужны требования?Developer – согласно

Анализ требований к программному обеспечениюКак собрать требования:Интервью, собрания (meetings, митинги) с

Анализ требований к программному обеспечениюЧто делать, если нет требований?Запросить соответствующий документЗапросить

Анализ требований к программному обеспечениюПравила работы команды тестирования:Каждый документ должен утверждаться

Анализ требований к программному обеспечениюПравильностьКаждое требование должно точно описывать то, что

Анализ требований к программному обеспечениюПолнотаВсе требования задокументированыКаждое требование содержит всю информацию,

Анализ требований к программному обеспечениюПонятностьОдинаковая интерпретация требования (недвусмысленность) Требование описано -

Анализ требований к программному обеспечениюИзмеримостьТребование должно быть сформулировано так, что бы

Анализ требований к программному обеспечениюТестируемостьТребование должно быть сформулировано так, что бы

Анализ требований к программному обеспечениюНепротиворечивость Требование не должно противоречить другим требованиямГде

Домашнее заданиеNB! Все, кроме перевода с английского на русский, выполняется на

Домашнее заданиеПрочитать и проанализировать презентацию по тестированию требований Testing_The_Requirements.pdf, перевести слайды

Домашнее заданиеУстановить Tortoise SVN (ссылка на скачивание http://bit.ly/1lJZUEw)Создать папку c именем

Похожие презентации