Николай

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

Притом в рекомендациях к ISTQB Foundation Level есть очень правильная оговорка: "Не рекомендуется сдавать людям, у которых менее 6 месяцев опыта". Если опыта нет, вы только начали работать или только планируете перейти в тестирование - не идите сдавать экзамен. Вы просто не поймете для чего это было придумано и как это применять в живой жизни.

К слову, ISTQB Foundation во многом основаны на книгах горячо любимого мной Коупланда.

Добрый день,

1. Практически уверен, что это незаконно. Эксплуатация детского труда и все такое. После этого пункта уже можно ставить точку, но я добавлю.
2. Вам уже корректно отметили в одном из комментариев, ребенок не составит вам тестовый отчет и вообще сложно будет понять, что именно не нравится. Не нравится, и все тут. Тестирование - это работа, а не просто потыкать по экрану.
3. В играх, детских приложениях и прочем, о чем вы вероятно думаете, я предполагаю, что тестирование на аудитории если и устраивают, то бета-тестами. Для этого распространяют приложение на определенный круг лиц. Например, англоязычные продукты любят сначала любят тестировать в Канаде - аудитория схожа, а страна и количество пользователей меньше. Полученные результаты анализируют. Выборка данных в разы больше, данные по UX по одному ребенку ничего не дадут.

Для бизнес и прочего софта, ваша потенциальная услуга точно будет бесполезной.

4. "... должно быть понятно даже ребенку". Расскажу про еще один подход к тестированию, касается UX. Посмотреть на сайт/приложения глазами пьяного, у которого внимание рассредоточено, а в глазах расплывается. Австралийский дизайнер какой-то разработал концепт чисто по приколу. Например, статья на эту тему. В целом не рекомендую так цепляться с фразам и пробовать на себе. А то, если подходить к пониманию вещей так буквально, то получится эксплуатация детей и пьющие родители. Прямо готовый кейс, как современные технологии разрушают семьи.

Дальше больше, посмотреть глазами умирающего, посмотреть глазами утопающего, посмотреть глазами без глаз и так далее.

Рекомендую для начала Коупланда (Copeland). Отличный автор, мало того на нем в том числе построена система сертификации по тестированию ISTQB.

Можно конечно того же Савина почитать.

Про jenkins / teamcity и другие сборщики уже ответили выше.

Если вопрос чисто организационный: почему тестеры чаще других пересобирают тестовые серваки? То это потому, что когда тикет приходит в тест, его невозможно тестировать, если негде тестировать. Не поднимать же себе локальную версию каждый раз?

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

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

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

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

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

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

Создавать кейсы вручную этой техникой долго и относительно сложно. Есть специализированные тулзы для этого.