Тестирование и его связь с жизненным циклом ПО

Содержание

Слайд 2

Цикл разработки ПО Цикл (процесс) разработки ПО (software development life cycle)

Цикл разработки ПО

Цикл (процесс) разработки ПО (software development life cycle) –

это путь от идеи до поддержки готового продукта. Чем более отлажены каждая из стадий цикла и координация между ними, тем эффективнее работает компания, тем выше качество и тем счастливее пользователи/клиенты.

it-courses.by

Слайд 3

Жизненный цикл ПО Формирование и анализ требований Проектирование Реализация Тестирование продукта Внедрение Эксплуатация и сопровождение it-courses.by

Жизненный цикл ПО

Формирование и анализ требований
Проектирование
Реализация
Тестирование продукта
Внедрение
Эксплуатация и сопровождение

it-courses.by

Слайд 4

Когда начать тестировать? it-courses.by

Когда начать тестировать?

it-courses.by

Слайд 5

Формирование и анализ требований Тестирование требований на вменяемость/ осуществимость Тестирование функциональной

Формирование и анализ требований

Тестирование требований на вменяемость/ осуществимость
Тестирование функциональной спецификации
Выделение модулей

приложения
Обдумывание предварительных тестовых сценариев на основе требований

it-courses.by

Слайд 6

Проектирование Тестирование документов, описывающих архитектуру (product architecture) и дизайн (product design) Тестирование плана проекта it-courses.by

Проектирование

Тестирование документов, описывающих архитектуру (product architecture) и дизайн (product design)
Тестирование плана

проекта

it-courses.by

Слайд 7

Реализация Тестирования кода и модульное тестирование Тестирование результатов итерации Регрессионное тестирование it-courses.by

Реализация

Тестирования кода и модульное тестирование
Тестирование результатов итерации
Регрессионное тестирование

it-courses.by

Слайд 8

Тестирование продукта Тестирование готового приложения Приемочное тестирование it-courses.by

Тестирование продукта

Тестирование готового приложения
Приемочное тестирование

it-courses.by

Слайд 9

Внедрение Тестирование совместимости продукта с существующей инфраструктурой заказчика (типы серверов, окружение…)

Внедрение

Тестирование совместимости продукта с существующей инфраструктурой заказчика (типы серверов, окружение…)
Сбор и

обработка обратной связи о приложении от пользователей

it-courses.by

Слайд 10

Эксплуатация и сопровождение Обработка отчетов об ошибках от пользователей во время

Эксплуатация и сопровождение

Обработка отчетов об ошибках от пользователей во время эксплуатации
Верификация

исправления ошибок
Обработка запросов новой функциональности
Тестирование новой функциональности

it-courses.by

Слайд 11

Когда прекращать тестирование? it-courses.by

Когда прекращать тестирование?

it-courses.by

Слайд 12

Эвристики Эвристики – это способы решения проблемы или принятия решения it-courses.by

Эвристики

Эвристики – это способы решения проблемы или принятия решения

it-courses.by

Слайд 13

Время вышло Эвристика «Время вышло!». Для многих специалистов по тестированию это

Время вышло

Эвристика «Время вышло!». Для многих специалистов по тестированию это наиболее распространенная эвристика.

Мы останавливаем тестирование, когда заканчивается выделенное на него время.

it-courses.by

Слайд 14

Пиньяты Эвристика пиньяты Мы прекращаем ломать программу, когда начинают выпадать конфеты

Пиньяты

Эвристика пиньяты Мы прекращаем ломать программу, когда начинают выпадать конфеты =

мы останавливаем тестирование, когда видим первую достаточно серьезную проблему.

it-courses.by

Слайд 15

Мертвая лошадь Эвристика «мертвой лошади» В программе слишком много ошибок, так

Мертвая лошадь

Эвристика «мертвой лошади» В программе слишком много ошибок, так что продолжение тестирования

не имеет смысла. Мы знаем, что все изменится настолько, что сведет на нет результаты текущего тестирования.

it-courses.by

Слайд 16

Задание выполнено Эвристика «Задание выполнено» Мы останавливаем тестирование, когда найдены ответы на все поставленные вопросы. it-courses.by

Задание выполнено

Эвристика «Задание выполнено»  Мы останавливаем тестирование, когда найдены ответы на все поставленные вопросы.

it-courses.by

Слайд 17

Отмена задания Эвристика «Отмена задания» Наш клиент сказал: «пожалуйста, прекратите тестирование».

Отмена задания

Эвристика «Отмена задания» Наш клиент сказал: «пожалуйста, прекратите тестирование». Это может произойти

по причине перерасхода бюджета, или вследствие отмены проекта, и по любой другой причине. Какова бы ни была причина, нам поручили остановить тестирование. («Время вышло!» может быть частным случаем «Отмены задания», в том случае, если предпочтительнее, чтобы не мы сами, а заказчик принял решение о прекращении тестирования)

it-courses.by

Слайд 18

Я зашел в тупик Эвристика «Я зашел в тупик!» По какой-то

Я зашел в тупик

Эвристика «Я зашел в тупик!»  По какой-то причине мы

останавливаемся, поскольку обнаруживаем препятствие. У нас нет информации, которая нам требуется (например, люди заявляют, что не могут тестировать без достаточного количества спецификаций). Есть блокирующая ошибка, и мы не можем перейти в ту область продукта, которую необходимо протестировать. У нас нет необходимого оборудования или инструментария, у команды нет квалификации, требуемой для выполнения некоторых тестов

it-courses.by

Слайд 19

Освежающая пауза Эвристика «освежающей паузы» Вместо прекращения тестирования мы приостанавливаем его.

Освежающая пауза

Эвристика «освежающей паузы»  Вместо прекращения тестирования мы приостанавливаем его. Мы можем остановить тестирование

и сделать перерыв, когда мы устали, нам стало скучно или пропало вдохновение. Мы можем сделать паузу на то, чтобы выполнить исследования, разработать планы, поразмыслить. Идея заключается в том, что нам нужен перерыв, после которого мы сможем вернуться к продукту.

it-courses.by

Слайд 20

Привычного завершения Эвристика «Привычного завершения» Есть протокол, задающий определенное количество идей

Привычного завершения

Эвристика  «Привычного завершения»  Есть протокол, задающий определенное количество идей для тестирования, или

тест-кейсов, или циклов тестирования. Agile-команды, например, часто применяют такой подход: «когда выполнены все приемочные тесты, мы знаем, что продукт готов к поставке»
Эвальд Руденриджс приводит пример этой эвристики в статье «Когда прекращать тестирование». Он говорит, что он останавливается, «когда выполнено определенное количество тестовых циклов, включая регрессионное тестирование»

it-courses.by

Слайд 21

Больше нет интересных вопросов Больше нет интересных вопросов Не осталось вопросов,

Больше нет интересных вопросов

Больше нет интересных вопросов  Не осталось вопросов, ответы на

которые были бы достаточно ценными, чтобы оправдать стоимость продолжения тестирования. Эта эвристика используется в основном как дополнение к другим эвристикам. Она помогает принять решение о том, есть ли какие-то риски, если остановить тестирование. Даже если одна эвристика советует нам прекратить тестирование, нужно проверить, есть ли интересные вопросы, серьезные риски в других областях. Если они есть, то лучше продолжить тестирование.

it-courses.by

Слайд 22

Уклонения/безразличия Эвристика уклонения/безразличия Тестируемое приложение может быть первой версией, которую, как

Уклонения/безразличия

Эвристика уклонения/безразличия Тестируемое приложение может быть первой версией, которую, как мы знаем, скоро

заменят. Некоторые люди прекращают тестирование по причине лени, злого умысла или отсутствия мотивации. Иногда бизнес-критичность выпуска нового релиза настолько высока, что никакая мыслимая проблема не остановит выход программы, и поэтому никакие новые результаты тестирования не будут иметь значения.

it-courses.by

Слайд 23

Методологии разработки «Колхоз» против «Процесса» it-courses.by

Методологии разработки

«Колхоз» против «Процесса»

it-courses.by

Слайд 24

Как построить процесс? it-courses.by

Как построить процесс?

it-courses.by

Слайд 25

Модель разработки ПО Структура, систематизирующая различные виды проектной деятельности, их взаимодействие

Модель разработки ПО

Структура, систематизирующая различные виды проектной деятельности, их взаимодействие и

последовательность в процессе разработки ПО. Выбор той или иной модели зависит от масштаба и сложности проекта, предметной области, доступных ресурсов и множества других факторов.

it-courses.by

Слайд 26

Основная задача методологий Быстрота выполнения работ и четкая координация команд Качественное

Основная задача методологий

Быстрота выполнения работ и четкая координация команд
Качественное исполнение и

контроль качества
Сокращение издержек

it-courses.by

Слайд 27

Отличия от Кустарного производства Большой объем параллельных проектов Большая предсказуемость объема работ и результата it-courses.by

Отличия от Кустарного производства

Большой объем параллельных проектов
Большая предсказуемость объема работ и

результата

it-courses.by

Слайд 28

Методология описывает Роли Активности Артефакты Фазы и критерии их начала/окончания it-courses.by

Методология описывает

Роли
Активности
Артефакты
Фазы и критерии их начала/окончания

it-courses.by

Слайд 29

Типичные роли Руководитель проекта (Project Manager) Архитектор (Architect/Designer) Бизнес-аналитик (Business Analyst)

Типичные роли

Руководитель проекта (Project Manager)
Архитектор (Architect/Designer)
Бизнес-аналитик (Business Analyst)
Разработчик (Developer)
Тестировщик (Test Engineer/Tester)

it-courses.by

Слайд 30

Waterfall Каскадная модель (англ. водопад) – модель процесса разработки ПО, в

Waterfall

Каскадная модель (англ. водопад) – модель процесса разработки ПО, в которой

весь процесс выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки

it-courses.by

Слайд 31

Waterfall Переход от одной фазы к другой происходит только после полного и успешного завершения предыдущей it-courses.by

Waterfall

Переход от одной фазы к другой происходит только после полного и

успешного завершения предыдущей

it-courses.by

Слайд 32

Стадии разработки по Waterfall it-courses.by

Стадии разработки по Waterfall

it-courses.by

Слайд 33

Waterfall. Принципы Переходит от одной стадии к другой строго последовательно Нельзя

Waterfall. Принципы

Переходит от одной стадии к другой строго последовательно
Нельзя приступить к

следующему
этапу, пока полностью и
исчерпывающе не сделан
текущий
Тестирования подключается с середины
Переходов назад, вперёд или перекрытия фаз - Нет

it-courses.by

Слайд 34

Agile Гибкая методология разработки (англ. гибкий) – серия подходов к разработке

Agile

Гибкая методология разработки (англ. гибкий) – серия подходов к разработке ПО,

ориентированных на использование итеративной инкрементальной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля

it-courses.by

Слайд 35

Итеративный подход Итеративный подход (англ. повторение) в разработке ПО – это

Итеративный подход

Итеративный подход (англ. повторение) в разработке ПО – это выполнение

работ параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы.

it-courses.by

Слайд 36

Инкрементальный подход Инкрементальный подход (англ. увеличение) в разработке ПО – это

Инкрементальный подход

Инкрементальный подход (англ. увеличение) в разработке ПО – это постепенное

прирощение (увеличение) функционала небольшими частями от релиза к релизу

it-courses.by

Слайд 37

Маленький, но жизнеспособный it-courses.by

Маленький, но жизнеспособный

it-courses.by

Слайд 38

it-courses.by Наглядно

it-courses.by

Наглядно

Слайд 39

Agile. Понятия Agility – ловкость, проворность Visibility – наглядность Release –

Agile. Понятия

Agility – ловкость, проворность
Visibility – наглядность
Release – выпуск, версия
Iteration –

итерация, повтор
Values – стоимость, оценка
Unity – сплоченность, единство
Simplicity – простота
Transparency – прозрачность
Adaptability – адаптируемость
Velocity - скорость
Burn up – разгорать

Goals – цели
Estimation – прогнозная оценка
Retrospective – взгляд в прошлое
Refactoring – доработка кода
Collaboration – взаимодействие, переговоры
Integration – слияние
Vision - вИдение

it-courses.by

Слайд 40

Преимущества итеративного подхода Снижение воздействия серьёзных рисков на ранних стадиях проекта,

Преимущества итеративного подхода

Снижение воздействия серьёзных рисков на ранних стадиях проекта, что

ведет к минимизации затрат на их устранение
Организация эффективной обратной связи команды с потребителем/ заказчиками и создание продукта, реально отвечающего их потребностям
Акцент усилий на наиболее важных и критичных направлениях проекта
Непрерывное итеративное тестирование
Раннее обнаружение конфликтов и потенциальных багов
Более равномерная загрузка участников проекта
Эффективное использование накопленного опыта
Реальная оценка текущего состояния проекта
Затраты распределяются по всему проекту, а не группируются в конце

it-courses.by

Слайд 41

Принципы Agile Agile - семейство процессов разработки, а не единственный подход

Принципы Agile

Agile - семейство процессов разработки, а не единственный подход в

разработке программного обеспечения, и определяется Agile Manifesto (http://agilemanifesto.org/iso/ru/manifesto.html )

it-courses.by

Слайд 42

Agile-манифест 1. Люди и взаимодействие 2. Работающий продукт 3. Сотрудничество с

Agile-манифест

1. Люди и взаимодействие
2. Работающий продукт
3. Сотрудничество с заказчиком
4.

Готовность к изменениям

1. процессов и инструментов
2. полной документации
3. условий контракта
4. следования первоначальному плану

it-courses.by

важнее

Слайд 43

Пояснение принципов Agile-манифеста Удовлетворение клиента за счёт ранней и бесперебойной поставки

Пояснение принципов Agile-манифеста

Удовлетворение клиента за счёт ранней и бесперебойной поставки ценного

программного обеспечения
Приветствие изменений требований даже в конце разработки (это может повысить конкурентоспособность полученного продукта)
Частая поставка рабочего программного обеспечения (каждый месяц, неделю или чаще)
Тесное общение заказчика с разработчиками на протяжении всего проекта
Проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием
Рекомендуемый метод передачи информации — личный разговор (лицом к лицу)

it-courses.by

Слайд 44

Пояснение принципов Agile-манифеста Работающее программное обеспечение - лучший измеритель прогресса Все

Пояснение принципов Agile-манифеста

Работающее программное обеспечение - лучший измеритель прогресса
Все члены команды

должны иметь возможность поддерживать постоянный темп на неопределённый срок
Постоянное внимание к улучшению технического мастерства и удобному дизайну
Простота - искусство не делать лишней работы
Лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды
Постоянная адаптация к изменяющимся обстоятельствам

it-courses.by

Слайд 45

Scrum Scrum (от англ. scrum «схватка») - методология управления проектами, активно

Scrum

Scrum (от англ. scrum «схватка») - методология управления проектами, активно применяющаяся

для гибкой разработки ПО. Scrum чётко делает акцент на качественном контроле процесса разработки.

it-courses.by

Слайд 46

Scrum. Основные понятия Скрам (Scrum) - это набор принципов, на которых

Scrum. Основные понятия

Скрам (Scrum) - это набор принципов, на которых строится

процесс разработки, позволяющий в жёстко фиксированные и небольшие по времени итерации, называемые спринтами (sprints), предоставлять конечному пользователю работающее ПО с новыми возможностями, для которых определён наибольший приоритет. Новые функции ПО, которые должны быть реализованы в очередном спринте определяются в начале спринта на этапе планирования и не должны изменяться на всём его протяжении. При этом строго фиксированная небольшая длительность спринта придаёт процессу разработки предсказуемость и гибкость.

it-courses.by

Слайд 47

Scrum. Основные понятия Спринт (Sprint) - итерация в скраме, в ходе

Scrum. Основные понятия

Спринт (Sprint) - итерация в скраме, в ходе которой

создаётся функциональный прирост ПО. Жёстко фиксирован по времени. Длительность одного спринта от 2 до 4 недель.

it-courses.by

Слайд 48

Scrum. Основные понятия it-courses.by

Scrum. Основные понятия

it-courses.by

Слайд 49

Scrum. Основные понятия Резерв Проекта (Product backlog) - это список требований

Scrum. Основные понятия

Резерв Проекта (Product backlog) - это список требований к

функциональности, упорядоченный по их степени важности, подлежащих реализации. Элементы этого списка называются «пожеланиями пользователя» (user story) или элементами резерва (backlog items)
Зачастую история имеет следующую структуру: «Будучи пользователем <тип пользователя> я хочу сделать <действие>, чтобы получить <результат>»
Резерв проекта открыт для редактирования для всех участников скрам процесса

it-courses.by

Слайд 50

Scrum. Основные понятия Резерв спринта (Sprint backlog) - содержит функциональность, выбранную

Scrum. Основные понятия

Резерв спринта (Sprint backlog) - содержит функциональность, выбранную владельцем

проекта из резерва проекта.
Все функции разбиты по задачам, каждая из которых оценивается скрам-командой.
Каждый день команда оценивает объем работы, который нужно проделать для завершения спринта.

it-courses.by

Слайд 51

Scrum. Процесс it-courses.by

Scrum. Процесс

it-courses.by

Слайд 52

Scrum. Роли По Scrum в производственном процессе есть определенные роли, разбитые

Scrum. Роли

По Scrum в производственном процессе есть определенные роли, разбитые на

2 группы: свиней и кур. Эти названия были использованы из-за шутки:
Свинья идёт по дороге. Курица смотрит на нее и говорит: «А давай откроем ресторан!» Свинья смотрит на курицу и отвечает: «Хорошая идея, и как ты хочешь его назвать?» Курица думает и говорит: «Почему бы не назвать 'Яичница с беконом'?». «Так не пойдёт», - отвечает свинья, «ведь тогда мне придётся полностью посвятить себя проекту, а ты будешь вовлечена только частично»

it-courses.by

Слайд 53

Scrum. Роли Свиньи - основные роли. Вовлечены в проект полностью Куры

Scrum. Роли

Свиньи - основные роли. Вовлечены в проект полностью
Куры - второстепенные

роли. Вовлечены в проект частично

it-courses.by

Слайд 54

Scrum. Свиньи Свиньи полностью включены в проект и в скрам-процесс. Скрам-мастер

Scrum. Свиньи

Свиньи полностью включены в проект и в скрам-процесс.
Скрам-мастер (ScrumMaster) -

проводит совещания (Scrum meetings) следит за соблюдением всех принципов скрам, разрешает противоречия и защищает команду от отвлекающих факторов. Данная роль не предполагает ничего иного, кроме корректного ведения скрам-процесса.
Владелец продукта (Product Owner) - представляет интересы конечных пользователей и других заинтересованных в продукте сторон.
Скрам-команда (Scrum Team) - кросс-функциональная команда, состоящая из специалистов разных профилей: тестировщиков, архитекторов, аналитиков, программистов и т. д. Команда является единственным полностью вовлечённым участником разработки и отвечает за результат как единое целое. Никто кроме команды не может вмешиваться в процесс разработки на протяжении спринта.

it-courses.by

Слайд 55

Scrum. Свиньи it-courses.by

Scrum. Свиньи

it-courses.by

Слайд 56

Scrum. Куры Пользователи (Users) Клиенты, Продавцы (Stakeholders) - лица, которые инициируют

Scrum. Куры

Пользователи (Users)
Клиенты, Продавцы (Stakeholders) - лица, которые инициируют проект и

для кого проект будет приносить выгоду. Они вовлечены в скрам только во время обзорного совещания по спринту (Sprint Review).
Управляющие (Managers) - люди, которые управляют персоналом.
Эксперты-консультанты (Consulting Experts)

it-courses.by

Слайд 57

Scrum. Project Manager? it-courses.by Scrum Master? А кто это?

Scrum. Project Manager?

it-courses.by

Scrum Master? А кто это?

Слайд 58

Scrum. Встречи (Meetings) Планирование спринта (Sprint Planning Meeting) - в начале

Scrum. Встречи (Meetings)

Планирование спринта (Sprint Planning Meeting) - в начале каждого

Спринта
Из резерва проекта выбираются задачи, обязательства по выполнению которых за спринт принимает на себя команда
На основе выбранных задач создается резерв спринта. Каждая задача оценивается в идеальных человеко-часах. Решение задачи не должно занимать более 12 часов или одного дня. При необходимости задача разбивается на подзадачи. Обсуждается и определяется, каким образом будет реализован этот объём работ
(первая часть совещания) Участвует владелец проекта и скрам команда: выбирают задачи из резерва проекта
(вторая часть совещания) Участвует только команда: обсуждают технические детали реализации

it-courses.by

4-8 часов

Слайд 59

Scrum. Встречи (Meetings) Ежедневное совещание (Daily Scrum meeting): Начинается точно вовремя

Scrum. Встречи (Meetings)

Ежедневное совещание (Daily Scrum meeting):
Начинается точно вовремя
Все могут наблюдать,

но только свиньи говорят
Проводится в одном и том же месте в течение спринта
В течение совещания каждый член команды отвечает на 3 вопроса:
Что сделано с момента предыдущего ежедневного совещания?
Что будет сделано с момента текущего совещания до следующего?
Какие проблемы мешают достижению целей спринта?

it-courses.by

15 мин

Слайд 60

Scrum. Встречи (Meetings) Обзор итогов спринта (Sprint review meeting) проводится после

Scrum. Встречи (Meetings)

Обзор итогов спринта (Sprint review meeting) проводится после завершения

спринта:
Команда демонстрирует инкремент функциональности продукта всем заинтересованным лицам (demo)
Все члены команды участвуют в демонстрации (один человек на демонстрацию или каждый показывает, что сделал за спринт).
Нельзя демонстрировать незавершенную функциональность.

it-courses.by

4 часа

Слайд 61

Scrum. Встречи (Meetings) Ретроспективное совещание (Retrospective meeting) проводится после завершения спринта:

Scrum. Встречи (Meetings)

Ретроспективное совещание (Retrospective meeting) проводится после завершения спринта:
Члены команды

высказывают своё мнение о прошедшем спринте
Отвечают на два основных вопроса:
Что было сделано хорошо в прошедшем спринте?
Что надо улучшить в следующем спринте?
Выполняют улучшение процесса разработки (решают вопросы и фиксируют удачные решения).

it-courses.by

1-3 часа

Слайд 62

процесс it-courses.by

процесс

it-courses.by

Слайд 63

Сравнение моделей разработки ПО it-courses.by

Сравнение моделей разработки ПО

it-courses.by

Слайд 64

Waterfall and Agile it-courses.by

Waterfall and Agile

it-courses.by

Слайд 65

Waterfall and Agile it-courses.by

Waterfall and Agile

it-courses.by

Слайд 66

Scrum. Расширение it-courses.by

Scrum. Расширение

it-courses.by