Как оцениваете свою скорость работы
Что проверяют
Умеете ли вы оценивать себя по фактам, а не по ощущениям. Для тестировщика важно ещё, как вы балансируете скорость и полноту проверки. Следом обычно спрашивают, что вы делаете, когда не успеваете протестировать к релизу.
Как отвечать
Каркас строится на вашем опыте, примеры и цифры нужны свои:
- как измеряете: сравниваете оценку задачи с фактом, знаете, сколько уходит на проверку типовой задачи, прогон регрессии, воспроизведение сложного бага. Например: «регресс мобильного приложения занимал у меня два дня, после автоматизации смоука стал полтора»;
- за счёт чего вы быстры: приоритизация по риску, чек-листы вместо подробных кейсов там, где функционал часто меняется, автотесты на рутину, заранее готовые тестовые данные, умение быстро достать информацию из логов, DevTools, Charles или Proxyman;
- где сознательно медленнее: платежи, миграции данных, всё, что трудно откатить. Здесь вы не экономите время и так и говорите;
- что делаете при нехватке времени: заранее сообщаете менеджеру, что проверено, что нет и какие риски остаются, а не режете покрытие молча.
Хорошо звучит честная оценка с оговоркой: «в знакомом продукте я быстрее среднего, на новом домене первые пару недель медленнее, пока разбираюсь в бизнес-логике».
Если опыта мало, опирайтесь на учёбу или стажировку: сколько кейсов вы писали и проходили за день и как это менялось. Скажите, что пока сверяете свои оценки с оценками старших коллег и с фактом.
Где спотыкаются
Отвечают «я очень быстрый» без единого факта. Такой ответ ничего не доказывает и настораживает.
Меряют скорость числом заведённых багов или пройденных кейсов. Для QA это плохие метрики: они поощряют мелкие дубли и поверхностную проверку.
Приносят заготовку про «сдали на два дня раньше срока с минимумом ошибок» без деталей. На первом уточняющем вопросе такая история рассыпается.