Здравствуйте, меня зовут Артём, и я с ноября месяца изучаю тестирование. Спустя ровно два месяца я получил первое приглашение на техническое собеседование, позиция Junior QA Engineer, мобильная разработка, геймдев. Хотел бы поделиться этой историей с теми, кому это может пригодиться, так как не все мои ожидания оправдались, а некоторые вопросы на собеседовании действительно поставили в тупик.
От соискателя помимо фундаментальной базы теории тестирования также требовались знание простых SQL запросов и понимание принципов функционирования клиент-серверных приложений. Также твоим преимуществами могут выступить опыт в написании тестовой документации, и знание английского языка от B1. Перед тем как откликнуться на вакансию, нужно было пройти небольшой тест с вариантами ответа по базовым аспектам тестирования (были вопросы а ля что такое smoke test, white box testing и прочее).
После моего отклика со мной связалась HR, выслав ссылку на тестовое задание, в котором нужно было написать тест-кейсы с максимальным тестовым покрытием для функционала по спеку, а также разбить эти тест-кейсы по видам тестирования.
К слову, на данный момент я искренне не понимаю, почему так не делает каждая компания при выборе кандидата на позицию джуна, желательно чтобы он при нажатии кнопки «Откликнуться» сразу же получал тестовое задание ссылкой, ведь благодаря этому можно примерно оценить навыки кандидата, на что он способен, а кандидату понять круг задач или хотя бы его часть, также это поможет отсеять всех тех кто бездумно жмёт кнопку «Откликнуться». Ну да ладно. Речь не об этом.
Своё решение тестового задания я отправил на следующий день, принялся ждать. Спустя 10 дней (были рождественские и новогодние праздники) мне сообщили, что проверят моё решение в течение 1-3 дней. После мне сообщили что хотят со мной провести интервью и предложили выбрать удобную мне дату. Я предварительно ознакомился со всеми отзывами сотрудников о компании, поиграл в игры которая она разрабатывает и просмотрел группу во ВКонтакте из которой тоже подчерпнул для себя много интересного. Не совсем доволен тем как прошло интервью с моей стороны, я готовился отвечать на вопросы с ходу, но первые 15 минут мне рассказывали о жизни и истории компании, и вопросы задавал я, я так расслабился в ходе рассказа что вообще забыл что мне могут задавать хоть какие-то вопросы, и по итогу немного переволновался, когда вопросы начали задавать мне. И всё же, меня пригласили на тех. собеседование. Всё проходило, к слову, дистанционно.
Конечно, и здесь присутствовало волнение, так как это была моя первая попытка трудоустроиться в принципе. На собеседовании помимо HR`a и QA Lead`a всей компании также присутствовал QA Lead конкретного проекта, под которого они искали сотрудника, от этого я стал волноваться еще больше, было неловко что столько серьезных людей выделило своё время ради меня, особенно сложно мне далась попытка рассказать о себе, представьте себе, сидят три крутых специалиста с огромным бэкграундом и жизненным опытом, и маленький я без практического опыта работы, который пару недель назад вышел на рынок труда в принципе, первые несколько минут я еле собирал предложения в слова, но потом пошло намного легче, когда мне начали задавать вопросы, ребята показались очень даже дружелюбными, а теорию я прям старался подготовить. А теперь к сути.
Кстати, у меня ни слова не спросили про моё знание клиент-серверной архитектуры, а также мой уровень английского языка, ни на интервью с HR`ом, ни на тех. собесе. А еще требуемый опыт работы в вакансии был указан 1-3 года, но готовы были взять начинающего. Тут уж думайте сами, одного собеседования мне недостаточно, чтобы понять, насколько это распространённая практика указывать то что может не пригодиться.
Собеседование в моём понимании шло неплохо, правда, был вопрос где меня попросили протестировать масло для волос (назвал я его сам так как меня попросили назвать первый предмет под рукой), я старался выдать вообще всевозможные проверки от того что масло свои функции выполняет правильно вплоть до проверки где мы пьём содержимое (на случай если ребенок чьей‑то мамы решит испить содержимое, было бы здорово чтобы он остался жив), а когда закончил то получил мгновенный фидбэк о том забыл провести проверку на то что этикетка приклеена, чтобы покупатель мог понять что это масло в принципе, тут я конечно виноват, каюсь, но я почему‑то представлял себе что масло будет продаваться в магазине/интернет‑магазине, и как бы на ценнике/в описании товара внутри сайта будет указана вся нужная информация. Но в любом случае спрашивали поменьше и попроще, чем я ожидал, думал будет хуже, но шло собеседование неплохо до тех пор. пока передо мной не поставили абстрактную задачу: «Какие будут различия в тестировании двух программ, где первая сортирует массивы методом пузырька, а вторая быстрой сортировкой, результат сортировки одинаковый?»
Я в свою очередь сперва предположил, что в ожидаемом результате работы программ, аргументируя это тем, что важно убедиться что сам алгоритм решения работает правильно в этих программах и мы это видим. Мне упростили задачу, сказав, что мы знаем что всё работает правильно и что одна программа выполняет свою работу быстрее другой. Тогда я предположил, что в скорости исполнения тестирования, и того, как много времени уйдёт на тестирование самих программ. Меня спросили, всё ли это. И тогда я еще дополнил, что в тест-кейсах, связанных с тестированием интерфейса, тоже могут быть отличия, подумав, что различие в том как будет отображаться решение. Меня опять спросили, всё ли это. Вот тогда я занервничал, еще так минут пять я сидел и думал, иногда выдавая подобного рода предположения, в ответ получая наводящие уточнения которые дают мне понять что я не прав и что что-то делаю не так, в конце я сказал, что наверное это всё, и больше я не могу придумать. Собеседующий сказал, что ответ нужно дать сейчас. И я сказал, что у меня нет окончательного ответа в данный момент. Когда я сдался мне таки объяснили, что это вопрос с подвохом, и правильный ответ в том, что различий нет.
Было на самом деле обидно, по сути обычный вопрос на понимание чёрноящичного тестирования, но я немного загнался когда услышал про матрицы потому что последний раз с ними сталкивался два‑три года назад при учёбе в ВУЗе очень поверхностно и бегло, уже ничего про них не помню и понятия не имею как с ними работать, и первое о чём я подумал когда услышал вопрос это «Блин, я же про массивы ничего не знаю, чё делать».
После был еще один непростой вопрос был о том, что я буду делать если лид тестировки будет в отпуске, мы в офисе и нужно сегодня же выпускать очень важный релиз, но есть критический баг, а кодер отказывается чинить (дословно). Сперва я сказал, что попробую убедить программиста, изложив перед ним факты (а ля дружище, релиз очень важный для компании, а эта проблема не даёт нам возможности выпустить обновление, нужно чинить, очень нужно). Спрашивают:
— А если он откажется потому что будет считать что это не баг?
— Тогда я попробую дозвониться до лида несмотря на то что он в отпуске, чтобы он помог разрешить ситуацию
— А если до лида не дозвониться?
— Тогда я не дам выпустить релиз, потому что лучше не выпускать вообще ничего, чем то что только навредит программе
— А если очень надо выпустить, потому что иначе компания потеряет много прибыли?
— В таком случае, я сделал всё что мог, все вопросы задавайте программисту.
К слову, правильного ответа я до сих пор не знаю, если он и есть. Наверное, стоит пытаться убедить программиста до последнего, пытаясь найти взаимопонимание всеми способами. Если не получится, то значит придётся нести ответственность и мне и ему, но лучше всё же не релизить в таком случае. Но я тогда над этим не думал, собеседование к тому моменту длилось уже около часа, и я чувствовал некоторую истощённость, технические вопросы как смог ответил, и об остальном не думал от слова совсем. Тогда я этому вопросу особого значения не придавал. Сейчас я понимаю что он больше на проверку личных качеств и поведения сотрудника в той или иной ситуации, и он не менее важный чем любой технический.
Спустя два дня компания дала мне ответ, назвав «способным, энергичным и быстро обучаемым», но недостаточно «усидчивым» (якобы моя скорость принятия решений мешала обращать мне внимание на мелочи, а в начале будет много рутинной и монотонной работы), а потому в данный момент они не готовы предложить мне роль QA в их команде.
На собеседовании я на все вопросы отвечал первое, что приходит на ум. чтобы показать свой ход мысли, быть вовлеченным в сам процесс и показать, что я есть на самом деле. Было немного обидно, потому что компания показалась мне очень даже хорошей, а также мобильная разработка это самое интересное для меня направление, к тому же я вполне усидчив, но не смог показать это на деле, и никак не могу оспорить их решение так как понимаю что со стороны я показал себя в целом так как мне и сказали, кажется, я действительно принимал решения слишком быстро и не совсем обдуманно, боясь что могу просто замолчать на какое‑то время. Также в качестве рекомендации мне посоветовали продолжить изучение теории тестирования и книгу Орлова «Джедайские техники конструктивного общения». В любом случае я благодарен этой компании за предоставленный опыт, я понял, в каких аспектах был недостаточно хорош
От себя могу добавить следующее.
Я готовил теорию на 110%, и готовил я только её, но сейчас я понимаю что личные качества и умение сотрудника решать нестандартные ситуации ценятся не меньше. Так же как и умение проецировать теорию на любую ситуацию, с этим я действительно справился не самым лучшим образом. Также для себя я понял что в некоторых ситуациях нет истинно верного ответа, или ответ может быть не так очевиден как кажется. Наверное для кого-то это и так очевидно, Но я в тот момент об этом не думал и рассуждал так чтоб прийти к единственному верному варианту в любом из случаев, и мне всё казалось проще и очевиднее. А еще я настоятельно рекомендую внимательно изучать каждую вакансию в индивидуальном порядке, от и до. Список советов, конечно, мог бы быть гораздо больше, но я здесь изложил лишь то что для себя узнал именно от этого случая.
Надеюсь, эта информация когда-нибудь и кому-нибудь поможет лучше подготовиться, чтобы воплотить желаемое в реальность, хорошего вам дня и спасибо за внимание.
Комментарии (55)
kindacute
00.00.0000 00:00+19К слову, правильного ответа я до сих пор не знаю.Предположу что вы должны эскалировать проблему выше, если TL вне зоны досягаемости садитесь писать письмо включая в СС всех: тимлида, менеджера, feature owner, scrum мастера, дева, Лида девов и менеджера девов: письмо в котором вы четко описываете что вот по вашему мнению это проблема которую надо решить вот прямо сейчас потому что это грозит большой потерей прибылей и объясняете всю ситуацию. Никакой ответственности ни вы ни дев не должны нести: ваша задача тестировать, задача дева писать код. Принимают решения другие люди, которых вы должны поставить в известность
Vmurashev70
00.00.0000 00:00+2А если ещё короче, то это область ответственности Product Owner и Scram Master. Они должны оценить все риски вплоть до того, чтобы обговорить их с клиентом: возможен ли выпуск релиза с этой проблемой и устранение её в следующем либо вообще отложить обновление до следующего релиза, в котором будет фикс. С программистом на эту тему можно поговорить лишь для того, чтобы обозначить проблему и ввести в курс дела, например показать как она воспроизводится
Задача же тестера, как было сказано выше, написать письмо с подробным описанием проблемы и каковы могут быть проблемы у клиента, добавить дефект с более лаконичным описанием, приаттачив это письмо и пометить дефект как Severity = High. Хотя и это будет лишним - даже приоритет дефекту будет назначать Product Owner.
lamerok
00.00.0000 00:00+3Если эскалировать выше, то, гай мой взгляд, это означает, что процесс настроен плохо.
По хорошему, должно быть так,
Тестер заносит баг, ну или считает, что баг,
ССТ менеджер или лид назначает инженера на анализ
Инженер анализирует, решает, что это не баг
ССТ команда рассматривает анализ и выдаёт вердикт, либо это не баг, либо анализ неверный и назначает инженера на переанализ.
Далее круг повторяется, если ССТ решает, что это баг, назначается инженер на исправление.
-
После исправления Тестер верифицирует и закрывает.
В таком случае, тестер никого не должен убеждать. Его задача занести и проверифицировать. В ССТ команду могут входить лид по разработке и тестериванию и, например менеджер проекта, зависит от уровня бага.
TITnet
00.00.0000 00:00-8Пожалуйста, не путайте профессию тестировщик и измерительный прибор.
lamerok
00.00.0000 00:00+2Мне кажется не вопрос тестера решать, исправлять баг или нет, а тем более принимать решения по вопросам типа ("А если очень надо выпустить, потому что иначе компания потеряет много прибыли"). Иначе это уже не тестер, а ген диреткор. Так можно на него навешать и вопросы продвижения товара, и маркетинг.
Все такие вопросы решаются либо в скопе проекта (когда сразу обозначается, что надо качественно, дешево, но долго, или быстро, дешево, но не качественно), и владельцем продукта, а владелец продукта (так как он не разарботчик и не тестер), должен как минимум знать мнение лидеров по разработке и тестированию (насколько быстро можно поправить баг, насколько это баг вообще критичный и так далее) и на основании этого принмать решение.
Тестер же отлично сделал свою работу - нашел(как ему кажется) несоотвествие между требованиями и тем, что программа делает. Дальше уже не его забота, что с этим багом делать.
А то ведь так можно все эскалировать до ген. директора, звонить там ему ночью. Каждый должен делать свое дело по процессу действовать.
R3B3LL10N
00.00.0000 00:00Это потому-что в нашей стране QA и тестеров мешают в одну кучу. Задача тестера - да, протыкать кнопочки, найти багу, зарепортить. Он ни за что не отвечает, от него ничего не ждут, платить ему много не нужно, даже знаний особых не надо. А QA отвечает за качество. Это в его интересах не пускать критикал на прод. С него в случае чего могут и спросить, но и полномочия заблочить релиз или донести разрабу что это баг, ткнув в ТЗ или ещё какой документ, тоже должны быть.
Если задают такие вопросы - значит ищут нормального QA, а не тестера, который кнопочки тыкает и на этом всё.
lamerok
00.00.0000 00:00+2Ну вообще то, под "тестером" я понимал как раз QA инженера, а не обезьянку тыкающую на кнопки:
С моей точки зрения QA инженер должен выполнить следующие шаги(минимально необходимые шаги):
Проанализировать требования
Написать цели тестирования
Разработать тестовые спецификции
Разработать тест скрипты
Запустить тесты
Оформить результаты
Собственно, он точно также не должен за вопросы бизнеса или там приостановку релиза отвечать, и вообще озадачиваться ими (ну только если он не является лидом по тестированию).
Он занес баг - и ждет пока его назначать на верификацию, когда баг исправили. Может и не дождаться, если ССТ команда решит не править баг.
Самое важное тут анализ, который делает один человек (обычно разработчик) при котором может произойти 3 вещи:
Это баг, надо править код
Это баг в тесте, надо править тест
-
Это баг в требованиях, возможно надо править все.
ССТ на основе этого анализа решает, что делать дальше. Для принятия решения она может привлекать как QA, так и разработчика, а может никого не привлекать, сама решит, если анализ хороший.
В идеальном случае QA вообще не должен взаимодействовать с разработчиком, потому что для него все должно быть черным ящиком, а разработчик уже может иметь знания о внутреннем устройстве ПО и вообще он ненужное звено тут. Для QA есть требования, что подать на вход ПО, и что должно быть на выходе. Остальное только мешает работе.
Баг в системе есть - извольте его как минимум проанализировать - и никаких полномочий об остановке релиза у QA нет, они есть у ССТ команды. Если она решит, что незначительный баг - можно выпускать - ОК, решит не выпускать тоже ОК. QA свою функцию выполнил, предупредил, что ПО требованиям не соотвествует.
P.S. ну это если процесс настроен, если процесса нет, то согласен с оратором ниже, тут только эскалация куда-то вверх. Там пусть решают.
Doman
00.00.0000 00:00Сфера ответственности QA намного шире чем у тестировщика. QA обеспечивает качество продукта, а для этого постоянно приходится залезать в менеджмент и процессы. По-другому качество обеспечить невозможно.
lamerok
00.00.0000 00:00Возможно, но я только по своему опыту. А мы делаем устройства с функциональной безопасностью SIL3, и там QA в менеджмент не лезет.
Качество обеспечивается процессом и его выполнением. QA может этот процесс собственно разработать и утвердить ( с менеджментов), но лезть потом к нему не должен (за исключением случаев, если в самом процессе прописано, что надо лезть к менеджементу и звонить директору в любое время суток в случае бага), так же как и менять процесс или вмешиваться на ходу в процесс.
Doman
00.00.0000 00:00Да, вы всё совершенно правильно описали, так и должно быть. Другой вопрос, что право на "no go" должно (или не должно) быть частью процесса, и если у QA есть такое право, то в описанной ситуации им вполне логично воспользоваться.
А вот с вашим предыдущим комментарием я абсолютно не соглашусь. Вы утверждаете, что QA можно вообще от разработчиков отделить. Но без понимания процесса, в т.ч. с точки зрения разработчика, без знания технологического и инфраструктурного стэка и особенностей его использования на проекте, без постоянного фидбэка - построить и нормальный процесс тестирования (в т.ч. авто, которое живет в том же стэке), и нормальный процесс разработки в целом - невозможно. Никакие демо, доки и синки не заменят погружения в нутрянку всех процессов.
На мой взгляд, процессы разработки и тестирования уже давно движутся навстречу друг другу, тулы для разработки уделяют всё больше времени тестируемости (testability), а тулы для автотестов расходятся на две ветки - максимальной простой no-code и продвинутые со всеми возможностями встраивания в процесс разработки. Поэтому роль QA Automation очень близка к разработчикам. А роль Manual QA чуть дальше, но тоже залезает в dev процессы.
Более того, специфика работы QA толкает интересоваться не только разработкой непосредственно, но и документацией, и дизайном, и саппортом, и переводами, и серверной инфраструктурой с CI, и даже маркетингом. На мой взгляд, QA это вообще самая экстравертная роль в команде, наравне с ПМом и техлидом. И держать QA в черном ящике вдали от команды - очень неэффективно.
Но да, об этом всем надо договариваться со всеми и заранее, чтобы не было недопониманий и "только мешает работе".
alex_124
00.00.0000 00:00+1С мнением отделения разработчика от тестировщика не согласен
На сегодняшний день системы становятся сложнее и больше. И если будем придерживаться принципа "у каждого своя зона ответственности", то бизнесу разработка будет дороже с каждым витком технологий. И в конечном итоге рынок айти будет сокращаться, а не расти.
Если брать именно разработку нового функционала, то тестер, аналитик и разраб должны быть в диалоге. Это взаимодействие позволяет экономить деньги и выпускать более качественный продукт
2tea2room22
00.00.0000 00:00+1Это лишь частная ситуация: все зависит от объемов работ, профиля компании/рынка и т.д.. Вполне хватает случаев, когда имеется фича/проект, за которым закреплены конкретные разработчик, тестировщик и аналитик. В таком случае большая часть вопросов решается напрямую. Если же возникают разногласия, то в ряде случаев практикуется 1ый уровень эскалации в виде обращения к аналитику для урегулирования спорных моментов и лишь последующий путь "выше". Если же проблема оказывает влияние на сроки/охват ожидаемого функционала, то здесь обращаются сразу по всей цепочки наверх: к сотрудникам, которые отвечают именно за эти метрики.
Это все к тому, что отнюдь не всегда и везде есть необходимость создавать прослойки между двумя исполнителями процесса. Лучше заняться поднятием корпоративного духа и грамотной проработкой персонала по средством HR, чтобы каждый сотрудник всегда исполнял свою роль ответственно. В таком случае, вероятность возникновения ситуации с "пинанием" проблемы сводится к минимуму, т.к. обе стороны понимают, что находятся в одной лодке и два весла работаю лишь в паре.
Wendor
00.00.0000 00:00+3Нужно определить зоны ответственности. За что отвечает тестировщик. Если тестировщик отвечает за выпуск, то он должен либо забрить, либо эскалировать проблему выше.
Если задача тестировщика лишь ловить баги и где-то фиксировать - то ничего больше и не нужно.
Главное во всем это разделить зоны ответственности. Нельзя бездумно принимать на себя ответственность, если ситуация выходит за рамки оговоренного процесса. При отсутствии процесса на такой случай - эскалировать проблему на уровень выше. Если "уровень выше" в отпуске, эскалировать на того, кто в настоящий момент выполняет его обязанности. Если же ни кто не назначен замом - эскалировать еще выше - вплоть до руководителя компании.
vshopin
00.00.0000 00:00Да просто писать или говорить всем кто выше лида. Если есть продакт манагер то ему, если его нету, то есть кто-то еще, кто стоит выше лида.
К примеру у нас есть только лид, наш руководитель, и дальше сразу тех дир и генеральный)
Как правило решение о релизе принимает тех дир, и наш руководитель, если руководителя нет, вместо него всегда лид. Такого что нет обоих, у нас небывает. Но если предположить что не будет лида и руководителя, то есть еще пара ребят которые могут лида подменить.
Но по факту тестировщиков ваще не спрашивают о чем либо, просто говорят что релизим и все. А решения принимает руководство.
AlekseiVB
00.00.0000 00:00Условия таковы что НУЖНО выпустить релиз, а ответственных лиц нет на связи в этот день - ИМ всем нужно дисциплинарное взыскание, а такому тестеру их премии выплатить!
darya_mikhaylova
00.00.0000 00:00Мне кажется вы вообще не в ту степь ушли.
Скорее всего, этот вопрос был тоже со звёздочкой. Об этом говорят их дальнейшие вопросы "а если до лида не дозвониться? а если очень надо выпустить?".
Компания хотела увидеть, насколько кандидат самостоятелен в каких-либо вопросах. Если порассуждать, то такой вопрос от разработчика мог появиться в следствии некорректно оформленного баг-репорта. Я думаю, что ждали все-таки такой ответ: "Такой ситуации не могло произойти, так как я спер-круто все проверил, прописал все шаги, чтобы ситуация воспроизвелась, приложил скриншот/скринкаст".kindacute
00.00.0000 00:00Не хотел бы я работать в том месте, где решения принимает джун. От джуна(стажера) я бы не ожидал какой-либо самостоятельности, особенно в вопросах релизить фикс в прод или нет
edogs
00.00.0000 00:00+6После был еще один непростой вопрос был о том, что я буду делать если лид тестировки будет в отпуске, мы в офисе и нужно сегодня же выпускать очень важный релиз, но есть критический баг, а кодер отказывается чинить (дословно).
Имхо - написать докладную записку руководству и всё.
Потому что это всё равно что задать вопрос мойщику окон "завтра приезжает делегация из китая, а мастер по этикету валяется пьяный в зюзю под столом, не до конца расставив тарелки". А мойщик такой "что же делать, расставить тарелки погуглив как это делается или за свой счет ехать выдергивать директора в другом городе из постели".
Тестировщик, тем более не лид тестировщик, никакого права принимать решения о выпуске продукта не должен в принципе. Его дело накатать отчет, довести его до нужных людей по каналам которые ему предоставили и всё. Брать на себя ответственность за стратегические решения и/или даже в чем-то прыгать выше головы - не его дело вообще.p.s.: Тем более, еще раз, это рядовой тестировщик, даже не лид тестировщиков. Что вообще в этой компании происходит? Возможно лучший ответ был бы "уволиться", что бы показать что Вы ищите серьезную компанию, а не ту где такой бардак, что завтра выпуск важного релиза, а никого из вышестоящих не найти:)
«Какие будут различия в тестировании двух программ, где первая сортирует массивы методом пузырька, а вторая быстрой сортировкой, результат сортировки одинаковый?»
Тогда я предположил, что в скорости исполнения тестирования, и того, как много времени уйдёт на тестирование самих программ.
Если тестируете скорость, то есть смысл как минимум и на потребление памяти протестировать, да и обязательно запустить в многопоточном окружении (т.к. если тестируется сам алгоритм и алгоритм умеет в многопоточку, то запуск в однопоточном может проблем не показать).
12rbah
00.00.0000 00:00+4Что вообще в этой компании происходит?
Да обычное дело, когда джун QA принимает решение о релизе продукта)
anonymous
00.00.0000 00:00НЛО прилетело и опубликовало эту надпись здесь
BugM
00.00.0000 00:00Просто по хорошему программисту стоит помочь. И с воспроизведением и со срочной перепроверкой после фикса. Но это конечно при условии что разработчик готов сотрудничать для фикса. Если не готов, то максимально формальный путь принятый в компании. С уведомлением через тот же трекер всех кого полагается. Кто-то же из продуктовой команды отвечает за релиз? Вот его и уведомить.
anonymous
00.00.0000 00:00НЛО прилетело и опубликовало эту надпись здесь
BugM
00.00.0000 00:00+4Оно по разному в жизни бывает. Баги которые воспроизводятся со 100% вероятностью на типовом окружении не интересны. Тикет, исполнитель, тест вместе с фиксом на этот случай и все молодцы.
А вот всякое воспроизводящееся только на специально подготовленных данных, в специальном окружении и только в 23-59 по воскресеньям как раз интересно. И оно иногда требуют помощи и показа как же оно ломается. По типовому сценарию без помощи любой разработчик закроет как "Cannot reproduce".
В трекер кулстори можно и нужно потом написать. На практике она поможет только при следующем подобном случае. Люди поймут куда копать.
EGA_production
00.00.0000 00:00Провальный опыт - тоже опыт. Главное сделать нужные выводы и двигаться дальше, и всё получится.
viksav
00.00.0000 00:00я VoIP инженер и я много собесов проходил, вопросы есть легкие, а есть прям ребусы. на ошибках или не понимании я как раз и научился. пускай и заваливал собесы (вообще хз кого они там искали, видать супермена), но пришлось свою базу знаний резко структурировать. Сейчас работаю и пока норм. Жаль конечно, что хуавей ушла ... ну это ладно
anton_reut
00.00.0000 00:00+2На счет "выпустить релиз с багом пока лид в отпуске" - у тебя как у тестировщика в принципе нет таких полномочий выпускать что то как есть или не выпускать, у лида в любом случае есть замещаюшее лицо и ты просто не ставишь свою "подпись" в чек-листе тестирования перед релизом уведомив старшего что есть косяк и всё. И не надо бодаться с программистом, это не твоя работа, а работа "погонщика" начальника.
Hebe
00.00.0000 00:00+3услышал про матрицы потому что последний раз с ними сталкивался два‑три года назад при учёбе в ВУЗе очень поверхностно и бегло, уже ничего про них не помню и понятия не имею как с ними работать, и первое о чём я подумал когда услышал вопрос это «Блин, я же про массивы ничего не знаю, чё делать»
"матрица" — это из алгебры попутали с "массивом" из программирования
Какие будут различия
найди отличие, там где нет отличия — такие вопросы в принципе новичкам не надо задавать
вообще очень адекватная статья, если в теме будете дальше развиваться, то вас возьмут куда хотите. в принципе на тестировщика и тут можно было брать, всё равно новичков без опыта работы какое-то время обучать надо специфике работы, а с обучаемостью у вас норм с их слов.
i86com
00.00.0000 00:00+2Значит, им не тестировщик нужен, а просто «в боссов поиграть».
Серьёзно, на Junior тестировщика мобильных игрушек более чем достаточно тестового задания, а дальше сразу испытательный срок. Это не та позиция, где ради чуть более уверенного кандидата имеет смысл проводить долгий отбор, это просто рутинная работа класса «выполнил/не выполнил».
Часто на такую работу, если работник реально нужен, вообще берут с порога — «Говоришь, что умеешь и хочешь работать? Зарплата и график устраивают? Сегодня-завтра можешь приступить? Ну и отлично, давай попробуем поработать.». Сам так несколько раз устраивался, при том, что даже не тестировщиком, а разработчиком, правда уже с опытом.
С тестированием конкретно игрушек понятно, что так не получится (слишком много школьников будут подавать заявки, рассчитывая, что это работа из серии «весь день играешь в игрушки и жалуешься на баги», что они и так забесплатно делают), хоть какой-то отбор нужен, но собеседования с trick questions после тестового задания — явный перебор.
Arhammon
00.00.0000 00:00Хитрые вопросы это прям к QA. Как то было дело ходил на завод, даже там хитрые вопросы были. Условно, я (благодаря эконом образованию) в принципе могу произвести впечатление QA, но QC буду около нулевым.
Nialpe
00.00.0000 00:00А как дословно был сформулирован вопрос про "баг перед релизом"?
В нашей компании есть определенный регламент проведения тестирования релиза. Поэтому я бы задал встречный вопрос о наличии такого регламента. Т. к. в моей практике пока не встречал самоорганизующейся команды, в том понимании, в котором о ней рассказывают с упоением в интернетах. Возможно, не повезло встретить. Не исключаю.
Darth_Anjan
00.00.0000 00:00Поделюсь своим мнением о релизе обновлений с критичным багом.
На мой взгляд, релизить такие обновления — это нормально, если подстелена хорошая соломка. Надо понять, в чём критичность бага. Ведёт ли он к порче данных? Попадёт ли клиент (или твоя компания) на бабки, если клиент на него наткнётся? В каких условиях (у каких клиентов) он будет воспроизводиться? Это баг в новой фиче, в фиче, которая включена только определённым пользователям, в раскатанной на всех фиче?
И можно будет катнуть, если складываются все эти условия:
— можем включать фичу только на тех пользователей, у кого не выстрелит баг (фича под флагом, потенциально страдающие пользователи легко выделяются);
— даже если случайно включим тем, у кого выстрелит, то это не приведёт к катастрофическим последствиям (порче данных, финансовым потерям) и пострадавшему можно будет отключить флаг, как только это всплывёт (если мы увидим его по метрикам/он обратится в техподдержку);
— не придётся никому отключать фичи, которые у них уже работали (то есть никому не ухудшаем ситуацию);
— мы обвешаны метриками/алертами, чтобы в случае чего быстро помочь пользователю;
В таком случае мы можем включить эту потенциально важную с точки зрения прибыли фичу хотя бы части пользователей, при этом держим в допустимых пределах вероятность проблем. Естественно, дежурные должны быть наготове, техподдержка предупреждена, а выборка пользователей на включение — сформирована.
Ну и тикет на исправление бага надо завести.
Dyrimar
00.00.0000 00:00Практически копия моего второго собеса. Тест не программного продукта, сравнение 2 работающих фич без различия и решение внутреннего конфликта. Из первого собеседования я вынес то что это огромный стресс и надо попробовать максимально его снизить. Собственно об этой стороне есть много материалов. Подготовить комфортное место, приготовить воду, курево если надо, дать свежий воздух, сидеть откинувшись назад(не сжимать диафрагму), если ораторских данных мало то лучше стоять. Короче сделать беседу максимально для вас комфортной - как будто вы общаетесь с друзьями в расслабленной обстановке. Как только вы расслабитесь физически придет эмоциональная раскованность и все пойдет легче
Timur_El
00.00.0000 00:00Ребята, кажется, все таки забыли, что собеседовали человека без опыта. С другой стороны - ты получил отличный опыт, в следующий раз будешь готов и отвечать спокойнее, и хитрых вопросов не боятся
dvoryakanton
00.00.0000 00:00У вас хоть приличный вопрос был, а не: "Как бы вы объяснили 9-месячному ребенку что такое БД. Для удобства можете воспользоваться кубиками". Ощущение было будто помоями облили. Вакансия кстати мидла была, привет Касперскому.
roswell
00.00.0000 00:00Дичь какая-то. Девятимесячному ребенку -- кубиками? Ну, ок.jpg, я попробую, но ребята там, кажется, немного оторвались от реальности.
Faenor
00.00.0000 00:00Спасибо за статью! Автор, не переживай - это одно собеседование из многих - и ты его прошел более чем хорошо) Бывают такие собеседования, что потом вообще думаешь, а стоит ли мне в этой профессии дальше пытаться что-то)
Так что поздравляю) Да, если давать совет, хоты вы уже сами себе его дали, не спешите с ответом на вопросы и принятием решений, если покажете ход мысли собеседующим, будете рассуждать перед ответом, то им станет намного понятнее - есть ли у вас потенциал.
Джунов правда берут по принципу - "Теорию вроде знает, ошибки есть, но голова работает как надо".
Так что вы быстро сможете себя зарекомендовать)
А ну еще. Не бойтесь говорить, что чего-то не знаете, это не страшно - от вас и не ждут знания всей теории а тем более практических задач, лучше вместо длинной паузы сказать - Затрудняюсь ответить, и время занять другими вопросами)
В общем удачи)
thevlad
00.00.0000 00:00+2"и правильный ответ в том, что различий нет."
Нет, товарищи из QA, так просто вы не отделаетесь. ) Cортировка пузырьком - стабильная, а быстрая нет, если с ключами ассоциированы данные, то на практике результат может быть принципиально разный.
iBljad
00.00.0000 00:00+1Нравится, как каждый на вопрос "что делать, если баг не хотят чинить" ответил по-своему, примерив эту ситуацию на личный опыт. Даже немного завидую людям, у которых последние n проектов были настолько одинаковы, что они имеют четкое и однозначное мнение по этому поводу с указанием ролей и процессов, которые порой попросту отсутствуют в некоторых компаниях (знаю такие, где нет ни аналитиков, ни скрам-мастеров, ни проджектов, а задачу зарелизить может и сам тестировщик парой кнопок в CI/CD).
На самом деле, это стандартный вопрос на QA-собеседованиях про то, что ты будешь делать в довольно стандартной (по сравнению с остальными) "нештатной" ситуации, но заданный в форме со звездочкой. Ну и стандартный ответ — что-то усредненное из всех комментариев :) (аргументировать/эскалировать/не доставать нож)
Vizmaros
00.00.0000 00:00На самом деле, это стандартный вопрос на QA-собеседованиях
Вопрос может и стандартный, но как джун имеющий начальника, он вообще не должен решать вопрос релиза и пытаться заставлять программиста чинить. Уговаривание разработчика для автора должно быть сугубо добровольным решением. Но вопрос «выпускать или чинить» им не должен решаться никоим образом, поскольку он подчинённый. Впрочем, ему могут явно или неявно такое право выдать, но тогда и нестандартной ситуация не будет.iBljad
00.00.0000 00:00+1Формулировка вопроса была пересказана, как я понимаю, в вольной форме и по ней (да и вообще) от автора нет никаких комментариев, хотя вопросы были. В текущей же редакции и не написано, что лично он должен принимать решение о релизе и/или заниматься его выпуском.
Для джуна, наверное, это вопрос не контрольный с правильным ответом, но полезный в плане возможности оценить представления кандидата о процессе разработки (забавный факт: я, например, свой первый баг почти 15 лет назад закрыл автоматом, подумав "ну не бежать же снова 20 минут до локации с багом, чтобы перепроверить")
PS: за свою карьеру пришел к выводу, что по поводу багов в случае разногласий (да и вообще почти по любому поводу) чаще всего стоит сперва пообщаться лично, это эффективнее и быстрее комментариев/писем/эскалаций на официальном языке, где коммуникация происходит раз в полчаса, если повезет.
Еще забавный факт: коллега, ушедшая в сине-красный маркетплейс, сильно удивилась, что один вопрос не решался по причине "они нам до сих пор [не первый день] не отвечают", хотя коллеги сидели в одном опенспейсе, в итоге сходили ножками и обо всем договорились (да, понятно, далеко не по всем вопросам надо бегать отвлекать вживую человека, и не через 5 минут после вопроса, и что долго не отвечать — тоже не очень хорошо и признак не лучших процессов)
Mixard
00.00.0000 00:00Спасибо автору за статью, и комментаторам за отзывы. Проходу обучение на QA, и любой опыт, тем более по собесам полезен!
zrcadlo7
00.00.0000 00:00Практика и практика. Всё индивидуально, но с десяток собеседований за месяц-два и нервная система адаптируется. :)
Kabanchos
00.00.0000 00:00+2Как действующий QA тоже поделюсь мнением по поводу вопроса с критичным багом
Если ты так тестер считаешь что перед тобой критикал, а разраб-нет, покажи ему требования или ТЗ(на основании чего-то было же принято решение что это баг), этим шагом как минимум удастся показать что ты знаешь об этом великолепном инструменте и умении им пользоваться(из практики: умение читать и вникать в ТЗ- скилл суперважный)
Если интервьюеры решат сказать что из требований непонятно баг или нет, то ответь что пойдёшь к бизнес аналитику, продукт овнеру, или ещё к кому кто за требования отвечает за прояснениями, если он подтвердит что баг найден - просим срочно, вот прям сейчас прописать всю информацию.
Если скажут, что ответственный за требования тоже полностью погружен в нирвану и никак его оттуда не достать, значит идём к заказчику(в случае если проект внешний) или менеджеру ( продукт овнеру, гейм дизайнеру) который отвечает за концепцию, с ним всё проясняем и заносим в требования, с требованиями идём к разрабу. Этот ответ на собесе даст понять, что ты человек готовый принимать решения и нести ответственность за их последствия.
Если работодатель окончательно решит в фантасмагорию и решит что джун qa это единственный человек в офисе в день релиза, то надо выкатывать продукт, предварительно отправив всем ответственным список багов. Решать всё надо будет на стадии мэнтенса хотфиксами в первые дни релиза, из этого ответа все поймут что знаешь что такое maintenance и hotfix, практика таких релизов распространенная, все знают в каком состоянии сейчас игры выходят
Касательно того что сейчас смотрят на софт-Скиллы, это да, и на них будут смотреть на каждом собесе. Научить человека писать тест кейсы и баг репорты достаточно просто, научить человека быть ответственным и способным в коммуникации намного сложнее, поэтому стоит всегда стараться показать что эти качества уже при тебе и ты готов продемонстрировать их на деле
Надеюсь вся эта писанина поможет автору или ещё кому с дальнейшими собесами. Удачи!
DmitriKon
00.00.0000 00:00Я думал, что завалить собес на qt джуна можно только в одном случае - если на него не явиться. ))
Bulevarshik
00.00.0000 00:00Прозреваю, что на вопрос про несогласие с программистом, хотели услышать ответ: "Сошлюсь на документацию, фт или около того"
Simpre_falta_algo
00.00.0000 00:00Интересно, есть люди, не из лиги плюща, хаха, которых с первого собеседования взяли на работу? Меня с вышкой и англ уровня полубог, плюс немецкий не брали на ксерокс даже :)))
Все у вас получится. Меньше думайте о вопросах, думайте наш ответами.
AndreySitaev
А что за матрицы вы упомянули? Матрицы трассируемости или математический концепт?
shark14
Возможно, человек просто путает массивы и матрицы. (К слову, в некотором смысле массив тоже можно считать матрицей размера N*1, только в информатике обычно так не говорят).
notwithstanding
Только если она заполнена элементами конкретного кольца или поля.