Полный глоссарий терминов и определений Agile-тестирования

Полный глоссарий Agile терминов и определений

Приемочное тестирование

Формальное тестирование, проводимое для определения того, удовлетворяет ли система своим критериям приемлемости и позволяет клиенту определить, принимать ли эту систему или нет.

Методология гибкой разработки ПО

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

Обработка отставания 

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

Нарушение сборки

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

Процесс сборки

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

График выгорания

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

Курица

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

Непрерывная интеграция

Непрерывная интеграция (CI) - это практика экстремального программирования (XP), когда члены команды доставки часто интегрируют свою работу (например, почасовую или по крайней мере один раз в день). Каждая интеграция проверяется автоматизированной сборкой, которая также выполняет тестирование, чтобы быстро и автоматически обнаруживать любые ошибки интеграции. Главная цель CI - избегать того, что обычно называют интеграцией или объединением ада.

Межфункциональная команда

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

Клиент

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

Ежедневный Standup

Ежедневная командная встреча обычно проводится первым делом с утра, чтобы предоставить обновленную информацию членам команды. Заседания, как правило, проходят по времени до 5-15 минут и проводятся стоя, чтобы напомнить людям о том, что совещание должно быть коротким и точным.

"Готово" (DOD)

Продукт подходит под критерии принятия работы. Указание этих критериев является обязанностью всей команды, включая бизнес. Как правило, есть три уровня «Готово».

  • Готово. Разработано, работает на платформе разработчика.
  • Готово. Проверено путем запуска модульных тестов, просмотра кода и т. д.
  • Готово. Качество подтверждено функциональными тестами, обзорами и т. д.

Точные критерии того, что составляет «Готово», варьируются для удовлетворения конкретных потребностей различных организаций и инициатив.

Эпик

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

Оценка

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

Экстремальное программирование

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

XP выступает за частые «выпуски» в короткие циклы разработки, целью которых является повышение производительности и внедрение контрольных точек, на которых могут быть приняты новые требования клиентов.

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

Функция

Согласованная бизнес-функция или атрибут программного продукта или системы. Функции обычно содержат множество подробных (единичных) требований. Одна функция обычно реализуется через множество историй.

Функции могут быть функциональными или нефункциональными; Они служат основой для организации историй.

Последовательность Фибоначчи

Последовательность чисел, в которой следующее число получается путем суммирования двух предыдущих (например, 1, 2, 3, 5, 8, 13, 21, 34 ...). Последовательность используется для определения размеров историй в Agile, таких как ,например, покер-планирование.

Помеха

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

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

Итерация

Период (от 1 недели до 2 месяцев), в течение которого команда разработки Agile производит обновление завершенного программного обеспечения. Все этапы жизненного цикла системы (требования, дизайн, код и тест) должны быть завершены в ходе итерации, а затем продемонстрированы для успешного принятия пользователем.

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

Канбан

Kanban - это инструмент, основанный на бережливом производстве и связанный с отраслью гибких практик, которую называют «Lean Software Development». (Бережливая разработка ПО)

Основное различие между Kanban и Scrum заключается в том, что Scrum ограничивает выполняемую работу спринтами и лимитами, Канбан - ограничивает, сколько работ может быть выполнено за один раз (например, N задач или N историй).

Бережливая разработка ПО

Бережливая разработка программного обеспечения ориентирована на оптимизацию потока производства программного обеспечения.

Парное программирование

Методика разработки программного обеспечения, в которой два программиста работают вместе на одной рабочем месте. Лицо, набирающее код, называется драйвером, а человек, просматривающий код называется наблюдателем или навигатором. Два программиста часто меняются ролями.

Свинья

Кто-то, кто отвечает за выполнение задачи на активной итерации. Это противоположно Chicken. Свиньи активно участвуют в проекте.

Покер планирования

Покер планирование в основном используется для оценки усилий или относительного размера задач в области разработки программного обеспечения. Является вариантом "широкополосного предсказателя" с использованием колоды карт со значениями, представляющими число квантов, которыми оценивается работа.

Продукт

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

Владелец продукта

Владелец продукта является одним из ключевых ролей в Scrum. Обязанности владельца продукта включают в себя:

  • Установление целей, общего видения конечного продукта
  • Мониторинг проекта
  • Принятие решения о выпуске официального релиза

Резерв продукта

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

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

Рефакторинг

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

План-релиз

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

Ретроспектива

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

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

Scrum

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

Scrum-команда

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

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

Команда Scrum несет ответственность за все работы и результаты.

ScrumMaster

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

Sprint

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

Задержка спринта

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

Планирование спринта

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

Участники - Scrum-мастер и команда Scrum.

Пользовательская история

Пользовательская история можно рассматривать как требование, функцию, которая имеет некоторую ценность для бизнеса. Истории описывают работу, которая должна быть завершена. Истории являются основной единицей коммуникации, планирования и переговоров между Scrum-командой, владельцем бизнеса и владельцем продукта.

Истории состоят из следующих элементов:

  • Описание с точки зрения бизнеса
  • Размер, как правило, выражается в сюжетных точках (например, 1, 2, 3, 5)
  • Один или несколько критериев приемлемости, давая краткое описание того, как будет подтверждено история

Задача

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

Timebox

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

Скорость продвижения

Сколько работы команда может завершить в итерации. Скорость часто измеряется в истории. Скорость также может измерять задачи в часах или эквивалентных единицах.

Работа в процессе выполнения

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

Хотите стать эффективным тестировщиком? В этом Вам помогут наши курсы курсы тестировщиков.