Как действующий QA тоже поделюсь мнением по поводу вопроса с критичным багом
Если ты так тестер считаешь что перед тобой критикал, а разраб-нет, покажи ему требования или ТЗ(на основании чего-то было же принято решение что это баг), этим шагом как минимум удастся показать что ты знаешь об этом великолепном инструменте и умении им пользоваться(из практики: умение читать и вникать в ТЗ- скилл суперважный)
Если интервьюеры решат сказать что из требований непонятно баг или нет, то ответь что пойдёшь к бизнес аналитику, продукт овнеру, или ещё к кому кто за требования отвечает за прояснениями, если он подтвердит что баг найден - просим срочно, вот прям сейчас прописать всю информацию.
Если скажут, что ответственный за требования тоже полностью погружен в нирвану и никак его оттуда не достать, значит идём к заказчику(в случае если проект внешний) или менеджеру ( продукт овнеру, гейм дизайнеру) который отвечает за концепцию, с ним всё проясняем и заносим в требования, с требованиями идём к разрабу. Этот ответ на собесе даст понять, что ты человек готовый принимать решения и нести ответственность за их последствия.
Если работодатель окончательно решит в фантасмагорию и решит что джун qa это единственный человек в офисе в день релиза, то надо выкатывать продукт, предварительно отправив всем ответственным список багов. Решать всё надо будет на стадии мэнтенса хотфиксами в первые дни релиза, из этого ответа все поймут что знаешь что такое maintenance и hotfix, практика таких релизов распространенная, все знают в каком состоянии сейчас игры выходят
Касательно того что сейчас смотрят на софт-Скиллы, это да, и на них будут смотреть на каждом собесе. Научить человека писать тест кейсы и баг репорты достаточно просто, научить человека быть ответственным и способным в коммуникации намного сложнее, поэтому стоит всегда стараться показать что эти качества уже при тебе и ты готов продемонстрировать их на деле
Надеюсь вся эта писанина поможет автору или ещё кому с дальнейшими собесами. Удачи!
Как действующий QA тоже поделюсь мнением по поводу вопроса с критичным багом
Если ты так тестер считаешь что перед тобой критикал, а разраб-нет, покажи ему требования или ТЗ(на основании чего-то было же принято решение что это баг), этим шагом как минимум удастся показать что ты знаешь об этом великолепном инструменте и умении им пользоваться(из практики: умение читать и вникать в ТЗ- скилл суперважный)
Если интервьюеры решат сказать что из требований непонятно баг или нет, то ответь что пойдёшь к бизнес аналитику, продукт овнеру, или ещё к кому кто за требования отвечает за прояснениями, если он подтвердит что баг найден - просим срочно, вот прям сейчас прописать всю информацию.
Если скажут, что ответственный за требования тоже полностью погружен в нирвану и никак его оттуда не достать, значит идём к заказчику(в случае если проект внешний) или менеджеру ( продукт овнеру, гейм дизайнеру) который отвечает за концепцию, с ним всё проясняем и заносим в требования, с требованиями идём к разрабу. Этот ответ на собесе даст понять, что ты человек готовый принимать решения и нести ответственность за их последствия.
Если работодатель окончательно решит в фантасмагорию и решит что джун qa это единственный человек в офисе в день релиза, то надо выкатывать продукт, предварительно отправив всем ответственным список багов. Решать всё надо будет на стадии мэнтенса хотфиксами в первые дни релиза, из этого ответа все поймут что знаешь что такое maintenance и hotfix, практика таких релизов распространенная, все знают в каком состоянии сейчас игры выходят
Касательно того что сейчас смотрят на софт-Скиллы, это да, и на них будут смотреть на каждом собесе. Научить человека писать тест кейсы и баг репорты достаточно просто, научить человека быть ответственным и способным в коммуникации намного сложнее, поэтому стоит всегда стараться показать что эти качества уже при тебе и ты готов продемонстрировать их на деле
Надеюсь вся эта писанина поможет автору или ещё кому с дальнейшими собесами. Удачи!