Классификация видов тестирования

Требования – это совокупность утверждени относительно атрибутов. Свойств или

качеств системы, полежащей реализации.

Требования могут быть представлены в разных виов: текстовом или графическом

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

Спецификация – законченное описание поведения программы, котою требуется

разработать

Функциональные требования – тебуемые характеристики системы

Нефункциональные требования – опр критерии работы системы в целом, а не

отдельные сценарии поведения. (удобная ручка или красивый цвет, требования
проивзодительности)

Тестовый случай – как мы проверяем требования; набор условий. При которых

тестировщик будет определять, удовлетворяется ли заранее определенное
требование

Ошибка (дефект, баг) – отклонение фактического результата от ожидаемого

Отчет об ошибке –(баг репорт) – документ, описывающий ситуацию, которая привела к

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

Тестирование ПО – процесс, позволяющий убедиться в том, что в программе нет

ошибок (неправильное)

Проверить программу полностью невозможно

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

назначение (тоже некорректное)
- процесс проверки и оценки соответствия между реальным и ожидаемым поведением
программы, осуществляемый на конечном наборе тестов. (правильно!!)

Проверяем как ожидаемое так и реальное поведение программы

Процесс оценки програмного обеспечения

Готова ли программа выпускаться и быть доступной для пользователя

Цели тестирования

- убедиться что по отвечает тебования

- не выполняет то что не требуется

Задачи:

- Пропустить как можно меньше дефектов

- Проверить что известные дефекты устранены

- Проверить что при устранении известных дефектов не ыли внесены новые

После выполнеии задач выполняется отчет о тестироавнии

Цикл тестирования ПО

Планирование тестироавания (опр ресурсы, выираем стратегию, оцениваем риски и

время) – разработка тестов (разр тесты, учитываем приоритеты, внешние данные,
наборы данных,) – выполнение тестов (находим дефекты) – анализ и отчет о
результатах тестирования (составление отчетов о результатах, готов ли программный
продукт к выходу)

В виде цикла, потому что круг может постоянно повтоярться

Принципы тестирования:

основные рекомендации по тестированию за последние 40 лет

1. Тестирование показывает наличие дефектов, но не может показать что

дефекты отсутствуют
 2. Исчерпывающее тестирование недостижимо, невыполнимо

3. Раннее тестирование (чем раньше обнаружен дефект, тем дешевле он для

разработки)

4. Скопление дефектов (возможно стоит поискать еще дефекты рядом)

5. Парадокс пестицида (расширять тесты и тестировать заново)

6. Тестирование зависит от контекста

7. Заблуждение об отсутствии ошибок (всегда нужно помнить об ожиданиях

конечного пользователя)

Классификация видов тестирования:

1. Функциональное

· Функциональное (рассматривает заранее указанное поведение и

основывается на анализе спецификация функциональности)

· Тестирование безопасности (проверка безопасностисиетмы, а также

выполняется для анализа рисков, связанных с защитой …)

· Тестирование взаимодействия (проверяет способность приложения

взаимодействовать с другими системами)

2. Нефункциональное

· Тестирование удобства (красивая, удобная и др.)

· Тестирование установки (проверка успешной инсталляции и

настройки, а также обновления или удаления программного
обеспечения)

· Тестирование производительности (проводится с целью

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

· Тестирование конфигурации (по успешно работает во всех системах

или браузерах)

· Тестирование на отказ и восстановление (краш тест?, проверяет

способность противостоять и успешно восстанавливаться после
возможных сбоев)

3. Виды тестирования, связанные с изменениями

 · Тестирование сборки (направлено на опр соответствия, выпущенной
версии, критериям качества для начала тестирвоания)

· Регрессионное тестирование (направлено на проверку изменений и

для подтверждения работоспособности существующей ранее
функциональности)

· Дымовое тестирование (минимальный набор тестов, проверяющий

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

· Санитарной тестирование (узконаправленное тестирование,

используемое для определения работоспособности определенной
части системы)

Дополнительные виды классификации тестирования

1. По состоянию

· Статическое – тестирование при котором код не выполняется

(программа. Открываем код и смотрим что нет ошибок)

· Динамическое – необходимо выполнение кода (проверка после

запуска кода)

2. По знанию системы

· Черный ящик – тестировщик не имеет доступа к коду

· Белый ящик – тестировщик имеет доступ к коду, при необзодимости

можем смотреть

· Серый ящик – знаем общую архитектуру систеы

3. По степени автоматизации:

· Ручное тестирование

· Автоматизиованное тетирование (производится компьютером)

· Полуавтоматизированное (часть тестировщиком, часть автоматом)

4. По степени подгтовленности тестирования

· По документации (тестирование производится по заранее

подготовленным тестовым случаям)

· Интуитивное тестирвоание (производится без какой-либо подготовки,

без плана и цели)

5. По времени проведения тестирования

· Альфа-тестирования – тестирование продукта на раннем этапе

специально обученными людьми
 · Бета – тестирования – тест готового продукта приглашенными
(непрофессиональными) ользователями

6. По признаку позитивности сценариев

· Позитивное тестирование – тестирование на тестовых случаях,

которые соответствуют ожидаемому поведению системы

· Негативное тестирование – это проверка устойчивости системы к

воздействиям различного рода, валидация неверного набора
данных.

Уровни тестирования

· Модульное или компонентное тестирование (тест отдельных

модулей, частей)

· Приемочное тестирование (критерии приемки и соответствие им,

сценарии поведения пользователя)

· Системное тестирование (как полностью вместе работают

компоненты)

· Интеграционное тестирование (как между собой взаимодействуют

компоненты, части)

Дефект, жизненный цикл и классификация дефектов

Дефект – отклонение фактического результата от ожидаемого

Условия существ дефекта

1. Известен фактический результат

2. Известен ожидаемый результат

3. Фактический результата отличается от ожидаемого

Функциональные дефекты:

Пример – система не реагирует на нажатие кнопки

Дефекты графического интерфейса

Пример – кнопка другого цвета

Дефекты документации

Пример – все кнопки должны быть синие, но одна красная

Дефекты производительности

Пример – сайт падает при большом количестве посетителей

Дефекты удобства использования

Пример – введены данные для поиска, а страница пустая

Решение – предусмотреть элемент загрузки, который показывается при выполнении

поиска

Ошибки сторонних сервисов

Пример – видео не воспроизводится ( с другого ресурса). На это невозможно

повлиять.

Это были наиболее часто встречающиеся дефекты.

Причины появления дефектов:

1. Человеческий фактор

· Ошибки спецификации

· Ошибки проектирования

· Ошибки реализации программной системы

2. Недостаток или отсутствие общения в команде (часть команды больше

общается с заказчиком, а часть меньше; другая часть команды может быть
неинформированной)

3. Изменение требований (от заказчика) в случае изменения требований для

одной из частей системы, могут появится ошибки в других частях

4. Сложность программного обеспечения, плохо документированный код

5. Неблагоприятные условия окружающей среды (сбои в электричестве, помехи в

передаче данных
 6. Умышленное причинение вреда (взломы и др.)

Отчет об ошибке

- документ, содержащий отчет о любом недостатке, который может привести

компонент или систему к невозможности выполнить требуемую функцию

Отчет об ошибке:

1. Заголовок (Title) – информативное и сжатое описание проблемы (Где – место

системы? Что – что пошло не так? Когда – в какой момент?)

2. Описание дефекта (Description)

· Тестовое окружение (операционная система, платформа и версия,

браузер и его версия, плагины, расширения сторонних
производителей, которые используются браузером, ссылка на
окружение (url/ip address), прочие технические штуки)

· Шаги по воспроизведению (использовать глагол в инфинитиве:

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

· Использовать корректный язык для описания (общепринятые

термины, четкие и однозначные формулировки)

3. Фактический результат (Actual result) – то как система ведет себя на самом

деле

4. Ожидаемый результат (Expected result) – то как система должна себя вести

(спецификация, общение с заказчиком, с командой, общепринятые правила)

Отчет об ошибке (дополнительные поля)

Серьезность – степень воздействия бага на ПО, исходя из принадлежности бага к

определенной технической категории.

· Блокирующая (blocker) – из-за возникновения бага блокируется работа

системы, системный сбой

· Критическая (critical) – проблемы, возникающие в основных функциональностях

системы, потеря данных, безопасность

· Значительная (major) – обычные дефекты функциональности или верстки

· Незначительная (minor) – опечатки и др.

Приоритет – это показатель важности бага для бизнеса компании. Очередность
выполнения задачи.

· Высокий (high)

· Средний (medium)

· Низкий (low)

Серьезность отражает технический аспект бага, а приоритет коммерческий.

Серьезность – абсолютная категория. Приоритет – относительная.

Серьезность не равно приоритет.

Дополнение описания дефекта:

· Тестовое окружение

· Предварительные условия – условия окружения и состояния, которые должны

быть выполнены перед началом выполнения опр. Теста или процедуры
тестирования

· Шаги по воспроизведению дефекта (steps to reproduce)

· Шаги по восстановлению системы (postconditions) (удалить товар из корзины,

удалить пользователя, если его создали)

Фактический и ожидаемый результат

Приложения (attachments) – все то, что поможет разработчику воспроизвести дефект

· Снимки экрана (screenshots)

· Видеозаписи экрана (screencasts)

· Логи приложения (logs)

· Др. Тестовые данные

Отчет об ошибке: пример

Не работает кнопка купить в корзине

Заголовок: страница «корзина»: система не реагирует на нажатие кнопки «купить»,

когда в корзине есть товар

Серьёзность: critical
Приоритет: high

Описание

Тестовое окружение: адрес сайта, браузер, операционная система

Предвар условия: пользователь с опр. Емэйлом существует

Шаги по воспроизведению:

1. Зайти в систему, используя верные логи и пароль

2. Положить товар в корзину

3. Зайти в корзину

4. Нажать кнопку «купить»

Шаги по восстановлению системы:

1. Удалить все товары из корзины пользователя

2. Выйти из системы

Фактический результат – пользователь остался на странице «корзина»

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

Необязательные поля используются по необходимости.

Жизненный цикл дефекта:

Найден дефект – открыт (re)opened -> является ли описанное поведение дефектом

или нет - > если это не дефект, то отклоняется (rejected) и карточка закрывается.

Если разработчик считает что это баг то разработчик переводится в статус

исправления (in progress) -> исправлен или нет

Тестировщик пишет отчет и создает карточку в системе отслеживания ошибок (место

где хранятся описания дефектов и задач на выполнение) отчет об ошибке – карточка
или тикет

Если мы наблюдаем похожий баг, который уже встречался, то это не значит что нужно
открывать старую карточку. Потому что причина возникновения дефекта может быть
другой.

Может быть допущена ошибка при программировании, а может потому что идет
загрузка.
Сколько стоят дефекты?

Стоимость исправления зависит от того, когда дефект найден.

Если на этапе разработки был обнаружен баг в требования, нужно повторять снова
этап анализа и разработки.

Если обнаружили баг на этапе внедрения, то нужно проходить больше шагов: анализ –
разработка – тестирование – внедрение. Потратится в два раза больше времени, чем
могли бы в идеальном случае. Тестирование должно проводится уже на этапе анализа
и быть внедрено в каждый этап разработки.

Тестировщики и разработчики сотрудники, а не враги. Одна команда.

Не нужно возвращать задачу при первом непонятном моменте.

Критиковать код, а не разработчика. Не переходить на личности.

Важно уметь слушать и задавать вопросы.

Эмоциональный интеллект:

1. Осознание своих эмоций

2. Управление своими эмоциями

3. Осознание эмоций других людей.

4. Управление эмоциями других людей.

Тестировщик должен смотреть на продукт с точки зрения конечного пользователя.

В дефектах виновата вся команда.

Важно постоянно учиться. И не паниковать.

Тестовая документация

Она позволяет увеличить прозрачность работы тестировщика.

Тестовый артефакт – продукт деятельности тестировщика, созданный им и

используемый в процессе тестирования программного обеспечения.

Виды:

· План тестирования (документ, описывающий весь объем по

тестированию: объект тестирования – какой продукт будем тестировать;
список функций и компонентов тестируемой системы – что будем
тестировать; стратегия тестирования – как будем тестировать?;
последовательность проведения работ – когда будет тестировать и в
 каком порядке; тестовое окружение и программные средства – где будем
тестировать и что будем использовать; критерии начала и окончания
тестирования; риски – какие неблагоприятные ситуации могут
возникнуть )

o бывает основной план тестирования – содержит высокоуровневую

информацию, не подвержен частому изменению в процессе
тестирования и пересмотра требований

o детальный план тестирования – постоянно претерпевает

изменения, отражающие реальное положение дел на проекте

Пример основного план тестирования:

§ цели

§ общая информация о продукте

§ ссылки на документацию и проектные ресурсы

§ требования к системе

§ стратегии тестирования (что мы конкретно должны делать)

§ инструменты (будем использовать с андроид версией 5.0 с

браузером хром)

§ оценка времени на тестирование

§ возможные риски

§ список артефактов

Пример детального плана тестирования:

§ цели

§ перечень задач для тестирования с приоритетами

§ общие правила тестиования

§ план работы с указанием сроков

§ необходимые ресурсы

§ ответственные за тестирование

· Тестовый случай

- документ, описывающий совокупность шагов и параметры для проверки

программного продукта.

o Позитивный случай (positive case)

o Негативный случай (negative case)

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

Что указывать в тестовом случае?

1. Идентификатор тестового случая (test case id)

2. Название тестового случая (test case title)

3. Предусловия (preconditions) – что-то изменили, чтобы что-то сделать

4. Описание тестового случая (test case description) – что конкретно мы должны

сделать, чтобы протестировать нужную функциональность

5. Тестовые данные (test data)

6. Постусловия (post conditions) – вернули то что меняли в предусловиях

7. Ожидаемый результат (expected result)

Доп поля: вид тестового случая, приоритет тестового случая, время.

· Матрица отслеживания (traceability matrix) – документ, отражающий

связь требований продукта и тестовых сценариев

· Список проверок (check list) – документ, содержащий результаты

тестирования функций по

1. Список проверок с требуемой степенью детализации

2. Тестовое окружение

3. Сборка, на которой проводилось тестирование (версия кода)

4. Дата тестирования

5. Результат проверок (прошло, Не прошло)

6. Поле для комментария (любая инфа, уточняющая положение

дел, ссылки на что-то)

· Отчет об ошибке (bug report) – документ, описывающий

последовательность действий, приведших к некорректной работе
объекта тестирования, с указанием ожидаемого и полученного
результатов.

Багтрекинговые системы (отслеживание ошибок)

Примеры систем: redmine (бесплатная), Jira (платная)

Что указывать в описании дефекта?

1. Идентефикатор дефекта (bug id)

 2. Автор (author)

3. Статус дефекта (bug status)

4. Приоритет дефекта

5. Серьезность дефекта

6. Ответственный (assignee) – кто в данный момент ответственен

за починку этого эффекта

7. Название дефекта – суть, коротко, но емко

8. Тестовое окружение - где это нашли, если тестовых окр

несколько, то в каких и во всех или нет

9. Предусловия

10. Шаги по воспроизведению

11. Постусловия

12. Фактический результат

13. Ожидаемый результат

14. Скриншот или другое приложение (скриншот полого экрана и

выделять цветом место, куда нужно посмотреть)

· Отчет о результатах тестирования (test result report)- документ,

содержащий инфу о выполненных дей-ях и результатах проведенной
работы

Составляется для заинтересованных лиц. Отчет составляется для

предоставления объективной инфы. Что будут делать? Принимать
соответствующее решение или меры.

§ Промежуточный отчет (ежедневный, недельный, месячный)

§ Версионный отчет (с данной версией кода)

§ Финальный отчет

Что указывается в отчете?

§ Состав команды

§ Сроки проведения тестирования – когда проводилось

тестирование?

§ Затраченное время – сколько время потратили на

тестирование?

§ Описание тестирования – какой вид тестирования проводили?

 § Перечень конфигураций – какие конфигурации проверяли (как в
чек листе, список окружений)

§ Перечень функциональностей – какие задачи протестировали?

§ Найденные дефекты – сколько ошибок обнаружено с описание

их критичности?

§ Повторяющиеся дефекты – есть ли повторяющиеся ошибки?

§ Исправленные дефекты – сколько ошибок, исправлено на дату

сдачи отчета

§ Оценка текущего качества проекта – что изменилось? Что не

сделали?

§ Заключение – пожелания, замечания, выводы, общая

информация

При необходимости: приложение со списком багов, классификация багов по

различным критериям, приложение со списком тест кейсов.

Основы тест-дизайна

§ Техники тест дизайна

§ Как составить набор тест кейсов

§ Как отличить хорошие тест кейсы от не очень

Тест дизайн – этап процесса тестирования по, на котором проектируются и создаются

тест кейсы в соответствии с опр. Ранее критериями качества и целями тестирования.

Время ограничено – нужно выделить главное.

Сроки проекта, желание заказчика и пользователей. Фиксированное время на

тестирование.

Зачем разрабатывать тест-кейсы

§ Мозг плохо приспособлен к многозадачности – риск пропустить ошибку

§ Без описания легко «заблудиться» в длинном тестовом сценарии

§ Тестирование документации

Тестирование по сценариям использования:

§ Какие есть роли пользователя (разные наборы функций для разных категорий
пользователя)?

§ Что могут делать пользователи каждой из ролей?

§ Какие есть особенности?

Тестируем соц. сеть: выделим основные роли пользователя

§ Зарегистрированный пользователь

o Обмениваться сообщениями

o Добавлять друзей

o Создавать записи

o Оставлять комменты

o …

§ Админ группы

§ Незарег пользователь

Составляем тест-кейсы:

§ Для каждой роли проверяем каждую зи доступных возможностей

§ Для каждой роли проверяем, что нельзя использовать недоступные по

спецификации возможности

§ Разделяем тесты: с использованием особой возможности и без неё

1. Тесты по сценариям использования:

· Проверяют работоспособность основной функциональности

· Воспроизводят действия пользователей при работе с системой

· Не проверяют отдельные элементы интерфейса

· Не проверяют комбинации данных при заполнении форм

· Не пытаются сломать систему

2. Диаграмма причина-следствие (поможет составить кейсы для

функциональностей, где есть много взаимодействующихэлементов)

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

Пример: соц сеть, лента новостей. Параметры на входе: текущий пользователь,

множество друзей пользователя, множество групп пользователя, черный список
пользователя. Данные на выходе: лента новостей пользователя.

Как входные параметры влияют на результат: видим то что постит друг, что постит
сообщество, не видим тех, кто в черном списке.
Диаграмма причина-следствие (диаграмма Исикавы):

· Представление связей между входными параметрами и выходными

данными

· Способ документирования приложения

· Основа для создания тест-кейсов

Таблица принятии решений.

- каждый результат получен хотя бы один раз

- каждый из входных параметров хотя бы один раз принял каждое из

возможных значений

3. Тестирование переходов между состояниями. (не для одной конкретной

функциональности, но при влиянии их друг на друга)

State-transition testing – техника тест дизайна, основанная на анализе состояний

системы и переходов между состояниями

Части диаграммы:

· Состояние (state)

· ПЕРЕХОД (transition)

o Событие (event) – пользователь что-то сделал, влияние

внешней программы

o Действие (action) – реакция приложения на событие

· Точка входа (entry point) и точка выхода (exit point)

Таблица переходов

Т С Р Нов
е о еа ое
к б кц сост
у ы ия оян
щ т ие
е и
е е

с
о
с
т
о
я
н
и
е

В з В под
ы а ал тве
б п ид ржд
о о ац ени
р л ия е
н ф
б и ор
и т м
л ь ы
е
т
о
в

В о У Отм
ы т да ена
б м ле зака
о е ни за
р н е
и ин
б т ф
и ь ор
л м
е ац
т ии
о о
в за
ка
зе
из
ба
зы

… … … …

о о С бил
п п ов ет
л л ер
а а ш
т т ит
а и ь
т де
ь не
ж
 н
ы
й
пе
ре
во
д

Стратегии выбора тестов:

· Использованы все состояния

· Произошли все события

· Пройдены пути от входа к каждому выходу

· Выполнены все переходы

Это полезно если приложение сложное, у него много частей и есть много
сценариев взаимодействия.

Классы эквивалентности и граничные значения

Equivalence Partitioning – техника тест-дизайна, при которой множество

всех возможных наборов тестовых данных разбивается на классы

· Тесты с данными из одного класса предназначены для выявления

одной и той же ошибки

· Для тестирования выбираем по одному представителю из каждого

класса

Признаки эквивалентных классов

· Если один из тестов в классе выявит ошибку, то и все остальные

тесты в этом классе найдут ту же ошибку

· Если один из тестов не выявит ошибки, остальные, скорее всего,

тоже этого не сделают

· Тесты используют значения одних и тех же входных параметров

· При выполнении теста используются одни и те же операции
программы, вызываются одни и те же блоки обработки ошибок
программы

· Тесты формируют значения одних и тех же выходных данных

Количество классов:

· Слишком много классов – не уменьшается время тестирования

· Слишком мало классов – увеличивается риск пропустить ошибку

Как разбить на классы эквивалентности:

· Классы допустимых и недопустимых входных данных (значений)

· Фиксированные перечни значений

· Переменные, значения которых должны быть равными

· По диапазонам для числовых значений

· Классы, зависящие от времени

Бронируем билет в кино:

· Для бронирования доступны 10 билетов

· Можно вводить целые одно- и двухзначные числа

· класс эквивалентности меньше 1

· 1-10

· 11-99

· Больше 99

· Буквы и специальные символы

· Дробное число
Анализ граничных значений (boundary value analysis) – техника поиска ошибок на
границах классов эквивалентности.

Часто программа ломается на области граничных значений, из-за сложности в коде.

Границы не всегда найти легко. Данные могут принимать разные замысловатые

значения.

Попарное тестирование (pairwise testing) – метод генерации тестовых данных,

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

Уменьшение количества тестов

Для 3-х полей 10 на 10 на 10

· Полный перебор: 1000 тестов – 50 часов

· Попарное тестирование: 112 тестов – 5,5 часов

Сокращает данные, которые нужно протестировать

Базовые тесты для разных типов данных

(не полный перечень, все зависит от того что нужно для проверки)

· Размер/длина: минимум, среднее значение, максимум, больше максимального,

меньше минимального, ноль.

· Текстовое поле ввода: буквы, цифры, специальные символы (в зависимости от

требований они будут по разному разбиваться на классы эквивалентности); тесты
для длины строки; текст с пробелом (в начале, в середине, в конце, только
пробел); символы которые можно ввести в поле ввода, но нельзя ввести на
клавиатуре; редактирование, копирование; символы конца строки; перенос строки

o SQL injection – ‘; SELECT ” и др.

· Числовые поля: то же, что и для текстовых полей; положительные,

отрицательные, ноль; целые, дробные; степени двойки; научная запись чисел (1Е-
10); римские числа; вычисляемые выражение (2+2)

· Радио-кнопки: любое значение можно выбрать; можно выбрать только 1

значение; можно ли не выбрать ни одного?
 · Чек-боксы: любое значение можно выбрать, можно выбрать любое количество
значений, можно не выбрать ни одного

· Файлы: размер, тип (допустимые и недопустимые типы, требование к

содержанию файла), имя (длина, язык, специальные символы), существование
файла, права на редактирование/удаление.

· Дата и время: границы минуты, часа, дня, недели, месяца, года, столетия;

переход на зимнее/летнее время;

несуществующие значения;

29 февраля;

часовые пояса;

соотношение с «сейчас»;

несколько связанных дат.

Всегда можно подумать, что еще можно проверить.

Описание тест-кейсов

· Обязательно:

o Заголовок (title)

o Шаги (steps)

o Ожидаемый результат (expected result) – чтобы было понятно был баг

или нет для других людей

· Желательно: тип тест-кейса (позитивный, негативный), приоритет (высокий,

низкий, средний) чтобы понять какие тесты нужно выполнить в первую очередь.

· При необходимости: тестовые данные (test data), предусловия – preconditions

(список действий для подготовки окружения к выполнению теста); постусловия -
postconditions (список действий, переводящих систему в первоначальное
состояние)

Как описать тест-кейс:

· Заголовок описывает суть тест-кейса

· При описании использовать активный залог

· Указывайте точные названия элементов приложения

· Используйте простой технический стиль (не объяснять простые вещи)

 · Не объясняйте базовые понятия работы с ОС

Title: попытка войти в систему с неверным паролем

Steps:

Expected result: Вход в систему не выполнен, отображается сообщение об ошибке «…»

Признаки хороших тест-кейсов:

· Один тест-кейс – одна проверка (поправка на уровень, на котором делается

тест-дизайн)

· Не содержит ненужных действий, содержит все необходимые действия

o Шаг теста не нужен, если он не влияет на ожидаемый

результат/логику теста

o Точное воспроизведение шагов в правильно работающей системе

приводит к ожидаемому результату

· Не зависит от других тестов

· Делает обнаруженную ошибку очевидной

· Правдоподобный – существует обоснованная вероятность выявления тестом

ошибки

Хороший набор тест-кейсов

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

сложные тесты и тесты на исключительные ситуации

· Не содержит похожих и дублирующих тестов (одинаковые тесты из одного

класса эквивалентности)

o Если два теста всегда либо вместе обнаруживают одну и ту же

ошибку, либо выполняются без ошибок, то один из этих тестов не
нужен

o Оставить более понятный и легко воспроизводимый

· Гибок для модификации – требования изменятся не «если», а «когда»

o Легко добавить, изменить или убрать шаг, в том числе в середине

теста
 o Легко добавить, изменить или убрать тестовые данные

o Логическая группировка – при изменении функции все связанные

тесты находятся рядом друг с другом

o Выносить часто повторяющиеся действия в отдельный блок

Зачем записывать тест кейсы:

· Чтобы не забыть

· Способ хранения части проектной информации

· Сокращает время на освоение продукта новыми сотрудниками

Пример тест-дизайна:

Тестируем форму регистрации.

Сценарии использования:

Тестирование отдельных полей.

Особенности тестирования веб-приложений (Лекция 5)

Архитектура веб-приложения.

Веб приложение – клиент-серверное приложение, в котором клиентом выступает

браузер, а сервером – веб-сервер. Логика веб-приложений распределена между
сервером и клиентом, хранение данных осуществляется преимущественно, на
сервере, обмен информацией происходит по сети. Одним из преимуществ такого
подхода является тот факт, что клиенты не зависят от конкретной ОС пользователя,
поэтому веб-приложения являются кроссплатформенными сервисами.

Сайт, на котором есть какой-то интерактив. Эл. Почта, соц сеть, онлайн банк и др.

· клиент – браузер

· Сервер – веб-сервис, обслуживающий запросы

· Канал связи – интернет

Особенности

· Много клиентов

· Много серверов

· Сбой может произойти в любой части приложения

· Со стороны клиента мы видим только симптомы ошибки

· Сложность синхронизации данных, времени

Связь

HTTP hypertext transfer protocol (Протокол передачи гипертекста)

HTTP-сообщение

(Для chrome) Для начала вызываем инструменты разработчика (developer tools): f12
или ctrl+shift+I или cmd+opt+i

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

Структура HTTP-сообщения

Стартовая строка (starting line)

Get (метод)

/training/- путь к ресурсу относительно корня

http/1.1 – версия протокола

Заголовки (Headers)

В формате «Название: значение»

Host: … - адрес корня сайта – host uri (унифицированный идентификатор ресурса)

Cache-control: max-age=0

Authorization: ”basic hxzdfgljm”

Content-type: “application/json”

Тело сообщения (Message body)

…………………..dfsgg……………………
}

Методы HTTP-запросов

Get – запрос ресурса

· Параметры передаются в URI

· Ответное сообщение содержит ресурс

· Примеры:

Адрес сайта

Поисковая выдача гугла

Картинка

Post – передача пользовательских данных

· Параметры передаются как в заголовках запроса, так и в uri

· Данные передаются в теле запроса

· Тело ответного сообщения содержит итог выполнения запроса

Put – создание ресурса

UPDATE – обновление ресурса

DELETE – удаление ресурса

Код статуса: целое трёхзначное число, часть стартовой строки ответа сервера

HTTP/1/1 200 OK

· 200 – ok

· 404 – not found

· 503 – service unavailable

Тестировщику необходимо проверять, что возвращается нужный код статуса.

Postman – программа для работы с запросами.

Клиент:
Толстый и тонкий клиент

Тонкий клиент – задачи выполняет сервер

Пример: Онлайн-банк

Толстый клиент – задачи выполняет клиент, сервер может хранить данные

Пример: графический редактор онлайн

Структура страницы:

Принцип один: клиент получает ответ от сервера и чтобы показать пользователю

страницу клиент строит dom (document object model) – модель страницы на основе
html-кода

Первоначально dom может меняться динамически. Для этого используется java script –
это скриптовый язык программирования. Он обеспечивает интерактивность на стороне
клиента: анимация, валидация, взаимное расположение и др.

Баги связанные с неправильным расположением элементов называются багами

верстки.

Ошибки при работе java script можно видеть в консоли браузера, которая находится в
инструментах разработчика.

AJAX (Asynchronous JavaScript and XML) – когда браузер и веб-сервер общаются

незаметно для пользователя.

Примеры: автоматический выход через 5 минут, обновление счетчика сообщений в

мессенджере, загрузка новой статьи при прокрутке страницы)

Операции на клиентской стороне:

1. Отправка запроса

2. Получение данных от сервера

3. Анализ данных и формирование DOM

4. Загрузка ресурсов: изображений, стилей, вложенных фреймов,

JavaScript

5. Выполнение JavaScript-кода: модификация DOM, загрузка

дополнительных ресурсов

Практика:

Данные:
Cookie – небольшой фрагмент данных, отправленный веб-сервером и хранимый на
компьютере пользователя (обычно хранится информация по идентификации вашего
компьютера, темы оформлений сайта и другие настройки)

При каждом последующем обращении к серверу, браузер отсылает куки обратно.

Куки можно не только получать с веб-сервера, но и устанавливать на клиентской

стороне с помощью скрипта.

Для просмотра куки можно воспользоваться инструментом разработчика. На вкладке

компликешнс в разделе кукис выбираем нужный домен и видим все куки с него

Кэш

Кэширование – сохранение данных на сервере или со стороны клиента для доступа к

ним.

Сервер кэширует статичные часто запрашиваемые данные.

Браузер – почти все.

Движок – программа, преобразующая DOM в изображение на экране.

Примеры движков: blink, webkit, blink…

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

Макет подстраивается под размеры экрана.

Разные размеры окна браузера.

Планшеты и смартфоны в разных положениях .

Device mode – быстрый и всегда под рукой, но не всегда соответствует

действительности. Эмуляция размеров экрана устройства.

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

Во время тестирования отключаем adblock и другие блокировщики чего бы то ни было.

Валидация

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

Валидация на клиенте выполняется до отправки данных на сервер.

Типичные проверки: ограничение на длину поля, обязательность, специфичные поля

(номер телефона, дата рождения, адрес эл. Почты…)
На сервере – после отправки данных.

· Проверки те же, что и на клиенте.

· Уникальность логина/почты при регистрации.

· Правильность пароля при входе

· Наличие нужных прав.

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

Мобильное приложение - ПО, предназначенное для работы на смартфонах,

планшетах и других мобильных устройствах

Типы:

● нативные - разрабатываются специально под конкретную платформу с

использованием “родного” языка программирования
● мобильные веб-приложения - сайт оптимизированный под мобильное
устройство. Код пишется под все платформы сразу. Они не устанавливаются в
устройство. Для работы нужен интернет
● Гибридные - сочетают в себе как нативных, так и мобильных веб-приложений.
Требуют подключения к интернету, код пишется сразу на все платформы и
частично приложения пишутся на стандартном языке программирования, а
частично на html5.

Каждый производитель мобильных устройств дополнительно пишет свою оболочку. И

это нужно учитывать.

Адаптируемость мобильных приложений. На разных устройствах и в разных

ориентациях (альбомная и портретная).

Различные разрешения экрана.

Особое место занимает retina - общее маркетинговое название жк-дисплеев с

плотностью пикселей больше 300 ppi.

Введен компанией эпл, но прижился в индустрии и используется для дисплеев любых

производителей с высоким показателем ppi.

При таком разрешении человеческий глаз перестает замечать, что картинка состоит из
пикселей.

Картинки предназначенные для ретина экрана не должны попадать на обычный и

наоборот.

Ограниченный размер экрана. Элементов не должно быть много. Сложное

взаимодействие с пользователем.

Важно учитывать безопасность и конфиденциальность. Нужно следить чтобы личные

данные пользователя не попали не в те руки.
Зависимость от сети/каналов связи.

Каждая сеть имеет свои характеристики, которые зависят от провайдера услуг.

В зависимости от сети и каналов связи мобильное приложение должно адекватно на
это реагировать.

Управление сессиями: сколько длиться, от чего зависит, как работает.

Реакция приложения на внешние прерывания:

● sms,mms, звонки, оповещения

● выключение устройства
● переход в режим ожидания
● отключение и подключение провода
● зарядка устройства
● отключение и включение сети
● ...

Нужно, чтобы прерывания, которые идут от самого приложения были

обоснованными и чтобы их было не слишком много.

Виды тестирования моб. приложения.

Тестирование обновлений:

● обновление ОС (потребует ли это вносить изменение в приложение или

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

Тестирование удобства использования (очень влияет на популярность продукта и

конкуретноспособность)

USER Guide|Guidelines - набор рекоменаций от создателе платформы, благодаря

которым приложения выглядят единообразно.

Android - Material Design

IOS - human interface Guidelines

Windows - Design Guidelines

Актуальны и для веб-приложений. Но больше для нативных.

 ● размер элементов и расстояние между ними (ориентироваться на Guidelines)
● отсутствие пустых экранов в приложении (пользователь всегда должен
понимать где он находится и для чего этот экран нужен)
● наличие или отсутствие “нативных” жестов (предусмотрены в самой
платформе)
● постоянная обратная связь с пользователем
- нажатое состояние у всех элементов
- скорость отклика элементов
- сообщения о загрузке
- сообщения при ошибке доступа к сети, BT, GPS
- наличие понятных сообщений при удалении информации
- наличие экрана или сообщения при окончании процесса

Нагрузочное тестирование - наблюдение за использованием памяти и системных

ресурсов. Основное назначение приложение влияет на ожидание производительности.

Случайное тестирование (monkey testing)

● нажатие на несколько кнопок одновременно

● многократное быстрое нажатие на кнопку

Падение приложения (crash) - это экстренная остановка функционирования

приложения и выход из него. В идеале этого быть не должно.

Мультиплатформенное и мультидевайсовое тестирование. Должно правильно

работать на всех конфигурациях устройств.

Лабораторное тестирование - это имитация реальных условий качества связи и

окружающей среды. (в лифте, в подвале, др.)

Аттестационное тестирование - соответствие требованиям и соглашениям,

установленным для различных ОС.

Android

● установочный файл приложения (.apk) согласован с Program Policies

● порядок управления версиями
● Material Design
● прочие требования и рекомендации для отдельных магазинов

IOS

● уникальное имя
● опр. категория
● ссылка для обратной связи с разработчиком
● Human interface Guidelines
● отказ в сертификации по некоторым причинам

Тестирование потребления ресурсов

● утечка памяти
● обработка ситуаций нехватки памяти для функционирования ОС
● недостаток места для установки или работы приложения
 ● отсутствие в некоторых устройствах поддерживаемых приложением функций
● установка и перенос на сд карту
● потребление электроэнергии
● временные файлы

Проблемы тестирования

● Режим ожидания (тестировать при реальных условиях: постоянно гаснет экран

и др.)
● Набор текста (много писаааать приходится тестировщику)
● Смена SIM-карты (приходится переставлять из одного устройства в другое:
выключить, вытащить симку, вставить, включить, долгооооо)
● Тестирование GPS (если в приложении подразумевается использование gps,
гулять по городу и тестировать, сторонние инструменты, которые позволяют
тестировать GPS, мноооого времени)
● Создание скриншотов экрана (постоянно помнить какое устройство вы держите
в руке и как на нём делать скриншот) на андроиде чаще всего кнопка питания и
уменьшения громкости + передать скриншот на компьютер (провод, отправить
по электронной почте, использовать облачные хранилища данных, мноооого
времени)

Инструменты тестирования:

● средства разработчика браузера (элементс ( все элементы страницы),

консорг (ошибки при повреждениях браузера, нетворк (запросы от
сервера и ответы на них)
● понадобится компьютер, кабель и само устройство (для андроида
средство разработчика гугл хрома; для ios понадобится средство
разработчика сафари и macos (без него никак), откроется веб инспектор
со всеми основными разделами)
● если под рукой нет устройства (смартфона), то можно использовать
google chrome (toggle device toolbar). Он позволяет выбрать девайс, на
котором вы хотите протестировать и браузер сам подстроит размеры
экрана под этот девайс.
● Есть специальные приложения (симуляторы и эмуляторы)
● Эмулятор - аналог мобильного устройства, в котором может быть
предусмотрен ряд ограничений по функционалу, возможностям и
поведению
● Симулятор - модель оригинального мобильного устройства, в которой
реализуется его логика работы и копируется интерфейс.
На них невозможно протестировать сложное взаимодействие с
пользователем. Есть ограничения.

Симуляторы для IOS - xcode simulator.

Облачные сервисы - позволяют удаленно протестировать свой продукт

на множестве устройств. Есть устройство подключенное к компу и веб
камера, которая на него смотрит. Сервисы платные.

● perfecto mobile
● device everywhere
● …
Автоматизация тестирования:

запустить приложение, перейти на экран, перейти на какой-то элемент…

Не все инструменты для автоматизации позволяют запускать тесты на эмуляторах и

симуляторах. Им часто нужно только устройство.

+ Appium (позволяет запускать на эмуляторах, симуляторах и реальных

устойствах)
+ Calabash

Обзор гибких методологий разработки ПО

заказчик+бизнес-аналитик+менеджер - управление продуктом

менеджер+QA lesd+ dev lead - управление проектом

dev lead + разработчик + дизайнер - разработка

Проектный треугольник
Каскадная модель разработки

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

На этапе тестирования мы знаем в каждом случае какой ожидаемый результат.

Минусы:
● отсутствие обратной связи между этапами (мы не можем просто вернуться к
анализу и поправить маленький кусочек)
● высокая стоимость ошибки
● нельзя изменить требования (их хочется менять, чтобы они лучше подходили к
реальности)
 ● у клиента и пользователей нет возможности ознакомиться с предварительной
версией ПО

Каскадная модель не позволяет быстро реагировать на изменяющуюся

реальность. Поэтому стали появляться другие модели.

Каскадная модель - применение

● медицина
● космос
● авиация

Когда нужна надежность. И много проверок.

Agile

Гибкие методологии разработки.

Это набор принципов, а не готовый сценарий, которым можно пользоваться.

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

разработки.

Итеративная разработка. Берем цикл из водопада и повторяем много-много раз. Один

раз это итерация.

Основные идеи:

● личности и их взаимодействия важнее, чем процессы и инструменты

● работающее ПО важнее, чем полная документация (не значит, что
документацию можно игнорировать вообще)
● сотрудничества с заказчиком важнее, чем контрактные обязательства
● реакция на изменения важнее, чем следование плану

Но все остальное тоже важно, просто в меньшей степени.

Принципы agile-манифеста.
 1. Наивысший приоритет - удовлетворение потребностей заказчика, благодаря
регулярной и ранней поставке ценного ПО. (Цель - максимально быстро
реагировать на требования от заказчика).
2. Изменение требований приветствуется, даже на поздних стадиях разработки.
Agile-процессы позволяют использовать изменения для обеспечения заказчику
конкурентного преимущества. Работающий продукт следует выпускать как
можно чаще, с периодичностью от пары недель до пару месяцев.
Регрессионное тестирование делаем часто и много. И это нужно закладывать
на этапе планирования.
3. На протяжение всего проекта разработчики и представители бизнеса должны
ежедневно работать вместе. Получать обратную связь. В идеале заказчик сам
хочет помочь вам разобраться в требованиях. Но видимо так не бывает)
4. Над проектом должны работать мотивированные профессионалы. Чтобы
работа была сделана, создайте условия, обеспечьте поддержку и полностью
доверьтесь им. Для команды это значит большие возможности. Если вы
видите, что можно сделать лучше, вы берете и делаете лучше. Но принимаете
на себя ответственность.
5. Непосредственное общение является наиболее практичным и эффективным
способом обмена информацией как с самой командой, так и внутри команды.
Все много общаются между собой. Быстрая передача информации.
6. Работающий продукт - основной показатель прогресса. Если продукт работает,
значит с задачей справились. Иногда могут чуть меньше внимания уделять
мелким дефектам или качеству кода. Но несовершенства могут накапливаться
и мешать выпускать продукт с той же регулярностью. Нужно все равно
исправлять проблемы.
7. Инвесторы, разработчики и пользователи должны иметь возможность
поддерживать постоянный ритм бесконечно. Agile помогает наладить такой
устойчивый процесс разработки.
8. Постоянное внимание к техн. совершенству и качеству проектирования
повышает гибкость проекта. Чтобы мы могли долго работать, нужно чтобы оно
было качественным и технически грамотным и аккуратно сделанным.
9. Простота - искусство минимизации лишней работы - крайне необходима.
Иногда достаточно итерации. Если какая-то работа не приносит пользы, не
нужно делать ее для галочки.
10. Самые лучшие требования, архитектурные и технические решения рождаются
у самоорганизующихся команд. Которые сами знают как наилучшим образома
достичь того что нужно.
11. Команда должна систематически анализировать возможные способы
улучшения эффективности и соответственно корректировать стиль своей
работы. Приложения выдвигают все члены команды.

Agile - команда

● учитывает интересы всех членов команды при планировании работы

● кроссфункциональная - нет закрепления отдельных ролей, но может быть
специализация (это было в начале, в идеале), но члены команды могут
помогать друг другу. Вы команда и у вас есть общая цель.
● работает над завершением задач более высокого приоритета в первую очередь
 ● признает наличие проблем, не нужно пытаться делать вид, что проблем нет
(итеративный процесс очень быстрый)
● члены команды помогают друг другу
● тестировщик - полноценный член команды
● ЗА КАЧЕСТВО ПРОЕКТА ОТВЕЧАЕТ ВСЯ КОМАНДА!!!

Scrum - опирается на идеи agile.

● скрам-мастер (scrum-master) - человек следить чтобы команда работала по
скраму
● владелец продукта (product owner, заказчик)
● команда разработки

Итерация/Спринт (Sprint)
● промежуток времени от 1 недели до 1 месяца (длина итерации), на практике 2-3
недели
● в конце итерации есть готовый инкремент (вариант) продукта
● длина итерации не меняется (если две недели, то всегда две недели)
● задачи заканчиваются в той итерации, в которой начались (отличительная
черта скрама)
● не более одного дня задержки между итерациями
● для каждой задачи команда знает, каким образом и от кого получить доп.
информацию

Работа в течение итерации

● приоритеты задач соблюдаются
● в случае отставания от плана команда предпринимает корректирующие
действия, о том что мы можем не успеть мы сразу же говорим владельцу
продукта
● проблемы обсуждаются командой сразу же (проблема - потенциальная
возможность не уложиться в план)
● вся незапланированная работа учитывается

Из чего состоит итерация?

● планирование итерации (sprint planning meeting)
- владелец продукта и все члены команды принимают участие в
планировании
- в бэклог спринта выбираются задачи из бэклога продукта (описаны все
функциональности, которые заказчик в принципе хочет; копилочка для
задач)
- для задач из бэклога спринта описаны критерии приемки
- все члены команды согласны с планом
- план возможно выполнить за итерацию
- каждая задача имеет приоритет внутри итерации (от самой
приоритетной)
- все задачи имеют оценки (обязательно для скрама, позволяет
посмотреть выполним план на итерацию или нет, суммарная оценка
совпадает с тем, что мы делаем обычно или нет, важно, чтобы задачи
были оценены, чтобы можно было процесс контролировать)
 ● ежедневный стендап (скрам)
- в одно и то же время, в одном и том же месте
- не более 15 минут
все принимают участие
-статус (что я сделал с момента прошлой встречи? что я планирую
сделать сегодня? вижу ли я препятствия для себя и команды?
● демо (demo) - встреча, где показывается прогресс за спринт
- в идеале проводится после каждой итерации
- демонстрируется работающее ПО
- на демо приглашаются все, кому будет интересен продукт
- владелец продукта корректирует бэклог продукта в соответствии с
пожеланиями заинтересованных лиц
● ретроспектива (retro) - митинг, встреча, в идеале проводится каждую
итерацию, в конце итерации после демо. Хорош ли наш процесс
разработки. Не о конкретных людях, а о процессе в целом.
- участвуют все члены команды и владелец продукта.
- каждый участник говорит: что было хорошо? что было плохо? какие
проблемы?
- разрабатывается план действий (два списка: что было хорошо? и это
применяем дальше. Что было плохо? по каждому пункту обсуждение,
где пытаются найти решение)
- разрабатывается план действий

Доска задач (scrum board)

Можно посмотреть что мы сейчас разрабатываем.

● колонки
- планы (to do)
- в работе (in progress)
- готово (done)

Это минимум колонок, которые есть. Обычно их больше.

Разделяют задачи, которые в разработке и которые в тестировании.
● каждая задача В работе имеет ответственного
● на стендапе доска задач актуализируется
● доска очищается после каждой итерации ( к моменту демо все задачи
перемещаются из колонки планы в колонку готово)

Kanban

похож на scrum, но имеет отличительные особенности.

В каждый момент времени у нас есть набор задач и их приоритеты.
Принципы:
● визуализировать работы (доска не сильно отличается)
● завершать каждую задачу как можно быстрее к пользователю (сначала
завершаем то, что уже в работе) задачи максимально быстро продвигаются в
колонку готово
- непрерывная поставка (continuous delivery) - новая разработка
оказывается у пользователя автоматически, не нужно ждать конца
спринта

● ограничивать работу (wip-limits|work-in-progress limits) чтобы задачи не

накапливались, которые могут быть в задании на тестировании. Если
загрузилось, значит процесс нужно модифицировать, чтобы тикеты не
скапливались у тестироващика.

Разница между scrum и kanban

Экстремальное программирование - еще один подход к agile-разработке.

Сейчас не очень широко используется. Но некоторые их принципы используются
повсеместно.

Разработка через тестирование (test-driven development, tdd) - разработчик когда

собирается писать кусочек кода, сразу пишет юнит тесты. Сначала пишет тесты на
новую функциональность, а потом пишет код.

Непрерывная интеграция (continuous integration) - как только разработчик делает

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

Этот подход превратился в continuous delivery

Рефакторинг - меняем код, не меняя функциональности. Чтобы программа работала
стабильнее. Два месяца ничего не происходит, а после рефакторинга нужно сделать
полное регрессионное тестирование.

Спиральная модель.

Объединяет в себе возможность завершить проект в обозначенный срок и гибкость

agile. Чтобы это реализовать используется подход MVP

MVP - минимально жизнеспособный продукт (minimum viable product) - продукт,

обладающий достаточным кол-вом Ф для сбора данных и изучения вариантов
дальнейшего развития продукта.

Вся работа по спиральной модели, мы делаем маленький вариант продукта и

постепенно наращиваем функциональность.

В каждой виток спирали входит:

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

Особенности спиральной модели

 ● итеративная разработка (на один виток спирали может приходиться как одна
итерация, так и несколько)
● недостающую работу можно будет выполнить на следующей итерации
● главная задача - как можно быстрее показать первую работающую версию
продукта (быть продукту или не быть)
Основные риски:
● дефицит специалистов (риск менеджера)
● нереалистические сроки и бюджеты (качество влияет на сроки и на бюджет)
● реализация несоответствующей функциональности (риск разработать не то)
● разработка неправильного интерфейса
● “золотая сервировка”, перфекционизм, ненужная оптимизация и оттачивание
деталей при плохо сделанной основной функциональности
● непрекращающийся поток изменений
● нехватка информации о внешних компонентах, определяющих окружение
системы или вовлеченных в интеграцию
● недостатки в работах, выполняемых внешними (по отношению к проекту)
ресурсами
● недостаточная производительность получаемой системы
● разрыв между квалификацией специалистов и требованиями проекта