Теория тестирования (начальный уровень)

Question 1

Что такое Исследовательское тестирование (Exploratory Testing)?

Теория тестирования

Answer 1

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

Основные принципы исследовательского тестирования:

• Самоуправляемость: Тестировщики самостоятельно определяют, какие аспекты ПО тестировать, в какой последовательности и как глубоко.
• Личный опыт и интуиция: Важным инструментом являются знания и предчувствия тестировщика, позволяющие ему эффективно навигировать по процессу тестирования.
• Обучение в процессе тестирования: Тестировщик постоянно учится в процессе работы ПО, а затем применяет новые знания для расширения и углубления тестирования.
• Адаптивность: Методика предполагает гибкость и способность быстро адаптироваться к новой информации о программном продукте и изменениям в тестовой среде.

https://easyoffer.ru/question/7823
https://vladislaveremeev.gitbook.io/qa_bible/vidy-metody-urovni-testirovaniya/issledovatelskoe-testirovanie-exploratory-testing

Question 2

Каковы преимущества Исследовательского тестирования?

Теория тестирования

Answer 2

Преимущества исследовательского тестирования:

• Гибкость: Возможность быстро адаптироваться к изменениям в программном обеспечении и требованиях.
• Выявление сложных дефектов: Благодаря творческому подходу и опыту тестировщиков могут быть обнаружены ошибки, которые сложно выявить с помощью традиционных методов тестирования.
• Эффективность: Может быть очень эффективным в условиях ограниченного времени, так как позволяет сосредоточиться на наиболее важных аспектах программного продукта.
• Повышение качества: Способствует более глубокому пониманию продукта и, как следствие, к повышению его качества.

Question 3

Когда стоит применять Исследовательское тестирование?

Теория тестирования

Answer 3

Когда применять исследовательское тестирование:

• В условиях неопределённости или когда требования к продукту не полностью известны или часто меняются.
• Для дополнения других форм тестирования, например, автоматизированных тестов или тестов, основанных на требованиях.
• В рамках комплексного тестирования пользовательского интерфейса, функциональности или производительности.

Question 4

Приведите пример Исследовательского тестирования.

Теория тестирования

Answer 4

Методика проведения тестовых туров — это один из вариантов исследовательского тестирования, предложенный Джеймсом Уиттакером. Каждый тур имеет свои конкретные цели. После изучения целей тура, тестировщик прикидывает план исследования системы и движется по нему, корректируя его в процессе при необходимости, но не отходя от основных целей. После достижения целей, все результаты фиксируются.

Примеры исследовательских туров:

• Тур, отменённый из-за дождя (The Rained-Out Tour). Идея заключается в том, чтобы начать какую-нибудь операцию в системе, а затем остановить.
• Тур “Второй бесплатно” (The TOGOF Tour). Тур, созданный для тестирования многократно повторяющихся копий одного приложения, запущенных одновременно.

Question 5

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

Теория тестирования

Answer 5

Сценарное тестирование — это классическое тестирование по предварительно написанным и задукоментированным сценариям.

Question 6

Что такое Интуитивное тестирование (Ad-hoc Testing)?

Теория тестирования

Answer 6

Под ad-hoc тестированием понимается тестирование без использования спецификаций, планов и разработанных тест-кейсов: чистая импроваизация.

У ad-hoc есть своя классификация:

• Buddy testing — процесс, когда разработчик и тестировщик работаю параллельно и находят дефекты в одном модуле. Такой вид тестирования помогает тестировщику проводить необходимые проверки, а разработчику исправлять дефекты на ранних этапах.
• Pair testing — процесс, когда два тестировщика проверяют один модуль и помогают друг другу. Один может дефекты находить, другой — их документировать.
• Monkey testing — произвольное тестирование продукта с целью как можно быстрее, используя различные вариации входных данных, нарушить работу программы или вызвать её сбой.

Question 7

Какая бывает документация?

Теория тестирования

Answer 7

Документация делится на три вида:
1) Пользовательская и маркетинговая документация — руководства, инструкции и справочные материалы, предназначенные для конечных пользователей.
* Примеры использования системы:
* Файл-образец
* Предзаполненные поля в форме ввода
* Примеры вызова API-методов
* Инструкции по установке
* Обучающие материалы:
* Статьи
* FAQ
* Презентации
* Маркетиговые материалы:
* Упаковочные текст и графика

2) Техническая документация — материалы, описывающие архитектуру, функциональность и реализацию программного обеспечения, предназначенные для разработчиков и тестировщиков.
* Требования
* Документация интерфейса взаимодействия:
* Письма от системы
* Сообщения об ошибках
* Pop-up сообщения

3) Регламентирующая документация — документы, содержащие требования к продукту, стандарты и процедуры, которым должно соответствовать программное обеспечение.
* Пользовательское соглашение/оферта

https://sky.pro/media/kak-provodit-testirovanie-dokumentaczii/

Question 8

Как тестировать документацию?

Теория тестирования

Answer 8

Документацию можно тестировать на следующие характеристики:
* Полнота — весь ли функционал описан?
* Однозначность — требования должны трактоваться всеми одинакова.
* Непротиворечивость —требования не должны противоречить сами себе.
* Необходимость — документация должна быть краткой, но ёмкой.
* Осуществимость — реализуем ли описанный функционал в принципе?
* Тестируемость — можно ли протестировать описанный функционал?

Question 9

Какие бывают виды требований?

Теория тестирования

Answer 9

• Техническое задние (ТЗ) — сухое описание того, как система должна работать, что уметь делать и как реагировать на ошибки.
• Вариант использования — описание через взаимодействие пользователя с системой.
• Пользовательский сценарий — тоже описание через взаимодействие пользователя с системой, только содержит больше нюансов, к примеру, тип и характеристики пользователя, а так же его мотивацию. В большей степени похоже больше на историю, чем на сухое описание.
• Графика:
  
  1. Блок-схема
  2. Диаграмма состояний и переходов
  3. Скриншот с пояснениями
  4. Схема движения транзакций
  5. И т.д.

Question 10

Что такое частное техническое задание? Для чего оно нужно?

Answer 10

ЧТЗ (частное техническое задание) – создается на основе ТЗ. Обычно содержит полное описание конкретной части разрабатываемого продукта и ВИ (варианты использования, сценарии использования предмета разработки пользователями, макеты разрабатываемой части предмета разработки, его логику и суть).

Почему необходимо?

• Помогает разработчикам реализовать разрабатываемый продукт точно так, как задумывалось. Помогает понять логику и правила оформления.
• Помогает новым сотрудникам разобраться в крупных и масштабных проектах, так как на некоторые системы нужны недели изучения. Имея под рукой ЧТЗ, сотрудник с легкостью сможет найти в нем необходимую информацию, сразу приступив к тестированию. Не нужно будет привлекать других сотрудников, знающих продукт, тем самым отвлекая их от работы. Очевидная экономия времени!
• Дает возможность примерно оценить трудозатраты на разработку и тестирование еще до начала работ.
• Помогает тестировщикам создать ЧЛ и тест-кейсы до начала работ и тестирования.

https://software-testing.ru/library/around-testing/requirements/2494-purpose-of-test-documentation

Question 11

Что такое тестовая документация (артефакты тестирования)?

Answer 11

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

Question 12

Какие есть виды тестовой документации?

Теория тестирования

Answer 12

Виды тестовой документации:

• Документы описания проверок:
  
  1. План тестирования (Test Plan)
  2. Тестовый сценарий (Test Case)
  3. Тестовый набор (Test Suite)
  4. Чек-лист
• Остальные документы:
  
  1. Протокол тестирования (Test Log)
  2. Отчёт о тестировании (Test Report)
  3. Отчёт о дефектах (Defect Report)
  4. Тестовые данные (Test Data)

https://easyoffer.ru/question/7821

Question 13

Что такое тест-план?

Answer 13

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

Question 14

Чем тест-план отличается от набора тестов?

Answer 14

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

Question 15

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

Answer 15

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

Question 16

Как определить, какую именно документацию необходимо внедрить в проект?

Answer 16

• На проекте до 15 человек (проекты низкой сложности):
  
  • техническое задание (предотвращает неверное понимание задачи разработчиками, т. к. документации нет);
  • чек-листы (легко поддерживать, не отнимают много времени);
  • отчеты в виде краткого письма или отписки в специальном сервисе ведения проектов, с указанием критических багов для выпуска.
• На проекте от 15 до 50 человек (проекты средней сложности):
  
  • техническое задание;
  • чек-листы;
  • тест-кейсы;
  • база знаний (например, в Wiki);
  • отчеты в виде письма с приложенным пройденным ЧЛ с указанием критических багов.
• Большой проект – от 50 человек и больше (проекты высокой сложности):
  
  • техническое задание;
  • частное техническое задание;
  • чек-листы;
  • тест-кейсы;
  • база знаний (например, в Wiki);
  • медиа-материалы;
  • отчеты в принятом в компании виде (обычно, в виде письма с подробными графиками и приложенными файлами);
  • прочее (зависит от типа, целей и нужд компании).

https://software-testing.ru/library/around-testing/requirements/2494-purpose-of-test-documentation

Question 17

Какие типы тестирования вы можете назвать?

Answer 17

• По доступности кода:
  
  • Black box
  • Grey box
  • White box
• По позитивности:
  
  • Позитивные
  • Негативные
• По целям (по объекту):
  
  • Функциональное
  • Нефункциональное:
    
    • Производительности (performance testing)
    • Нагрузочное тестирование (load testing, capacity testing):
    • Стресс-тестирование (stress testing)
    • Надёжности (reliability testing)
    • Usability (удобства использования)
    • Тестирование GUI
    • Доступности (accessibility testing)
    • Безопасности
    • Локализации (localization testing)
    • Совместимости (compatibility testing, interoperability testing)
• По исполнителям:
  
  • Альфа-тестирование
  • Бета-тестирование
• Связанное с изменениями:
  
  • Регрессионное (Regression testing)
  • Тест работоспособности (Sanity testing)
  • Дымовое (Smoke testing)
• По степени автоматизации:
  
  • Ручное
  • Автоматизированное
  • Полуавтоматизированное
• По исполнению кода (по состоянию системы):
  
  • Статическое
  • Динамическое
• По формальности документирования:
  
  • Сценарное тестирование
  • Исследовательское тестирование
  • Интуитивное тестирование (Ad-hoc testing)
• По уровням тестирования:
  
  • Компонентное или Модульное (Component testing, Unit testing)
  • Интеграционное (Integration testing)
  • Системное (System testing)
  • Приемочное (Acceptance testing)

https://vladislaveremeev.gitbook.io/qa_bible/vidy-metody-urovni-testirovaniya/osnovnye-vidy-testirovaniya-po

Question 18

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

Теория тестирования

Answer 18

Проверка продукта на соответствие требованиям.

Тестирование - процесс в рамках жизненного цикла разработки программного обеспечения, который оценивает качество компонента или системы, а также связанных с ними рабочих продуктов. [ISTQB Glossary]

Тестирование программного обеспечения — процесс анализа программного средства и сопутствующей документации с целью выявления дефектов и повышения качества продукта. [Святослав Куликов]

Тестирование ПО — проверка соответствия между реальным и ожидаемым поведением программы [Что-то из интернета]

Контроль качества (QC) - набор действий, предназначенных для оценивания качества компонента или системы. [ISTQB Glossary]

Обеспечение качества (QA) - активности, направленные на обеспечение уверенности в том, что требования к качеству будут выполнены [ISTQB Glossary]

Давайте разберемся на примере создания мобильного приложения, потому что определения не всегда отражают суть:

1. В рамках тестирования мы выполним проверки и задокументируем дефекты, убедимся, что продукт соответствует требованиям.
2. В рамках контроля качества мы проанализируем полученные данные и убедимся, что соблюдены все требования, предъявляемые к качеству как продукта, так и самого процесса. Мы должны убедиться, что уровень качества нашего продукта высокий и он готов к релизу.
3. В рамках обеспечения качества мы формируем процесс QA для соответствия стандартам качества на всех этапах SDLC, еще до этапа создания нашего продукта, который будет минимизировать количество дефектов и предупреждать их.

Основные отличия процессов:

Контроль качества и тестирование (как его часть) направлены на продукт, а обеспечение качества на процесс.
Тестирование и контроль качества являются контролирующими мерами, а обеспечение качества - превентивными, или предупреждающими.

https://stepik.org/lesson/1036731/step/3?auth=login&unit=1045216
https://easyoffer.ru/question/7800

Question 19

Зачем тестировать ПО?

Теория тестирования

Answer 19

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

Question 20

Какие этапы тестирования?

Теория тестирования

Answer 20

1) Инициация

2) Выявление требований прямых и косвенных

3) Создание тест-кейсов

4) Отбор тест-кейсов

5) Проведение проверок

6) Фиксация результатов

7) Анализ результатов

8) Передача результатов о соответствии продукта требованиям

https://easyoffer.ru/question/8134

Question 21

Какие уровни тестирования знаете?

Теория тестирования

Answer 21

Уровни тестирования:
* Модульное
* Интеграционное
* Системное
* Приёмочное

Модульное тестирование (Unit Testing)

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

Пример: Проверка функции сложения в программе калькулятора.

Интеграционное тестирование (Integration Testing)

На нем проверяется взаимодействие между различными модулями или компонентами системы. Цель интеграционного тестирования — обнаружить дефекты в взаимодействии и передаче данных между различными частями программы.

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

Системное тестирование (System Testing)

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

Пример: Тестирование веб-приложения в различных браузерах и на разных устройствах.

Приемочное тестирование (Acceptance Testing)

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

Пример: Бета-тестирование программы с участием реальных пользователей.

https://easyoffer.ru/question/7802

Question 22

Какие техники тест-дизайна знаете?

Теория тестирования

Answer 22

Чёрный ящик (Black-box techniques):

• Эквивалентное разбиение (Equivalence Partitioning): Разделение входных данных на группы (классы эквивалентности), которые можно обрабатывать одинаково. Достаточно тестировать по одному представителю от каждой группы.
• Граничные значения (Boundary Value Analysis): Тестирование на значениях на границах или около границ классов эквивалентности.
• Комбинаторные
  
  • Попарное тестирование (Pairwise testing) - тестирование всех комбинаций пар параметр-значение
  • Таблицы решений (Decision Table Testing): тестировщик определяет условия (входы) и результирующие действия системы (выходы). Пары условий и действий образуют строки таблицы, при этом условия указываются сверху, а действия – снизу.
• Тестирование переходов состояний (State Transition Testing): Проверка переходов между различными состояниями системы на основе событий или условий.
• Use Case Testing (Случаи использования): Создание тестов на основе сценариев использования программы пользователями.

Техники основанные на опыте (Experience-based techniques):

• Предугадывание ошибки (Error Guessing): Основано на опыте и интуиции тестировщика, который предполагает, где могут возникнуть ошибки.
• Тестирование на основе чек-листов (Checklist-based Testing): Использование чек-листов, основанных на предыдущем опыте, для проверки определённых аспектов программы.
• Исследовательское тестирование (Exploratory testing)
• Произвольное тестирование (Ad-hoc testing)
• Attack Testing: Software attacks (sometimes called fault attacks) are focused on trying to induce a specific type of failure. When performing attack testing, you should consider all areas of the software and its interaction with its environment as opportunities for failures. Attacks target the user interface, the operating system, interfacing systems, database interfaces, APIs, and any file system interaction. Anytime data is being exchanged, it is potentially vulnerable to a failure and consequently is an excellent target for an attack.

Белый ящик (White-box techniques):

• Тестирование путей (Path Testing): Анализ выполнимых путей через код для проверки всех возможных путей выполнения.
• Тестирование на основе управляющих структур (Control Structure Testing): Фокусируется на логических операциях и условиях в коде, проверяя все условные операторы.

https://vladislaveremeev.gitbook.io/qa_bible/test-dizain
https://easyoffer.ru/question/7819

Question 23

Что такое техника анализа классов эквивалентности?

Теория тестирования

Answer 23

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

Принципы:

• Определение эквивалентных классов: Входные данные или условия тестирования разделяют на классы, внутри которых система должна вести себя одинаково. Эти классы могут быть как допустимыми (валидными), так и недопустимыми (невалидными).
• Выбор представителей: Для каждого эквивалентного класса выбирается хотя бы один представитель (тестовый случай), который будет использован в тестировании.
• Тестирование: Проводится тестирование на основе выбранных представителей каждого класса. Результаты тестирования для представителя класса экстраполируются на весь класс.

https://easyoffer.ru/question/7825

Question 24

Что такое техника анализа граничных значений? В чем ценность этой техники?

Теория тестирования

Answer 24

Суть: Проверяются все значения на границах эквивалентных классов

Метод анализа граничных значений является продолжением метода эквивалентного разбиения, но может быть применим, только если классы состоят из упорядоченных числовых значений. Максимальное и минимальное значение класса являются его границами [Beizer 1990]. Некорректное поведение более вероятно на границах класса, чем внутри класса. [ISTQB CTFL Syllabus 2018]

Почему она важна:

• Высокая эффективность: большое количество ошибок с минимальным количеством тестов.
• Экономия времени и ресурсов: Сосредоточение усилий на наиболее вероятных местах возникновения ошибок - сокращает время на тестирование и оптимизирует использование ресурсов.
• Улучшение качества продукта: Гарантия корректной обратоки данных на границах значений

https://easyoffer.ru/question/7835
https://stepik.org/lesson/1036738/step/6?auth=login&unit=1045223

Question 25

Что такое Regression и Confirmation тестирования, какая между ними разница?

Теория тестирования

Answer 25

Суть: Retest - смотрим на изменившейся участок. Регресс - смотрим на не изменившиеся участки.

Регрессионное тестирование (regression testing): Тестирование уже протестированной программы, проводящееся после модификации для уверенности в том, что процесс модификации не внес или не активизировал ошибки в областях, не подвергавшихся изменениям. Проводится после изменений в коде программного продукта или его окружении. (ISTQB)

Confirmation тестирование (retest) - тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок.

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

https://vladislaveremeev.gitbook.io/qa_bible/vidy-metody-urovni-testirovaniya/regressionnye-vidy-testirovaniya-regression-testing
https://easyoffer.ru/question/7801
https://vk.com/wall-130102652_218

Question 26

Как часто следует проводить регрессионное тестирование продукта?

Теория тестирования

Answer 26

При каждом изменении в системе.

Question 27

Какие есть виды интеграционного тестирования?

Теория тестирования

Answer 27

• Big bang - все компоненты приложения тестируются сразу после того, как они были разработаны, без поэтапного интегрирования. Этот подход обычно используется в небольших проектах.
• Инкрементное тестирование - разработка приложения разбивается на отдельные этапы, после завершения каждого из которых происходит интеграция уже готовых компонентов. Этот подход позволяет обнаруживать проблемы на ранних этапах и быстрее реагировать на изменения в требованиях.
  В свою очередь, инкрементное тестирование можно разделить на:
  
  • Нисходящий подход
  • Восходящий подход
  • Гибридный подход

https://easyoffer.ru/question/8982

Question 28

Что такое Configuration Testing?

Теория тестирования

Answer 28

Краткая суть: Тестирование различных конфигураций системы - железа, драйверов, операционных систем

Конфигурационное тестирование (Configuration testing) - специальный вид тестирования, направленный на проверку работы ПО при различных аппаратных и программных конфигурациях системы (заявленных платформах, поддерживаемых драйверах, при различных конфигурациях компьютеров и т. д.).

Configuration = performance + compatibility:

• performance аспект: определить оптимальную конфигурацию оборудования, обеспечивающую требуемые характеристики производительности и времени реакции тестируемой системы;
• compatibility аспект: проверить объект тестирования на совместимость с объявленным в спецификации оборудованием, операционными системами и программными продуктами третьих фирм;

Существует два главных уровня конфигурационного тестирования: серверный и клиентский.

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

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

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

https://software-testing.org/testing/chto-takoe-konfiguracionnoe-testirovanie-configuration-testing.html

Question 29

Какие существуют стандарты UI?

Теория тестирования

Answer 29

• Material Design
• Apple Human Interface Guidelines
• Microsoft Design Language
• Bootstrap
• Materialize

Существует множество UI-стандартов, некоторые из которых являются общепризнанными и широко используются в индустрии разработки ПО. Ниже перечислены некоторые из них:

1. Material Design - стандарт дизайна, разработанный компанией Google. Включает в себя рекомендации по использованию цветовой палитры, шрифтов, иконок и анимаций.
2. Apple Human Interface Guidelines - руководство от Apple, в котором описываются стандарты дизайна для приложений под iOS, macOS и watchOS.
3. Microsoft Design Language - стандарт дизайна, используемый в операционных системах и приложениях от Microsoft. Он включает в себя рекомендации по использованию типографики, цвета, анимации и иконок.
4. Bootstrap - фреймворк, который содержит рекомендации по использованию готовых компонентов интерфейса, таких как кнопки, формы, таблицы и другие элементы.
5. Materialize - фреймворк, основанный на Material Design, который содержит готовые компоненты интерфейса, такие как кнопки, навигационные панели, формы и др.

Кроме этого, многие компании имеют свои собственные UI-стандарты и руководства для разработки интерфейсов своих продуктов.

https://easyoffer.ru/question/8980

Question 30

Что такое Black/Grey/White Box Testing?

Теория тестирования

Answer 30

Краткая суть:
* Черный ящик: Нет доступа ко внутренней структуре приложения и коду. Тестирование проводится с точки зрения конечного пользователя.
* Белый ящик: Основывается на внутренней структуре системы или ее реализации (код, архитектура, принципы работы и\или потоки данных внутри системы)
* Серый ящик: доступ к базам данных, архитектурным схемам и документации API.

Белый ящик (White Box Testing)
Также известен как структурное тестирование. В этом подходе тестировщики имеют полное представление о внутренней структуре и коде программы. Тесты разрабатываются с учётом алгоритмов, ветвлений кода, путей выполнения и внутренних интерфейсов. Цель — проверить внутренние операции продукта и убедиться, что все внутренние компоненты функционируют правильно.

Чёрный ящик (Black Box Testing)
В этом методе тестировщики не знают о внутреннем устройстве тестируемой системы. Тесты разрабатываются на основе требований и спецификаций функциональности, без знания о том, как система реализует эти функции. Цель — проверить, соответствует ли система внешним требованиям и ожиданиям пользователя. Тестируется функциональность и поведение системы.

Серый ящик (Grey Box Testing)
Этот метод является комбинацией подходов белого и чёрного ящиков. Тестировщики имеют частичное знание о внутреннем устройстве системы, что позволяет им создавать более целенаправленные тестовые сценарии, основываясь как на внутренней структуре, так и на функциональных требованиях. Это может включать доступ к базам данных, архитектурным схемам и документации API.

https://easyoffer.ru/question/7858

Question 31

Что такое Performance Testing?

Теория тестирования

Answer 31

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

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

Основная цель тестирования производительности - выявить и устранить узкие места производительности в программном приложении. Это подмножество performance engineering, также известное как «Perf Testing». Само по себе оно не призвано находить дефекты, но оно помогает в обнаружении узких мест в системе.

Обычно продолжительность теста производительности составляет 1 час (устойчивое состояние) на средней / ожидаемой нагрузке; это может варьироваться в зависимости от вашего SLA / требований.

Примечание 1: все подвиды тестирования производительности отличаются, грубо говоря, только параметрами (тип возрастания нагрузки, ее количество, длительность и т.п.) и собираемыми метриками (без которых это тестирование бессмысленно). Точкой отсчета для всех подвидов принято брать результаты Capacity testing.

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

Question 32

Что такое Smoke и Sanity тестирование и какая между ними разница?

Теория тестирования

Answer 32

Smoke - проверка стабильности билда, что он вообще работает.

Sanity - более глубокая проверка важного функционала.

Question 33

Что такое Traceability Matrix?

Теория тестирования

Answer 33

Краткая суть:
Таблица для отслеживания взаимосвязей между требованиями проекта и выполненной по ним работе. (Учёт реализации требований)

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

Основные цели:

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

Типы:

• Вертикальная трассируемость: Отслеживает взаимосвязь между требованиями на разных уровнях (например, от бизнес-требований к пользовательским историям и далее к функциональным и нефункциональным требованиям).
• Горизонтальная трассируемость: Связывает требования с соответствующими артефактами разработки, такими как техническая документация, исходный код, тестовые сценарии и результаты тестирования.

Структура:

Матрица может быть структурирована различными способами в зависимости от потребностей проекта, но обычно она содержит:

• ID требований: Уникальные идентификаторы для каждого требования.
• Описание требований: Краткое описание требований для удобства отслеживания.
• Ссылки на артефакты: Ссылки на дизайн, исходный код, тестовые случаи и другие документы, связанные с каждым требованием.

Статус: Текущее состояние реализации требования (например, “Не начато”, “В процессе”, “Завершено”).
Матрица трассируемости является мощным инструментом управления качеством и рисками в проектах разработки, позволяя эффективно контролировать выполнение требований и обеспечивать высокое качество конечного продукта.

https://easyoffer.ru/question/7931

Question 34

Что такое Sanity Testing?

Теория тестирования

Answer 34

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

Тест работоспособности (sanity test): См. тест “на дым”. (ISTQB)

Другие источники:

Sanity testing также является подмножеством регрессионного тестирования и выполняется до или вместо полной регрессии, но после smoke. Эти два подвида похожи, но в целом Sanity используется на более стабильных билдах для определения работоспособности определенной части приложения после внесения изменений.

Примечание. Санитарным это тестирование в русскоязычной среде назвалось по совершенно непонятным причинам, но гуглится только так. На самом же деле дословно переводится как тестирование на вменяемость / разумность / работоспособность / согласованность или по версии ISTQB “Тест работоспособности”.

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

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

Пример:

Допустим, команда разработки вносит изменения в модуль регистрации пользователей в веб-приложении. После внесения изменений QA инженер проводит Sanity тестирование этого модуля, чтобы убедиться, что регистрация по-прежнему работает корректно: пользователь может зарегистрироваться, получить подтверждение регистрации и войти в систему используя новые учетные данные.

Цели:

• Быстрая проверка: Убедиться, что после небольших изменений или исправлений в программном продукте не возникло критических проблем.
• Сосредоточение на изменениях: Проверка только тех аспектов программного продукта, которые подверглись изменениям, без проведения глубокого и всеобъемлющего тестирования.
• Экономия времени и ресурсов: Позволяет быстро оценить влияние внесенных изменений, не тратя время на полный цикл тестирования.
• Такое тестирование является важной частью процесса обеспечения качества программного продукта, так как оно позволяет быстро и эффективно подтвердить, что внесенные изменения не повлияли негативно на уже проверенную и работающую функциональность. Этот тип тестирования особенно полезен в условиях ограниченного времени и ресурсов, когда необходимо сделать быструю проверку перед выпуском продукта или передачей его на дальнейшие этапы тестирования.

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

https://easyoffer.ru/question/7810
https://vladislaveremeev.gitbook.io/qa_bible/vidy-metody-urovni-testirovaniya/regressionnye-vidy-testirovaniya-regression-testing

Question 35

Что такое End-to-End тест?

Теория тестирования

Answer 35

Сквозное тестирование - Сквозное тестирование (End-to-end, E2E, Chain testing) — используется для проверки ПО от начала до конца, а также его интеграцию с внешними интерфейсами.

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

Пример: На примере интернет магазина, это одна объемная проверка, которая включает в себя все шаги пользователя, начиная от регистрации в системе и заканчивая покупкой товара в магазине.

https://habr.com/ru/companies/otus/articles/681066/

Question 36

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

Теория тестирования

Answer 36

Суть: выявляет уязвимости, угрозы и риски.

Целью тестов безопасности является выявление всех возможных лазеек и слабых мест в ПО, которые могут привести к потере информации, доходов, репутации компании, сотрудников или клиентов. Общая стратегия безопасности основывается на трех основных принципах:
* Конфиденциальность - сокрытие определенных ресурсов или информации;
* Целостность - ресурс может быть изменен только в соответствии с полномочиями пользователя;
* Доступность - ресурсы должны быть доступны только авторизованному пользователю, внутреннему объекту или устройству;

Тестирование безопасности обычно выполняет отдельный специалист по безопасности. В ходе тестирования безопасности испытатель играет роль взломщика. Ему разрешено все:

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

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

https://vladislaveremeev.gitbook.io/qa_bible/vidy-metody-urovni-testirovaniya/testirovanie-bezopasnosti-security-and-access-control-testing

Question 37

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

Теория тестирования

Answer 37

Краткая суть: приоритеты в тестировании устанавливаются на основе оценки рисков. Акцент на частях системы с наибольшим риском возникновения серьёзных проблем, влияющих на работоспособность продукта и удовлетворённость пользователя.

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

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

Основные этапы:

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

Преимущества:

• Фокус на критически важных аспектах: Тестирование сосредотачивается на наиболее важных с точки зрения бизнеса и технической сложности функциях.
• Эффективное использование ресурсов: Ресурсы для тестирования распределяются таким образом, чтобы максимизировать покрытие наиболее рискованных областей при ограниченных времени и бюджете.
• Улучшение качества продукта: Снижение рисков, связанных с программным обеспечением, ведёт к повышению общего качества продукта.
• Повышение удовлетворённости клиентов: Защита от потенциальных проблем, которые могли бы наиболее негативно сказаться на пользовательском опыте.

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

https://easyoffer.ru/question/7932

Question 38

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

Теория тестирования

Answer 38

Краткая суть: через выполнение кода (через запуск программы.

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

Основные аспекты динамического тестирования:

• Виды тестирования: Включают функциональное (проверка соответствия функциональным требованиям), нефункциональное (проверка производительности, безопасности, удобства использования и т. д.), а также регрессионное (проверка, что новые изменения не привели к появлению ошибок в уже протестированных частях программы).
• Уровни: Различают несколько уровней, включая модульное (тестирование отдельных компонентов или модулей), интеграционное (проверка взаимодействия между модулями или системами) и системное (проверка всей системы в целом).
• Автоматизация: Динамическое тестирование может быть как ручным, так и автоматизированным. Автоматизация включает использование специального ПО для создания и выполнения тестов, что позволяет повысить эффективность тестирования и ускорить процесс разработки.
• Тестовые сценарии и данные: Разработка тестовых сценариев и подготовка тестовых данных являются ключевыми аспектами динамического тестирования. Они описывают условия и шаги для проверки конкретных функций или сценариев использования, а тестовые данные предоставляют необходимую информацию для выполнения этих тестов.

Преимущества:

• Практическая проверка: Динамическое тестирование демонстрирует реальное поведение программы, позволяя обнаружить ошибки, которые могут не быть очевидны при статическом анализе.
• Валидация функциональности: Помогает убедиться, что программное обеспечение выполняет все требуемые функции и соответствует спецификациям.
• Повышение качества продукта: Помогает улучшить надёжность, производительность и безопасность программного продукта, повышая тем самым удовлетворённость пользователя.

https://easyoffer.ru/question/7826

Question 39

Что такое “эффект пестицида”?

Теория тестирования

Answer 39

Суть: Повторное использование одних и тех же тестовых сценариев со временем становится всё менее эффективным в обнаружении новых дефектов.

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

Причины:

• Ограниченное покрытие: Повторяющиеся тесты часто проверяют одни и те же аспекты программного обеспечения, оставляя другие части кода мало исследованными.
• Привыкание к дефектам: Со временем разработчики и тестировщики могут начать игнорировать известные проблемы, считая их “нормой”.
• Неадаптивность к изменениям: В процессе разработки ПО постоянно вносятся изменения, но если тесты не адаптируются под эти изменения, их эффективность уменьшается.

Как преодолеть эффект:

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

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

https://easyoffer.ru/question/7872

Question 40

Что такое Bug, Error, Failure, Fault?

Теория тестирования

Answer 40

Суть: Некорректная работа программы, вызванная ошибкой в программном коде или дизайне продукта.

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

Причины возникновения могут включать:

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

Обработка и исправление включает в себя несколько этапов:

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

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

Question 41

Опишите основные фазы STLC?Дайте определение Entry и Exit Criteria.

Теория тестирования

Answer 41

Software Testing Life Cycle:
1. Анализ требований
2. Планирование тестирования
3. Разработка тест-кейсов
4. Настройка тестовой среды
5. Выполнение тестов
6. Завершение цикла испытаний

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

Критерии выхода: определяют элементы, которые должны быть выполнены до завершения тестирования.

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

STLC имеет несколько взаимосвязанных фаз и в целом очень похож на SDLC. Эти фазы являются последовательными и называются:

• Анализ требований (Requirement Analysis): один из важнейших этапов, потому что именно на нем можно почти бесплатно исправить недостатки проекта. Этап анализа требований также определяет потенциальную потребность в автоматизированном тестировании и позволяет производить экономические расчеты затрат на рабочую силу на основе оценки проекта. На этом же этапе обсуждаются и документируются критерии начала и окончания тестирования
• Планирование тестирования (Test Planning): на этом этапе формируется план тестирования, т.е. мы определяем действия и ресурсы, которые помогут достичь целей тестирования (участники и их роли, инструменты, окружение). Во время планирования мы также пытаемся определить метрики, метод сбора и отслеживания этих метрик. План составляют исходя из требований, тестовой стратегии и анализа рисков
• Разработка тест-кейсов (Test Case Development): подразумевает использование ручного и автоматизированного тестирования для достижения полного охвата функциональности программного обеспечения, при этом процесс основан на заранее установленных требованиях. Чаще всего тест-кейсы для автоматического тестирования пишутся отдельно, так как кейсы для ручного тестирования описаны в виде шпаргалок (cheat sheets)
• Настройка тестовой среды (Test Environment Setup): в плане тестирования четко указано, какую тестовую среду следует использовать. На этом этапе STLC настраиваются операционные системы и виртуальные машины, развертываются инструменты тестирования, такие как Selenium, Katalon Studio, а также тестовая среда и базы данных проекта. Мы также обращаемся с запросами к DevOps и администраторам, если требуется поддержка
• Выполнение тестов (Test Execution): тесты выполняются на основе готовой тестовой документации и правильно настроенной тестовой среды. Все результаты тестирования регистрируются в Системе управления тестированием. Отрицательно пройденные тесты, в которых фактический результат отличается от ожидаемого, регистрируются как ошибки и передаются команде разработчиков на доработку с последующей перепроверкой после исправления
• Завершение цикла испытаний (Test Cycle Closure): окончательная генерация отчетов о тестировании для клиента. Они должны включать затраченное время, процент обнаруженных ошибок и положительных результатов тестирования, общее количество обнаруженных и исправленных ошибок. Что касается отдела тестирования, то это момент для анализа его работы, подведения итогов, анализа его продуктивности и возможности внести предложения по улучшению качества тестирования.

Критерии входа: Критерии входа содержат обязательные элементы, которые должны быть выполнены перед началом тестирования.
1. Выход билда для тестирования
2. 100% требований и мокапов утверждены и проверены

Критерии выхода: Критерии выхода определяют элементы, которые должны быть выполнены до завершения тестирования.
1. Выполнение более 80 % запланированных на итерацию тест-кейсов
2. Исправлено 100% критических багов
3. Автоматизированно 80% регрессионных тест-кейсов

https://stepik.org/lesson/1036729/step/4?auth=login&unit=1045214
https://vladislaveremeev.gitbook.io/qa_bible/sdlc-i-stlc/zhiznennyi-cikl-testirovaniya-po-stlc-software-testing-lifecycle

Question 42

Что такое Bug, Error, Failure, Fault?

Теория тестирования

Answer 42

Суть: Некорректная работа программы, вызванная ошибкой в программном коде или дизайне продукта.

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

Причины возникновения могут включать:

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

Обработка и исправление включает в себя несколько этапов:

• Идентификация и регистрация: Сначала он должен быть обнаружен, что может произойти в процессе разработки, тестирования или уже после релиза продукта пользователями. Затем ошибка регистрируется в системе учёта задач или баг-трекере с подробным описанием проблемы, условий, при которых она возникает, и, по возможности, шагов для её воспроизведения.
• Анализ и приоритизация: Команда разработки анализирует зарегистрированные баги, определяет их причины и приоритеты для исправления на основе важности функционала и влияния ошибки на пользователей.
• Исправление: Разработчики вносят необходимые изменения в код для устранения ошибки.
• Тестирование: После исправления бага проводится повторное тестирование соответствующего функционала, а также регрессионное тестирование для убедительности в том, что исправления не привели к новым проблемам в программе.
• Деплоймент: Исправленный код включается в следующую версию программного продукта, которая после прохождения всех тестов и проверок выкладывается для пользователей.

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

Надо дополнить:
https://testengineer.ru/error-defect-fault-bug-failure/
https://testbase.ru/235

Question 43

Какие атрибуты у баг-репорта? Какие основные поля для заполнения?

Теория тестирования

Question 44

Какая разница между приоритетом и серьезностью?

Теория тестирования

Answer 44

Приоритет - как быстро нужно исправить ошибку
Серьезность - насколько серьезно ошибка затрагивает функциональность

Question 45

Приведите примеры серьезного, но не приоритетного бага.

Теория тестирования

Answer 45

У компании Google на главной странице ошибка в слове “Gogle”.

Высокий приоритет, но низкая серьёзность

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

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

Низкий приоритет, но высокая серьёзность

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

Примеры могут включать:

• Критические ошибки в редко используемых функциях: Например, сбой системы при выполнении специфической операции, которую используют единицы пользователей.
• Серьёзные ошибки в функционале, планируемом к скорому удалению или переработке: Если известно, что данный функционал будет скоро заменён, может быть принято решение не тратить ресурсы на исправление серьёзной ошибки.

https://easyoffer.ru/question/7895

Question 46

В чем разница между валидацией и верификацией?

Теория тестирования

Answer 46

Верификация отвечает на вопрос “Строим ли мы продукт правильно?”, проверяя соответствие продукта требованиям и спецификациям на каждом этапе разработки.

Валидация отвечает на вопрос “Строим ли мы правильный продукт?”, подтверждая, что конечный продукт удовлетворяет потребностям и ожиданиям конечного пользователя.

https://easyoffer.ru/question/7811

Question 47

Что такое тест-план? Какие элементы у него есть?

Теория тестирования

Answer 47

Суть: документ для планирования тестирования

1. Что надо протестировать
2. Что будем действительно тестировать
3. Как будем тестировать
4. Когда будем тестировать
5. Критерии сдачи
6. Критерии приёмки

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

Основные элементы:

1. Введение: Краткое описание проекта и целей тестирования.
2. Объекты тестирования: Список компонентов или функций программного обеспечения, которые будут тестироваться.
3. Задачи тестирования: Четкое определение целей тестирования, включая что должно быть протестировано и что должно быть достигнуто в результате тестирования.
4. Область тестирования и исключения: Описание того, что будет тестироваться, а также того, что будет исключено из тестирования.
5. Подход к тестированию: Описание методологии и техник тестирования, которые будут использоваться, включая уровни тестирования (например, модульное, интеграционное, системное, приемочное).
6. Критерии начала и завершения тестирования: Определение условий, при которых тестирование начнется и завершится.
7. Ресурсы: Перечень всех необходимых ресурсов для тестирования, включая персонал, тестовое оборудование, и тестовые данные.
8. Ответственные: Распределение ролей и обязанностей в команде тестирования.
9. График тестирования: Временная шкала выполнения тестовых задач и этапов.
10. Управление рисками: Оценка потенциальных рисков для плана тестирования и стратегии их минимизации.
11. План выпуска тестов: Порядок выполнения тестов, включая зависимости между тестами.
12. Требования к документированию: Описание того, как будут документироваться найденные дефекты, отчеты о тестировании и итоговые результаты.

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

https://easyoffer.ru/question/7846

Question 48

1.

Какую обязательную информацию должен содержать тест-план?
Как правильно его использовать, поддерживать и вообще он нужен для большинства проектов?

Теория тестирования

Answer 48

Суть: планирование требуется всегда, тест план нужен не всегда

1. Что надо протестировать
2. Что будем действительно тестировать
3. Как будем тестировать
4. Когда будем тестировать
5. Критерии сдачи
6. Критерии приёмки

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

Даже в Agile необходимо предварительное планирование для структурирования работы, распределения ресурсов и планирования - по крайней мере, на высоком уровне - процесса выпуска на ближайшие месяцы. Но итерация за итерацией, а часто и день за днем, общий план постоянно корректируется с учетом событий и новой информации, которая появляется на свет. Планирование - это непрерывное обучение, а не задача с конечным результатом.

В гибких методологиях всё чаще говорят о концепции одностраничного тест-плана, а в случае необходимости дополнений и уточнений просто создаются ссылки на внешние страницы/документы.

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

Question 49

Какая разница между чек-листом и тест-кейсом?

Теория тестирования

Answer 49

Тест-кейс и чек-лист являются инструментами в области тестирования ПО, но они служат разным целям и используются в различных контекстах.

Тест-кейс

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

Особенности:

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

Чек-лист

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

Особенности:

• Список проверок без подробных инструкций.
• Гибкость в использовании.
• Может не содержать ожидаемых результатов.
• Подходит для общего обзора тестирования и помощи в организации тестов.

Различия:

• Детализация: Тест-кейс содержит подробные шаги и ожидаемые результаты, в то время как чек-лист представляет собой простой список элементов для проверки.
• Цель использования: Тест-кейсы разработаны для детального тестирования функциональности и обеспечения полного покрытия тестами. Чек-листы же чаще используются для быстрой проверки или в качестве напоминания о том, что нужно протестировать.
• Гибкость: Чек-листы более гибкие и могут быть легко адаптированы под разные задачи и условия тестирования. Тест-кейсы, с другой стороны, требуют точного следования предписанным шагам.

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