Блог сайта

В этой статье кратко суммированы все основные требования к тестировщику ПО и вопросы для собеседования. Она поможет быстро подготовиться к интервью, повторить или проработать самые необходимые темы. Статью можно использовать как контрольный список, пройдя по которому можно убедиться, что все самые важные темы разобраны и никакая из областей не забыта.

{tab=Tab Title 1} Your text... {tab=Tab Title 2} Your text... {/tabs}

[tab] [tab_item title="Наши контакты"] Контакты

Skype: xpavnov

E-Mail: Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра.

VK: https://vk.com/doitsmartly

[/tab_item] [tab_item title="Написать нам"]

[/tab_item] [/tab]

Итак, мы подошли к последней, но не по важности, группе вопросов, которые часто задаются на собеседовании и которые есть смысл проработать перед походом на интервью - это мотивация кандидата. Часто интервьюером оцениваются, например, следующие моменты: "причины, побудившие кандидата сменить работу", "что движет, вдохновляет кандидата в работе", "ожидания, ориентиры и цели кандидата" и т.п.

Далее разберем тему оценки мотивации более подробно.

Оценка времени на тестирование, это довольно трудная задача, особенно для начинающего специалиста. И, соответственно, оценка трудозатрат, это один из самых сложных вопросов на собеседовании. Тестировщик тут не является исключением. Конечно очень большую роль здесь играет опыт, но даже его немного, то в любом случае лучше хотя бы теоретически представлять как выполнить оценку. Работодатель в этом плане хочет убедиться, что при необходимости делать оценку сотрудник как минимум не растеряется и будет представлять с чего начать, от чего отталкиваться. Ведь оценка времени своей работы, это практически первое, с чем придется столкнуться приступая к своим задачам.

В статье рассмотрен пример жизненного цикла дефекта:

Показаны основные участники процесса, которые работают с дефектом

Приведены типовые статусы дефекта, по которым он проходит от момента создания, до закрытия

Указаны возможные переходы между статусами в рамках одной и разными группами (от "разработки" к "тестированию")

Ниже рассмотрим более подробно каждый из статусов дефекта и возможные для него переходы.

Рассмотрим схему типового дефекта, его основные составные части, параметры и атрибуты. На схеме представлен пожалуй минимальный необходимый набор полей, который требуется использовать при описании ошибки. В этом случае дефект станет понятен и разработчику, который будет с ним работать, и другим членам команды тестирования, и сам тестировщик, который создал этот дефект, спустя длительное время сможет быстро понять о чем в нем идет речь. Фактически, грамотное и полное описание дефекта (как и других артефактов тестирования) дает возможность работать с ним любому участнику процесса разработки ПО без постоянных вопросов к инициатору.

Далее рассмотрим, почему именно такие поля необходимы при описании дефекта.

О проекте

  • Проведение тренингов и вебинаров: QA, Time management, People management, Agile
  • Консалтинг в области организации рабочих процессов в ИТ
  • Проведение и подготовка к собеседованиям

Информация об авторе проекта

 

Контакты

Skype: xpavnov

E-mail: xpavnov@gmail.com

VK: https://vk.com/doitsmartly

Группа вконтакте

doITsmartly©2019
Яндекс.Метрика

Search

//