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

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

Цикл разработки ПО Цикл (процесс) разработки ПО (software development life cycle) – это путь от идеи до поддержки готового продукта. Чем более отлажены каждая из стадий цикла и координация между ними, тем эффективнее работает компания, тем выше качество и тем счастливее пользователи/клиенты.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Наглядно

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

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

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

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

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

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

Scrum Scrum (от англ. scrum «схватка») - методология управления проектами, активно применяющаяся для гибкой разработки ПО. Scrum чётко делает акцент на качественном контроле процесса разработки.

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

Scrum. Основные понятия Спринт (Sprint) - итерация в скраме, в ходе которой создаётся функциональный прирост ПО. Жёстко фиксирован по времени. Длительность одного спринта от 2 до 4 недель.

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

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

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

Scrum. Процесс

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

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

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

Scrum. Свиньи

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

Scrum. Project Manager?

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

Scrum. Встречи (Meetings) Ежедневное совещание (Daily Scrum meeting): Начинается точно вовремя Все могут наблюдать, но только свиньи говорят Проводится в одном и том же месте в течение спринта В течение совещания каждый член команды отвечает на 3 вопроса: Что сделано с момента предыдущего ежедневного совещания? Что будет сделано с момента текущего совещания до следующего? Какие проблемы мешают достижению целей спринта?

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

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

процесс

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

Waterfall and Agile

Waterfall and Agile

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