Фундаментальная теория Flashcards
Изучите базовые принципы QA: цели тестирования, виды дефектов, принципы, уровни тестирования и основные термины. Идеально чтобы заложить прочную основу для работы в QA.
Почему юнит-тесты находятся внизу пирамиды тестирования?
Unit-тесты проверяют отдельные компоненты, требуют меньше ресурсов и времени, обеспечивают широкое покрытие кода. Интеграционные тесты проверяют взаимодействие компонентов, а E2E — работу приложения в реальных условиях. Чем выше уровень, тем сложнее и дороже тесты.
Что такое тестирование?
Проверка соответствия реального поведения программы ожидаемым результатам на основе выбранных тестов.
Что такое баг?
Несоответствие фактического результата требованиям (ожидаемому результату).
Цель тестирования.
Проверка соответствия ПО требованиям, поиск ошибок до релиза, повышение уверенности в качестве продукта.
Для чего проводится тестирование ПО?
Проверка соответствия требованиям.
Раннее обнаружение ошибок.
Выявление непредусмотренных сценариев.
Повышение доверия пользователей.
Что такое QA?
Quality Assurance — улучшение процессов разработки, коммуникаций в команде и качества продукта на всех этапах (ВЕРИФИКАЦИЯ И ВАЛИДАЦИЯ).
Какие задачи включает обеспечение качества?
Проверка требований к ПО.
Применение: у нас есть требования к фиче (feature или новый функционал), которые сформировал аналитик. Мы проверяем Ожидаемые (требования и тестовая документация) с фактическими результатами. Так же бывают нефункциональные требования, которые в целом понятны, но были не учтены аналитиком или разрабом. FE: Кнопка Окей должна быть зеленая, а Cancel красная, но у нас в продукте наоборот.
Оценка рисков и планирование улучшений.
Применение: Зачастую при планировании следующего спринта (дальше узнаете что это), на оценке задач, мы как QA подымаем вопрос о том, в чем могут возникнуть проблемы, что может быть задето + оценка времени, которое уйдет на тестирование.
Подготовка тестовой среды и документации.
Применение: Само тестирование по составленной тестовой документации
Тестирование и анализ результатов.
Применение: Когда мы совершаем прогон в нашей TMS (Test Management System - место где хранится наша дока), у нас формируется отчет сколько успешных кейсов было пройдено, сколько багов, сколько пропустили и сколько нашли блокеров.
Что такое QC?
Quality Control — контроль качества готового продукта (верификация соответствия требованиям).
В чем разница между валидацией и верификацией?
Верификация: Соответствие продукта требованиям (правильно ли мы делаем?).
Валидация: Соответствие потребностям пользователя (правильное ли мы делаем?).
7 принципов тестирования.
- Тестирование выявляет дефекты, но не гарантирует их отсутствие.
- Исчерпывающее тестирование невозможно.
- Раннее тестирование экономит время и деньги.
- Дефекты склонны группироваться.
- Парадокс пестицида (тесты устаревают).
- Тестирование зависит от контекста.
- Заблуждение об отсутствии ошибок (пройденные тесты ≠ отсутствие багов).
Что такое нефункциональное тестирование?
Проверка аспектов, не связанных с функциональностью: производительность, безопасность, удобство использования.
Что такое регрессионное тестирование?
Проверка, что изменения в коде не нарушили существующую функциональность.
Что такое Smoke-тестирование?
Проверка базовой работоспособности системы перед углубленным тестированием. Если смок тест не пройден, то нет смысла проводить дальнейшее тестирование.
Пример бага с высокой серьезностью, но низким приоритетом.
Краш приложения у 1% пользователей устаревшей ОС, которую компания не поддерживает.
Почему раннее тестирование экономит ресурсы?
Исправление ошибок на ранних этапах дешевле, чем на стадиях тестирования или эксплуатации.
Какие виды тестирования существуют?
Что такое Severity и Priority дефекта?
Severity: Влияние дефекта на систему (выставляет тестировщик).
Priority: Срочность исправления (выставляет менеджер).
Градации Severity.
- Blocker — система неработоспособна.
- Critical — нарушена ключевая логика.
- Major — существенные ошибки с обходным путем.
- Minor — незначительные дефекты (например, GUI).
- Trivial — косметические недочеты.
Градации Priority.
Высокий (High)Критическая для проекта ошибка. Должна быть исправлена как можно быстрее.
Средний (Medium)Не критичная для проекта ошибка, однако требует обязательного решения.
Низкий (Low)*Наличие данной ошибки не является критичным и не требует срочного решения. Может быть исправлена, когда у команды появится время на ее устранение.
Что проверяют на интеграционном уровне тестирования?
Взаимодействие компонентов, API, работу с БД и внешними сервисами.
Почему Unit-тесты сложно поддерживать?
Частые изменения кода, сложность мокирования зависимостей, тестирование приватных методов.
Что такое парадокс пестицида?
Если тесты не обновляются, они перестают находить новые дефекты.
Что такое «заблуждение об отсутствии ошибок»?
Ошибочное мнение, что отсутствие найденных дефектов = их полное отсутствие.
Какие атрибуты должны быть у требований, что значит каждое из них?
Корректность, проверяемость, полнота, однозначность, непротиворечивость, приоритетность, атомарность.
Этапы SDLC и их описание.
Анализ и сбор требований: на этом этапе происходит определение и сбор требований к программному продукту. Проводится исследование, выявляются потребности пользователей и определяются функциональные и нефункциональные требования.
Проектирование: на этом этапе разрабатывается архитектура и дизайн программного продукта. Определяются компоненты системы, их взаимосвязи и интерфейсы.
Разработка: на этом этапе происходит непосредственная реализация программного продукта. Программисты пишут код, создают функциональность и выполняют тестирование единиц кода.
Тестирование: на этом этапе проводится тестирование программного продукта с целью выявления ошибок, дефектов и проверки его соответствия требованиям. Включает в себя функциональное тестирование, интеграционное тестирование, системное тестирование и другие виды тестирования.
Развёртывание: на этом этапе программный продукт готовится к выпуску и установке на целевой среде. Включает в себя подготовку документации, инсталляцию, настройку и обучение пользователей.
Эксплуатация и поддержка: после развёртывания программного продукта происходит его эксплуатация, поддержка и обновление. Ведется мониторинг работы системы, исправление ошибок и добавление новой функциональности.
Этапы STLC и их описание
Планирование: на этом этапе определяются цели тестирования, разрабатывается план тестирования и определяются ресурсы, необходимые для выполнения тестов.
Анализ требований и создание тестовой документации: на этом этапе изучаются требования к программному продукту и создается тестовая документация, включающая тестовые случаи, тестовые сценарии и другие артефакты.
Дизайн тестов: на этом этапе разрабатывается стратегия тестирования и определяются методы, подходы и техники, которые будут использоваться для проведения тестов. Создаются тестовые случаи и сценарии на основе требований и анализа продукта.
Подготовка к выполнению тестов: на этом этапе создается тестовая среда, включающая необходимые инструменты и данные для проведения тестов. Также выполняется подготовка тестовых сценариев и проверка настроек тестовой среды
Выполнение тестов: на этом этапе проводятся тестирование по определенным тестовым случаям и сценариям. Результаты тестов регистрируются, ошибки и дефекты отслеживаются и отчеты о тестировании создаются.
Анализ результатов тестирования: на этом этапе происходит анализ результатов тестирования, выявление и регистрация дефектов. Оценивается качество продукта и принимаются решения о его готовности к выпуску.
Завершение: на этом этапе подводятся итоги тестирования, создается финальный отчет о выполненном тестировании, проводится оценка процесса тестирования и выявление возможных улучшений.
Задачи QC
- Проверка готовности ПО к релизу
- Проверка ФР к ОР
- Проверка соответствия требований и качества данного продукта
Виды документации
Проектная и продуктовая
Требования
Это спецификация (описание) того, что должно быть реализовано.
Требования прописывает…
либо заказчик, либо аналитик, либо проджект/продукт менеджер.
Что такое STLC
(Software Testing Life Cycle) - это жизненный цикл тестирования программного обеспечения. Он представляет собой структурированный процесс, состоящий из различных фаз и этапов, которые выполняются при проведении тестирования программного продукта.
Блокирующий дефект
(Blocker) тестирование значительной части функциональности вообще недоступно. Блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой или ее ключевыми функциями становится невозможна.
Что такое SDLC
(Software Development Life Cycle) - это жизненный цикл разработки программного обеспечения. Он представляет собой структурированный процесс, состоящий из различных фаз и этапов, которые выполняются при создании программного продукта.
Что такое серьёзность (Severity)
Показывает степень ущерба, который наносится проекту существованием дефекта. Severity выставляется тестировщиком.
Что такое срочность (priority)
Показывает, как быстро дефект должен быть устранён. Priority выставляется менеджером, тимлидом или заказчиком
Значительный дефект
(Major) не работает важная часть одной какой-либо функции/бизнес-логики, но при выполнении специфических условий, либо есть workaround, позволяющий продолжить ее тестирование либо не работает не очень значительная часть какой-либо функции. Также относится к дефектам с высокими visibility - обычно не сильно влияющие на функциональность дефекты дизайна, которые, однако, сразу бросаются в глаза.
Критический дефект
(Critical) критическая ошибка, неправильно работающая ключевая бизнес-логика, дыра в системе безопасности, проблема, приведшая к временному падению сервера или приводящая в нерабочее состояние некоторую часть системы, то есть не работает важная часть одной какой-либо функции либо не работает значительная часть, но имеется workaround (обходной путь/другие входные точки), позволяющий продолжить тестирование.
Незначительный дефект
(Minor) часто ошибки GUI, которые не влияют на функциональность, но портят юзабилити или внешний вид. Также незначительные функциональные дефекты, либо которые воспроизводятся на определенном устройстве.
Тривиальный дефект
(Trivial) почти всегда дефекты на GUI — опечатки в тексте, несоответствие шрифта и оттенка и т.п., либо плохо воспроизводимая ошибка, не касающаяся бизнес-логики, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта
Какой баг отловить при верификации невозможно
Баги, возникающие в реальных условиях эксплуатации
Сколько процентов функционала содержит основное количество багов
20% функционала имеет 80% багов
Когда проводится sanity тестирование
Smoke тестирование проверяет основную работоспособность всей системы, чтобы определить, готова ли она к дальнейшему тестированию. Sanity тестирование, напротив, фокусируется на проверке конкретных областей или функций, затронутых изменениями. Локально одну фичу
Виды интеграционного тестирования
Существует три различных подхода к интеграционному тестированию, каждый из которых будет объяснен ниже: интеграционное тестирование сверху вниз, интеграционное тестирование снизу вверх и многослойное интеграционное тестирование.
Интеграционный уровень
Проверят взаимосвязь компоненты, которую проверяли на модульном уровне, с другой или другими компонентами, а также интеграцию компоненты с системой (проверка работы с ОС, сервисами и службами, базами данных, железом и т.д.). Часто в английских статьях называют service test или API test.
В случае с интеграционными тестами редко когда требуется наличие UI, чтобы его проверить. Компоненты ПО или системы взаимодействуют с тестируемым модулем с помощью интерфейсов. Тут начинается участие тестирования. Это проверки API, работы сервисов (проверка логов на сервере, записи в БД) и т.п.
Строго говоря на модульном уровне тестирование тоже участвует. Возможно помогает проектировать тесты или во время регресса смотрит за прогоном этих тестов, и если что-то падает, то принимает меры.
Компонентный уровень
Чаще всего называют юнит тестированием. Реже называют модульным тестированием. На этом уровне тестируют атомарные части кода. Это могут быть классы, функции или методы классов.
Пример: твоя компания разрабатывает приложение “Калькулятор”, которое умеет складывать и вычитать. Каждая операция это одна функция. Проверка каждой функции, которая не зависит от других, является юнит тестированием.
Юнит тесты находят ошибки на фундаментальных уровнях, их легче разрабатывать и поддерживать. Важное преимущество модульных тестов в том, что они быстрые и при изменении кода позволяют быстро провести регресс (убедиться, что новый код не сломал старые части кода).
Тест на компонентном уровне:
1. Всегда автоматизируют.
2. Модульных тестов всегда больше, чем тестов с других уровней.
3. Юнит тесты выполняются быстрее всех и требуют меньше ресурсов.
4.Практически всегда компонентные тесты не зависят от других модулей (на то они и юнит тесты) и UI системы.
В 99% разработкой модульных тестов занимается разработчик, при нахождении ошибки на этом уровне не создается баг-репортов. Разработчик находит баг, правит, запускает и проверяет (абстрактно говоря это разработка через тестирование) и так по новой, пока тест не будет пройден успешно*.
На модульном уровне разработчик (или автотестер) использует метод белого ящика. Он знает что принимает и отдает минимальная единица кода, и как она работает.
Принципы пирамиды
Тест (ручной, на высоких уровнях, или автотест, на низких уровнях), должен быть на том же уровне, что и тестируемый объект. Например, модульный тест (проверяющий функции, классы, объекты и т.п.) должен быть на компонентном уровне. Это неправильно, если на приемочном уровне запускается тест, который проверят минимальную единицу кода.
Тесты уровнем выше не проверяют логику тестов уровнем/уровнями ниже.
Чем выше тесты уровнем, тем они:
сложней в реализации, и соответственно, дороже в реализации;
важнее для бизнеса и критичней для пользователей;
замедляют скорость прохождения тестовых наборов, например, регресса.
