Конспект курса
https://www.youtube.com/playlist?list=PLlBzzzm8XPJG1DVoF1ihdgg2fQeK6LHxh
Курс ISTQB Foundation | Fundamentals of Testing
1 глава
- позволяет предотвратить появление дефектов - через ревью и анализ документации, требований, тикетов в баг трекинговой системе
- поиск дефектов и ошибок, чтобы снизить риск появления в процессе промышленной эксплуатации
- верификация - проверка того что система соответствует предъявляемым к ней требованиям
- валидация - проверка на соответствие ожиданиям
- можно составить представление об уровне качества ПО
- проинформировать всех заинтересованных лиц о состоянии
- проверка вто ПО соответствует внешним требованиям (стандартам, правовым нормам и пр.)
Тестирование и отладка
Ошибка, дефект (недочет, изъян), отказ (сбой)
Цикл разработки ПО
QA - QC -
Тестирование - это контроль качества, но не QA.
Принципы тестирования
Контекстные факторы, которые влияют на корпоративный процесс тестирования, включают, в частности:
- Используемые модель жизненного цикла разработки программного обеспечения и проектные методологии
- Рассматриваемые уровни и типы тестирования
- Продуктовые (риски функционирования и качества продукта) и проектные риски (риски реализации, разработки, доработки и тестирования)
- Предметную область (бизнес область)
- Операционные ограничения, включая, в частности:
- Бюджеты (деньги на людей) и ресурсы (есть ли в команде необходимы скиллы)
- Сроки (временные ограничения)
- Сложность (простые и сложные системы)
- Договорные и нормативные требования (со стороны регуляторов и/или заказчика)
- Организационные политики и практики
- Необходимые внутренние и внешние стандарты (например внутри отраслевые стандарты)
- Планирование тестирования - определение цели, подхода тестирования, принять во внимание контекст и ограничения. После планирования появляется тест-план, который говорит, что тестируем, как тестируем, какие ограничения принимаем во внимание
- Мониторинг и контроль тестирования - регулярная активность направленная на то, чтобы убедиться что все активности идут по плану, а если не по плану, то нужно предпринять чтобы вернуться к плану или изменить план. Раз в спринт создается саммари репорт.
- Анализ тестирования - что тестируем. Описываются условия тестирования, баг-репорты по документации
- Проектирование тестов - как тестируем. Высокоуровневые тест-кейсы и матрицы покрытия, проектирование окружения
- Реализация (имплементация) тестов - проверяет, что всё готово к тестированию - написание тест-кейсов, подготовка тестовых данных. Создание низкоуровневых тест-кейсов, тестовых наборов.
- Выполнение тестов - баг-репорты, логируем результаты прохождения тест-кейсов
- Завершение тестирования - результаты тестирования. Тест саммари репорт (отчет), могут возникнут запросы на изменение.
Курс ISTQB Foundation | Testing Throughout the Software Development Lifecycle | часть 1
2 глава
(9-13 вопросы)
Тестирование - это способ оценить качество ПО и снижения риска ошибок в работе этого ПО.
Верификация - процесс проверки того что ПО соответствует предъявляемому требованию
Валидация - проверка ПО что оно соответствует ожиданиям (неформальным требованиям)
Цели тестирования:
Процесс тестирования в контексте
Процесс тестирования - Шаги - Активности по каждому этапу - см. в силлабусе!
- Компонентное интеграционное тестирование - зона ответственности разработчиков
- Системное интеграционное тестирование - зона ответственности тестировщиков/ Системное интеграционное тестирование может быть выполнено после системного тестирования или параллельно с выполняемыми активностями по системному тестированию
- Большой взрыв - все компоненты уже написаны и по отдельности уже протестированы. Одновременная интеграция всех модулей, которые уже готовы.Экстремальный подход. Сложно локализовать проблему.
- Инкрементальные подходы: сверху вниз или снизу вверх по спецификации, функциональная интеграция (интеграция по функциональности).
Приемочное тестирование:
Есть ли какие-то риски?
Выполнили ли разработчики свои обязательства?
Может ли система быть выпущена на рынок?
Виды: пользовательское (пригодное к использованию, решает реальные потребности, бизнес процессы выполняются как ожидает пользователь) и операционное (эксплуатационное - проводится командой, которая будет выполнять поддержку выпускаемой системы)
Задачи операционного приемочное тестирование: создание бэкапа, восстановление из бэкапа, сбор логов и т.п.
Контракт и комплаенс (нормативное, регуляторное) приемочное тестирование
Альфа и Бета - производится пользователями продукта на стороне производителя и за её пределами, на стороне пользователей.
Характеристики:
- Для каждой активности в разработке существует тестовая активность
- Каждый уровень тестирования имеет характерные задачи для этого уровня
- Анализ и дизайн теста для каждого уровня тестирования начинается во время соответственной активности по разработке
- Тестировщики должны быть вовлечены в процесс ревью документов как только первые черновики этих документов готовы, доступны.
- Документация (спеки) (функциональные, не функциональные, по безопасности и пр.)
- Эпики, юзер стори, критерии приемки
- Спецификации архитектуры и дизайна
- Код
- Тестовые артефакты
- Юзер гайды
- Веб-странички
- Контракты, проект планы
- Настройки конфигурации инфраструктуры
- Модели
- нахождение дефектов на ранней стадии
- чем раньше нашли тем дешевле их исправление
- чем больше дефектов нашли в течении статического тестирования, тем меньше придется менять на поздних стадиях
- идентификация дефектов, которые сложно найти во время динамического тестирования
- предотвращение дефектов в дизайне и разработке путем нахождения различных ошибок в требованиях
- повышение продуктивности разработки
- уменьшение ресурсозатрат на разработку и на тестирование
- улучшение коммуникаций по время ревью
- дефекты требований
- дефекты дизайна (неэффективные алгоритмы или структуры БД)
- дефекты кода (переменные с неопределенными значениями, объявленные переменные но не используемые, повторяющийся код)
- отклонения от стандартов
- некорректные спеки интерфейсов
- уязвимости в безопасности
- пробелы или не точности в тестовом покрытии
- дефекты сопровождения
Неформальные - не документируются.
- выбранной модели жизненного цикла разработки
- от сложности подхода и технологий разработки
- от сложности самого продукта
- от законодательных и нормативных требований
- необходимостью логирования (ведению журнала)
- Планирование - определение скоупа (цели, что и зачем), ответы на ряд вопросов, оценка ресурсозатрат, определяется тип ревью, роли, активности, составление чек-листа, выбор людей, определяются критерии входа и выхода, проверка на соответствие критериям входа
- Начало ревью (старт) - рассылка рабочего продукта и материалов (спеки, чек листы и пр.), объяснение целей и пр, назначение ролей и другие орг вопросы.
- Индивидуальное ревью (индивидуальная подготовка) - обзор, потенциальные дефекты, рекомендации, заполняются чек-листы
- Коммуникация и анализ - обсуждение найденных проблем, анализ дефектов, оценка результата ревью, обсуждение критериев выхода.
- Исправление дефектов и отчетность - заведение баг репортов, обновление статусов дефектов, сбор метрик, проверка соответствия критериям выхода. Авторы фиксят баги.
Критерии входа и выхода:
Критерии входа нужны чтобы понимать, можно ли начинать следующий этап, должны быть выполнены некие условия.
Критерии выхода нужны, чтобы понять можно ли заканчивать ревью и считать работу завершенной.
Роли и обязанности в формальном ревью
- Автор рабочего продукта - создатель продукта и исправитель ошибок
- Менеджер - ответственный за планирование, назначает людей, определяет бюджет, дедлайны, следит за эффективность ресурсозатрат, принимает контрольные решения на любом этапе в случае необходимости
- Модератор - эффективное проведение митингов
- Руководитель (лидер) ревью - отв за процесс ревью, отв-сть перед менеджером, определение ролей, орг решения
- Ревьюер - эксперт, заказчик, пользователь
- Секретарь
- Неформальное ревью - получить результат не затрачивая много ресурсов
- Разбор (прохождение) - обучение, митинг проводится автором
- Техническое ревью - для решения каких-то неопределенностей, для понимания функционала или уточнение технических деталей.
- Инспекция - поиск дефектов
Главная цель для всех - нахождение дефектов.
Выбор зависит от потребностей проекта, ресурсов, рисков, навыков.
Над одним продуктом могут проходить несколько разных типов ревью.
Неформальное ревью - нет формального процесса, может не быть митинга, не документируются, практикуется при agile, цель - быстро и дешево получить результат
Разбор (прохождение) - митинги проводятся автором, индивидуальная подготовка не обязательна, обязательно участие секретаря, цели - обучение, понимание, нахождение дефектов
Техническое ревью - цель - помимо нахождения дефектов, нахождение решений, индивидуальная подготовка, митинг проводится модератором, можно обойтись без участия менеджмента, обязательно участие секретаря и лучше чтобы это был не автор
Инспекция - цель - нахождение дефектов, полностью соблюдается формальная процедура, автор не может принимать другие роли.
Техники для индивидуальной подготовки, для наиболее эффективного нахождения дефектов, техники могут применяться ко всем типам ревью:
AD-hoc - используется когда нет инструкций и пояснений, ревьюеры последовательно проходят по рабочему продукту, по пути находя и документируя проблему. Техника очень сильно зависит от уровня навыков специалиста. Может привести к нахождению одних и тех же дефектов найденных разными специалистами.
Ревью на основе использования чек-листа
Основным преимуществом методики, основанной на чек-листах, является систематизированное покрытие характерных типов дефектов. При этом нужно следить за тем, чтобы искать дефекты не только по чек-листу, но и за его пределами.
Основанное не сценарии
Эти сценарии, в отличие от чек-листов, дают рецензентам более четкое представление о том, как идентифицировать специфические типы дефектов. Как и с рецензированием по чек-листам, чтобы не пропустить другие типы дефектов (например, отсутствующие функции), рецензенты не должны ограничиваться документированным сценарием.
Ролевое рецензирование
Ролевое рецензирование – это метод, в котором рецензенты оценивают рабочий продукт с точки зрения отдельных ролей заинтересованных сторон. Типичные роли – это конкретные типы конечных пользователей (опытные, неопытные, взрослый, ребенок и т.д.), а также конкретные роли в организации (администратор, системный администратор, тестировщик производительности и т.д.).
Рецензирование на основе точки зрения (перспектива)
При анализе на основе точки зрения, аналогичном ролевому анализу, рецензенты берут на себя различные точки зрения заинтересованных сторон при индивидуальном рассмотрении. Типичные точки зрения заинтересованных сторон включают в себя конечного пользователя, маркетолога, дизайнера, тестировщика или оператора. Использование различных точек зрения заинтересованных сторон приводит к большей глубине при индивидуальном рассмотрении с меньшим дублированием вопросов среди рецензентов.
Курс ISTQB Foundation | Test Design Techniques | часть 1
Разбираются техники черного ящика
Курс ISTQB Foundation | Test Design Techniques | часть 2
Курс ISTQB Foundation | Test Management | часть 1
Независимое тестирование
- независимый тестировщик часто может видеть больше разных дефектов, чем тестировщик который работает с командой разработки, и тем более тестировщик который разработчик.
- независимый тестировщик привносит необходимый скептический настрой
- на уровне команды, независимая команда тестировщиков может иметь больший авторитет
- независимый тестировщик может быть способен доносить результаты честно и не беспокоиться о том, что его коллеги будут показывать на него пальцем или воспринимать лично
- независимая команда часто имеет отдельный бюджет, с этим проще обеспечить какой-то тренинг для тестировщиков, обеспечить тулы и т.д.
- в некоторых организациях, независимые тестировщики могут расти в карьерном, профессиональном плане быстрее чем в команде разработки
- независимая команда тестировщиков не освобождена от рисков, команда может стать изолированной
- могут возникнуть проблемы с коммуникациями, может возникнуть ощущение отчужденности и антипатии
- стейкхолдеры (заинтересованные лица) могут видеть в тестировании "узкое горлышко", источник проблем, задержек
- некоторые разработчики могут снимать с себя ответственность
- могут иметь не всей информации, которую они должны иметь, для того чтобы идентифицировать тестовый объект, потому что они находятся за пределами организации
Задачи тест менеджера и тестировщика
Задачи тест менеджера:
- определять цели тестирования, политики тестирования и тестовые стратегии
- планирует тестовую активность, основываясь на тестовую активность и риски, учитывая контекст организации и проекта
- написание и обновление (со временем) документа - тест план
- координация тест плана(ов) с другими участниками проектов, с ПМ и с др.
- обсуждение тестовых перспектив с другими участниками проекта и учитывая проектную активность
- остальное см в силлабусе...
- ревью и соответствие тестовым планам с т.з. тестировщика
- анализ, просмотр и работа с требованиями (документацией), юзер сториз, по которым ведется разработка, критериями приемки, спецификациями (тех. требования) и моделями.
- остальное см. в силлабусе
С движением проекта и изменением тест-плана больше информации становится доступно, поэтому тестовые планы должны быть обновлены соответствующим образом несколько раз на протяжении всего жизненного цикла.
Тестовые стратегии и тестовые подходы
Тестовая стратегия - описание процессов которые находятся на уровне продукта или организации. Стратегия тестирования дает общее описание процесса тестирования, в то время как подход к тестированию адаптирует стратегию к конкретному проекту или релизу.
Типичные стратегии:
Аналитический подход – базируется на анализе некоторого фактора (например, требования или риска). Тестирование, основанное на рисках, является примером аналитического подхода, при котором тесты разрабатываются и ранжируются по приоритетам в зависимости от уровня риска.
Тестирование на основе моделей – подход, при котором тесты разрабатываются на основании модели некоторого аспекта продукта, такого как функция, бизнес-процесс, внутренняя структура или нефункциональная характеристика (например, надежность). Примерами являются модели бизнес-процессов, модели состояния и модели роста надежности.
Методический подход – основан на систематическом использовании некоторого предопределенного набора тестов или тестовых условий, таких как классификация общих или вероятных типов отказов, список важных характеристик качества или корпоративный стандарт дизайна мобильных приложений или веб-страниц.
Тестирование на основе процесса (или стандарта) – подразумевает анализ, проектирование и выполнение тестов в соответствии с внешними правилами или стандартами, такими как: отраслевые стандарты, документация процесса, базис тестирования или любой другой нормативной базой, используемой в организации.
Направленный (или консультативный) подход – определяется, прежде всего, советами, руководствами или инструкциями заинтересованных сторон, экспертов предметной области или экспертов по технологиям, которые могут находиться вне команды тестирования или организации.
Тестирование на основе минимизации регресса – нацелено на проверку работоспособности существующих возможностей ПО. Эта стратегия тестирования подразумевает повторное использование существующего тестового обеспечения (особенно тестовых сценариев и тестовых данных), обширную автоматизацию регрессионных тестов и стандартные наборы тестов.
Реактивный подход – тестирование в данном случае не является спланированным заранее, но зависит от тестируемого компонента, системы или событий, происходящих при выполнении тестов. Новые тесты проектируются, разрабатываются и выполняются, исходя из знаний, ранее полученных при тестировании. Исследовательское тестирование является распространенной методикой, применяемой в реактивных стратегиях.
5.2.3 Критерии входа и выхода (критерии готовности и критерии завершения)
Критерии, которые определяют, когда начинается и завершается каждая из активностей по тестированию.
Оценка затрат на тестирование подразумевает прогнозирование объема связанной с тестированием работы, которая необходима для достижения целей тестирования проекта, релиза или итерации. Факторы, влияющие на затраты, могут включать характеристики продукта, характеристики процесса разработки, характеристики людей и результаты тестирования.
5.2.6 Методы оценки тестирования
Существует несколько методов, используемых для оценки затрат (времени, людей и др. ресурсы) на адекватное тестирование. Наиболее популярные методы - это:
- Метод, основанный на метриках - оценка затрат, использующая метрики ранее выполненных проектов или типовые значения
- Метод экспертной оценки - оценка затрат на основе опыта владельцев задач тестирования или экспертов
Например, в гибкой разработке диаграммы сгорания являются примерами метода, основанного на метриках: трудозатраты фиксируются и отслеживаются, а затем используются для оценки скорости работы команды и определения объема работы, которую команда может выполнить в следующей итерации.
Покер планирования является примером метода, основанного на экспертизе, поскольку члены команды оценивают трудозатраты на основе своего опыта (ISTQB-AT Базовый уровень. Тестировщик в сфере Гибких методологий).
В итерационных методологиях примером метода, основанного на метриках, является модель устранения дефектов: сбор информации о количестве дефектов и времени на их исправление дает базис для оценки схожих проектов в будущем.
Цель мониторинга тестирования заключается в сборе информации и обеспечении обратной связи о состоянии тестирования. Требуемая информация может собираться вручную или автоматически и использоваться для отслеживания прогресса тестирования, оценки выполнения критериев выхода или критериев готовности (в случае гибкой разработки), таких, как обеспечение требуемого покрытия рисков продукта, требований или критериев приемки.
Контроль (управление) тестирования представляет собой любые корректирующие действия, предпринятые на основании полученной информации или метрик. Действия могут охватывать любую активность тестирования и влиять на любую активность жизненного цикла программного обеспечения.
5.5 Риски и тестирование
5.5.1 Определение риска
Риск подразумевает наступление некоторого негативного события в будущем. Уровень риска можно определить через вероятность события и серьезность последствий (влияние).
Идея в том чтобы макс снизить риски продукта
Комментариев нет:
Отправить комментарий