Привет Хабр! Меня зовут Иван, сегодня поговорим о вопросах на собеседованиях Джуну+ (от 6 месяцев работы) и узнаем как ответить на них не как ChatGPT. Я как инженер по ручному и автоматизированному тестированию провожу собеседования на роль Junior+ QA (с дальнейшим ростом в автоматизаторы). Делюсь своим списком вопросов и ответов, которые я ожидаю услышать. Мой полезный телеграм

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

Хекслет - Как пройти собеседование на тестировщика: все этапы и вопросы.

Telegra.ph - Собеседование с QA. 250+ вопросов для Junior, Middle, Senior.

Test, Test, Test - Test-engineer Interview.

Каких ответов я жду на собеседовании по тестированию - тут у меня много вопросов. Автор отрицает пользу негативных тестов. Такие профессионалы создают интернет-магазин, в котором можно заказать отрицательное количество товаров, и деньги за них будут возвращены на карту. Статья была написана в 2015 году, и, конечно, она была великолепна для своего времени, но мир не стоит на месте. Продолжаем двигаться вперёд. Я всё ещё советую к прочтению для общего развития!

Вступление

В России QA, QC и тестирование - одно и тоже. В основном пишут "Инженер по тестированию" или "QA". Внесу ясность:

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

QC (Quality Control) - это процесс контроля качества, который включает в себя проверку конкретных продуктов или компонентов, чтобы убедиться, что они соответствуют установленным стандартам и требованиям. QC фокусируется на обнаружении дефектов и исправлении их.

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

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

База для Junior QA

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

Сравнение ожидаемого результата с фактическим результатом ПО. Тестирование это не поиск багов!

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

2. Зачем тестировать ПО? Цель тестирования?

Есть две цели тестирования:

• техническая - предоставление информации о состоянии приложения на данный момент;

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

Своими словами: для своевременного предоставления информации по сравнению ожидаемого поведения ПО с фактическим поведением ПО. Мы предоставляем данные для координации направления продукта. Это определение дает общее понимание и роль QA зависит от методологии разработки ПО.

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

При подготовке релиза тестировщик выполняет следующие шаги:

1. Планирование тестирования.

2. Подготовка и выполнение проверок.

3. Составление отчета по результатам.

Подробнее:

1. Инициация процесса тестирования.

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

3. Генерация тестовых случаев.

4. Отбор значимых тестовых случаев.

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

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

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

8. Передача информации о соответствии проверенного продукта требованиям.

Планирование

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

Подготовка и тестирование

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

Составление отчета

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

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

Их три:

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

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

• тестирование изменений. (связанные с изменениями)

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

Вопрос 4 и 4.1 тесно сплетены и найти адекватную черту между ними сложно. Читайте тут и тут разбор про типы и виды. По сути типы делят все виды на три.

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

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

2. интеграционная: выполняет проверку взаимодействия между компонентами и связи с различными частями системы.

3. системная: проводит общую проверку функциональности всей программы или системы в целом на высоком уровне.

4. приемочная: проводится перед передачей готового продукта заказчику для проверки и принятия.

Уровни идут по очереди и путать последовательность = непонимание.

Внимание! При изучении материалов можно запутаться между уровнями, методами и видами тестирования. Ресурс, который я предоставил выше вводит нас в заблуждение ответом на вопрос "Какие методики тестирования Вы знаете?"

МЕТОДЫ тестирования вы найдете в вопросе 15. А в ошибочном ответе используются УРОВНИ тестирования из вопроса 5. Будьте бдительны, дорогие Джуны.

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

• Граничные значения - проверяем данные на границах;

• Классы эквивалентности;

• Таблицы принятия решений;

• Причинно-следственная связь;

• Попарное тестирование;

• Тестирование состояний и переходов;

• Тестирование на основе пользовательских сценариев;

• Исследовательское тестирование - тестирование и проектирование документации одновременно.

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

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

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

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

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

Техника выделения ГЗ помогает проверить, корректно ли приложение обрабатывает границы КЭ, а также дополнить проверки КЭ типа «диапазон» тестами на границах. Ценность так же в сокращении тестовых проверок.

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

Regression - регресс проверяет всю систему на предмет изменений и ошибок после правки кода. Confirmation - проверочное проверяет исправления ошибки/бага/задачи.

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

Каждый раз при изменении системы, при релизе с тестовых стендов на пром.

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

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

• Инкрементальный подход:

  • Нисходящий подход (сверху вниз) - тестирование начинается с «верхних» модулей и идет далее к «нижним».

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

  • Сэндвич – комбинация «сверху вниз» и «снизу вверх».

Подробнее: Типы интеграционного тестирования

12. Что такое Configuration Testing?

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

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

13.Что такое Exploratory Testing?

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

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

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

• Принцип KISS (Keep It Simple, Stupid) - принцип поддержания простоты, без усложнения.

• Не заставляй меня думать! - не давай лишний повод думать пользователю, когда можно сделать проще.

• Мы удаляем очевидное - не акцентировать внимание на интуитивных действиях.

• Соотношение сигнала и шума - убирать ненужные элементы, чтобы не отвлекать пользователя.

• Лучше рабочее, чем модное - предпочтение функциональности перед модным дизайном.

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

• Люди не читают - больше использовать визуальные и интерактивные элементы.

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

• Бумажник Миллера - ограничение количества элементов в одном функциональном блоке до 5-7.

• Принцип группировки - разделение информации на части и дозирование ее представления.

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

• Все полезно на виду - важные элементы интерфейса должны быть видны и выделены.

• Принцип 3 клика - пользователь должен достичь нужной информации или раздела не более чем за 3 клика.

• Однородность - использование единого стиля во всем продукте.

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

• Защита от случайных действий - предотвращение случайного удаления, заказа, пересылки или отправки.

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

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

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

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

Метод серого ящика - тестирование с некоторым представлением о внутренней структуре ПО.

Метод белого ящика - тестирование внутренней структуры и реализации ПО.

Статья JavaScript для QA. Фронтендер учит дебажить код через Devtools

16. Что такое Performance Testing?

Performance Testing (тестирование производительности) - это процесс проверки и оценки производительности системы, приложения или компонента с целью определения их способности работать в условиях нагрузки и стресса. Целью такого тестирования является измерение и анализ производительности системы, выявление узких мест и проблем, а также определение максимальной нагрузки, которую система может выдержать.

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

Дымовое тестирование - это название позаимствовано из простейшей методики проверки оборудования. Суть этой методики заключалась в подаче электропитания на устройство с дальнейшим наблюдением за этим устройством. Если появлялся дым, сопровождаемый запахом гари, это свидетельствовало о наличии серьезных проблем. В производстве программного обеспечения дымовой тест – это очень простой и быстрый тест, позволяющий выяснить, работает ли программа вообще и дает ли она ожидаемые результаты. Такое вступление выделит вас среди кандидатов и продемонстрирует вашу начитанность. Книга - Философия DevOps. Искусство управления IT.

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

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

Отличия между Smoke и Sanity тестированием смотрите в вопросе 19.

18. Что такое Traceability Matrix?

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

???? Оранжевым цветом отмечена доступная функциональность ПО.

???? Синим - Разделы ПО (Названия разделов скрыты)

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

Таким образом мы выявили покрытие тестами наше ПО. Осталось дописать недостающие проверки, а также сократить дублирующиеся.

19. Что такое Sanity Testing?

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

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

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

End-to-End тест (E2E тест) - это вид тестирования программного обеспечения, который проверяет работоспособность системы в целом, от начала до конца, с точки зрения пользователя. Он имитирует реальные сценарии использования и проверяет, как различные компоненты системы взаимодействуют друг с другом.

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

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

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

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

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

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

1. Конфиденциальность – чтобы данные пользователя не попали в чужие руки;

2. Целостность – чтобы изменения в ПО мог вносить только пользователь/администратор, имеющий на это полномочия;

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

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

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

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

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

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

24. Что такое «парадокс пестицида»?

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

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

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

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

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

3. Проектирование тестов: На этом этапе разрабатываются тестовые случаи и тестовые сценарии на основе требований. Определяются тестовые данные и создаются тестовые среды.

4. Выполнение тестов: В этой фазе проводятся тесты в соответствии с разработанными тестовыми случаями и сценариями. Результаты тестирования записываются и анализируются.

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

6. Завершение: На этом этапе происходит оценка выполненных работ, а также анализ эффективности и эффективности процесса тестирования. Возможно, требуется повторное тестирование или доработка тестовых случаев.

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

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

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

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

Defect (дефект) - ситуация, когда приложение не работает согласно требованиям. Отличается от ожидаемого поведения продукта.

Error (ошибка) - неправильное понимание требований разработчиками, что приводит к появлению багов.

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

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

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

Название - Что? Где? Когда? Статус 403 в разделе корзины при обновлении страницы

Описание - Подробное описание баг-репорта.

Приоритет - Какой приоритет выполнения бага? Критичный - нет возможности работать с корзиной, но не блокер (сервис не упал совсем)

Предусловие - Что нужно сделать перед выполнением шагов? Войти под Admin 123

Шаги - Каждый шаг - одно действие.

ОР - Поведение, которое ожидаем от системы (требования, спецификации) Статус 200

ФР - Поведение, которое получили от системы. Статус 403

Приложение - (скриншот, скринкаст, логи).

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

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

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

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

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

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

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

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

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

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

Тест-план — это документ, который содержит:

• данные о том, что, как и когда нужно протестировать;

• доступные ресурсы и потенциальные риски;

• критерии для входа и выхода из тестирования: когда начинать и заканчивать проверку;

• планы на регресс и ретест багов;

• планы на автоматизированное тестирование.

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

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

По ТК протестировать ПО может человек с улицы, не имеющий представление об этом ПО, а по ЧЛ протестировать может только специалист, который знаком с ПО.

35. Приведите пример хорошего тест-кейса.

Я представил упрощенный вариант ТК, который считается примером хорошего тона. ОР и ФР в ТК мы не пишем, если это не особый формат, в котором у каждого шага есть ОР :) Наш тест-кейс и есть сам по себе ожидаемый результат и если он не сходится, то заводим баг-репорт.

Благодарю за прочтение этого важного материала. Я уверен это поможет вам в подготовке к собеседованию на роль manual QA. Телеграм для связи