QA_Bible
  • Введение
  • FAQ для новичков
    • Ответы на самые популярные вопросы новичков в чатах
    • Качества и навыки, которыми нужно обладать тестировщику?
    • Что должен знать и уметь Junior? Что спросят на собеседовании?
    • С чего начать обучение и куда развиваться?
    • Как составить резюме?
    • Где искать работу?
    • Как происходит процесс найма?
    • Как проходить собеседование?
    • Начало работы Junior-тестировщика
    • Ошибки в работе у начинающих тестировщиков
    • Как взаимодействовать с коллегами?
    • Перспективы профессии
  • Полезные ссылки
    • Список полезных ресурсов на разных платформах
    • Список ресурсов по инструментам тестировщика
  • Общее
    • QA/QC/Testing
    • Почему требуется тестирование ПО?
    • Качество ПО (Software Quality)
    • Принципы тестирования
    • Верификация и валидация (Verification and Validation)
    • Дефекты и ошибки
    • Серьезность и приоритет Дефекта (Severity & Priority)
    • Альфа- и бета- тестирование (Alpha Testing and Beta Testing)
    • Процесс тестирования (test process) (draft)
    • Техники оценки тестов/оценка трудозатрат на тестирование (Test Estimation)
    • Экономика тестирования/стоимость качества (Cost of quality)
    • Подход к тестированию (Test Approach)
    • Импакт анализ (анализ влияния, Impact Analysis)
    • Анализ первопричин (RCA - Root Cause Analysis)
    • Тестирование со сдвигом влево (Shift left testing)
    • Модель зрелости возможностей (CMM - Capability Maturity Model)
    • Тестовая среда и тестовый стенд (Test Environment/Test Bed)
    • Бизнес-логика (Business logic)
    • Политика отсутствия багов (ZBP - Zero Bug Policy)
    • Независимое тестирование (Independent testing)
    • Роли/должности в команде
    • Эвристики и мнемоники
  • Виды-методы-уровни тестирования
    • Методы тестирования (White/Black/Grey Box)
    • Тестирование методом черного ящика (Black Box Testing)
    • Тестирование методом белого ящика (White Box Testing)
    • Тестирование методом серого ящика (Grey Box Testing)
    • Статическое и динамическое тестирование (Static Testing, Dynamic Testing)
    • Пирамида / уровни тестирования (Test Pyramid / Testing Levels)
    • Модульное/юнит/компонентное тестирование (Module/Unit/Component testing)
    • Интеграционное тестирование (Integration testing)
    • Системное тестирование (System Testing)
    • Приемочное тестирование (AT - Acceptance testing)
    • Основные виды тестирования ПО
    • Функциональное тестирование (Functional/Behavioral testing)
    • Нефункциональное тестирование (Non-Functional testing)
    • Тестирование производительности (Performance testing)
    • Тестирование емкости (Capacity testing)
    • Нагрузочное тестирование (Load testing)
    • Стрессовое тестирование (Stress testing)
    • Тестирование масштабируемости (Scalability testing)
    • Объемное тестирование (Volume testing)
    • Тестирование выносливости/стабильности (Endurance/Soak/Stability testing)
    • Тестирование устойчивости (Resilience testing)
    • Тестирование надежности (Reliability Testing)
    • Тестирование на отказ и восстановление (Failover and Recovery testing)
    • Эталонное и базовое тестирование (Benchmark and Baseline Testing)
    • Тестирование хранилища (Storage testing)
    • Одновременное / многопользовательское тестирование (Concurrency/Multi-user testing)
    • Тестирование сервиса (Service Testing)
    • Тестирование безопасности (Security and Access Control testing)
    • Оценка уязвимости/защищенности (Vulnerability Assessment)
    • Фаззинг-тестирование (Fuzz testing)
    • Можно ли отнести тестирование безопасности или нагрузочное тестирование к функциональным видам тести
    • Тестирование совместимости/взаимодействия (Compatibility/Interoperability testing)
    • Конфигурационное тестирование (Configuration testing)
    • Инсталляционное тестирование (Installation Testing)
    • Тестирование на соответствие (Conformance/Compliance testing)
    • Тестирование удобства пользования (Usability testing)
    • Тестирование доступности (Accessibility testing)
    • Тестирование локализации, глобализации и интернационализации (Localization/ globalization/internatio
    • Исследовательское тестирование (Exploratory testing)
    • Свободное / Интуитивное тестирование (Adhoc, Ad-hoc Testing)
    • Тестирование поддержки (Maintenance testing)
    • Регрессионные виды тестирования (Regression testing)
    • Тестирование клиентской части и серверной (Frontend testing Vs. Backend testing)
    • Тестирование графического интерфейса/визуальное тестирование (GUI - Graphical User Interface testing
    • Тестирование API (API - Application Programming Interface)
    • A/B тестирование (A/B Testing)
    • Деструктивное и недеструктивное тестирование (DT - Destructive testing and NDT - Non Destructive tes
    • Выборочное/хаотическое тестирование (Random/monkey testing)
    • Тестирование рабочего процесса/воркфлоу (Workflow testing)
    • Тестирование документации (Documentation testing)
    • Как протестировать продукт без требований?
    • Кроссбраузерное тестирование (Cross-browser testing)
    • Тестирование, основанное на рисках (Risk-Based Testing)
    • Разница тестирования ПО и железа (Software Vs. Hardware testing)
    • Тестирование качества данных (Data Quality Testing)
  • Тест дизайн
    • Тест-дизайн и техники тест-дизайна (Test Design and Software Testing Techniques)
    • Static - Reviews
    • Static - Static Analysis
    • Dynamic - White box
    • Dynamic - Black box
    • Dynamic - Experience based
  • Тестовая документация и артефакты (Test Deliverables/test artifacts)
    • Виды тестовой документации
    • Политика качества и политика тестирования (Quality policy and Test policy)
    • Стратегия тестирования (Test strategy)
    • План тестирования (Test plan)
    • Тестовый сценарий (Test scenario)
    • Тест-кейс (Test case)
    • Чек-лист (Check List)
    • Баг-репорт (Defect/bug report)
    • Требования (Requirements)
    • Пользовательские истории (User stories)
    • Критерии приемки (Acceptance Criteria)
    • Виды отчетов (Reports)
    • Базис тестирования (Test basis)
    • Матрица трассируемости (RTM - Requirement Traceability Matrix)
    • Метрики тестирования (Software Test Metrics)
    • Тестовый оракул (Test oracle)
  • Мобильное тестирование
    • Android
      • Архитектура Android OS
      • Архитектура Android Application
      • Тестирование покупок в Android-приложениях
      • Android Developer Settings
      • Android Debug Bridge (ADB)
      • Android Studio для QA
    • iOS
      • Архитектура iOS
      • Архитектура iOS Application
      • Тестирование покупок в iOS-приложениях
      • iOS Developer Settings
    • Особенности в тестировании мобильных приложений
    • Покрытие девайсов
    • Типы мобильных приложений
    • Симуляторы и эмуляторы
    • Основные различия Android/iOS
    • Последнее обновление Android/iOS, что нового?
    • Основные проверки при тестировании мобильного приложения
    • Каким образом тестировщик получает приложение на тест?
    • Как успешно зарелизить продукт в App Store и Google Play
    • Тестирование требований к мобильным приложениям
    • Тестирование push-уведомлений
    • Тестирование дип линков (mobile deep links)
    • Тестирование сохраненных поисков
    • Тестирование рекламы
    • Тестирование просмотренных товаров
    • Middleware
    • Как проверить использование ресурсов на Android
    • Как протестировать приложение для другой страны?
  • Тестирование в разных сферах-областях (testing different domains)
    • Тестирование веб-сайта или веб-приложения (Web application)
    • Тестирование интернет-магазина (eCommerce)
    • Тестирование платежного шлюза (Payment Gateway)
    • Тестирование игр (Game testing)
    • Тестирование VR программного обеспечения
    • Тестирование мессенджера (Messenger)
    • Тестирование чат-бота (Chatbot)
    • Тестирование электронных писем (E-mail)
    • Тестирование интернета вещей (IoT - Internet of Things)
    • Тестирование облачных решений (Cloud testing)
    • Тестирование сервис-ориентированной архитектуры (SOA - Service Oriented Architecture)
    • Тестирование микросервисной архитектуры (MSA/Microservices)
    • Тестирование платформы электронного обучения (E-learning platform)
    • Тестирование систем розничной торговли (POS - Point Of Sale)
    • Тестирование банковского ПО (Banking domain applications/BFSI)
    • Тестирование страхового ПО (Insurance)
    • Тестирование в сфере телекоммуникаций (Telecom)
    • Тестирование планирования ресурсов предприятия (ERP - Enterprise Resource Planning)
    • Тестирование миграции данных (ETL)
    • Тестирование баз данных (Database)
    • Другое
  • SDLC и STLC
    • Жизненный цикл разработки ПО (SDLC - Software Development Lifecycle)
    • Жизненный цикл тестирования ПО (STLC - Software Testing Lifecycle)
    • Модели разработки ПО
    • Agile
    • Scrum
    • Подходы к разработке/тестированию (... - driven development/testing)
  • Сети и около них
    • База по сетям
    • Клиент - серверная архитектура (Client-Server Architecture)
    • Микросервисная архитектура (Microservice Architecture)
    • Эталонные модели OSI и TCP/IP
    • HTTP
    • Идентификация ресурсов в сети (Identifying resources on the Web)
    • Веб-сервис (WS - Web service)
    • REST/SOAP/gRPC
    • Socket / WebSocket
      • Сокет/веб-сокет (socket/websocket)
      • Тестирование WebSocket на клиентах
    • Хранилище на стороне клиента (Client-side storage)
    • Кэш (Cache)
    • Аутентификация и авторизация (Authentication and authorization)
    • Рендеринг в интернете (Rendering on the Web)
  • Практическая часть
    • Логические задачи
    • Тестирование полей и форм
    • Примеры задач на собеседованиях и тестовых заданий
    • Платформы для тренировок и квизы
  • Автоматизация (beta)
    • Общее
    • Полезные ссылки
    • Как стать автоматизатором и вопросы с собеседований
    • Что нужно автоматизировать?
    • Виды и инструменты автоматизации
    • Инфраструктура и пайплайн (CI/CD)
    • Процессы и автоматизация проекта с нуля
    • Лучшие практики автоматизации
    • Что такое flaky tests?
    • Мутационное тестирование (Mutation testing)
    • Параллельное тестирование (Parallel testing)
    • Подкожный тест (Subcutaneous test)
    • Разница между coupling и cohesion
    • Другое (ссылки)
  • Контакты
Powered by GitBook
On this page

Was this helpful?

Edit on GitHub
  1. SDLC и STLC

Scrum

PreviousAgileNextПодходы к разработке/тестированию (... - driven development/testing)

Last updated 3 years ago

Was this helpful?

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

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

Ценности:

  • Преданность (Commitment): Члены команды лично привержены достижению целей команды;

  • Смелость (Courage): Члены команды поступают правильно и работают над сложными проблемами;

  • Сфокусированность (Focus): Сконцентрируйтесь на работе, намеченной для спринта, и целях команды;

  • Открытость (Openness): Члены команды и заинтересованные стороны открыто рассказывают обо всей работе и проблемах, с которыми сталкивается команда;

  • Уважение (Respect): Члены команды уважают друг друга за способности и независимость.

Принципы:

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

  • Инспекция (Inspection): Частые контрольные точки встроены в структуру, чтобы дать команде возможность поразмышлять о том, как работает процесс. Эти контрольные точки включают в себя Daily Scrum meeting и the Sprint Review Meeting;

  • Адаптация (Adaptation): Команда постоянно изучает, как идут дела, и проверяет те пункты, которые кажутся бессмысленными.

События:

  • Спринт (Sprint): это временной интервал в 2-4 недели, в течение которого команда создает потенциально готовый к поставке инкремент продукта;

  • Планирование спринта (Sprint Planning): Команда начинает спринт с обсуждения, чтобы определить, над какими элементами из бэклога продукта (product backlog) они будут работать во время спринта. Конечным результатом планирования спринта является бэклог спринта (Sprint Backlog). Планирование спринта обычно состоит из двух частей. В первой части владелец продукта и остальная часть команды согласовывают, какие элементы бэклога продукта будут включены в спринт. Во второй части планирования спринта команда определяет, как они будут успешно доставлять идентифицированные элементы Product Backlog как часть потенциально возможного инкремента продукта. Команда может определить конкретные задачи, необходимые для этого, если это одна из их практик. Элементы Product Backlog, определенные для доставки, и задачи, если применимо, составляют бэклог спринта. После того, как команда и владелец продукта установят объем спринта, как описано в элементах Product Backlog, никакие дополнительные элементы не могут быть добавлены в журнал Sprint Backlog. Это защищает команду от изменений в рамках этого спринта;

  • Ежедневная встреча (Daily Scrum/Meeting): это короткое (обычно не более 15 минут) обсуждение, во время которого команда координирует свои действия на следующий день. Дейли не предназначен для обсуждения статуса или обсуждения проблем;

  • Обзор спринта (Sprint Review): в конце спринта вся команда (включая владельца продукта) рассматривает результаты спринта с заинтересованными сторонами продукта. Цель этого обсуждения - обсудить, продемонстрировать и потенциально дать заинтересованным сторонам возможность использовать инкремент для получения обратной связи. Обзор спринта не предназначен для предоставления отчета о состоянии (status report). Отзывы об обзоре спринта помещаются в Product Backlog для дальнейшего рассмотрения;

  • Ретроспектива спринта (Sprint Retrospective): в конце спринта после обзора спринта (sprint review) команда (включая владельца продукта) должна подумать о том, как дела шли во время предыдущего спринта, и определить корректировки, которые они могут внести в будущем. Результатом этой ретроспективы является как минимум одно действие, включенное в бэклог следующего спринта;

  • Упорядочение бэклога ();

Артефакты:

  • Бэклог продукта (Product Backlog): это упорядоченный список всех возможных изменений, которые могут быть внесены в продукт. Пункты в бэклоге продукта являются вариантами, а не обязательствами, и то, что они существуют в бэклоге продукта, не гарантирует, что они будут доставлены. Владелец продукта постоянно ведет бэклог продукта, включая его содержание, доступность и порядок;

  • Бэклог спринта (Sprint Backlog): это набор элементов из бэклога продукта, выбранных для доставки в спринте. После того, как команда определяет задачи, эти задачи необходимо выполнить для достижения цели спринта (Sprint Goal);

  • Инкремент (Increment): это набор элементов из бэклога продукта, которые соответствуют Definition of Done к концу спринта. Владелец продукта может решить выпустить дополнение или развить его в будущих Спринтах;

Роли:

  • Владелец продукта (Product Owner): роль, ответственная перед командой за управлением бэклогом продукта для достижения результатов, к которым стремится команда. Роль product owner-а существует в Scrum для решения проблем, когда команда разработки имеет множественные противоречивые направления движения или отсутствие направления вообще в отношении того, что создавать;

  • Команда разработки (Development Team): состоит из людей, которые создают инкремент продукта внутри спринта. Основная ответственность команды разработки - обеспечить инкремент, который приносит пользу каждому спринту. Как распределить работу, это остается на усмотрение команды в зависимости от условий на тот момент.

Жизненный цикл Scrum:

  • Создайте бэклог продукта;

  • Владелец продукта и команда разработчиков проводят планирование спринта. Определите объем спринта в первой части планирования спринта и план реализации этого объема во второй половине планирования спринта;

  • По мере продвижения спринта команда разработчиков выполняет работу, необходимую для доставки выбранных элементов бэклога продукта;

  • Команда разработчиков ежедневно координирует свою работу в рамках Daily Scrum;

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

  • Команда повторяет шаги 2-5 до тех пор, пока не будет достигнут желаемый результат.

Стори поинты (Story points)

Источники:

Доп. материал:

Особенности тестирования в Scrum:

Критерии Готовности (): это общее соглашение команды о критериях, которым должен соответствовать элемент бэклога продукта, прежде чем он будет считаться выполненным$

Пользовательские истории ();

Цель спринта ();

Диаграмма сгорания задач ().

Скрам Мастер (Scrum Master): роль, ответственная перед командой за то, чтобы команда придерживалась гибких ценностей и принципов и следовала процессам и практикам, которые команда согласилась использовать. Изначально это имя предназначалось для обозначения кого-то, кто является экспертом в Scrum и, следовательно, может обучать других. Роль обычно не имеет никаких фактических полномочий. Люди, выполняющие эту роль, должны руководить с позиции влияния, часто занимая позицию лидера-слуги ();

Чтобы оценить объем работы над Элементом Бэклога Продукта, Скрам-команды обычно используют Стори Поинты (, ). Это условная величина, позволяющая давать Элементам Бэклога относительные веса. Чаще всего для оценки в Стори Поинтах используются числа Фибоначчи (1, 2, 3, 5, 8, 13, …), что позволяет провести оценку достаточно быстро.

,

Grooming
Definition of Done
User Story
Sprint Goal
Burndown chart
servant-leadership
1
2
What is Scrum?
Scrum Guide
Scrum Glossary
Мини-справочник и руководство по Scrum
Scrum-мем на злобу дня
Когда Scrum не работает. Пять основных проблем его применения
Лекция 7: Этапы и мероприятия Scrum
Как провести ретроспективу
Покер планирования - как сделать процесс постановки задач максимально прозрачным и четким
Cheat-sheet
еще одна
Тестирование в рамках SCRUM. Тернии, грабли и успехи
Регрессионное тестирование на Scrum-проектах: руководство по проведению
QA-процесс в Miro: отказ от водопада и ручного тестирования, передача ответственности за качество всей команде
Тесты должна писать разработка (?)
The Role of QA in Sprint Planning
Код-ревью для тестировщиков