Шпаргалка для собеса тестировщика

1. Что такое тестирование программного обеспечения?

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

2. Что такое контроль качества и обеспечение качества?

Контроль качества QC (Quality Control) — это тщательное тестирование программы на наличие дефектов, а также проверка того, что программное обеспечение соответствует всем требованиям, выдвинутым заказчиком.

Обеспечение качества QA (Quality assurance) – это подход, который помогает убедиться, что методы, технологии и процессы, используемые для создания качественных результатов, применяются правильно.

3. Что такое SDLC (Жизненный цикл разработки программного продукта)?

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

Этапы SDLC:

1. Требования
2. Проектирование
3. Разработка
4. Тестирование
5. Релиз
6. Поддержка

4. Что такое STLC Жизненный цикл тестирования программного продукта?

Жизненный цикл тестирования программного продукта (STLC – Software testing lifecycle) - процесс, направленный на тестирование программного продукта.

Этапы STLC

1. Анализ требований
2. Тестовое планирование
3. Написание тестовых сценариев
4. Подготовка тестовой среды
5. Выполнение тестов
6. Завершающая фаза

5. Что такое тест-кейс?

Тест-кейс – пошаговый сценарий, описывающий как проводится тестирование, и включающий более детализированные проверки (шаги).

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

6. Атрибуты тест-кейсов, что в себя включает тест-кейс?

1. Название проекта – здесь указывается название проекта, для которого мы пишем сценарии проверки
2. ID – это уникальный Идентификатор, уникальный номер тест-кейса, в нашей системе, на одном проекте не должно быть 2-х одинаковых тест-кейсов, это необходимо для того чтоб мы могли всегда корректно ссылаться на наш документ, при общении с другими коллегами, указанием в других системах и т.д.
3. Требования – ссылка на документ, на основании которого составлен данный документ
4. Модуль – название модуля к которому относится данный функционал
5. Название - здесь идет название нашей проверки, отображающее то, что именно мы будет проверять в данном тесте
6. Приоритет - показывает, на сколько важно проведение данного теста
   P1 Высокий (High)
   P2 Средний (Medium)
   P3 Низкий (Low)
   Тестировщик самостоятельно выставляет данный приоритет, основываясь на своем опыте.
7. Среда тестирования – здесь мы указываем окружение, на котором мы будем проводить тестирование – то есть наша платформа, версия браузера (если это веб-продукт) и т.д.
8. Шаги-теста – самый главный атрибут нашего документа, в котором мы подробно расписываем все шаги прохождения нашего теста
9. Ожидаемый результат – в данном атрибуте мы указываем, а какой именно результат мы ожидаем получить, после того как мы выполним данный шаг, очень важно писать результат по каждому шагу, а не один для всех шагов. Это позволит любому члену команды повторить данный тест.

7. Что такое тестовый набор?

Тестовый набор (Testsuite) – набор тест-кейсов, объединенный по одному модулю или цели проверки.

8. Атрибуты тестового набора, что в себя включает тестовый набор?

Они дублируют с атрибутами тест-кейсов.

1. ID тест-кейса
2. Название проекта
3. Модуль
4. Описание теста
5. Ожидаемый результат
6. Приоритет - показывает, на сколько важно проведение данного теста:
   P1 Высокий (High)
   P2 Средний (Medium)
   P3 Низкий (Low)
7. Дата проведения теста
8. Исполнитель
9. Среда тестирования
10. Статус

9. Что такое чек-лист?

Чек-лист- список проверок, в котором мы указываем, что мы будем тестировать, результат и статус проверок.

10. Атрибуты чек-листа, что включает в себя чек-лист?

1. Проект – здесь указывается название проекта, для которого мы пишем сценарии проверки;
2. Цель проверки - здесь идет название модуля который будет проверять в данном документе;
3. Идентификатор -это уникальный Идентификатор документа;
4. Требования - ссылка на документ, на основании которого составлен данный документ;
5. Дата проведения;
6. Исполнитель;
7. Среда тестирования – здесь мы указываем окружение, на котором мы будем проводить тестирование – то есть наша платформа, версия браузера (если это веб-продукт) и т.д.
8. Тип тестов;
9. Название проверок - здесь идет название нашей проверки, отображающее то, что именно мы будет проверять в данном тесте;
10. Результат проверки

11. Что такое план тестирования?

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

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

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

13. Принципы тестирования

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

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

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

15. Что такое требования?

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

16. Что такое баг и баг-репорт?

Баг – это дефект – это отклонение ожидаемого поведения работы программного продукта от фактического.

Баг-репорт – это отчет об ошибках.

Отчёт о дефекте (bug report) — документ, который содержит отчет о любом недостатке в компоненте или системе, который потенциально может привести компонент или систему к невозможности выполнить требуемую функцию.

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

1. Проект
2. Название документа
3. Ссылка на требования
4. Цель проверки
5. Дата проведения
6. Исполнитель
7. Среда тестирования
8. Шаги теста
9. Ожидаемый результат
10. Фактический результат
11. Статус бага
12. Серьезность бага
13. Приоритет устранения бага
14. Прикрепленный файл

18. Приоритет устранения и серьезность бага

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

У серьезности могут быть следующие статусы:

• Blocker – блокировка, работа ПО невозможна
• Critical –критический, приводит наш функционал в нерабочее состояние, отклонение от БЛ ПО, не реализация функций, потеря пользовательских данных
• Major-серьезные ошибки, которые свидетельствуют об отклонении работы от БЛ или нарушающие работу программы, но не имеют критическое воздействие на ПО
• Minor – незначительный дефект не нарушающий функционал нашего приложения, который является несоответствием ожидаемого результата (ошибка дизайна, пример)
• Trivial –не имеет влияния на функционал и работу нашей программы, но может быть обнаружен визуально.

Приоритет - показывает, как быстро дефект должен быть устранён. Priority выставляется менеджером, team-lead или заказчиком.

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

Основные виды тестирования ПО

19. Классификация по запуску кода на исполнение:

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

20. Классификация по доступу к коду и архитектуре:

• Тестирование белого ящика — метод тестирования ПО, который предполагает полный доступ к коду проекта.
• Тестирование серого ящика — метод тестирования ПО, который предполагает частичный доступ к коду проекта (комбинация White Box и Black Box методов).
• Тестирование чёрного ящика — метод тестирования ПО, который не предполагает доступа (полного или частичного) к системе. Основывается на работе исключительно с внешним интерфейсом тестируемой системы.

21. Классификация по уровню детализации приложения (Пирамида тестирования):

1. Модульное тестирование или юнит-тестирование (англ. unit testing) — проводится для тестирования какого-либо одного логически выделенного и изолированного элемента (модуля) системы в коде. Проводится самими разработчиками, так как предполагает полный доступ к коду.
   Модульное тестирование производят сами разработчики, не тестировщики.
2. Интеграционное тестирование (Integration testing) — тестирование, направленное на проверку корректности взаимодействия нескольких модулей, объединенных в единое целое.
   Взаимодействие компонентов, модулей и иных систем между собой. Тестирование части системы, состоящей из 2-х и более модулей.
3. Системное тестирование (System testing) — тестирование взаимодействия между всеми компонентами системы или разных систем между собой или тестирование интерфейсов, между которыми взаимодействует система. Полная проверка приложения, всех модулей, можно ли пройти весь бизнес путь.
4. Приёмочное тестирование (acceptance test) — тестирование на сдаче приемки всего программного продукта или его части Заказчику
   А) Пользовательское приемное тестирование (User Acceptance Testing) – перед релизом собирается группа конечных пользователей, тестируется основной функционал, при наличии дефектов-устраняются.
   Б) Эксплуатационное (Operational acceptance testing) – производится пользователем или администратором в среде, которая имитирует реальные условия эксплуатации ПО, производится тестирование резервного копирования, аварийное восстановление системы, безопасность ПО.
   В) На соответствие контракту – на соответствие гостов, нормативных актов и т.д

22. Классификация по принципам работы с приложением

• Позитивное тестирование — тестирование, при котором используются только корректные данные.
• Негативное тестирование — тестирование приложения, при котором используются некорректные данные и выполняются некорректные операции.

23. Классификация по целям тестирования

1. Функциональное тестирование – тестирование которое направленно на проверку соответствия функциональных требований ПО к его реальным характеристикам. Подтверждение того, что наш продукт обладает всем функционалом, который требует заказчик.
   Функциональное тестирование отвечает на вопрос – что должен делать наш продукт?
2. Нефункциональное тестирование – направленно на проверку соответствия свойств ПО с его нефункциональными требованиями. Тестирование свойств, которые не относятся к функциональности системы – надежность, производительность и т.д.
   Нефункциональное тестирование отвечает на вопрос – как это должен делать наш продукт?

24. Функциональное тестирование

1. Smoke test — тестирование, которое проводится после появления нового билда . Направлено на проверку готовности разработанного продукта к проведению расширенного тестирования и определения общего качества продукта.
   Проверяет заявленную бизнес-логику ПО.
2. Тестирование критического пути (critical path) — направлено для проверки функциональности, используемой обычными пользователями во время их повседневной деятельности.
   Основной тип тестовых испытаний, во время которого значимые элементы и функции приложения проверяются на предмет правильности работы при их стандартном использовании.
3. Расширенное тестирование (extended) — направлено на исследование всей заявленной в требованиях функциональности.
   Проверка нестандартного использования продукта (например, вводить не корректные логин и пароль в окне авторизации, работать на многих вкладках одновременно, подгрузка файлов недопустимых размеров или форматов. Максимально загружать нашу систему, проводить множество негативных тестов.

25. Нефункциональное тестирование

1. Тестирование доступности - доступно ли людям с ограниченными возможностями.
   Пример: Может ли человек, получив голосовое, прослушать его из верхнего динамика.
2. Тестирование локализации и интернетизации - тестирование с целью проверки адаптации ПО к любой культуре или особенностям языка другой страны.
   Пример: Можно ли писать сообщения иероглифами (поддерживает ли кодировку)(локализация) или есть ли функция в мессенджере для оповещения о молитвенном времени (интернационализация).
3. Тестирование безопасности - тестирование направленное на проверку безопасности конфиденциальных данных и защиту от хакерских атак, вирусов и тд.
   Пример: Отправить файл, зараженный вирусом и проверить, пропустит ли его мессенджер. Или встроить в картинку инъекцию.
4. Проверка удобства - тестирование направленное на удобство пользования и дизайна.
   Пример: Проверить, удобно ли будет пользоваться одной рукой, не режет ли глаз цвета, не маленькая ли кнопка отправить и тд.
5. Нагрузочное тестирование - проводимое тестирование использования в пределах нормы.
   Пример: Сервер мессенджера рассчитан на 10 человек, и им пользуются 10 человек, отправляя сообщения и допустимые файлы допустимых размеров.
6. Стресс-тестирование - нагрузка, превышающая норму в несколько раз.
   Пример: Сервер мессенджера рассчитан на 10 человек, а им одновременно пользуются 30 человек, активно отправляя сообщения, фото и файлы друг другу.
7. Тестирование стабильности - тестирование, направленное на продолжительное испытание в пределах нормы.
   Пример: Сервер мессенджера рассчитан на 10 человек, им пользуются 10 человек в рамках стандартного использования в течении месяца (переписываются, отправляют картинки и тд).
8. Инсталляционное тестирование - тестирование, направленное на проверку установки, обновления и удаления приложения.
   Пример: Скачать приложение, установить его, удалить, установить еще раз и после обновить.

25.1. Классификация по цели тестирования

1. Тестирование новой функциональности (new feature test) – производится, как только была разработана новая функциональность.
   То есть, как только разработчик выполнил свою часть работы, по созданию новой функциональности, он передает ее на тестирование.
2. Re-test – проверка правильности исправления дефекта. Повторное тестирование функционала, в котором был найден дефект, то есть баг.
3. Регрессионное тестирование – повторная проверка ранее разработанного функционала, после появления нового билда, то есть новой версии нашего программного продукта, для того, чтоб убедиться, что новый функционал билда никак ему не навредил.
   Регрессионное тестирование проводится: - после появления нового билда (новой версии нашего продукта)
   - тестирование того функционала в котором часто обнаруживаются дефекты
   - плановое тестирование
   - того функционала, который часто меняется в ходе разработки

26. Что такое Тест-дизайн?

Тест-дизайн — это этап тестирования ПО, на котором проектируются и создаются тестовые случаи (тест-кейсы).

27. Техники тест-дизайна

1. Тестирование на основе классов эквивалентности (equivalence partitioning) — это техника, при которой мы разделяем диапазон возможных вводимых значений на группы эквивалентных по своему влиянию на систему значений.
2. Техника анализа граничных значений (boundary value testing) — это техника проверки поведения продукта на граничных значениях входных данных.
3. Попарное тестирование (pairwise testing) — это техника формирования наборов тестовых данных из полного набора входных данных в системе, которая позволяет существенно сократить количество тест-кейсов.
4. Тестирование на основе состояний и переходов (State-Transition Testing) — применяется для фиксирования требований и описания дизайна приложения.
5. Таблицы принятия решений (Decision Table Testing) — техника тестирования, основанная на методе чёрного ящика, которая применяется для систем со сложной логикой.
6. Доменный анализ (Domain Analysis Testing) — это техника основана на разбиении диапазона возможных значений переменной на поддиапазоны, с последующим выбором одного или нескольких значений из каждого домена для тестирования.
7. Сценарий использования (Use Case Testing) — Use Case описывает сценарий взаимодействия двух и более участников (как правило — пользователя и системы).