1. Тестирование — не лучший путь в менеджмент.
2. Уход в менеджмент после 2-3 лет технической работы это вообще фиаско для всех.

Вообще нет. Процесс описания занимает менее 5%. Активности, которые занимают большую часть времени: анализ требований, написание и редактирования тест-кейсов / чек-листов / чартов, тестирование (в т.ч. и исследование факторов которые приводят к дефекту). В некоторых случаях еще подготовка тестового окружения.
75% на документацию дефектов это может быть только в случае, когда адски забагованный аппликейшн выдается на эксплоратори тестирование.

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

Если интересует астрофизика, сделай: компьютерную модель Солнечной системы или Галактики. Проверь компьютерным экспериментом необходимость включения в модель темной материи. Просчитай альтернативные ТМ теории. Это из самого простого. Ограничений нет.

Мне не очень понятно как может быть одновременно «Заинтересовала физика» и «не могу найти задач для поддержания интереса». Вы либо трусы наденьте, либо крестик снимите :-)

Очень важно сформулировать цель, для чего Вы хотите учить астрофизику. Потому что:
1. За эту работу везде платят копейки. Только единицы раскрутившихся могут заработать прилично. Реальная зарплата сотрудника будет меньше, чем у рабочего за конвейерной лентой. Это похоже на ситуацию с художниками, когда 0.01% известны и гребет миллионы, 1-2% прилично зарабатывает, а остальные ~98% едва сводят концы с концами.

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

3. Для того, чтобы преуспеть в теоретической части (где можно сделать имя без всего, что описано в п.2) нужно иметь просто уникальные математические способности (1 на миллион или около того). Если этого нет, будешь статистом в лучшем случае.

Саммарайз — советую идти в эту отрасль только, если жить без этого не можешь. Но это вообще не вяжется с «немогу найти задач для поддержания интереса».

В обсужденнии много лулзов (что хорошо), но маловато конструктива. Исправляю :-)
Идея не реализуема. Проблемы:

1. «Полнота языка». Компьютерные программы как правило описывают реальный мир. Следовательно, для описания сбоя без существенной потери смысла нужно примерно то же количество слов, что и в живом современном языке минус синонимы, идиомы и прочее. Итого у нас получится что-то вроде en.wikipedia.org/wiki/Special_English или en.wikipedia.org/wiki/Basic_English. Т.е. 850 или 1500 слов. плюс IT-специфические термины. В итоге, получим словарный запас среднего тестировщика в мировой IT индустрии.

2. Падение автотеста однозначно не идетифицируется без вмешательства человека. Это значит, что баг-репорт будет содержать только сырую и непроверенную информацию. В результате бОльшея часть баг-репортов будут невалидным и только отвлекать девов, порождать недоверие к результатам тестов. Почему нельзя установить истинную причину автоматически см. en.wikipedia.org/...​_law_of_requisite_variety

3. Унификация с ручными тестами. Не все можно автоматизировать, а указанный вариант может быть применим только к ним. Соответсвенно, баги от автотестов и найденные другим путем будут иметь разный формат. Цель не достигнута.

4. Избыточность/неполнота общего формата описания ворк-продактов тестирования (в т.ч. багов). Даже ISTQB признает, что нет золотого стандарта и что тестирование всегда контекстно-зависимо. То, что хорошо для Аэроспейс индустрии будет злом при создании веб-магазинчика по шаблону. И наоборот.

Пару лет назад изучал вопросы на Test Manager. Сложилось стойкое впечатление, что они составлялись не с целью проверить необходимые знания, а с целью, чтобы пройти их могли только те, кто целенаправлено зубрил определенную программу. К примеру, вопрос на «подумать». 4 варианта ответа. Правильных больше одного. Из них 1 железно правильный, 1 железно неправильный и 2 спорных. И нужно, руководствуясь вот этой спорной логикой, угадать тот, который считается правильным. А иначе весь ответ не засчитывается. Короче говоря, сложилось ощущение, что в сертификации около 30% полезных знаний и 70% бесполезных догматов которые нужны исключительно для извлечения большей прибыли.
Интересно, что думают по этому поводу те, кто получил этот сертификат. В особенности уже после того, как имел нормальный опыт работы тест-менеджером.

Цель — понять, передо мной homo sapiens, способный думать или абизяна, способная только клацать.

Это можно узнать значительно проще. Просто спроси, собирается ли кандидат голосовать за Зе во втором туре :-)
Соррян, не смог удержаться от политоты )

«Цiкаве питання, будемо полемiзувати...»
Знать чем отличается test strategy от test plan (хотя бы в одном из вариантов) миддл должен. А вот уметь писать стратегию или сетапить все процессы тестирования с нуля — нет.
Нормально спрашивать вопросы, выходящие за пределы компетенции, чтобы понять профессиональный кругозор, но это не то, за что миддла стоит реджектить на собеседовании. Также обязательно проговаривать необязательность знания этого кандидату, чтобы не было дурных мыслей, что зареджектили именно за это.
Если Вы лид или Тест-Менеджер, так оставляйте за себя Синьора, который метит выше, а не миддла, который знает все тоже, что и синьор, но просто звучит дешевле.

Ну так автор же попросила не забрасывать камнями, а дать конструктив... Но коммент все равно не залайкала, неблагодарная :-)

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

Вопрос «вы пришли на проект, что будете делать» весьма правильный. И для миддла на него существует вполне логичный набор ответов: Уточню ожидания от моей работы у непосредственного руководителя (KPI, если есть), ознакомлюсь с рабочими инструкциями, составлю рамп-ап/ноледж шэринг план, познакомлюсь с командой... Это все ОК. Но вот требовать от миддла строить тестовые процессы (особенно с нуля) это все равно, что от миддл девелопера в-одиночку разрабатывать архитектуру приложения.

Опять же спросить в общих чертах, на уровне понимания терминов об отличие тест-плана от тест-стратегии норм. Но вот просить описать составляющие это будет уже перебор.

Конечно. Это может быть Lead QA или Test Manager / Test Engineer. Но в любом случае не миддл.

Я бы не советовал собеседоваться в компанию в которой для позиции Middle QA задают вопросы, релевантные только для тест-менеджера. Это неадекватный подход. Либо кто-то повышает свое ЧСВ за Ваш счет, либо придется работать тест-менеджером за зарплату миддла.

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

Тест-кейс. Придираюсь не к наполнению, а, в-основном, к форме:
0. ID тест-кейса. Как на него ссылаться?
1. Нерелевантный Precondition. То, что описано,- это конфигурация. Ее лучше в отдельную секцию вынести (Критично)
2. В прекондишены можно загнать степы 1-2. (Logged in to a web site, page .. is displayed) — (Важно)
3. Саммари можно сделать лучше. «Get last month’s statistics through ... bar» — короче и понятнее. Вы ж не требования пишите, а тест-кейс (средне)
4. Английский кривой. Злоупотребление модальным глаголом should. Устоявшееся правило писать тест-кейсы и рабочие инструкции в present simple. Не «The bar should show...», а «The bar shows ...» (Важно)

Баг-репорт:
0. ID дефекта...
1. Summary не годится. Из него в идеале должна быть понятна проблема (остальные поля должно лишь уточнять его). (Критично)
2. Снова... Информация об ОС и браузере это конфигурация или энвайронмент. Это стоит выделять в отдельное поле (Очень важно)
3. В баг-репорте отсутствуют:
3.1. Дата создания (критично). Да, баг-трэкинг системы это делают сами. Но у нас же экселька... 3.2. Версия (бранч) тестируемого софта (Очень важно).
3.3. Ссылка на тест-кейс (средне, но зависит от отрасли. В регулируемых отраслях это критично). 3.4. Ссылка на требование или даже версию требования (средне. Опять же, при разработке веб-магазина может быть вообще пофиг, но в аэроспейсе может быть очень важно).
3.5. Occurrence (once/sometimes/always либо в формате 3/5) (Важно)

Под ситуацию можно еще много чего придумать. Но остальное уже мелочи

А как получить PMP не имея опыта и не будучи практикующим PMом?

«Дайте мне мотивированную, кроссфункциональную команду профессионалов, и я запилю любой проект и без скрама» © Архимед.

Ну нельзя всех под одну гребенку. И вне IT есть много мест, где сотрудников ценят и советуются с ними. И в IT есть немало мест, где «Где бля и быстро бля!». Может Григорий как раз из других.

Думаю, что толковый ПМ не из IT может при определенных обстоятельствах эффективно руководить IT проектом. Но есть проблемы:

1. Отсутствие профессионального портфолио. Особенно актуально для аутсорс-проектов (80% рынка). Просто представьте себе первое представление такого ПМа заказчику: «Здравствуйте, это Валентин. Он раньше работал прорабом, не имеет никакого опыта в IT, никогда не вел IT проекты. Имеет только теоретическое представление об SDLc и IT best practices. Мы уверены, он отлично справится с Вашим проектом». Вот нафига компании так сразу себя подставлять?

2. Отсутствие авторитета. Это может вылиться в неуважение со стороны подчиненных. Пара некорректных вопросов или глупых комментариев, высказанных таким ПМом (а такое однозначно случится) превратят его в объект шуток на курилках со всеми вытекающими. В худшем случае это может вылиться в месячные эстимейты для задачи на день. Даже если Вы это поймете, Вам будет очень тяжело с этим бороться.

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

4. У Вас нет команды и доверенных людей по многим вопросам. Хорошо, если придя на уже идущий проект Вы застанете там компетентных, мотивированных архитекторов и лидов. Или, если при старте нового проекта компания снабдит Вас хорошим архитектором, лид-девелоперами, тест-менеджером и т.д. А если нет? А как Вы поймете, что они некомпетентные? А если поймете, как подберете новых, компетентных?

Саммари: желающих перейти в ПМы и среди айтишников не мало. Так какой смысл брать человека со стороны, если у него сразу 3-4 больших минуса. Ну и ко всему прочему есть фактор клановости. Для IT-шников Вы чужак. Тут бывший девелопер трижды подумает, чтобы сделать ПМом тестировщика. А Вы для нас вообще: «из какого района? не заблудился?»

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