А нужно ли все таки четко отвечать на поставленный вопрос? Ведь все вопросы в первую очередь направлены на проверку опыта и знаний кандидата. Если кандидат может ответить Зачем? и как применяли на своих проектах, то это довольно таки неплохой плюс, если есть необходимость покопать глубже, то можно продолжить задавать направляющие вопросы по теме.
"Налицо психологический эффект: тот, кто сообщает о баге, как бы нависает в образе более компетентного специалиста."
"Встреча со специалистом по тестированию сама по себе несёт скрытый мотив — «ты не профи»."
На как показывает практика, чем опытнее специалист, тем менее он подвержен подобным искажениям.
Как правильно заметил, Stan_1, если все члены команды преследуют одну цель - производство максимально качественного и полезного продукта, этого можно избежать.
"2. Спрашивайте у соискателя только те вещи, которые точно пригодятся в работе."
Не согласен, очень часто на проектах приходится выполнять не только те задачи, под которые ты "заточен". И такие вопросы позволяют понять ширину кругозора и других технических навыков.
Согласен абсолютно:) Метрики багов выявленных на продакшене будут являться прямым показателем качества работы команды, если конечно приложение уже доступно пользователям.
1) Я бы отнес к самой сложной метрику покрытия требований, тк она требует очень больших трудозатрат на актуализацию информации, если приложение большое и аналитика не полная, то это тот еще квест.
2) Снятие и анализ метрик всегда будут затратны мне кажется, однако плюсы, которые можно извлечь из изменения процессов перектроют это. Можно распределить ответственность за метрики на всю команду QA, тогда слон будет не таким большим и его можно осилить.
3) На разных проектах всегда все отличалось, стандарты нужны. В случае отклонения выбираем стиль не наказания, а разбора первопричин и устранения таковых, эти первопричины можно в дальнейшем рассмотреть в других командах, возможно проблема массовая.
"1. Нет ответа на конкретный вопрос"
А нужно ли все таки четко отвечать на поставленный вопрос? Ведь все вопросы в первую очередь направлены на проверку опыта и знаний кандидата. Если кандидат может ответить Зачем? и как применяли на своих проектах, то это довольно таки неплохой плюс, если есть необходимость покопать глубже, то можно продолжить задавать направляющие вопросы по теме.
Я бы выделил здесь именно психологический аспект:
"Налицо психологический эффект: тот, кто сообщает о баге, как бы нависает в образе более компетентного специалиста."
"Встреча со специалистом по тестированию сама по себе несёт скрытый мотив — «ты не профи»."
На как показывает практика, чем опытнее специалист, тем менее он подвержен подобным искажениям.
Как правильно заметил, Stan_1, если все члены команды преследуют одну цель - производство максимально качественного и полезного продукта, этого можно избежать.
"2. Спрашивайте у соискателя только те вещи, которые точно пригодятся в работе."
Не согласен, очень часто на проектах приходится выполнять не только те задачи, под которые ты "заточен". И такие вопросы позволяют понять ширину кругозора и других технических навыков.
I am totally agree with you. You need to use only metrics that you can process without prejudice to other areas.
Согласен абсолютно:) Метрики багов выявленных на продакшене будут являться прямым показателем качества работы команды, если конечно приложение уже доступно пользователям.
1) Я бы отнес к самой сложной метрику покрытия требований, тк она требует очень больших трудозатрат на актуализацию информации, если приложение большое и аналитика не полная, то это тот еще квест.
2) Снятие и анализ метрик всегда будут затратны мне кажется, однако плюсы, которые можно извлечь из изменения процессов перектроют это. Можно распределить ответственность за метрики на всю команду QA, тогда слон будет не таким большим и его можно осилить.
3) На разных проектах всегда все отличалось, стандарты нужны. В случае отклонения выбираем стиль не наказания, а разбора первопричин и устранения таковых, эти первопричины можно в дальнейшем рассмотреть в других командах, возможно проблема массовая.