Собеседования играют важную роль в жизни любого человека. И всегда хочется, чтобы встреча с HR-специалистом прошла удачно с первой попытки. В этом руководстве мы рассмотрим несколько каверзных вопросов по ручному тестированию, а также приведем примеры ответов, которые помогут вам легко пройти собеседование.
Эти вопросы будут очень полезны как для начинающих, так и для более опытных тестировщиков.
Ищите работу Junior QA? Тогда вам в наш телеграм канал QA Вакансии. Каждую неделю 7 лучших вакансий с телеграм контактом HR компании.
Интересные вопросы с собеседований по ручному тестированию
1. Что такое тестовое покрытие?
Тестовое покрытие – это статистическая мера качества, определяющая процент тестирования после прогона установленного количества тест-кейсов. Эта метрика также позволяет определить, насколько тест-кейсы охватывают весь код приложения. Здесь важно понимание области кода и приложения, которое будет протестировано.
БОЛЬШЕ ВОПРОСОВ С СОБЕСЕДОВАНИЙ В НАШЕМ ТЕЛЕГРАМ КАНАЛЕ QASOBES
2. Что вы будете делать, если обнаружите ошибку?
Необходимо попробовать воспроизвести баг на другом устройстве, чтобы исключить проблемы с самой тестовой средой. Если речь идет о веб-приложении, нужно в первую очередь проверить кроссбраузерную совместимость.
После подтверждения можно заводить баг-репорт, указав в нем соответствующие шаги по воспроизведению дефекта. К отчету по возможности нужно приложить необходимые доказательства наличия дефекта – скриншоты, видеозаписи экрана или логи сервера.
3. Назовите ключевые поля баг-репорта
Наиболее важными элементами баг-репорта являются:
- Заголовок. Он должен быть уникальным и легко понятным. Суть в том, чтобы разработчик в большинстве случаев понял из заголовка, в чем заключается ошибка.
- Описание. Состоит из перечня необходимых шагов для воспроизведения ошибки.
- Приложения. К отчету нужно приложить любые подтверждающие материалы – скриншоты, видео, серверные логи.
- Ожидаемый и действительный результат. Здесь описывается ожидаемое и фактическое поведение программного обеспечения при выполнении тест-кейса.
4. В чем отличие тестового сценария от тест-кейса?
Тестовый сценарий состоит из очень подробного описания того, что необходимо проверить. Его можно назвать набором тест-кейсов, которые обычно охватывают сквозную функциональность конкретного модуля/функции.
Тест-кейс – это набор действий (также называемых шагами), которые должны быть выполнены при проверке функциональности тестируемого приложения.
5. Есть ли разница между регрессионным и повторным тестированием?
Регрессионное тестирование – это выполнение тестов после исправления одной или нескольких ошибок и/или внесения новых изменений в приложение. Его проводят, чтобы убедиться, что внесенные изменения не повлияли на другие части (части) приложения.
Повторное тестирование – это проверка уже исправленной ошибки. В его процессе выполняются определенные тест-кейсы, выявившие ошибки во время последнего запуска, для подтверждения успешности их исправления.
6. В чем суть тестирования API?
Тестирование API проверяет, соответствует ли разработанный API предварительно установленным критериям в отношении функциональности, надежности, производительности, безопасности и удобства обслуживания.
В основном проверяется, являются ли выходные данные, полученные из другого приложения или базы данных, правильными, правильно структурированными и пригодными для использования вызывающим приложением. Данные ответа должны быть основаны на параметрах запроса/входа.
Следует также учитывать следующие моменты:
- Время отклика
- Тип требуемой аутентификации
- Безопасность передачи данных по сети.
7. Каков ваш подход к написанию тест-кейсов?
Прежде чем приступить к разработке тест-кейса, специалист по контролю качества должен получить достаточные знания о функции/модуле. Сделать это можно следующим образом:
- Изучить историю пользователя (если она доступна)
- Получить знания о приложении из имеющейся документации (если таковая имеется) или от любого члена команды
Основные правила написания тест-кейса:
- Тест-кейс должен быть как можно более простым, чтобы его мог выполнить даже человек, не знакомый с приложением
- Тест-кейсы должны быть легко идентифицируемы/понятными по их названию/заголовку
- Все тест-кейсы должны быть независимыми
- Везде, где это необходимо, четко определяйте предварительные условия (precondition)
- Создавайте тест-кейс с точки зрения конечного пользователя
- Ожидаемые результаты и входные данные должны быть четко определены
- Каждый шаг тест-кейса в идеале должен иметь только один ожидаемый результат
- Избегайте дублирования тест-кейсов. При необходимости модульно структурируйте тест-кейс и вызывайте его везде, где это необходимо.
- Избегайте любых предположений
- Старайтесь применять такие методы разработки тестов, как анализ граничных значений, разбиение на классы эквивалентности и т.д.
Примечание: Также важно, чтобы разработанный тест-кейс был рассмотрен коллегами, включая бизнес-аналитиков.
8. Как определить приоритетность выполнения тест-кейсов?
Более приоритетными можно считать следующие тест-кейсы:
- проверяющие критическую функциональность
- с помощью которых часто обнаруживаются ошибки
- для функций, в код которых часто вносят изменения
- охватывающие сквозные потоки функциональности
- для вновь добавленных функций
- включающие проверку полей (особенно важны негативные тест-кейсы).
9. В чем суть тестирования совместимости для десктопных и веб-приложений?
Для десктопных приложений тестирование совместимости проводится для проверки работоспособности приложения в условиях различных конфигураций, то есть различных комбинаций аппаратных средств и операционных систем (программного обеспечения).
При этом следует учитывать как обратную, так и прямую совместимость.
Для веб-приложений проводят кроссбраузерное тестирование. Это проверка приложения на различных комбинациях браузера и ОС. Также всегда нужно проводить тестирование на различных типах устройств (мобильных, планшетных и т. д.).
10. Как проверить срок действия ссылки (должен истечь в 12 часов ночи)?
Измените системную дату и время (в данном случае 12 часов ночи — следующий день), а затем проверьте, работает ли ссылка.
11. Вы переходите по ссылке , но появляется страница с ошибкой 500. Как вы будете устранять неисправность?
Выполните следующие действия:
- Проверьте, имеет ли вошедший в систему пользователь соответствующие права доступа
- Исключите проблемы с совместимостью браузеров, обсудив их с разработчиком
- Удалите файлы cookie и проверьте еще раз
- Если проблема не исчезла, заведите баг-репорт
12. Несколько ошибок, которые были проверены и устранены, снова появляются в новой сборке во время выполнения тестов. В чем может быть причина?
Если указанные ошибки были проверены в предыдущей сборке, то это значит, что проблемы возникли уже в новой. Наиболее вероятная причина – внесение разработчиками последних изменений.
Кроме того, возможно, что сама функциональность была изменена без ведома QA-инженера, хотя такое случается редко. В этом случае тестировщику следует провести обсуждение с командой разработчиков и затем сделать выводы.
13. Как проводится тестирование в Scrum?
В Scrum может не быть выделенных QA-специалистов. За тестирование отвечают все члены Scrum-команды.
- QA составляет тест-кейсы по мере готовности истории пользователя
- Разработчики выполняют модульные тесты
- QA выполняет функциональные и нефункциональные тесты по пользовательской истории
- В ходе демонстрационного спринта заказчики/заинтересованные стороны могут проводить приемочное тестирование и предоставлять важные отзывы, которые становятся исходными данными для следующего спринта
- Результаты тестирования сохраняются
14. Что вы будете делать, если разработчик не примет ошибку, о которой вы сообщили?
Если возникла подобная ситуация, повторно проверьте ошибку, чтобы убедиться, что она воспроизводится. Предоставьте разработчику необходимые подтверждения бага: скриншоты, видео, а также подробный перечень шагов.
Если и после этого разработчик не принимает ошибку, созовите совещание с участием руководителя группы/менеджера и бизнес-аналитика, чтобы обсудить ситуацию и принять коллективное решение.
15. Что такое BVT?
Build Verification Tests, также часто называемые Sanity tests, – это наиболее приоритетные тесты, которые выполняются при каждой новой сборке. Они должны прогоняться очень быстро, чтобы команда могла оперативно принять решение, пригодна ли сборка для дальнейшего тестирования. Как правило, эти тесты автоматизированы.
16. В чем разница между Smoke и Sanity-тестированием?
Smoke-тестирование позволяет определить, является ли развернутая сборка стабильной. Эти тесты помогают обнаружить проблемы на ранней стадии тестирования. Набор Smoke-тестов обычно содержит очень ограниченное число тест-кейсов, которые проверяют только основную функциональность программного продукта.
Если сборка недостаточно стабильна, выполнение таких тестов вручную потребует много времени. По этой причине в идеале они должны быть автоматизированы.
Sanity-тестирование проводится сразу после запуска новой сборки ПО. Эти тесты определяют, работает ли предлагаемая функциональность так, как ожидается. Обычно это позволяет сэкономить много времени, так как Sanity тестирование в основном ориентировано на ограниченные области/функциональные возможности. Это помогает определить, можно ли QA инженерам приступать к дальнейшему тестированию (например, регрессионному).
17. Что такое нефункциональное тестирование?
При нефункциональном тестировании проверяются нефункциональные аспекты программного продукта. Производительность и надежность ПО под воздействием нагрузки очень важны для удобства пользователей.
Как правило, проводятся следующие нефункциональные тесты:
- тестирование удобства использования
- тестирование производительности
- нагрузочное тестирование
- тестирование безопасности
18. Назовите основные компоненты отчета о тестировании и его преимущества
Содержание отчета о тестировании может различаться в зависимости от заинтересованных сторон, которым он будет направлен. Чаще всего этот документ состоит из следующих компонентов:
- Обзор проекта
- Цели тестирования
- Сводка тестирования
- Отчет о дефектах
Правильно составленная тестовая отчетность дает важные сведения заинтересованным сторонам, что, в свою очередь, позволяет им принять решение об успешном выпуске продукта в производственную среду.
19. Как проводить регрессионное тестирование при дефиците времени?
Если время, отведенное на тестирование, меньше ожидаемого, необходимо расставить приоритеты для выполнения тест-кейсов в новом порядке. Иногда может потребоваться привлечение дополнительных ресурсов. В такой ситуации решающую роль играет автоматизация тестов.
20. Что такое план и стратегия тестирования? Что из них важнее?
План тестирования – это документ, определяющий объем, цель, подход и интенсивность тестирования программного обеспечения. План тестирования может быть динамическим.
Стратегия тестирования – это набор рекомендаций/протоколов, которые описывают техники тестирования и определяют, как оно должно выполняться. Стратегия тестирования не может быть изменена. Часто она включается в план тестирования в качестве одного из его компонентов.
Стратегия тестирования задается на уровне организации, то есть определяется задолго до начала проекта.
21. Как вы решаете, когда прекратить тестирование?
На принятие решения о прекращении тестирования влияют следующие критерии:
- выполнение заранее определенного набора тест-кейсов с оговоренным процентом прохождения
- окончание срока тестирования и/или релиза
- количество ошибок уменьшилось до определенного заранее уровня и не наблюдается высокоприоритетных ошибок
- функциональное покрытие и покрытие кода достигают заранее установленной точки
- решение руководства (например, бюджет на тестирование исчерпан).
22. Возможно ли достичь 100% тестового покрытия? Как бы вы это обеспечили?
Полное тестовое покрытие очень зависит от размера тестируемого приложения. Сложность кода также играет важную роль. Для приложений небольшого размера оно может быть легко достигнуто.
Для каждой функциональности/требования должны быть тщательно разработаны тест-кейсы. Необходимо вести матрицу трассируемости. Не лишним будет использование автоматизированных тестов.
Примечание. Если основное внимание уделяется достижению 100% покрытия тестами, при этом сопоставление с требованиями/функциональными возможностями не выполняется и не поддерживается должным образом, это будет пустой тратой времени.
23. Опишите ваш процесс ознакомления с новыми продуктами и членами команды
Для ознакомления нужно пообщаться с членами команды и задать все возможные вопросы о продукте, процессах и трудностях, с которыми столкнулась команда. Затем нужно попробовать прогнать уже существующие ручные тест-кейсы, которые могут дать больше полезной информации о продукте. Также нужно самостоятельно изучить продукт со всех сторон.
24. Оцениваете ли ваш текущий подход к тестированию? Как вы его корректируете?
Да, подход к тестированию оценивается путем сбора и анализа некоторых ключевых показателей. Первый из них – это количество ошибок, найденных в результате выполнения утвержденных тестов до выпуска приложения. Этот показатель позволяет определить уровень тестового покрытия.
Следующая метрика – количество ошибок, найденных вне прогона тест-кейсов (возможно, в ходе исследовательского тестирования) или даже после релиза приложения. Если за пределами существующего тестового набора обнаружено достаточно много ошибок, то, безусловно, требуется корректировка всего подхода к тестированию.
Тест-кейсы должны быть пересмотрены и, если необходимо, переработаны для обеспечения более полного тестового покрытия. Нужно добавить недостающие тест-кейсы (если таковые имеются). Команде и руководству следует рассмотреть вопрос о необходимости автоматизации тестирования, по крайней мере, для некоторых ключевых функций.
25. Тестирование бывает сложной задачей. Что помогает вам сохранять мотивацию?
Сохранять мотивацию помогают следующие вещи:
- Сеансы обмена знаниями
- Обучение на рабочем месте
- Вознаграждение за успехи
- Неудачи рассматриваются как возможность для обучения
- Интерес руководства и поддержание с его стороны мотивации членов команды.
Заключение
Мы рассмотрели некоторые из практических вопросов и ответов на собеседовании по ручному тестированию. В основу статьи лег реальный опыт проведения собеседований. Надеемся, что данное руководство оказалось полезным, и вы сможете уверенно пройти любое интервью. Удачи!
Перевод статьи «Some Tricky Manual Testing Questions & Answers».