Или всё же нет?
Буду с вами откровенен, если очень поискать как следует, то получится найти минимум 3-4 годных статьи на тему "тестирование карандаша/ручки". Все статьи говорят о разном и об одном и том же (привет, диалектика Гегеля: "Единство и борьба противоположностей").
Но я хочу поговорить не об этом, а о своём опыте использования данного тестового задания на собеседовании. Добро пожаловать под кат.
Меня зовут Кирилл, я развиваю молодое сообщество для начинающих тестировщиков в телеграм канале (aboutqa) и, помимо этого, я работаю руководителем отдела тестирования. Я часто собеседую начинающих и продолжающих тестировщиков. Относительно недавно мне впервые пришлось прибегнуть к этому, прямо скажем, унизительному заданию.
Обычно я использую более сложные задачки, опирающиеся на текущие потребности команды и компании. Но в этот раз был совсем молодой джун, который имел мало опыта тестирования функций API, так что моё задание для него было слишком сложным, и я не придумал ничего лучше, чем использовать в качестве объекта тестирования, прости Господи, канцелярскую ручку.
Я не знаю во имя чего другие руководители просят протестировать ручку и карандаш, но меня волновал только один вопрос (я свято верю в то, что мои коллеги делают всё то же самое по тем же причинам): "Как человек мыслит?"
Декомпозировав эту задачу можно выделить следующие ключевые точки:
- Структура и алгоритм действий
- Спросит ли "А какие были требования/спецификация?"
- Начнет ли с позитивных тестов?
- Копает вширь или вглубь
- Как много видов тестирования вспомнит
- Будет ли учитывать условия тестирования и окружение
Меня волновал только один вопрос: "Как человек мыслит?"
Попробую кратенько, но в достаточной мере, раскрыть каждый из этих ключевых аспектов ответа, дабы вы, во-первых, не бесились, когда вам вдруг зададут эту задачу; во-вторых, понимали цели интервьюера; в-третьих, смогли без нервов быстро и правильно ответить и, не мучая себя, перейти к другим, более интересным задачам.
Структура и алгоритм действий
Конечно, хоть какой-то ответ лучше, чем пятиминутное молчание. Однако, для меня очень важно придумывает ли человек идеи на ходу или следует какому-то известному ему алгоритму. И, прямо скажем, я хочу увидеть, как у человека перед его внутренним взором возникает чит-лист или mind-map, по которому он проходится, придумывая тест-кейсы.
Это, на мой личный взгляд - самый важный показатель профессионализма и потенциала тестировщика. В нашей работе важна структура и умение быстро покрывать большой пул проверок. Если ты мечешься, как загнанная мышь - это плохой знак.
А какие требования?
Ну будем честны. Самый первый вопрос тестировщика к заказчику это: "а какие были требования?". Конечно, никаких требований у руководителя на интервью не будет. Но сам этот вопрос важен, т.к. отличает профессионального тестировщика от просто проверяльщика. Может быть эта синяя ручка пишет отлично, но вообще-то заказчик просил красную. Ну вы поняли.
Начни с позитивных тестов
А вот что еще выделяет профессионального тестировщика - первым делом проверить позитивные проверки. Как пишет ручка? Можно ли заточить карандаш? Если есть стёрка - стирает ли?
К сожалению много начинающих тестировщиков приходят в отрасль с позывом ломать. Они так и пишут в резюме "у меня призвание ломать, я это дело люблю". Но мы тут собрались не для того, чтобы сломать ПО. А для того, чтобы помочь повысить качество ПО.
Начать с позитивных тестов - это сэкономить время на проверках в случае, если какой-то из тестов выявит дефект. Ломать, не проверив позитивные тесты, значит потратить драгоценное время команды, и, возможно, пропустить баг в ключевой функциональности.
В ширь VS в глубь
А вот еще один аспект, влияющий на распределение времени тестирования. Мы все любим копать глубоко. Но правильно начать с поверхностных проверок всего функционала, а потом постепенно углубляться. Потратить время на все возможные виды стресс-тестов это, конечно здорово, но хотелось бы чего-то более приближенного к эксплуатации изделия.
Условия и окружения
И раз уж речь зашла про эксплуатацию. Будет очень здорово, если собеседуемый не забудет про то, что условия использования и окружения могут быть различными. Ближайший аналог из ПО - один и тот же сайт на куче браузеров, девайсах и разрешениях.
Буду честен - не стал бы отказывать кандидату только за то, что он забыл об этом пункте. Но если вспомнил - это дополнительный плюсик в карму.
Какие виды тестирования вспомнит
Ну и под конец (именно под конец, а не в начале) - будет ли проводить разные виды тестирования кроме функциональных тестов. А так же то, как он проведет аналогии между тестированием ПО и карандашом/ручкой.
Идеальный ответ для меня звучал бы как попытка объяснить другу/маме/дедушке, какие виды тестирования бывают на примере карандаша.
Вместо заключения
Я долго вынашивал идею этой статьи, но в конце концов остановился на формате "личный опыт", т.к. истины в вопросе "тестирования карандаша" похоже что нет. Но вот в таком формате вы можете добавить себе в копилочку мой опыт и моё видение, которые вполне могут понять чуть больше про тестирование, собеседования и, возможно, карандаши.
Как всегда, комментарии приветствуются. Если кто-то сталкивался на собеседовании с таким заданием - напишите свой опыт и впечатления. Ну и заходите на огонёк в телеграм канал "aboutqa", я там выкладываю всякие полезности для начинающих тестировщиков.