Тестовая документация Flashcards

1
Q

Разница между чек-листом и тест-кейсом

A
  • Уровень детализации:
    • Чек-лист: Краткие пункты для проверки.
    • ест-кейс: Подробное описание шагов и ожидаемых результатов.
  • Цель:
    -Чек-лист: Быстрая проверка ключевых функций или требований.
    • Тест-кейс: Тщательная и детализированная проверка конкретных сценариев использования.
  • Использование:
    • Чек-лист: Используется для высокоуровневого тестирования, когда не требуется детальное руководство.
    • Тест-кейс: Используется для точного тестирования, особенно когда важно соблюдение конкретных шагов.
  • Гибкость:
    • Чек-лист: Гибкий и легко адаптируемый, подходит для ситуаций, где требуется быстрая проверка.
    • Тест-кейс: Строгий и менее гибкий, но обеспечивает высокий уровень точности и повторяемости.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Атрибуты баг-репорта

A

Заголовок
Идентификатор (ID)
Описание
Шаги для воспроизведения
Ожидаемый результат (Expected Result)
Фактический результат (Actual Result)
Скриншоты / Видео
Серьезность (Severity)
Приоритет (Priority)
Окружение (Environment)
Логи и другая инфа, которая может помочь разрабу

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Атрибуты тест кейса

A

Уникальный номер
Заголовок/Название
Предусловие
Шаги
Ожидаемый результат тест-кейса

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

В каком атрибуте разница между тест кейсом и баг репортом

A

В фактическом результате

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

В чем разница между тест кейсом и баг репортом

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Какой ТМС пользовались

A

Test IT, TestRail, Zephyr, Allure, Qase, Kaiten (на выбор одна из)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Что такое баг репорты

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Какие знаешь техники тест дизайна

A

Классы эквивалентности, Анализ граничных значение, попарное тестирование, таблица принятия решений, предугадывание ошибок

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Расскажи жизненный цикл бага

A

Создание > Назначение > Анализ > Исправление > Проверка > Закрытие

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Расскажи о чек листе

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Что описывается в тест плане

A

Подходы и методы тестирования; Критерии завершения тестирования; Критерии входа в тестирование; Ресурсы и роли; График и планирование; Оценка рисков; Тестовые окружения

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Техника анализа граничных значений, можешь о ней рассказать

A

Проверка граничных значений.
Условно: если даны условия 0 и 100, то нужно проверить -1,0,1, 99,100,101

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Зачем нужны техники дизайна

A
  • Техники тест-дизайна помогают выявить все возможные сценарии, включая граничные и исключительные случаи, которые могут неочевидно повлиять на работу системы.
  • Например, техника эквивалентного разделения помогает убедиться, что каждая группа входных данных, обрабатываемых системой, протестирована хотя бы один раз.
  • С помощью техник тест-дизайна можно минимизировать количество тестов, необходимых для достижения требуемого уровня покрытия. Это особенно важно в условиях ограниченных ресурсов.
  • Например, попарное тестирование (pairwise testing) помогает сократить количество тестов, обеспечивая при этом проверку всех возможных пар входных данных.
  • Техники тест-дизайна обеспечивают структурированный подход к созданию тест-кейсов. Это помогает избежать хаотичного и несистемного тестирования.
  • Тестировщик точно знает, какие сценарии и комбинации данных нужно протестировать.
  • Структурированный подход к созданию тестов снижает вероятность пропуска важных дефектов.
  • Например, использование техник анализа граничных значений позволяет найти ошибки, которые возникают на краях допустимых диапазонов входных данных.
  • Техники тест-дизайна помогают убедиться, что тест-кейсы покрывают все требования, описанные в спецификациях.
  • Это обеспечивает соответствие тестирования целям проекта и требованиям заказчика.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Зачем нужна техника эквивалентного разделения

A

Предположим, что в системе есть поле для ввода возраста пользователя, которое принимает значения от 0 до 120 лет. Тестировщик может разделить все возможные входные значения на следующие классы эквивалентности:

  1. Валидные классы:
    • Возраст от 0 до 120 включительно.
    • Например, тестируем значения 10, 50, 120.
  2. Невалидные классы:
    • Отрицательные значения.
    • Например, тестируем значение -1.
    • Значения больше 120.
    • Например, тестируем значение 121.
    • Невозможные значения (например, текст вместо числа).
    • Например, тестируем значение “ABC”.

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Что такое таблица принятия решений

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

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

A

Основывается оно на создании УНИКАЛЬНОЙ ПАРЫ, так как проверка ВСЕХ ВОЗМОЖНЫХ пар будет очень долгим.
это метод тест-дизайна, направленный на оптимизацию процесса тестирования путем проверки уникальных пар комбинаций входных параметров. Основная идея заключается в том, что большинство дефектов в программном обеспечении вызывается взаимодействием не более чем двух параметров. Поэтому тестирование всех парных комбинаций может выявить значительную часть дефектов, при этом уменьшая количество тестов по сравнению с полным перебором всех возможных комбинаций.

17
Q

Какие артефакты тестирования знаешь

A

Тест кейс, чек лист, тест план, баг-репорт, отчет о тестировании

18
Q

Назови виды внутренней документации

A

Архитектурная документация, Технические спецификации, Документация по API, Тест-план, Тест-кейсы, Чек-листы, Тестовые данные, Отчеты о тестировании, Требования, План релиза, Обучающие материалы

19
Q

Какие требования входят в функциональные

A

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

20
Q

Какие требования входят в нефункциональные

A

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

21
Q

Приведи примеры прямых требований

A

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

  • Регистрация пользователя:
    • “Система должна предоставлять пользователю возможность зарегистрироваться, указав имя пользователя, адрес электронной почты и пароль. Пароль должен содержать не менее 8 символов, включать как минимум одну заглавную букву, одну строчную букву и одну цифру.”
22
Q

Какие есть источники требований

A

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

23
Q

Какие существуют степени серьезности бага

A

Blocker
Critical
Major
Minor (Trivial)

24
Q

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

A

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

25
Q

Что такое Test Run / тестовый прогон

A

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

26
Q

Как понимаешь выполнение тест-кейсов

A

Формируем набор тест кейсов под прогон, запускаем этот набор и идем по кейсам и шагам, выставляя результат - выполнен, пропущен, заблокирован или баг

27
Q

Что такое трейсабилити матрица или матрица покрытия

A

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

28
Q

Какую документацию вел на проекте

A

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

29
Q

Какого рода тест-кейсы ты писала (функциональные, e2e, системные)?

A

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

30
Q

Как ты тестировал требования

A

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

31
Q

Какие кейсы попадают в регресс

A

Основные бизнес-функции, Исправление дефектов, новые функции, Основные сценарии использования, Сценарии высокого риска, Исторически проблемные области, Дефекты, которые были исправлены, Тесты, которые были написаны на прошлые фичи