Warning

Этот репозиторий в архиве. Актуальные вопросы вы можете посмотреть здесь

Вопросы с собеседований для тестировщиков

This repository is created and maintained by the team and the community of Hexlet, an educational project. Read more about Hexlet.

See most active contributors on hexlet-friends.

---

Как помочь?

Мы принимаем Pull Request'ы!

Правила

• Для добавляйте вопросы с пояснениями

<details>
<summary>Вопрос</summary>
Ответ/пояснение к вопросу
</details>

Вопросы

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

По объекту требования:

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

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

Вопросы по теории тестирования, классификациям и видам тестирования

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

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

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

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

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

Критерии начала тестирования:

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

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

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

Что такое качество?

Качество (Quality) – степень соответствия совокупности присущих характеристик объекта требованиям.

Важнейшие характеристики качества при эксплуатации, также называемого внешним качеством:

• Производительность
• Масштабируемость
• Доступность
• Надёжность
• Информационная безопасность

Важнейшие характеристики качества при модернизации, также называемого внутренним качеством:

• Безошибочность кода
• Изменяемость кода
• Переносимость кода

Разница между QA, QC и тестировщиком

Функция QC (Quality Control, контроль качества) или тестировщика ПО заключается в проверке качества продукта на последнем этапе разработки. Они могут это делать любым видом и типом тестирования – ручным, автоматизированным, нагрузочным, тестированием безопасности и так далее.

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

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

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

Какие виды тестирования включает классификация по запуску кода?

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

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

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

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

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

Тестирование белого ящика — метод тестирования ПО, который предполагает полный доступ к коду проекта.

Согласно ISTQB, тестирование белого ящика — это:

• тестирование, основанное на анализе внутренней структуры компонента или системы;
• тест-дизайн, основанный на технике белого ящика — процедура написания или выбора тест-кейсов на основе анализа внутреннего устройства системы или компонента.
• почему «белый ящик»? Тестируемая программа для тестировщика — прозрачный ящик, содержимое которого он прекрасно видит.

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

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

Согласно ISTQB, тестирование черного ящика — это:

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

В чем отличие позитивного и негативного тестирования?

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

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

• умножить на калькуляторе цифр 3 и 5,
• в игре посадить морковь на грядку для овощей,
• оплатить покупку действующей картой.

Негативное — тест кейс оперирует как корректными, так и некорректными данными (минимум 1 некорректный параметр) и ставит целью проверку исключительных ситуаций; при таком тестировании часто выполняются некорректные операции. Пример:

• умножить на калькуляторе числа 3 на грушу (значение «груша» не является валидным для калькулятора),
• в игре посадить морковь на реку,
• оплатить покупку несуществующей картой.

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

Функциональное тестирование (functional testing) – рассматривает заранее указанное поведение и основывается на анализе спецификации компонента или системы в целом, т.е. проверяется корректность работы функциональности приложения.

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

• юнит-тестирование,
• интеграционное,
• системное,
• приемочное.

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

Нефункциональное тестирование – это тестирование качественных характеристик компонента или системы. Эти характеристики не относятся к конкретной функции или действию пользователя, не влияют на функционал продукта, но являются их неотъемлемой частью.

К нефункциональному тестированию относятся:

• нагрузочное тестирование,
• тестирование безопасности,
• UX и UI тестирование,
• совместимости.

В чем отличие нагрузочного тестирования от стресс тестирования?

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

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

• Рассмотрим такой тест на примере среднего интернет-магазина. При проектировании ресурса мы ожидаем, что наша площадка должна выдерживать одновременную нагрузку, как минимум, от 4 тыс. пользователей. Максимально идеальный вариант отклика сайта в таком случае должен не превышать 3 секунд. Нагрузочное тестирование создает вышеупомянутую нагрузку и одновременно определяется время отклика. Если оно выше ожидаемого, тогда у сервера при росте посещаемости проблемы, и ваш интернет-магазин будет тормозить.

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

• В продолжение предыдущего примера. Стресс-тестированием будет работа интернет-магазина при одновременной нагрузке много более чем 4 тыс. пользователей

• Еще один пример. Требование гласит, что приложение должно работать быстро (время обработки запросов не более 3 секунд), если на устройстве не менее 500 Мб свободной оперативной памяти. Если мы эмулируем работу приложения при памяти меньше 500 Мб – это будет стрессовое тестирование.

Как классифицируются виды тестирования по уровню?

Классификация по уровню тестирования:

• Модульное тестирование (Unit) — проводится для тестирования какого-либо одного логически выделенного и изолированного элемента (модуля) системы в коде. Проводится самими разработчиками, так как предполагает полный доступ к коду.
• Интеграционное тестирование — тестирование, направленное на проверку корректности взаимодействия нескольких модулей, объединенных в единое целое.
• Системное тестирование — процесс тестирования системы, на котором проводится не только функциональное тестирование, но и оценка характеристик качества системы — ее устойчивости, надежности, безопасности и производительности.
• Приёмочное тестирование — проверяет соответствие системы потребностям, требованиям и бизнес-процессам пользователя.

В чем отличие регрессионного тестирования от повторного?

Повторное тестирование (Re-test) – это тестирование конкретного кода после его изменения, тогда как Регрессионное тестирование (Regression) - это тестирование функциональности всего программного обеспечения после внесения новых изменений.

Ключевая разница:

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

Что такое "парадокс пестицидов" в тестировании программного обеспечения и как его преодолеть?

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

Суть парадокса:

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

Способы преодоления парадокса пестицидов:

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

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

Что такое исследовательское тестирование и в чем его основное отличие от тестирования по заранее подготовленным тест-кейсам?

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

1. Гибкость: тестировщик может адаптировать свой подход в режиме реального времени, основываясь на полученных результатах.
2. Креативность: поощряется творческий подход к поиску дефектов.
3. Отсутствие предварительной подготовки тестов: тесты создаются и выполняются в процессе исследования системы.
4. Фокус на обучении: тестировщик постоянно узнает новое о системе в процессе тестирования.
5. Эффективность в обнаружении неожиданных дефектов: позволяет находить ошибки, которые могли быть пропущены при составлении формальных тест-кейсов.

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

Что такое туры в исследовательском тестировании по Джеймсу Виттакеру и какие основные типы туров он выделяет?

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

Виттакер выделяет несколько основных категорий туров:

1. Туры по бизнес-центру: фокус на основных бизнес-функциях приложения.
2. Туры по историческому району: проверка старого функционала или кода.
3. Туры по району развлечений: исследование дополнительных функций, настроек.
4. Туры по туристическому району: быстрые проверки основных функций.
5. Туры по району отелей: проверка второстепенных функций.
6. Туры по неблагополучному району: тестирование безопасности и устойчивости к атакам.

В рамках этих категорий Виттакер описывает конкретные туры, включая:

1. Тур по достопримечательностям (Landmark tour): Проверка всех основных функций продукта.
2. Тур по функциональности (Feature tour): Систематическое исследование каждой функции продукта.
3. Сложный тур (Complex tour): Тестирование сложных сценариев использования и комбинаций функций.
4. Тур по улицам и переулкам (Street tour): Исследование всех ссылок, меню и переходов в приложении.
5. Интеллектуальный тур (Intellectual tour): Фокус на самых сложных и запутанных аспектах продукта.
6. Тур FedEx (FedEx tour): Отслеживание движения данных через систему.
7. Тур коллекционера (Collector's tour): Сбор различных типов данных и проверка их обработки системой.
8. Тур одиночки (Lonely tour): Исследование частей системы, которые редко используются или игнорируются.
9. Ночной тур (Night tour): Тестирование нестандартных конфигураций и "темных уголков" приложения.
10. Тур супермодели (Supermodel tour): Оценка пользовательского интерфейса.
11. Тур саботажника (Saboteur tour): Попытки подорвать работу приложения.
12. Обсессивно-компульсивный тур (Obsessive-Compulsive tour): Многократное повторение действий.

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

Что такое тестирование на основе рисков (risk-based testing) и какие основные шаги включает в себя этот подход?

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

Основные шаги тестирования на основе рисков включают:

1. Идентификация рисков: Определение потенциальных проблем, которые могут возникнуть в продукте.

2. Анализ рисков: Оценка вероятности возникновения каждого риска и его потенциального воздействия на продукт или бизнес.

3. Приоритизация рисков: Ранжирование рисков на основе их вероятности и воздействия.

4. Разработка стратегии тестирования: Создание плана тестирования, который фокусируется на областях с наивысшим риском.

5. Выполнение тестов: Проведение тестирования с акцентом на высокоприоритетные риски.

6. Мониторинг и переоценка: Постоянное отслеживание рисков и корректировка стратегии тестирования по мере необходимости.

Преимущества этого подхода:

• Эффективное использование ресурсов тестирования
• Раннее выявление критических проблем
• Улучшенное покрытие наиболее важных аспектов продукта
• Более информированное принятие решений о готовности продукта к выпуску

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

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

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

План тестирования (test plan) План тестирования описывает все действия по тестированию в рамках одного проекта. Здесь вы можете найти информацию обо всем, что нужно сделать тестировщику или команде QA в ходе проекта. В каждом плане тестирования указывается объект тестирования, график работы, необходимое оборудование критерии начала и окончания тестирования, стратегия, риски и список выполненных работ. Отвечает на вопросы:

• Что надо тестировать?
• Что будете тестировать?
• Как будете тестировать?
• Когда будете тестировать?
• Критерии начала тестирования.
• Критерии окончания тестирования.

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

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

Сценарий использования (use case) Use case — это более простой и менее официальный документ. Он описывает сценарий взаимодействия с программным обеспечением. Каждый юзкейс основан на предположении о том, что пользователь программы будет делать и где он будет кликать. Это позволяет тестировщикам протестировать предполагаемые пути пользователя. При создании юзкейсов тестировщики учитывают требования и бизнес-цели.

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

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

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

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

Что такое тест сьют (Test Suite)?

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

Что такое требования и для чего они нужны?

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

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

Атрибуты к требованиям:

• Корректность — каждое требование должно точно описывать желаемый функционал.
• Проверяемость — требование должно быть сформулировано так, чтобы существовали способы однозначной проверки, выполнено оно или нет.
• Полнота — каждое требование должно содержать всю информацию, необходимую разработчику, чтобы правильно спроектировать и реализовать требуемую функциональность.
• Недвусмысленность — требование описано без неочевидных аббревиатур и расплывчатых формулировок и допускает только однозначное объективное понимание.
• Непротиворечивость — требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.
• Приоритетность — приоритет требования представляет собой количественную оценку степени значимости (важности) требования.
• Атомарность — требование нельзя разбить на отдельные требования без потери завершённости и оно описывает одну и только одну ситуацию.
• Модифицируемость — характеризует простоту внесения изменений в отдельные требования и в набор требований.
• Прослеживаемость — у каждого требования должен быть уникальный идентификатор, по которому на него можно сослаться.

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

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

Тест-дизайн нужен:

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

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

• Класс эквивалентности (Equivalence class) – это набор входных (или выходных) данных ПО, которые обрабатываются программой по одному алгоритму или приводят к одному результаты
• Техника анализа граничных значений (boundary value testing) — проверка поведения продукта на крайних значениях входных данных.
• Попарное тестирование (pairwise testing). Суть техники заключается в минимизации вариативности комбинаций проверок, достаточных для обеспечения высокого качества ПО (основано на комбинаторике, позволяет создавать уникальные пары и тестировать огромное количество поступающих данных в разных сочетаниях)
• Тестирование на основе состояний и переходов (State-Transition Testing) применяется для фиксирования требований и описания дизайна приложения (состояния программы в разные периоды времени и на разных этапах использования).
• Таблицы принятия решений (Decision Table Testing) — способ компактного представления модели со сложной логикой. А ещё это техника тестирования чёрного ящика, которая применяется для систем со сложной логикой.
• Исследовательское тестирование (Exploratory Testing) — это подход, когда тестировщик не использует тест-кейсы, а тестирует приложение по определённому сценарию, который часто составляется прямо во время проверки.
• Доменный анализ (Domain Analysis Testing) — это техника основана на разбиении диапазона возможных значений переменной (или переменных) на поддиапазоны (или домены), с последующим выбором одного или нескольких значений из каждого домена для тестирования.
• Сценарий использования (Use Case Testing) — Use Case описывает сценарий взаимодействия двух и более участников (как правило — пользователя и системы). Пользователем может выступать как человек, так и другая система. Для тестировщиков Use Case являются отличной базой для формирования тестовых сценариев (тест-кейсов), так как они описывают, в каком контексте должно производиться каждое действие пользователя.

Что такое дефект? Типы дефектов

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

Дефекты можно подразделить на:

• Дефекты требований и спецификаций.
• Дефекты дизайна.
• Дефекты кода.
• Дефекты тестирования.

Основные атрибуты баг-репорта

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

Основные атрибуты баг-репорта:

• Заголовок (summary) – краткое изложение сути обнаруженного дефекта (это ответы на вопросы: что, где и когда произошло в одном предложении).
• Описание (description) – описание алгоритма возникновения ошибки, в отдельных системах, в частности в вышеупомянутом Mantis, есть возможность дать развернутые пояснения (кроме описания последовательности действий добавить условия появления дефекта и прочее).
• Ожидаемый и фактический результат (expected and actual result) – необходимо описать, что конкретно хотел получить пользователь и что он получил на выходе.
• Вложения (attachments) – это может быть любой файл, позволяющий наглядно показать, в чем проблема: скриншот сообщения об ошибке, фотография экрана любым имеющимся под рукой гаджетом, видеозапись или любой другой документ.
• Приоритет (priority) – срочность поставленной задачи, чем он выше, тем важнее сделать задачу в максимально короткие сроки: high/высокий, medium/средний или low/низкий (высокий ставят тем задачам, которые критически сказываются на работе ПО, а низкий – когда ошибки не оказывают существенного влияние на выполнение основных функций).
• Серьёзность (severity) – уровень влияния на работоспособность всего программного комплекса: blocker — полностью останавливают работу приложения, critical — серьезная ошибка, не приводящая к блокировке, major – важный дефект, не препятствующий выполнению поставленных перед ПО задач, но ведущий к ошибкам в данных или выполняемых функциях, minor — несущественные ошибки, сказывающиеся на визуальном отображении результата или в тексте.
• Статус (status) – этап тестирования: new – новая ошибка, feedback – необходима обратная связь, acknowledged –документ принят в работу, accepted – ошибка подтверждена, assigned – ведется работа по исправлению, resolved – исправления внесены, closed – ошибка более не возникает.

В чем отличие Severity от Priority?

Разница между этими понятиями следующая, серьезность (Severity) – это больше относится к технической интерпретации вопроса, а приоритетность (Priority) – к управленческой (менеджерской).

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

Уровни Серьезности дефекта (Severity):

• Блокирующий (S1 – Blocker) – баг полностью блокирует выполнение поставленного функционала, и нет никакой возможности его обойти
• Критический (S2 – Critical) – ошибка блокирует некоторую часть функционала, но существует альтернативный способ для ее обхода.
• Значительный (S3 – Major) – баг, демонстрирующий некорректную работу определенной части созданного функционала. Обычно связан не с тем, что определенная функция не работает, а с тем, что она работает некорректно.
• Незначительный (S4 – Minor) – часто ошибки GUI, которые не влияют на функциональность, но портят юзабилити или внешний вид. Также незначительные функциональные дефекты, либо которые воспроизводятся на определенном устройстве.
• Тривиальный (S5 – Trivial) – почти всегда дефекты на GUI — опечатки в тексте, несоответствие шрифта и оттенка и т.п., либо плохо воспроизводимая ошибка, не касающаяся бизнес-логики, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта.

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

Уровни Приоритета дефекта (Priority):

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

Результаты каких тестов приоритетнее?

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

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

Типы приоритизации тестовых наборов:

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

Жизненный цикл баг-репорта (отчета о дефекте)

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

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

• Открыт (Open) — тестировщик выявил баг и добавил в репорт.
• В работе (In Progress) — о баге сообщили исполнителю, и он занимается исправлением.
• Исправлен (Ready for check) — исполнитель закончил работу по исправлению бага и передал проект на повторную проверку тестировщику.
• Закрыт (Closed) — баг устранен и больше не воспроизводится. Кроме основных есть еще несколько статусов:
• Отклонен (Rejected) — исправлению бага помешала ошибка в репорте, например неверный алгоритм в пункте «Шаги к воспроизведению».
• Отсрочен (Deferred) — баг признан неприоритетным и исправление переносится.
• Переоткрыт (Reopened) — баг был отсрочен или отклонен, но теперь исполнитель взял его в работу.

Атрибуты отчета о дефекте:

• Уникальный идентификатор (ID) — присваивается автоматически системой при создании баг-репорта.
• Тема (краткое описание, Summary) — кратко сформулированный смысл дефекта, отвечающий на вопросы: Что? Где? Когда(при каких условиях)?
• Подробное описание (Description) — более широкое описание дефекта (указывается опционально).
• Шаги для воспроизведения (Steps To Reproduce) — описание четкой последовательности действий, которая привела к выявлению дефекта. В шагах воспроизведения должен быть описан каждый шаг, вплоть до конкретных вводимых значений, если они играют роль в воспроизведении дефекта.
• Фактический результат (Actual result) — описывается поведение системы на момент обнаружения дефекта в ней. Чаще всего, содержит краткое описание некорректного поведения(может совпадать с темой отчета о дефекте).
• Ожидаемый результат (Expected result) — описание того, как именно должна работать система в соответствии с документацией.
• Вложения (Attachments) — скриншоты, видео или лог-файлы.
• Серьёзность дефекта (важность, Severity) — характеризует влияние дефекта на работоспособность приложения.
• Приоритет дефекта (срочность, Priority) — указывает на очерёдность выполнения задачи или устранения дефекта.
• Статус (Status) — определяет текущее состояние дефекта. Статусы дефектов могут быть разными в разных баг-трекинговых системах.
• Окружение (Environment) – окружение, на котором воспроизвелся баг.

Жизненный цикл ПО и этапы тестирования

Опишите жизненный цикл ПО

Жизненный цикл — это период времени, который начинается с решения о создании программного продукта и заканчивается в момент его изъятия из эксплуатации.

• Идея
• Требования
• Дизайн
• Разработка
• Тестирование
• Развертывание
• Эксплуатация и поддержка
• Закрытие

Какова роль QA на каждом из этапов, и когда QA подключается к разработке?

Ответ/пояснение к вопросу

Перечислите этапы жизненного цикла тестирования

1. Анализ требований. Включает в себя определение типов тестирования, выявление приоритетов, определение тестового окружения и т.д.
2. Планирование тестирования. Включает в себя подготовку стратегии, выбор инструментов тестирования, оценку трудозатрат, распределение ресурсов
3. Подготовка тест-кейсов
4. Настройка тестового окружения. Этот этап может идти и параллельно этапу создания тест-кейсов. QA-команда может не принимать непосредственного участия, но должна будет убедиться в работоспособности окружения.
5. Выполнение тестов.
6. Завершение тестирования. На этом этапе создается отчет по результатам тестирования.

Что такое методология разработки?

Для чего она нужна?

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

Какие виды методологий разработки бывают?

Назовите плюсы и минусы каждого вида

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

Плюсы:

• Простота понимания и использования.
• Жесткая структура и линейность, что упрощает планирование и контроль.
• Документирование каждого этапа, что полезно для будущего сопровождения.

Минусы:

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

2. Итеративная модель (Iterative): Итеративная модель разработки предполагает постепенное развитие ПО через серию коротких итераций. Каждая итерация включает в себя фазы разработки, тестирования и обратной связи с заказчиком. Примером итеративной методологии является Agile, включая Scrum и Kanban.

Плюсы:

• Гибкость и возможность быстро реагировать на изменения требований и обратную связь.
• Лучшая вовлеченность заказчика и возможность постоянного улучшения продукта.
• Более быстрая доставка начальных результатов.

Минусы:

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

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

Плюсы:

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

Минусы:

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

В чем отличие валидации от верификации?

• Верификация — проверка соответствия приложения прописанным требованиям.
• Валидация — проверка соответствия приложения всем остальным (подразумеваемым) требованиям.

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

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

Что такое Agile?

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

Опыт и рабочий процесс

Был ли коммерческий опыт QA?

Если да, то что приходилось делать? Были ли действующие проекты с реальными пользователями? Если нет, то как ставились, выполнялись и проверялись задачи?

Почему именно QA?

QA - это интерес надолго или трамплин для чего-то большего?

Каким видится взаимодействие с разработчиками и менеджерами?

Если был опыт, поделитесь плюсами и минусами.

Опишите опыт работы до обучения/стажировки QA?

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

Тестирование веб-приложений

Что такое клиент серверная архитектура?

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

В клиент-серверной архитектуре используется три компонента:

• Клиент — программа, c которой работает пользователь в браузере или с desktop-приложением и обеспечивает связь с сервером.
• Сервер — компьютер, на котором хранится сайт или приложение.
• База данных — хранилище данных, обеспечивающее сохранность данных, даже если в приложении что-то сломается.

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

Что такое HTTP и HTTPS?

Клиент и сервер общаются по правилам, то есть по протоколам. Для работы с сайтами используются два основных протокола:

• HTTP (HyperText Transfer Protocol) – протокол (или набор правил) передачи данных прикладного уровня модели TCP/IP.
• HTTPS (HyperText Transfer Protocol Secure) — защищённый протокол передачи данных, работающий через шифрованные транспортные механизмы SSL (устарел в 2015г.) и TLS.

По умолчанию HTTPS использует 443 TCP-порт (для незащищённого HTTP используют TCP-порт 80).

Основное отличие HTTP и HTTPS — шифрование данных. При использовании HTTP данные передаются в открытом виде, поэтому сайты, в основном, используют протокол HTTPS, который шифрует данные.

Протоколы HTTP и HTTPS описывают набор правил, в каком формате посылаются запросы от клиента, и что ожидается в ответ от сервера.

Каждое HTTP-сообщение состоит из трёх частей, которые передаются в указанном порядке:

• Стартовая строка (Request line) — определяет тип сообщения;
• Заголовки (Headers) — характеризуют тело сообщения, параметры передачи и прочие сведения;
• Тело сообщения (Body) — непосредственно данные сообщения. Обязательно должно отделяться от заголовков пустой строкой.

Стартовая строка для запроса включает в себя тип запроса, путь и версию протокола.

Например:

HEAD / HTTP/1.0

HEAD — тип запроса (называют метод или «глагол», определяющий как реагировать на запрос); / - путь к ресурсу URI (в данном случае корень сайта); HTTP/1.0 – версия протокола.

Стартовая строка для ответа представлена версией протокола, кодом состояния и пояснением к нему.

Например:

HTTP/1.0 200 OK

HTTP/1.0 – версия протокола; 200 – код состояния; OK – пояснение.

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

Например:

• Content-Type: text/plain; charset=windows-1251
• Content-Language: ru

Тело HTTP-сообщения опционально. Тело сообщения может быть добавлено в запрос, только когда метод запроса допускает тело объекта. Тело сообщения в запросе сопровождается добавлением к заголовкам запроса поля заголовка Content-Length, в котором указывается длина тела запроса.

Включается или не включается тело сообщения в сообщение ответа — зависит как от метода запроса, так и от кода состояния ответа. Все ответы на запрос с методом HEAD не должны включать тело сообщения, даже если присутствуют поля заголовка объекта (entity-header), заставляющие поверить в присутствие объекта. Никакие ответы с кодами состояния 1xx (Информационные), 204 (Нет содержимого, No Content), и 304 (Не модифицирован, Not Modified) не должны содержать тела сообщения. Все другие ответы содержат тело сообщения, даже если оно имеет нулевую длину.

Какие бывают виды методов HTTP (типы запросов)

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

Виды методов:

• GET Используется для запроса содержимого указанного ресурса. С помощью метода GET можно также начать какой-либо процесс. В этом случае в тело ответного сообщения следует включить информацию о ходе выполнения процесса.

Клиент может передавать параметры выполнения запроса в URI целевого ресурса после символа «?»:

GET /path/resource?param1=value1&param2=value2 HTTP/1.1

• HEAD Аналогичен методу GET, за исключением того, что в ответе сервера отсутствует тело. Запрос HEAD обычно применяется для извлечения метаданных, проверки наличия ресурса (валидация URL) и чтобы узнать, не изменился ли он с момента последнего обращения.

• POST Применяется для передачи пользовательских данных заданному ресурсу. Например, в блогах посетители обычно могут вводить свои комментарии к записям в HTML-форму, после чего они передаются серверу методом POST и он помещает их на страницу. При этом передаваемые данные (в примере с блогами — текст комментария) включаются в тело запроса. Аналогично с помощью метода POST обычно загружаются файлы на сервер.

• PUT Применяется для загрузки содержимого запроса на указанный в запросе URI. Если по заданному URI не существует ресурса, то сервер создаёт его и возвращает статус 201 (Created). Если же ресурс был изменён, то сервер возвращает 200 (Ok) или 204 (No Content). Фундаментальное различие методов POST и PUT заключается в понимании предназначений URI ресурсов. Метод POST предполагает, что по указанному URI будет производиться обработка передаваемого клиентом содержимого. Используя PUT, клиент предполагает, что загружаемое содержимое соответствует находящемуся по данному URI ресурсу.

• PATCH Аналогично PUT, но применяется только к фрагменту ресурса.

• DELETE Удаляет указанный ресурс.

Что такое код ответа HTTP?

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

В настоящее время выделено пять классов кодов состояния:

• 1хх – Информационный (Informational). Информирование о процессе передачи;
• 2хх – Успех (Success). Информирование о случаях успешного принятия и обработки запроса клиента;
• 3хх – Перенаправление (Redirection). Сообщает клиенту, что для успешного выполнения операции необходимо сделать другой запрос (как правило, по другому URI);
• 4хх – Ошибка клиента (Client Error). Указание ошибок со стороны клиента;
• 5хх – Ошибка сервера (Server Error). Информирование о случаях неудачного выполнения операции по вине сервера.

Что такое DNS? Как работает браузер?

DNS (Domain Name System или система доменных имён) - это автоматизированная система, которая связывает между собой доменное имя сайта, то есть его название, и IP-адрес — он нужен для «общения» компьютеров по сети. Благодаря DNS-серверу не нужно знать IP-адрес сайта, чтобы попасть на него.

Распределённая база данных DNS поддерживается с помощью иерархии DNS-серверов. Система может работать внутри локальной и глобальной сетей. Когда компьютер посылает сообщение на другое устройство, то запрашивает IP-адрес получателя у DNS-сервера. Так это выглядит пошагово:

1. Компьютер А_1 посылает запрос на DNS-сервер с просьбой сказать ему IP-адрес компьютера А_2
2. DNS-сервер находит в записях компьютер А_2 и возвращает его IP-адрес на компьютер А_1
3. Компьютер А_1 посылает информацию на адрес, который получил от DNS-сервера.

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

1. Пользователь открывает свой браузер и вводит адрес нужного сайта.
2. Браузер ищет сервер. Сначала - в кэше роутера, операционной системе или же в истории подключений, которая хранит информацию об IP-адреса сервера, если его уже посещали ранее. Если браузер там его не находит, он обращается к DNS.
3. Браузер пытается установить соединение с сервером. Когда браузер нашёл нужный IP-адрес, он устанавливает с ним соединение с помощью специального протокола TCP/IP, который отвечает за передачу данных в интернете.
4. Браузер отправляет HTTP запрос на сервер. Таким образом он запрашивает информацию для того, чтобы отобразить страницу. Эта коммуникация осуществляется с помощью GET-запроса и POST-запроса.
5. Сервер обрабатывает запрос и отправляет ответ браузеру. Сервер отправляет браузеру ответ с данными о файлах cookie, способах кэширования ну и, конечно же, контентом для отображения страницы.
6. Браузер обрабатывает ответ и отображает запрашиваемый контент. Это называется рендерингом. Пока он происходит, браузер и сервер обмениваются данными. По завершении, пользователь видит загруженную страницу.

Что такое куки и кэш?

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

1. в какое время и с какого устройства человек заходил на страницу;
2. предпочтения пользователей (например, язык, валюта или размер шрифта);
3. товары, которые просматривались или добавлялись в корзину, даже если пользователь временно вышел из интернет-магазина;
4. текст, который мы вводили на сайте раньше;
5. IP-адрес и местоположение пользователя;
6. дату и время посещения сайта;
7. версию операционной системы и браузера;
8. клики и переходы.

Выделяют два основных вида cookies:

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

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

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

Что такое HTML и CSS?

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

CSS (Cascading Style Sheets) — это каскадные таблицы стилей. По сути — язык, который отвечает за описание внешнего вида HTML-документа. Подавляющее большинство современных веб-сайтов работают на основе связки HTML+CSS.

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

Что такое API?

API (Application Programming Interface — программный интерфейс приложения, или интерфейс программирования приложений) — специальный протокол для взаимодействия компьютерных программ, который позволяет использовать функции одного приложения внутри другого.

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

• SOAP API. Дословно переводится как «простой протокол доступа к объектам». Обмен информации между программой и сервером производится на языке XML. Сегодня он используется редко, так как существуют более гибкие интерфейсы.
• RPC API. Удаленный вызов процедур. Клиент запрашивает необходимое действие у сервера и получает ответ, что и приводит функцию приложения в исполнение.
• Websocket API. Очередная современная веб-версия. Для отправки информации клиенту или серверу применяется текстовый формат JSON. Особенность этого варианта API состоит в том, что у сервера есть возможность присылать сообщения обратного вызова, что повышает эффективность взаимодействия программ.
• REST API. Сегодня это самая востребованная версия. Программа присылает нужную информацию серверу, а тот в свою очередь производит выполнение встроенных функций и отправляет итоговые данные клиенту.

Примерами API может служить любая интеграция в сети:

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

Каковы различия между идентификацией, аутентификацией, авторизацией?

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

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

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

Задания

Покажи пример тест кейса

Покажи пример баг репорта