Еще одна статья про тестирование карандаша

Или всё же нет?

Буду с вами откровенен, если очень поискать как следует, то получится найти минимум 3-4 годных статьи на тему "тестирование карандаша/ручки". Все статьи говорят о разном и об одном и том же (привет, диалектика Гегеля: "Единство и борьба противоположностей").

Но я хочу поговорить не об этом, а о своём опыте использования данного тестового задания на собеседовании. Добро пожаловать под кат.

Еще одна статья про тестирование карандаша

Меня зовут Кирилл, я развиваю молодое сообщество для начинающих тестировщиков в телеграм канале (aboutqa) и, помимо этого, я работаю руководителем отдела тестирования. Я часто собеседую начинающих и продолжающих тестировщиков. Относительно недавно мне впервые пришлось прибегнуть к этому, прямо скажем, унизительному заданию.

Обычно я использую более сложные задачки, опирающиеся на текущие потребности команды и компании. Но в этот раз был совсем молодой джун, который имел мало опыта тестирования функций API, так что моё задание для него было слишком сложным, и я не придумал ничего лучше, чем использовать в качестве объекта тестирования, прости Господи, канцелярскую ручку.

Я не знаю во имя чего другие руководители просят протестировать ручку и карандаш, но меня волновал только один вопрос (я свято верю в то, что мои коллеги делают всё то же самое по тем же причинам): "Как человек мыслит?"

Декомпозировав эту задачу можно выделить следующие ключевые точки:

  • Структура и алгоритм действий
  • Спросит ли "А какие были требования/спецификация?"
  • Начнет ли с позитивных тестов?
  • Копает вширь или вглубь
  • Как много видов тестирования вспомнит
  • Будет ли учитывать условия тестирования и окружение

Меня волновал только один вопрос: "Как человек мыслит?"

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

Структура и алгоритм действий

Конечно, хоть какой-то ответ лучше, чем пятиминутное молчание. Однако, для меня очень важно придумывает ли человек идеи на ходу или следует какому-то известному ему алгоритму. И, прямо скажем, я хочу увидеть, как у человека перед его внутренним взором возникает чит-лист или mind-map, по которому он проходится, придумывая тест-кейсы.

Это, на мой личный взгляд - самый важный показатель профессионализма и потенциала тестировщика. В нашей работе важна структура и умение быстро покрывать большой пул проверок. Если ты мечешься, как загнанная мышь - это плохой знак.

А какие требования?

Ну будем честны. Самый первый вопрос тестировщика к заказчику это: "а какие были требования?". Конечно, никаких требований у руководителя на интервью не будет. Но сам этот вопрос важен, т.к. отличает профессионального тестировщика от просто проверяльщика. Может быть эта синяя ручка пишет отлично, но вообще-то заказчик просил красную. Ну вы поняли.

Начни с позитивных тестов

А вот что еще выделяет профессионального тестировщика - первым делом проверить позитивные проверки. Как пишет ручка? Можно ли заточить карандаш? Если есть стёрка - стирает ли?

К сожалению много начинающих тестировщиков приходят в отрасль с позывом ломать. Они так и пишут в резюме "у меня призвание ломать, я это дело люблю". Но мы тут собрались не для того, чтобы сломать ПО. А для того, чтобы помочь повысить качество ПО.

Начать с позитивных тестов - это сэкономить время на проверках в случае, если какой-то из тестов выявит дефект. Ломать, не проверив позитивные тесты, значит потратить драгоценное время команды, и, возможно, пропустить баг в ключевой функциональности.

В ширь VS в глубь

А вот еще один аспект, влияющий на распределение времени тестирования. Мы все любим копать глубоко. Но правильно начать с поверхностных проверок всего функционала, а потом постепенно углубляться. Потратить время на все возможные виды стресс-тестов это, конечно здорово, но хотелось бы чего-то более приближенного к эксплуатации изделия.

Условия и окружения

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

Буду честен - не стал бы отказывать кандидату только за то, что он забыл об этом пункте. Но если вспомнил - это дополнительный плюсик в карму.

Какие виды тестирования вспомнит

Ну и под конец (именно под конец, а не в начале) - будет ли проводить разные виды тестирования кроме функциональных тестов. А так же то, как он проведет аналогии между тестированием ПО и карандашом/ручкой.

Идеальный ответ для меня звучал бы как попытка объяснить другу/маме/дедушке, какие виды тестирования бывают на примере карандаша.

Вместо заключения

Я долго вынашивал идею этой статьи, но в конце концов остановился на формате "личный опыт", т.к. истины в вопросе "тестирования карандаша" похоже что нет. Но вот в таком формате вы можете добавить себе в копилочку мой опыт и моё видение, которые вполне могут понять чуть больше про тестирование, собеседования и, возможно, карандаши.

Как всегда, комментарии приветствуются. Если кто-то сталкивался на собеседовании с таким заданием - напишите свой опыт и впечатления. Ну и заходите на огонёк в телеграм канал "aboutqa", я там выкладываю всякие полезности для начинающих тестировщиков.

88
Начать дискуссию