Комментарии 55
А что за матрицы вы упомянули? Матрицы трассируемости или математический концепт?
К слову, правильного ответа я до сих пор не знаю.
Предположу что вы должны эскалировать проблему выше, если TL вне зоны досягаемости садитесь писать письмо включая в СС всех: тимлида, менеджера, feature owner, scrum мастера, дева, Лида девов и менеджера девов: письмо в котором вы четко описываете что вот по вашему мнению это проблема которую надо решить вот прямо сейчас потому что это грозит большой потерей прибылей и объясняете всю ситуацию. Никакой ответственности ни вы ни дев не должны нести: ваша задача тестировать, задача дева писать код. Принимают решения другие люди, которых вы должны поставить в известность
А если ещё короче, то это область ответственности Product Owner и Scram Master. Они должны оценить все риски вплоть до того, чтобы обговорить их с клиентом: возможен ли выпуск релиза с этой проблемой и устранение её в следующем либо вообще отложить обновление до следующего релиза, в котором будет фикс. С программистом на эту тему можно поговорить лишь для того, чтобы обозначить проблему и ввести в курс дела, например показать как она воспроизводится
Задача же тестера, как было сказано выше, написать письмо с подробным описанием проблемы и каковы могут быть проблемы у клиента, добавить дефект с более лаконичным описанием, приаттачив это письмо и пометить дефект как Severity = High. Хотя и это будет лишним - даже приоритет дефекту будет назначать Product Owner.
Если эскалировать выше, то, гай мой взгляд, это означает, что процесс настроен плохо.
По хорошему, должно быть так,
Тестер заносит баг, ну или считает, что баг,
ССТ менеджер или лид назначает инженера на анализ
Инженер анализирует, решает, что это не баг
ССТ команда рассматривает анализ и выдаёт вердикт, либо это не баг, либо анализ неверный и назначает инженера на переанализ.
Далее круг повторяется, если ССТ решает, что это баг, назначается инженер на исправление.
После исправления Тестер верифицирует и закрывает.
В таком случае, тестер никого не должен убеждать. Его задача занести и проверифицировать. В ССТ команду могут входить лид по разработке и тестериванию и, например менеджер проекта, зависит от уровня бага.
Пожалуйста, не путайте профессию тестировщик и измерительный прибор.
Мне кажется не вопрос тестера решать, исправлять баг или нет, а тем более принимать решения по вопросам типа ("А если очень надо выпустить, потому что иначе компания потеряет много прибыли"). Иначе это уже не тестер, а ген диреткор. Так можно на него навешать и вопросы продвижения товара, и маркетинг.
Все такие вопросы решаются либо в скопе проекта (когда сразу обозначается, что надо качественно, дешево, но долго, или быстро, дешево, но не качественно), и владельцем продукта, а владелец продукта (так как он не разарботчик и не тестер), должен как минимум знать мнение лидеров по разработке и тестированию (насколько быстро можно поправить баг, насколько это баг вообще критичный и так далее) и на основании этого принмать решение.
Тестер же отлично сделал свою работу - нашел(как ему кажется) несоотвествие между требованиями и тем, что программа делает. Дальше уже не его забота, что с этим багом делать.
А то ведь так можно все эскалировать до ген. директора, звонить там ему ночью. Каждый должен делать свое дело по процессу действовать.
Это потому-что в нашей стране QA и тестеров мешают в одну кучу. Задача тестера - да, протыкать кнопочки, найти багу, зарепортить. Он ни за что не отвечает, от него ничего не ждут, платить ему много не нужно, даже знаний особых не надо. А QA отвечает за качество. Это в его интересах не пускать критикал на прод. С него в случае чего могут и спросить, но и полномочия заблочить релиз или донести разрабу что это баг, ткнув в ТЗ или ещё какой документ, тоже должны быть.
Если задают такие вопросы - значит ищут нормального QA, а не тестера, который кнопочки тыкает и на этом всё.
Ну вообще то, под "тестером" я понимал как раз QA инженера, а не обезьянку тыкающую на кнопки:
С моей точки зрения QA инженер должен выполнить следующие шаги(минимально необходимые шаги):
Проанализировать требования
Написать цели тестирования
Разработать тестовые спецификции
Разработать тест скрипты
Запустить тесты
Оформить результаты
Собственно, он точно также не должен за вопросы бизнеса или там приостановку релиза отвечать, и вообще озадачиваться ими (ну только если он не является лидом по тестированию).
Он занес баг - и ждет пока его назначать на верификацию, когда баг исправили. Может и не дождаться, если ССТ команда решит не править баг.
Самое важное тут анализ, который делает один человек (обычно разработчик) при котором может произойти 3 вещи:
Это баг, надо править код
Это баг в тесте, надо править тест
Это баг в требованиях, возможно надо править все.
ССТ на основе этого анализа решает, что делать дальше. Для принятия решения она может привлекать как QA, так и разработчика, а может никого не привлекать, сама решит, если анализ хороший.
В идеальном случае QA вообще не должен взаимодействовать с разработчиком, потому что для него все должно быть черным ящиком, а разработчик уже может иметь знания о внутреннем устройстве ПО и вообще он ненужное звено тут. Для QA есть требования, что подать на вход ПО, и что должно быть на выходе. Остальное только мешает работе.
Баг в системе есть - извольте его как минимум проанализировать - и никаких полномочий об остановке релиза у QA нет, они есть у ССТ команды. Если она решит, что незначительный баг - можно выпускать - ОК, решит не выпускать тоже ОК. QA свою функцию выполнил, предупредил, что ПО требованиям не соотвествует.
P.S. ну это если процесс настроен, если процесса нет, то согласен с оратором ниже, тут только эскалация куда-то вверх. Там пусть решают.
Сфера ответственности QA намного шире чем у тестировщика. QA обеспечивает качество продукта, а для этого постоянно приходится залезать в менеджмент и процессы. По-другому качество обеспечить невозможно.
Возможно, но я только по своему опыту. А мы делаем устройства с функциональной безопасностью SIL3, и там QA в менеджмент не лезет.
Качество обеспечивается процессом и его выполнением. QA может этот процесс собственно разработать и утвердить ( с менеджментов), но лезть потом к нему не должен (за исключением случаев, если в самом процессе прописано, что надо лезть к менеджементу и звонить директору в любое время суток в случае бага), так же как и менять процесс или вмешиваться на ходу в процесс.
Да, вы всё совершенно правильно описали, так и должно быть. Другой вопрос, что право на "no go" должно (или не должно) быть частью процесса, и если у QA есть такое право, то в описанной ситуации им вполне логично воспользоваться.
А вот с вашим предыдущим комментарием я абсолютно не соглашусь. Вы утверждаете, что QA можно вообще от разработчиков отделить. Но без понимания процесса, в т.ч. с точки зрения разработчика, без знания технологического и инфраструктурного стэка и особенностей его использования на проекте, без постоянного фидбэка - построить и нормальный процесс тестирования (в т.ч. авто, которое живет в том же стэке), и нормальный процесс разработки в целом - невозможно. Никакие демо, доки и синки не заменят погружения в нутрянку всех процессов.
На мой взгляд, процессы разработки и тестирования уже давно движутся навстречу друг другу, тулы для разработки уделяют всё больше времени тестируемости (testability), а тулы для автотестов расходятся на две ветки - максимальной простой no-code и продвинутые со всеми возможностями встраивания в процесс разработки. Поэтому роль QA Automation очень близка к разработчикам. А роль Manual QA чуть дальше, но тоже залезает в dev процессы.
Более того, специфика работы QA толкает интересоваться не только разработкой непосредственно, но и документацией, и дизайном, и саппортом, и переводами, и серверной инфраструктурой с CI, и даже маркетингом. На мой взгляд, QA это вообще самая экстравертная роль в команде, наравне с ПМом и техлидом. И держать QA в черном ящике вдали от команды - очень неэффективно.
Но да, об этом всем надо договариваться со всеми и заранее, чтобы не было недопониманий и "только мешает работе".
С мнением отделения разработчика от тестировщика не согласен
На сегодняшний день системы становятся сложнее и больше. И если будем придерживаться принципа "у каждого своя зона ответственности", то бизнесу разработка будет дороже с каждым витком технологий. И в конечном итоге рынок айти будет сокращаться, а не расти.
Если брать именно разработку нового функционала, то тестер, аналитик и разраб должны быть в диалоге. Это взаимодействие позволяет экономить деньги и выпускать более качественный продукт
Это лишь частная ситуация: все зависит от объемов работ, профиля компании/рынка и т.д.. Вполне хватает случаев, когда имеется фича/проект, за которым закреплены конкретные разработчик, тестировщик и аналитик. В таком случае большая часть вопросов решается напрямую. Если же возникают разногласия, то в ряде случаев практикуется 1ый уровень эскалации в виде обращения к аналитику для урегулирования спорных моментов и лишь последующий путь "выше". Если же проблема оказывает влияние на сроки/охват ожидаемого функционала, то здесь обращаются сразу по всей цепочки наверх: к сотрудникам, которые отвечают именно за эти метрики.
Это все к тому, что отнюдь не всегда и везде есть необходимость создавать прослойки между двумя исполнителями процесса. Лучше заняться поднятием корпоративного духа и грамотной проработкой персонала по средством HR, чтобы каждый сотрудник всегда исполнял свою роль ответственно. В таком случае, вероятность возникновения ситуации с "пинанием" проблемы сводится к минимуму, т.к. обе стороны понимают, что находятся в одной лодке и два весла работаю лишь в паре.
Нужно определить зоны ответственности. За что отвечает тестировщик. Если тестировщик отвечает за выпуск, то он должен либо забрить, либо эскалировать проблему выше.
Если задача тестировщика лишь ловить баги и где-то фиксировать - то ничего больше и не нужно.
Главное во всем это разделить зоны ответственности. Нельзя бездумно принимать на себя ответственность, если ситуация выходит за рамки оговоренного процесса. При отсутствии процесса на такой случай - эскалировать проблему на уровень выше. Если "уровень выше" в отпуске, эскалировать на того, кто в настоящий момент выполняет его обязанности. Если же ни кто не назначен замом - эскалировать еще выше - вплоть до руководителя компании.
Да просто писать или говорить всем кто выше лида. Если есть продакт манагер то ему, если его нету, то есть кто-то еще, кто стоит выше лида.
К примеру у нас есть только лид, наш руководитель, и дальше сразу тех дир и генеральный)
Как правило решение о релизе принимает тех дир, и наш руководитель, если руководителя нет, вместо него всегда лид. Такого что нет обоих, у нас небывает. Но если предположить что не будет лида и руководителя, то есть еще пара ребят которые могут лида подменить.
Но по факту тестировщиков ваще не спрашивают о чем либо, просто говорят что релизим и все. А решения принимает руководство.
Условия таковы что НУЖНО выпустить релиз, а ответственных лиц нет на связи в этот день - ИМ всем нужно дисциплинарное взыскание, а такому тестеру их премии выплатить!
Мне кажется вы вообще не в ту степь ушли.
Скорее всего, этот вопрос был тоже со звёздочкой. Об этом говорят их дальнейшие вопросы "а если до лида не дозвониться? а если очень надо выпустить?".
Компания хотела увидеть, насколько кандидат самостоятелен в каких-либо вопросах. Если порассуждать, то такой вопрос от разработчика мог появиться в следствии некорректно оформленного баг-репорта. Я думаю, что ждали все-таки такой ответ: "Такой ситуации не могло произойти, так как я спер-круто все проверил, прописал все шаги, чтобы ситуация воспроизвелась, приложил скриншот/скринкаст".
После был еще один непростой вопрос был о том, что я буду делать если лид тестировки будет в отпуске, мы в офисе и нужно сегодня же выпускать очень важный релиз, но есть критический баг, а кодер отказывается чинить (дословно).
Имхо - написать докладную записку руководству и всё.
Потому что это всё равно что задать вопрос мойщику окон "завтра приезжает делегация из китая, а мастер по этикету валяется пьяный в зюзю под столом, не до конца расставив тарелки". А мойщик такой "что же делать, расставить тарелки погуглив как это делается или за свой счет ехать выдергивать директора в другом городе из постели".
Тестировщик, тем более не лид тестировщик, никакого права принимать решения о выпуске продукта не должен в принципе. Его дело накатать отчет, довести его до нужных людей по каналам которые ему предоставили и всё. Брать на себя ответственность за стратегические решения и/или даже в чем-то прыгать выше головы - не его дело вообще.
p.s.: Тем более, еще раз, это рядовой тестировщик, даже не лид тестировщиков. Что вообще в этой компании происходит? Возможно лучший ответ был бы "уволиться", что бы показать что Вы ищите серьезную компанию, а не ту где такой бардак, что завтра выпуск важного релиза, а никого из вышестоящих не найти:)
«Какие будут различия в тестировании двух программ, где первая сортирует массивы методом пузырька, а вторая быстрой сортировкой, результат сортировки одинаковый?»
Тогда я предположил, что в скорости исполнения тестирования, и того, как много времени уйдёт на тестирование самих программ.
Если тестируете скорость, то есть смысл как минимум и на потребление памяти протестировать, да и обязательно запустить в многопоточном окружении (т.к. если тестируется сам алгоритм и алгоритм умеет в многопоточку, то запуск в однопоточном может проблем не показать).
Просто по хорошему программисту стоит помочь. И с воспроизведением и со срочной перепроверкой после фикса. Но это конечно при условии что разработчик готов сотрудничать для фикса. Если не готов, то максимально формальный путь принятый в компании. С уведомлением через тот же трекер всех кого полагается. Кто-то же из продуктовой команды отвечает за релиз? Вот его и уведомить.
Оно по разному в жизни бывает. Баги которые воспроизводятся со 100% вероятностью на типовом окружении не интересны. Тикет, исполнитель, тест вместе с фиксом на этот случай и все молодцы.
А вот всякое воспроизводящееся только на специально подготовленных данных, в специальном окружении и только в 23-59 по воскресеньям как раз интересно. И оно иногда требуют помощи и показа как же оно ломается. По типовому сценарию без помощи любой разработчик закроет как "Cannot reproduce".
В трекер кулстори можно и нужно потом написать. На практике она поможет только при следующем подобном случае. Люди поймут куда копать.
Провальный опыт - тоже опыт. Главное сделать нужные выводы и двигаться дальше, и всё получится.
я VoIP инженер и я много собесов проходил, вопросы есть легкие, а есть прям ребусы. на ошибках или не понимании я как раз и научился. пускай и заваливал собесы (вообще хз кого они там искали, видать супермена), но пришлось свою базу знаний резко структурировать. Сейчас работаю и пока норм. Жаль конечно, что хуавей ушла ... ну это ладно
На счет "выпустить релиз с багом пока лид в отпуске" - у тебя как у тестировщика в принципе нет таких полномочий выпускать что то как есть или не выпускать, у лида в любом случае есть замещаюшее лицо и ты просто не ставишь свою "подпись" в чек-листе тестирования перед релизом уведомив старшего что есть косяк и всё. И не надо бодаться с программистом, это не твоя работа, а работа "погонщика" начальника.
услышал про матрицы потому что последний раз с ними сталкивался два‑три года назад при учёбе в ВУЗе очень поверхностно и бегло, уже ничего про них не помню и понятия не имею как с ними работать, и первое о чём я подумал когда услышал вопрос это «Блин, я же про массивы ничего не знаю, чё делать»
"матрица" — это из алгебры попутали с "массивом" из программирования
Какие будут различия
найди отличие, там где нет отличия — такие вопросы в принципе новичкам не надо задавать
вообще очень адекватная статья, если в теме будете дальше развиваться, то вас возьмут куда хотите. в принципе на тестировщика и тут можно было брать, всё равно новичков без опыта работы какое-то время обучать надо специфике работы, а с обучаемостью у вас норм с их слов.
Серьёзно, на Junior тестировщика мобильных игрушек более чем достаточно тестового задания, а дальше сразу испытательный срок. Это не та позиция, где ради чуть более уверенного кандидата имеет смысл проводить долгий отбор, это просто рутинная работа класса «выполнил/не выполнил».
Часто на такую работу, если работник реально нужен, вообще берут с порога — «Говоришь, что умеешь и хочешь работать? Зарплата и график устраивают? Сегодня-завтра можешь приступить? Ну и отлично, давай попробуем поработать.». Сам так несколько раз устраивался, при том, что даже не тестировщиком, а разработчиком, правда уже с опытом.
С тестированием конкретно игрушек понятно, что так не получится (слишком много школьников будут подавать заявки, рассчитывая, что это работа из серии «весь день играешь в игрушки и жалуешься на баги», что они и так забесплатно делают), хоть какой-то отбор нужен, но собеседования с trick questions после тестового задания — явный перебор.
А как дословно был сформулирован вопрос про "баг перед релизом"?
В нашей компании есть определенный регламент проведения тестирования релиза. Поэтому я бы задал встречный вопрос о наличии такого регламента. Т. к. в моей практике пока не встречал самоорганизующейся команды, в том понимании, в котором о ней рассказывают с упоением в интернетах. Возможно, не повезло встретить. Не исключаю.
На мой взгляд, релизить такие обновления — это нормально, если подстелена хорошая соломка. Надо понять, в чём критичность бага. Ведёт ли он к порче данных? Попадёт ли клиент (или твоя компания) на бабки, если клиент на него наткнётся? В каких условиях (у каких клиентов) он будет воспроизводиться? Это баг в новой фиче, в фиче, которая включена только определённым пользователям, в раскатанной на всех фиче?
И можно будет катнуть, если складываются все эти условия:
— можем включать фичу только на тех пользователей, у кого не выстрелит баг (фича под флагом, потенциально страдающие пользователи легко выделяются);
— даже если случайно включим тем, у кого выстрелит, то это не приведёт к катастрофическим последствиям (порче данных, финансовым потерям) и пострадавшему можно будет отключить флаг, как только это всплывёт (если мы увидим его по метрикам/он обратится в техподдержку);
— не придётся никому отключать фичи, которые у них уже работали (то есть никому не ухудшаем ситуацию);
— мы обвешаны метриками/алертами, чтобы в случае чего быстро помочь пользователю;
В таком случае мы можем включить эту потенциально важную с точки зрения прибыли фичу хотя бы части пользователей, при этом держим в допустимых пределах вероятность проблем. Естественно, дежурные должны быть наготове, техподдержка предупреждена, а выборка пользователей на включение — сформирована.
Ну и тикет на исправление бага надо завести.
Практически копия моего второго собеса. Тест не программного продукта, сравнение 2 работающих фич без различия и решение внутреннего конфликта. Из первого собеседования я вынес то что это огромный стресс и надо попробовать максимально его снизить. Собственно об этой стороне есть много материалов. Подготовить комфортное место, приготовить воду, курево если надо, дать свежий воздух, сидеть откинувшись назад(не сжимать диафрагму), если ораторских данных мало то лучше стоять. Короче сделать беседу максимально для вас комфортной - как будто вы общаетесь с друзьями в расслабленной обстановке. Как только вы расслабитесь физически придет эмоциональная раскованность и все пойдет легче
Ребята, кажется, все таки забыли, что собеседовали человека без опыта. С другой стороны - ты получил отличный опыт, в следующий раз будешь готов и отвечать спокойнее, и хитрых вопросов не боятся
У вас хоть приличный вопрос был, а не: "Как бы вы объяснили 9-месячному ребенку что такое БД. Для удобства можете воспользоваться кубиками". Ощущение было будто помоями облили. Вакансия кстати мидла была, привет Касперскому.
Спасибо за статью! Автор, не переживай - это одно собеседование из многих - и ты его прошел более чем хорошо) Бывают такие собеседования, что потом вообще думаешь, а стоит ли мне в этой профессии дальше пытаться что-то)
Так что поздравляю) Да, если давать совет, хоты вы уже сами себе его дали, не спешите с ответом на вопросы и принятием решений, если покажете ход мысли собеседующим, будете рассуждать перед ответом, то им станет намного понятнее - есть ли у вас потенциал.
Джунов правда берут по принципу - "Теорию вроде знает, ошибки есть, но голова работает как надо".
Так что вы быстро сможете себя зарекомендовать)
А ну еще. Не бойтесь говорить, что чего-то не знаете, это не страшно - от вас и не ждут знания всей теории а тем более практических задач, лучше вместо длинной паузы сказать - Затрудняюсь ответить, и время занять другими вопросами)
В общем удачи)
"и правильный ответ в том, что различий нет."
Нет, товарищи из QA, так просто вы не отделаетесь. ) Cортировка пузырьком - стабильная, а быстрая нет, если с ключами ассоциированы данные, то на практике результат может быть принципиально разный.
Нравится, как каждый на вопрос "что делать, если баг не хотят чинить" ответил по-своему, примерив эту ситуацию на личный опыт. Даже немного завидую людям, у которых последние n проектов были настолько одинаковы, что они имеют четкое и однозначное мнение по этому поводу с указанием ролей и процессов, которые порой попросту отсутствуют в некоторых компаниях (знаю такие, где нет ни аналитиков, ни скрам-мастеров, ни проджектов, а задачу зарелизить может и сам тестировщик парой кнопок в CI/CD).
На самом деле, это стандартный вопрос на QA-собеседованиях про то, что ты будешь делать в довольно стандартной (по сравнению с остальными) "нештатной" ситуации, но заданный в форме со звездочкой. Ну и стандартный ответ — что-то усредненное из всех комментариев :) (аргументировать/эскалировать/не доставать нож)
На самом деле, это стандартный вопрос на QA-собеседованиях
Вопрос может и стандартный, но как джун имеющий начальника, он вообще не должен решать вопрос релиза и пытаться заставлять программиста чинить. Уговаривание разработчика для автора должно быть сугубо добровольным решением. Но вопрос «выпускать или чинить» им не должен решаться никоим образом, поскольку он подчинённый. Впрочем, ему могут явно или неявно такое право выдать, но тогда и нестандартной ситуация не будет.
Формулировка вопроса была пересказана, как я понимаю, в вольной форме и по ней (да и вообще) от автора нет никаких комментариев, хотя вопросы были. В текущей же редакции и не написано, что лично он должен принимать решение о релизе и/или заниматься его выпуском.
Для джуна, наверное, это вопрос не контрольный с правильным ответом, но полезный в плане возможности оценить представления кандидата о процессе разработки (забавный факт: я, например, свой первый баг почти 15 лет назад закрыл автоматом, подумав "ну не бежать же снова 20 минут до локации с багом, чтобы перепроверить")
PS: за свою карьеру пришел к выводу, что по поводу багов в случае разногласий (да и вообще почти по любому поводу) чаще всего стоит сперва пообщаться лично, это эффективнее и быстрее комментариев/писем/эскалаций на официальном языке, где коммуникация происходит раз в полчаса, если повезет.
Еще забавный факт: коллега, ушедшая в сине-красный маркетплейс, сильно удивилась, что один вопрос не решался по причине "они нам до сих пор [не первый день] не отвечают", хотя коллеги сидели в одном опенспейсе, в итоге сходили ножками и обо всем договорились (да, понятно, далеко не по всем вопросам надо бегать отвлекать вживую человека, и не через 5 минут после вопроса, и что долго не отвечать — тоже не очень хорошо и признак не лучших процессов)
Компания занимается космическими запусками и тебя приглашали на главного инженера? Если нет, то над тобой просто издевались люди которым было скучно, там пройти невозможно было
Спасибо автору за статью, и комментаторам за отзывы. Проходу обучение на QA, и любой опыт, тем более по собесам полезен!
Практика и практика. Всё индивидуально, но с десяток собеседований за месяц-два и нервная система адаптируется. :)
Как действующий QA тоже поделюсь мнением по поводу вопроса с критичным багом
Если ты так тестер считаешь что перед тобой критикал, а разраб-нет, покажи ему требования или ТЗ(на основании чего-то было же принято решение что это баг), этим шагом как минимум удастся показать что ты знаешь об этом великолепном инструменте и умении им пользоваться(из практики: умение читать и вникать в ТЗ- скилл суперважный)
Если интервьюеры решат сказать что из требований непонятно баг или нет, то ответь что пойдёшь к бизнес аналитику, продукт овнеру, или ещё к кому кто за требования отвечает за прояснениями, если он подтвердит что баг найден - просим срочно, вот прям сейчас прописать всю информацию.
Если скажут, что ответственный за требования тоже полностью погружен в нирвану и никак его оттуда не достать, значит идём к заказчику(в случае если проект внешний) или менеджеру ( продукт овнеру, гейм дизайнеру) который отвечает за концепцию, с ним всё проясняем и заносим в требования, с требованиями идём к разрабу. Этот ответ на собесе даст понять, что ты человек готовый принимать решения и нести ответственность за их последствия.
Если работодатель окончательно решит в фантасмагорию и решит что джун qa это единственный человек в офисе в день релиза, то надо выкатывать продукт, предварительно отправив всем ответственным список багов. Решать всё надо будет на стадии мэнтенса хотфиксами в первые дни релиза, из этого ответа все поймут что знаешь что такое maintenance и hotfix, практика таких релизов распространенная, все знают в каком состоянии сейчас игры выходят
Касательно того что сейчас смотрят на софт-Скиллы, это да, и на них будут смотреть на каждом собесе. Научить человека писать тест кейсы и баг репорты достаточно просто, научить человека быть ответственным и способным в коммуникации намного сложнее, поэтому стоит всегда стараться показать что эти качества уже при тебе и ты готов продемонстрировать их на деле
Надеюсь вся эта писанина поможет автору или ещё кому с дальнейшими собесами. Удачи!
Я думал, что завалить собес на qt джуна можно только в одном случае - если на него не явиться. ))
Прозреваю, что на вопрос про несогласие с программистом, хотели услышать ответ: "Сошлюсь на документацию, фт или около того"
Интересно, есть люди, не из лиги плюща, хаха, которых с первого собеседования взяли на работу? Меня с вышкой и англ уровня полубог, плюс немецкий не брали на ксерокс даже :)))
Все у вас получится. Меньше думайте о вопросах, думайте наш ответами.
Как я завалил первый тех. собес на позицию Junior QA Engineer