Итак, мы подошли к последней, но не по важности, группе вопросов, которые часто задаются на собеседовании и которые есть смысл проработать перед походом на интервью - это мотивация кандидата. Часто интервьюером оцениваются, например, следующие моменты: "причины, побудившие кандидата сменить работу", "что движет, вдохновляет кандидата в работе", "ожидания, ориентиры и цели кандидата" и т.п.
Далее разберем тему оценки мотивации более подробно.
Оценка времени на тестирование, это довольно трудная задача, особенно для начинающего специалиста. И, соответственно, оценка трудозатрат, это один из самых сложных вопросов на собеседовании. Тестировщик тут не является исключением. Конечно очень большую роль здесь играет опыт, но даже его немного, то в любом случае лучше хотя бы теоретически представлять как выполнить оценку. Работодатель в этом плане хочет убедиться, что при необходимости делать оценку сотрудник как минимум не растеряется и будет представлять с чего начать, от чего отталкиваться. Ведь оценка времени своей работы, это практически первое, с чем придется столкнуться приступая к своим задачам.
В статье рассмотрен пример жизненного цикла дефекта:
Показаны основные участники процесса, которые работают с дефектом
Приведены типовые статусы дефекта, по которым он проходит от момента создания, до закрытия
Указаны возможные переходы между статусами в рамках одной и разными группами (от "разработки" к "тестированию")
Ниже рассмотрим более подробно каждый из статусов дефекта и возможные для него переходы.
Рассмотрим схему типового дефекта, его основные составные части, параметры и атрибуты. На схеме представлен пожалуй минимальный необходимый набор полей, который требуется использовать при описании ошибки. В этом случае дефект станет понятен и разработчику, который будет с ним работать, и другим членам команды тестирования, и сам тестировщик, который создал этот дефект, спустя длительное время сможет быстро понять о чем в нем идет речь. Фактически, грамотное и полное описание дефекта (как и других артефактов тестирования) дает возможность работать с ним любому участнику процесса разработки ПО без постоянных вопросов к инициатору.
Далее рассмотрим, почему именно такие поля необходимы при описании дефекта.
С дефектами та же ситуация, что и с тест кейсами – нужно знать что такое дефект, для чего он нужен (и когда нужен), как и из чего он формируется. Пожалуй это основные вопросы на интервью по теме дефектов и их обязательно нужно разобрать во время подготовки к собеседованию. Также в случае с дефектом важно представлять его жизненный цикл – переходы по статусам, кто и в какой момент подключается к работе над дефектом. Понимание жизненного цикла дефекта очень важно не только для прохождения собеседования, но и для ежедневной работы. Далее рассмотрим все эти пункты и вопросы по порядку.
В этой статье предлагаю рассмотреть типовой шаблон теста:
Показаны основные составные части тест-кейса
Приведены важные параметры и атрибуты, которые должен содержать любой хорошо описанный тестовый сценарий
Конечно структура реального тест-кейса может и отличаться от данного шаблона (схема ниже), но тут показан наиболее краткий и, в тоже время, содержащий достаточно информации пример оформления.
Ниже подробнее рассмотрим основные поля, необходимые при описании дефекта.
