xndrya

Я последнее время часто провожу собеседования тестеров. Начал вам подробно отвечать, получилось столько текста, что решил написать на эту тему полноценную статью. Правда там больше информации по найму manual junior. Но на некоторых вопросах посыпется половина и более опытных QA. Разместил ее на спарке в блоге нашего проекта: https://spark.ru/startup/neaktor/blog/31094/nanyat...

Краткое содержание вопросов по самому собеседованию:

• Что такое вообще тестирование?
  
• Что такое blackbox / whitebox / graybox?
  
• Жизненный цикл бага / ПО?
  
• Чем отличается чек-лист от тест-кейса? Когда стоит их использовать?
  
• Виды / типы / уровни тестирования
  
• Техники тест-дизайна. Минимальный набор: Boundary Values, Equivalence Partition, Decision Tables, State Transition. Более продвинутые: Pairwise например. Решите практическое задание по составлению тест-кейсов с применением техник тест-дизайна, которые знаете. Explorative - не в счет
  
• Логические задачи
  
• Вопросы на адекватность. Что делать, если вам возвращают тикет в Reject? Не знаете как тестировать какой-то функционал. Что делать?
  

Отдельно тестовым заданием проверяется оформление дефектов.

Большинство вопросов "открытые", то есть можно остановить соискателя в любой момент и попросить уточнить какие-то делали. Например, "Тестирование производительности? Давайте остановимся подробнее. Какие подтипы знаете? Чем отличается Load от Stress тестинга? Как вы будете проводить тестирование производительности?"

Или вот например еще задача на подумать. Когда тестирование интерфейса является функциональным тестированием, а когда нет? Приведите пример.

Если говорить про собеседования senior, то более технические вопросы обязательны. Артем выше привел неплохие примеры. Но тут можно вообще про много что спрашивать. От как вы будете тестировать API до запросов в noSQL базы. Также у тестеров с опытом спрашивать про матрицы покрытия тестов, тест-планирование, цикл разработки тестовой документации и так далее.

Надеюсь вам поможет.

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

Руками или автоматизируют.

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

Да нет, там как раз все просто. Грубо говоря есть три уровня:

• "Делает ли эта функция то, что должна?": Мы (как тестировщики) знаем, что функция делает внутри себя, и убеждаемся, что она продолжает это делать и в будущем. Это именуют модульным или юнит-тестированием. В маленьких проектах обычно его не делают или покрывают такими тестами только определенные части проекта. Помогает оперативно находить изменения в поведении существующих модулей, которые так могут долго оставаться незамеченными и потом не понятно, что вызвало поломку. По идее такие тесты должны в автоматическом режиме проходить перед сборкой кода для продакшена.
  
• "Работают ли несколько модулей вместе так, как задумано?": Мы не знаем, что происходит внутри связки, но знаем, что есть на входе и что должно быть на выходе. Это именуют интеграционным тестированием. По идее оно помогает находить проблемы на стыке модулей, когда поведение одного модуля поменяли, а про другой забыли. В реальном мире встречается не так часто, т.к. требует включения мозгов для написания тестов.
  
• "Решает ли система задачи пользователя?": Это по-разному называют. Тут идет работа от ТЗ. Мы знаем, что должен получить пользователь от готовой системы в ответ на свои действия, но как она работает внутри нам фиолетово. Наиболее понятный сценарий такого тестирования - заранее написать кейсы, примеры того, как пользователь решает какую-то задачу, а потом перед каждым релизом "прокликивать" нужные последовательности кнопок или что-то вроде того. Это могут делать руками (студенты-обезьянки) или можно автоматизировать. Посмотрите примеры использования CodeceptJS и все станет ясно. По-хорошему это стоит делать на проектах любого размера, но на практике...
  

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