Фундаментальная теория тестирования

Question 1

Почему именно такой порядок у пирамиды тестирования, и почему юнит - тесты в самом низу?

Answer 1

1. Unit-тесты занимают основное место в пирамиде, так как они:
   - Наименее затратные по времени и ресурсам.
   - Проверяют отдельные компоненты, что позволяет быстро обнаруживать и устранять ошибки в них.
   - Обеспечивают широкий охват кода при меньших усилиях.
2. Integration-тесты следуют за Unit-тестами, проверяя взаимодействие между компонентами:
   - Устанавливают корректность передачи данных и работы между компонентами.
   - Имеют более высокий уровень абстракции и сложности, чем Unit-тесты, поэтому их меньше, но они все еще затратны.
3. End-to-End (E2E) тесты занимают вершину пирамиды:
   - Проверяют приложение на уровне пользователя, оценивая его работу в реальных условиях.
   - Более медленные и затратные, так как они эмулируют действия пользователя на более высоком уровне.

Question 2

Что такое тестирование?

Answer 2

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

Question 3

Что такое баг?

Answer 3

это различие фактического от ожидаемого (требования) результата.

Question 4

Цель тестирования

Answer 4

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

Question 5

Для чего проводится тестирование ПО?

Answer 5

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

Question 6

QA

Answer 6

(Quality Assurance) — Обеспечение качества продукта — изучение возможностей по изменению и улучшению процесса разработки, улучшению коммуникаций в команде, где тестирование является только одним из аспектов обеспечения качества. QA подключается к задачам с момента идеи. (ВАЛИДАЦИЯ и ВЕРИФИКАЦИЯ)

Question 7

К задачам обеспечения качества относятся:

Answer 7

1. проверка технических характеристик и требований к ПО;
   Применение: у нас есть требования к фиче (feature или новый функционал), которые сформировал аналитик. Мы проверяем Ожидаемые (требования и тестовая документация) с фактическими результатами. Так же бывают нефункциональные требования, которые в целом понятны, но были не учтены аналитиком или разрабом. FE: Кнопка Окей должна быть зеленая, а Cancel красная, но у нас в продукте наоборот.
2. оценка рисков;
   Применение: Зачастую при планировании следующего спринта (дальше узнаете что это), на оценке задач, мы как QA подымаем вопрос о том, в чем могут возникнуть проблемы, что может быть задето + оценка времени, которое уйдет на тестирование.
3. планирование задач для улучшения качества продукции;
   Применение: QA Engineer может предлагать улучшения при обсуждении новой фичи, как можно оптимизировать или улучшить уже придуманную аналитиком фичу.
4. подготовка документации, тестового окружения и данных;
5. тестирование;
   Применение: Само тестирование по составленной тестовой документации
6. анализ результатов тестирования, а также составление отчетов и других документов.
   Применение: Когда мы совершаем прогон в нашей TMS (Test Management System - место где хранится наша дока), у нас формируется отчет сколько успешных кейсов было пройдено, сколько багов, сколько пропустили и сколько нашли блокеров.

Question 8

QC

Answer 8

(Quality Control) — Контроль качества продукта — анализ результатов тестирования и качества новых версий выпускаемого продукта. QC engineer, как и тестировщик, подключается к проекту, когда разработка завершена. Он проверяет, что продукт получился таким, как хотел заказчик. (По факту только ВЕРИФИКАЦИЯ)

Question 9

К задачам контроля качества относятся:

Answer 9

проверка готовности ПО к релизу;
проверка соответствия требований и качества данного проекта.
Проверка ФР к ОР

Question 10

Верификация (verification)

Answer 10

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

Question 11

Валидация (validation)

Answer 11

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

Question 12

Виды документации

Answer 12

Проектная и продуктовая

Question 13

7 принципов тестирования

Answer 13

1. Тестирование демонстрирует наличие дефектов (только снижает вероятность наличия, но не гарантирует их отсутствия)
2. Исчерпывающее тестирование невозможно, за исключением тривиальных случаев.
3. Раннее тестирование
   4.Скопление дефектов.
4. Парадокс пестицида
5. Тестирование зависит от контекста
6. Заблуждение об отсутствии ошибок

Question 14

Требования - что это?

Answer 14

это спецификация (описание) того, что должно быть реализовано.

Question 15

Требования прописывает…

Answer 15

либо заказчик, либо аналитик, либо проджект/продукт менеджер.

Question 16

9 атрибутов требований

Answer 16

1. Корректность — точное описание разрабатываемого функционала.
2. Проверяемость
3. Полнота
4. Недвусмысленность -требование должно содержать однозначные формулировки.
5. Непротиворечивость
6. Приоритетность
7. Атомарность
8. Модифицируемость
9. Прослеживаемость

Question 17

SDLC

Answer 17

(Software Development Life Cycle) - это жизненный цикл разработки программного обеспечения. Он представляет собой структурированный процесс, состоящий из различных фаз и этапов, которые выполняются при создании программного продукта.

Question 18

этапы SDLC

Answer 18

1. Анализ и сбор требований: на этом этапе происходит определение и сбор требований к программному продукту. Проводится исследование, выявляются потребности пользователей и определяются функциональные и нефункциональные требования.
2. Проектирование: на этом этапе разрабатывается архитектура и дизайн программного продукта. Определяются компоненты системы, их взаимосвязи и интерфейсы.
3. Разработка: на этом этапе происходит непосредственная реализация программного продукта. Программисты пишут код, создают функциональность и выполняют тестирование единиц кода.
4. Тестирование: на этом этапе проводится тестирование программного продукта с целью выявления ошибок, дефектов и проверки его соответствия требованиям. Включает в себя функциональное тестирование, интеграционное тестирование, системное тестирование и другие виды тестирования.
5. Развёртывание: на этом этапе программный продукт готовится к выпуску и установке на целевой среде. Включает в себя подготовку документации, инсталляцию, настройку и обучение пользователей.
6. Эксплуатация и поддержка: после развёртывания программного продукта происходит его эксплуатация, поддержка и обновление. Ведется мониторинг работы системы, исправление ошибок и добавление новой функциональности.

Question 19

STLC

Answer 19

(Software Testing Life Cycle) - это жизненный цикл тестирования программного обеспечения. Он представляет собой структурированный процесс, состоящий из различных фаз и этапов, которые выполняются при проведении тестирования программного продукта.

Question 20

Основные этапы STLC включают:

Answer 20

1. Планирование: на этом этапе определяются цели тестирования, разрабатывается план тестирования и определяются ресурсы, необходимые для выполнения тестов.
2. Анализ требований и создание тестовой документации: на этом этапе изучаются требования к программному продукту и создается тестовая документация, включающая тестовые случаи, тестовые сценарии и другие артефакты.
3. Дизайн тестов: на этом этапе разрабатывается стратегия тестирования и определяются методы, подходы и техники, которые будут использоваться для проведения тестов. Создаются тестовые случаи и сценарии на основе требований и анализа продукта.
4. Подготовка к выполнению тестов: на этом этапе создается тестовая среда, включающая необходимые инструменты и данные для проведения тестов. Также выполняется подготовка тестовых сценариев и проверка настроек тестовой среды
5. Выполнение тестов: на этом этапе проводятся тестирование по определенным тестовым случаям и сценариям. Результаты тестов регистрируются, ошибки и дефекты отслеживаются и отчеты о тестировании создаются.
6. Анализ результатов тестирования: на этом этапе происходит анализ результатов тестирования, выявление и регистрация дефектов. Оценивается качество продукта и принимаются решения о его готовности к выпуску.
7. Завершение: на этом этапе подводятся итоги тестирования, создается финальный отчет о выполненном тестировании, проводится оценка процесса тестирования и выявление возможных улучшений.

Question 21

Серьёзность (Severity)

Answer 21

показывает степень ущерба, который наносится проекту существованием дефекта. Severity выставляется тестировщиком.

Question 22

Градация Серьезности дефекта (Severity):

Answer 22

1. Блокирующий
2. Критический
   3.. Значительный
3. Незначительный
4. Тривиальный

Question 23

Блокирующий дефект

Answer 23

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

Question 24

Критический дефект

Answer 24

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

Question 25

Значительный дефект

Answer 25

(Major) не работает важная часть одной какой-либо функции/бизнес-логики, но при выполнении специфических условий, либо есть workaround, позволяющий продолжить ее тестирование либо не работает не очень значительная часть какой-либо функции. Также относится к дефектам с высокими visibility - обычно не сильно влияющие на функциональность дефекты дизайна, которые, однако, сразу бросаются в глаза.

Question 26

Незначительный дефект

Answer 26

(Minor) часто ошибки GUI, которые не влияют на функциональность, но портят юзабилити или внешний вид. Также незначительные функциональные дефекты, либо которые воспроизводятся на определенном устройстве.

Question 27

Тривиальный дефект

Answer 27

(Trivial) почти всегда дефекты на GUI — опечатки в тексте, несоответствие шрифта и оттенка и т.п., либо плохо воспроизводимая ошибка, не касающаяся бизнес-логики, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта

Question 28

Срочность

Answer 28

(priority)
показывает, как быстро дефект должен быть устранён. Priority выставляется менеджером, тимлидом или заказчиком

Question 29

Градация Приоритета дефекта (Priority):

Answer 29

Высокий (High)Критическая для проекта ошибка. Должна быть исправлена как можно быстрее.
Средний (Medium)Не критичная для проекта ошибка, однако требует обязательного решения.
Низкий (Low)*Наличие данной ошибки не является критичным и не требует срочного решения. Может быть исправлена, когда у команды появится время на ее устранение.

Question 30

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

Answer 30

также часто говорят уровни тестирования, это группировка тестов по уровню детализации и их назначению.

Question 31

Принципы пирамиды

Answer 31

Тест (ручной, на высоких уровнях, или автотест, на низких уровнях), должен быть на том же уровне, что и тестируемый объект. Например, модульный тест (проверяющий функции, классы, объекты и т.п.) должен быть на компонентном уровне. Это неправильно, если на приемочном уровне запускается тест, который проверят минимальную единицу кода.
Тесты уровнем выше не проверяют логику тестов уровнем/уровнями ниже.
Чем выше тесты уровнем, тем они:
сложней в реализации, и соответственно, дороже в реализации;
важнее для бизнеса и критичней для пользователей;
замедляют скорость прохождения тестовых наборов, например, регресса.

Question 32

Компонентный уровень

Answer 32

Чаще всего называют юнит тестированием. Реже называют модульным тестированием. На этом уровне тестируют атомарные части кода. Это могут быть классы, функции или методы классов.
Пример: твоя компания разрабатывает приложение “Калькулятор”, которое умеет складывать и вычитать. Каждая операция это одна функция. Проверка каждой функции, которая не зависит от других, является юнит тестированием.
Юнит тесты находят ошибки на фундаментальных уровнях, их легче разрабатывать и поддерживать. Важное преимущество модульных тестов в том, что они быстрые и при изменении кода позволяют быстро провести регресс (убедиться, что новый код не сломал старые части кода).
Тест на компонентном уровне:
1. Всегда автоматизируют.
2. Модульных тестов всегда больше, чем тестов с других уровней.
3. Юнит тесты выполняются быстрее всех и требуют меньше ресурсов.
4.Практически всегда компонентные тесты не зависят от других модулей (на то они и юнит тесты) и UI системы.
В 99% разработкой модульных тестов занимается разработчик, при нахождении ошибки на этом уровне не создается баг-репортов. Разработчик находит баг, правит, запускает и проверяет (абстрактно говоря это разработка через тестирование) и так по новой, пока тест не будет пройден успешно*.
На модульном уровне разработчик (или автотестер) использует метод белого ящика. Он знает что принимает и отдает минимальная единица кода, и как она работает.

Question 33

Интеграционный уровень

Answer 33

Проверят взаимосвязь компоненты, которую проверяли на модульном уровне, с другой или другими компонентами, а также интеграцию компоненты с системой (проверка работы с ОС, сервисами и службами, базами данных, железом и т.д.). Часто в английских статьях называют service test или API test.
В случае с интеграционными тестами редко когда требуется наличие UI, чтобы его проверить. Компоненты ПО или системы взаимодействуют с тестируемым модулем с помощью интерфейсов. Тут начинается участие тестирования. Это проверки API, работы сервисов (проверка логов на сервере, записи в БД) и т.п.
Строго говоря на модульном уровне тестирование тоже участвует. Возможно помогает проектировать тесты или во время регресса смотрит за прогоном этих тестов, и если что-то падает, то принимает меры.

Question 34

Виды интеграционного тестирования

Answer 34

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

Question 35

Приведи пример когда высокая серьезность, но низкий приоритет

Answer 35

В мобильном приложении условно, банка, когда клиент заходит в приложение, у него происходит краш (блокер). Если эта проблема у 1-2 юзеров из миллионов, и мы не поддерживаем данную ОС. Скорее всего такой баг мы вообще не возьмем в работу, так как стоимость разработки стоит больше, чем потерять этих клиентов.

Question 36

Когда проводится sanity тестирование

Answer 36

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

Question 37

Сколько процентов функционала содержит основное количество багов

Answer 37

20% функционала имеет 80% багов

Question 38

Чем отличается валидация от верификации

Answer 38

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

Question 39

Какой баг отловить при верификации невозможно

Answer 39

Баги, возникающие в реальных условиях эксплуатации

Question 40

Что такое нефункциональное тестирование

Answer 40

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

Question 41

Что означает тестирование демонстрирует наличие дефектов, а не их отсутствие

Answer 41

Фраза напоминает, что основная цель тестирования — выявление ошибок и дефектов, а не доказательство их отсутствия. Это утверждение имеет несколько ключевых аспектов:

Question 42

Что означает заблуждение об отсутствии ошибок

Answer 42

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

Question 43

Что значит Раннее тестирование сохраняет время и деньги

Answer 43

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

Question 44

Почему unit тестирования в поддержке сложны

Answer 44

Частые изменения в коде.
Сложность модуляризации.
Избыточное использование заглушек и моков.
Тестирование приватных методов.
Проблемы с поддержанием тестовых данных.
Трудности с пониманием и воспроизведением ошибок.

Question 45

Какие виды тестирования существуют

Answer 45

Функциональное тестирование, Нефункциональное
По уровню автоматизации: Ручное, автоматизированное
Smoke тестирование, Sanity тестирование, Регрессионное тестирование, Exploratory тестирование, Ad-hoc тестирование

Question 46

Что такое регрессионное тестирование

Answer 46

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

Question 47

Расскажи что такое Smoke тестирование

Answer 47

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