Я последнее время часто провожу собеседования тестеров. Начал вам подробно отвечать, получилось столько текста, что решил написать на эту тему полноценную статью. Правда там больше информации по найму 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 базы. Также у тестеров с опытом спрашивать про матрицы покрытия тестов, тест-планирование, цикл разработки тестовой документации и так далее.

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

Речь же идет о сайте, верно? Хотя не так принципиально. Начните с контента: с того, какую информацию вы хотите разместить на своем сайте/проекте. От этого уже пойдет составление технического задания, оно же "ТЗ":
1) Структура страниц: что, где, на какой странице должно располагаться
2) Как будут выглядеть отдельные страницы блоки
3) Какой дополнительный функционал будет подключаться. Например, виджеты обратных звонков.
ну и т.д

Дальше в хорошей студии большую часть всего этого доработают за вас. Сначала вы заполните бриф, ответите на вопросы что и как хотите сделать. После этого менеджер по продукту со стороны студии задаст нужные вопросы по ТЗ и отдаст в работу.

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

-- выучится на тестировщика гораздо проще;

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

Порог вхождения в тестирование ниже, чем в программирование - это правда. Но ближе к Senior-уровню ситуация меняется: хорошим тестером быть дано не каждому. И я даже не говорю по Automation. И не буду говорить что есть три уровня тестеров: Tester, QC, QA (последних вообще мало).

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

Тестирование - во многом:
1) Про умение писать техническую документацию: тест-планы, тест-кейсы, баг-репорты. Писать нужно очень много - это 70 процентов работы.
2) Про коммуникацию. Необходимо общаться и эффективно получать информацию от BA, Dev, Customers, Stakeholders
3) Про способность докапываться до сути и понимать потребности бизнеса. Dev может делать только свой кусочек работы, а QA должен понимать как это работает в целом.
4) Технические навыки и хотя бы общее понимание того, как пишется код - тоже обязательны.

И, в целом, в QA много рутинной работы, с которой не все справляются.

-- знание ООП, алгоритмов, синтаксиса ЯП является бонусом, но не всегда это обязательно;

Чем больше вы знаете, тем больше вы стоите. Конечно ООП нужно знать.

-- тестировщики постоянно востребованы, почти так же как и программисты;

Безусловно

-- почему тогда все не идут в тестировщики, вместо программистов? Из-за любви к программированию? Или лишь потому что программистам платят немного больше?

Читайте выше - работа QA не для всех в виду ее специфики.

-- можно ли устроится тестировщиком после 34 лет (в вакансиях конечно требования к возрасту не пишут, по понятным причинам)? Слышал, что это в основном для молодёжи..

Можно, но сложнее, кто бы вам не говорил иначе. В странах СНГ средний возраст айтишника пока около 28-30 лет, хотя в штатах уже давно значительно выше.

-- правда ли то что тестировщики с опытом работы так же востребованы за рубежом как и программисты?

Да

-- если кандидат пройдёт онлайн курсы тестировщиков, это повысит его шансы при приёме на работу в IT компанию?

Сомнительно. Лучше почитайте Коупланда (Copeland)

-- и верно ли то что раньше (лет 10 тому назад) тестировщиком легче было устроится без опыта, "с улицы"?

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