Please enable JavaScript.

Coggle requires JavaScript to display documents.

Agile Scrum - Coggle Diagram

- - - - 3
        UX (User Experience), юзабилити - то, где мы разместим
        элемент на сайте, корзину, блок, кнопку
        Простота и Удобство использования
      - 2
        UI
  - - - На основе требований
        
        Е2Е
        
        Пример
        
        на пример протестировать работу воспроизведения трека:
        зайти в приложение(любое музыкальное)
        включить трек
        кнопка перемотка вперед
        кнопка перемотка назад
        регулятор громкости
        ползунок перемотки
        остановка на паузу
        снятие с паузы
        и кнопочка зацикливание трека, его повтор
        выйти из приложения
        и того 10 тест кейсов, это е2е тестирование,
        и в тоже время является smoke а так же, получается эти 10 тест кейсов являются тест сьют набором, т.к тестируют определенный функционал
        
        Smoke(системное)
        
        Набор тест suite(сьютов)
        Которые заносим в тестовый цикл
        для проверки билда
        
        Sanity(системное)
        
        Это если в смоук какой то тест кейс не прошел
        или не работает какая то кнопка и
        её пофиксили, то перепроверка этой функции
        Санити тестирование
        
        Регрессионное
        
        Полное
        
        К примеру, когда решена проблема
        с производительностью
        
        При изменении окружения
        Например
        Смена БД с MySQL на Oralce
        
        Частичное
        
        Выбираем тест кейсы в которых часто
        встречаются баги
        
        Граничных значений
        
        Пассивные
        Ввод не правильных данных
        
        Позитивные(в первую очередь)
        
        Для изменений кода в отдельных
        разделов системы
        
        Делается в конце спринта
        
        Интеграционное
        
        Тестирование отдельных модулей
        программы
        
        Приложение имеет 3 модуля, например
        «Страница входа»
        «Почтовый ящик»
        «Удалить электронную почту».
        Каждый из них интегрирован логически.
        
        «Почтовый ящик»: проверьте его
        интеграцию с модулем
        «Удалить электронную почту».
      - Ad-hock / Manking /
        Исследовательское
        
        Без документации
        и требований
        Нужны только для одного
        запуска, если дефект
        не обнаружен
    - - Ревью документов
        Требование к спецификации
        Проектный документ
        Исходный код
    - - минимизирования уровня рисков продукта и информирования заинтересованных лиц о текущем состоянии рисков с начальных стадий проекта.
        Заказчик сказал сделать веб прил.
        Риски - потеря аудитории, т.к нативные приложение лучше
        Информируем заказчика
    - - UI
        То, как будет выглядеть
      - UX - User Experience
        Юзабилити
        то, где мы разместим элемент
        на сайте, корзину, блок, кнопку
        Удобство интерфейса
      - Пример:
        надежность, эффективность,
        юзабилити, поддерживаемость,
        переносимость
    - - На этом этапе проводится не только функциональное тестирование, но и оценка характеристик качества системы - ее устойчивости, надежности, безопасности и производительности.
    - - Это GUI(UI)
      - нужно выполнить
        
        Проверка производительности
        Изменения или обновления
        приложения, которые могут сломать
        функциональность интерфейса
    - - проверяет серверную часть мобильного приложения. Все, что введено и / или сохранено во внешнем интерфейсе, проверяется во внутреннем. Также проверяется безопасность и производительность мобильного приложения.
    - - Test cases
        
        Установка и удаление
        
        Функциональность
        
        Обмен данными
        
        Интерфейс
        
        Обязательно протестируйте разные версии основных платформ (iOS и Android).
  - - - Обычное системное
        тестирование
    - - Смесь Black box и While box
        Тестируется API
    - - Баги заводятся на уровне
        кода
  - - - Анализ граничных значений
        
        Проверить от 1 до 10
        Это: - 1, 1, 2, 5, 9, 10, 11
        До, само, после, середина, и, до, само, после
      - разделение на классы
        эквивалентности
        
        делит вводимые данные
        на классы эквивалентных друг другу значений,
        на базе которых создаются тест-кейсы
        один тест находит ошибку, то и другой,
        скорее всего, найдет ошибку и наоборот
        
        Пример
        
        От 1 до 1000
        
        2 класс Недопустимые значения
        От - ∞ до 0.
        От 1001 до + ∞.
        Специальные символы (# @ + — / _ : ; “ ‘ и т.д.).
        Буквы.
        
        Итого минимум 5 тестов:
        46, -37, 1773, Имя, $_=#.
    - - GIVEN - дано
        WHEN - когда я сделал что то
        AND - и сделал дополнительно что то, дополнительный шаг (ввел имя AND пароль в след шаге)
        THEN - увидел что то
  - - - тест E2E всегда является системным
        тестом, но системный тест не обязательно
        является тестом E2E.
        Пример
        
        Добавить товар в корзину
        Оформить заказ
        Оплатить
        Завершить
    - - На этом этапе проводится не только функциональное тестирование, но и оценка характеристик качества системы - ее устойчивости, надежности, безопасности и производительности.
  - - - На пример нужно:
        проверка функциональности входа
    - - Описание по пунктам всевозможных
        сценариев проверки тестового сценария
  - - - SDET (Software Development Engineer in Test) инженер по разработке ПО в тестировании — это ИТ-специалист, который может одинаково эффективно работать в сфере разработки и тестирования, и он / она принимает участие в полном процессе разработки ПО. В отличие от Quality Analyst (QA), которым желательны базовые знания в программировании, но нет необходимости писать код, SDET это делает на постоянной основе, совмещая в себе и тестировщика и разработчика.
      - Состоит из:
        Dev
        QA
        Автоматизаторы qa
        SDET
      - QA ручные тесты
        UI и е2е qa и команда по автоматизации
        API - иногда dev, Автоматизаторы и SDET
        Unit - разрабы
- - - - На этом этапе, на основе требований, тестировщики могут начинать писать тест кейсы, подбирать инструменты тестирования, определять для себя риски, время, и если какой то функционал меняется или добавляется, думать примерно какие тест кейсы войдут в частичное регрессию
    - - SRS(Software requirement specification, ориентир для разработчиков продукта) - спецификация требований ПО, он содержит все требования к продукту, он действует в течении всего SDLC
  - - - риски
      - затраты времени
      - используемые технологии
        и инструменты
      - бюджет
      - определит лучший подход
        к проектированию продукта.
    - - спецификации
      - функции
      - требования
    - - все предложенные подходы
        документируются спецификацией
        DDS(Design Document Specification) -
        
        это уже сама спецификация проекта, DDS рассматривается всеми заинтересованными сторонами и на основании различных параметров, таких как оценка риска, надежность продукта, модульность системы, бюджет и временные ограничения для продукта подбирается наилучший подход к проектированию, данный подход четко определяет все архитектурные модули продукта а также его связь с внешними и сторонними модулями
  - - - Каждый класс нельзя покрыть юнит тестами, по этому по методологии TDD - сначала нужно писать тесты и под них рабочий код
  - - - Тот ли продукт мы разрабатываем
    - - Правильно ли делаем продукт
  - - - Приемочные (UAT - User Acceptance Testing) и пользовательские тесты
        Тестируют те, кого предусмотрит компания
        Как правило конечный пользователь
      - Прохождение критериев релиза
        
        Стиль кода
        Отсутствие приоритетных багов
        Покрытие тестами на 90%
        Документация на не закрытые баги и перенос в следующий спринт
        Тесты девов и qa
      - Регрессиия
      - Go / No-Go miting
        Встреча перед релизом
        Всё ли критерии выполнены
    - - Как только развернули сборку релиза доступную
        клиенту, переходим к проверке релиза
        Т.е, то что тестировали неделю или две, будем проверять за день, но, не углубляясь в функциональное тестирование, но на предмет основного функционала
        Верефицируем внедрение сторисов в продакшне
        баги, тесты
      - Мини отчёт в Slack
      - Если нашли критичны баг
        Банально сообщаем в Slack и репортим в Jira
        Вил такого фикса - в hot fix
        
        Если же фиксить долго, то откатываем
        релиз и переносим его
  - - - Написание кода
        Unit
        Build
        Деплой в репозиторий
        return;
    - - Тестирование
        Подготовка к деплою
        Деплой в продакшн
        return;
- - - - разбивают сториз на приоритезированные задачи