Как провести неидеальное собеседование тестировщика и почему идеальных не бывает / Яндекс.Деньги corporate blog / Habr
Дрейк и не знал, насколько был близок к подбору правильного тестировщика.
Рано или поздно может настать момент, когда к вам придут с просьбой найти тестировщика. Можно, конечно, почитать какую-нибудь литературу про тестирование – например, «Тестирование Дот Ком» Романа Савина. Да только, вполне возможно, кандидаты её тоже читали.
Поэтому я хочу поделиться своим взглядом на то, какие вопросы задавать и на какие качества обращать внимание при собеседовании вашего первого тестировщика.
Последние 5 лет я работаю в Яндекс.Деньгах руководителем отдела тестирования и регулярно собеседую людей на позиции тестировщиков. Приходилось проводить собеседования как по хорошо знакомым продуктам, так и по тем, про которые самому пришлось узнать за пару минут до интервью. Со временем я составил оптимальный для себя путь прохождения квеста, которым и хочу поделиться в статье.
Наверное, в деле собеседований самое важное – идти без мысли «скорее всего, это наш человек». В моей практике не раз встречались идеальные резюме, как будто специально написанные под нашу вакансию. Во-первых, они действительно могут быть просто под вас написаны, а во-вторых, в реальном общении человек может оказаться тяжелым или просто необщительным. Поэтому, если кандидат не подойдет, предварительный настрой на найм именно его будет психологически тяжело изменить.
Есть даже расхожее название псевдо-идеальных резюме – «письма к Санте». К ним стоит в начале добавлять: «Дорогой Санта, сделай так, чтобы в следующем году я знал: …» А в конце: «Best regards, Tommy».
Справедлив и вариант от обратного, когда вы заранее негативно настроены к человеку из-за слабого резюме – о собеседовании уже договорились и отменять как-то некрасиво. Если договорились пообщаться, то будьте беспристрастны.
К слову об общительности и опрятном виде – для тестировщика это важные, близкие к необходимым качества. Какой бы баг он ни обнаружил, приходится объяснять разработчикам, почему это ошибка и как ее воспроизвести – по понятным причинам делать все это нужно в благожелательном тоне. Без навыков общения тут не обойтись, потому что на резкую критику по поводу найденных багов легко получить негатив в ответ.
Это может показаться неоднозначным, но я рекомендую не заострять внимание на небольшом опоздании кандидата на собеседование, особенно если он позвонил и предупредил. Пунктуальность у инженеров не самое распространенное качество. К тому же с секундомером утром на входе все равно никто не стоит и найти офис с первого раза новому человеку не всегда просто.
Еще я не люблю популярные в наши дни стрессовые собеседования, особенно на инженерные позиции. Вы ведь не менеджера по урегулированию конфликтов ищете, а специалиста по QA. В его работе стресс связан не с конфликтами, а с уровнем ответственности за пропущенные ошибки. Поэтому в нашем деле лучше обойтись без криков на собеседовании и нарочно пролитого кофе – пусть этим занимается кто-нибудь из сферы биржевой торговли.
Когда нанимаешь человека на новую для себя и компании должность, непонятно, о чем вообще его спрашивать. Тут часто возникают две крайности:
%candidacy_name% должен уметь все, включая администрирование и навыки моделирования ракетных двигателей. На всякий случай.
- %candidacy_name% должен быть отличным разработчиком.
Оба варианта одинаково ужасны и порождают массу странных и ненужных вопросов, создавая собеседующему неприглядный имидж в глазах кандидата. Проще идти от реальных обязанностей человека. Если тестировщик будет проверять новые сборки продукта и искать в них ошибки – предложите кандидату сделать именно это.
Предварительно составьте описание продукта или сервиса. Если продукт слишком большой, возьмите ту его часть, которой и будет заниматься потенциальный идеальный кандидат. Желательно при этом не подниматься до такого уровня абстракции, где будет два больших квадрата – фронтэнд или бэкенд, – дайте больше конкретики по вашей системе. Совсем замечательно, если спросите про что-то, что и сами не понимаете, как тестировать. В конце концов, не зазорно быть немного меркантильным.
Например, мы просим протестировать наш небольшой сервис под названием «Напоминатель» – письменные напоминания о том, что какой-то платеж нужно будет вот-вот совершить. Удобен он тем, что не очень понятно, как его тестировать: как получить напоминание, которое должно прийти через месяц, как проверить, что если напоминание поставлено на 31 число месяца, то в условном феврале оно придет 28, а не 29-ого.
Каждый тестировщик должен быть хоть немного и аналитиком. Поэтому на собеседованиях мы часто просим людей рассказать, как бы они сами создали продукт или сервис, который им предлагается протестировать. С тем же напоминателем просим описать, где бы хранились его записи (после этого даже самые недогадливые понимают, что там, где хранятся напоминатели, хранится и дата следующего события), какой бы механизм выбрасывал оповещения. Если вам нужен не monkey clicker, а осознающий свои поступки человек, то это хороший способ проверить его на тот самый «аналитический склад ума».
Надеюсь, что вы не будете указывать «аналитический склад ума» в требованиях к кандидату. А если указали, то не продолжайте чтение, пока не поправите объявление.
Нелишне спросить все то же самое, но про тот продукт, который тестировщик уже проверял раньше. Спросите про архитектуру, как была устроена система. В процессе задайте пару вопросов формата «а зачем вы так сделали?», чтобы человек описал хотя бы общими словами, почему он принял именно такое решение. Главное, чтобы он не пожимал плечами со словами: «я-то откуда знаю – я простой тестировщик».
Представьте, что вас забросили на парашюте в центр Китая. Без денег и телефона, без знания языка. То же самое произойдет, если вы в свою команду приведете умного и всячески приятного в общении человека. Он и команда разработчиков просто не будут понимать друг друга, и вам придется нанимать кого-нибудь вроде героини Эми Адамс из «Прибытия», чтобы она научила нового специалиста этому непонятному птичьему языку. Ведь, помимо умения составлять правильные алгоритмы тестов, тестировщик должен общаться с разработкой и продуктовой командой на одном языке.
К такому собеседованию как раз удобно привлекать разработчиков из своей команды – разумеется, они легко «завалят» кандидата, но вы сможете оценить кругозор нового человека и его общее понимание, где он оказался. Например, банальные фразы про JIRA, Bitbucket, сертификаты и IDE могут быть наскальной азбукой для совсем новичков в профессии.
Если разработчиков почему-то не привлечь, то спросите в лоб: что такое интернет? Что мне только не отвечали на эту банальность: от «ну это сайты» и до «это то, что позволяет общаться между собой». Часто люди просто уходили глубоко в себя, а после встречи бурно возмущались, что им задают такие глупые и бесполезные вопросы.
Важно также предложить кандидату составить не особенно сложный алгоритм для какого-то действия или теста. Так вы убедитесь, что ему это не впервой и с алгоритмами он знаком. К этому навыку я еще добавляю умение быстро считать в уме. Конечно, это спорный момент, но для плодотворной работы полезно уметь посчитать выражения из кода в уме – без предварительной сборки проекта и калькулятора.
Согласен, что тестовое задание сродни практике – позволяет лучше оценить знания. Но обычно кандидаты не горят желанием их выполнять, потому что это долго, муторно и непонятно, стоит ли игра свеч. Да и проверяющие не всегда добросовестно относятся к тесту. Например, они могут отложить проверку результатов на несколько дней (а кандидат торопился, делал) или проверять «по трафарету». Если решение вылезает за границы идеального трафарета – кандидат бракуется, что не правильно. Вы ведь помните про ход мысли и его приоритет над правильным решением?
На мой взгляд, тестовое задание в большинстве случаев не нужно, но, надо признать, есть ряд оправданных исключений:
Вы ищете не junior тестировщика, а автоматизатора, то есть уже состоявшегося специалиста со своим карьерным путем. В таком случае может оказаться проще оценить заявленное владение технологиями и проверить опыт работы.
У вас в компании высокая степень формализма при написании многочисленной документации, и нужно быть точно уверенным, что кандидат способен письменно излагать свои мысли и не страдает дислексией. Но вообще это можно проверить, дав кандидату ноутбук и попросив завести описание какого-нибудь бага.
- Нужно привлечь на собеседования массу народа, а подходящих на первый взгляд резюме находится немного. Тут придется пойти к разработчикам с просьбой что-нибудь поломать. Придумываете баги и выпускаете специальную «дырявую» сборку для практических работ тестировщиков.
По одной такой задаче нам как-то пришло полторы тысячи писем. На второй сотне сообщений о багах вы впадаете в дзен и перестаете реагировать на внешние раздражители. Заодно можно быстро, без регистрации и СМС научиться медитации.
Любопытное наблюдение я сделал после работы в нескольких крупных компаниях – тестировщики часто развивают свою карьеру не в сторону разработки, а в сторону проектного управления. В сущности, это неудивительно, так как в основе обеих профессий лежит навык общения с людьми. Тестировщику тоже важнее сохранять корректность и нейтралитет, чем знать пару дополнительных языков программирования.
Спросите кандидата, как он будет справляться с относительно невозможными ситуациями. Относительно – потому что не стоит спрашивать у него, что он будет делать, когда вогоны сносят его планету, и почему у него нет с собой полотенца.
Примеры подходящих вопросов:
- «Два ПМа приходят к тебе и просят быстро протестировать их проект, который нужно релизить вечером. Что ты будешь делать?»
- «ПМ укатил в отпуск и не сказал, должна ли стоять по умолчанию галочка в пункте «да, я хочу получать ежесекундные напоминания о трансфере Неймара», а разработчик говорит, что в гробу он его видел и галочка стоять не должна. Стоит ли заводить баг или нет?»
Если ранжировать качества кандидатов, то на первое место я с особой помпой поставлю ум, а на второе – остроумие. Поэтому всегда спрашиваю, какие книги читал кандидат. Причем это не обязательно должны быть книги по тестированию.
Один из наших старших тестировщиков устроился в Яндекс.Деньги после письма, которое начиналось со слов: «Я ничего не знаю о тестировании, но очень хочу у вас работать». Это было три года назад, и с тех пор он сначала избавился от приставки «младший», а потом получил «старшего». Леша, привет!
Инженер по тестированию (стажер)
Яндексу нужны талантливые начинающие инженеры по тестированию, которые помогут нам в задачах поддержания качества различных сервисов компании. В наших проектах вы сможете не только испытать и развить свои навыки в области специфики, правил и процессов тестирования, но и узнать все особенности проверок нестандартных задач, используя внутренние инструменты Яндекса.
Вам понадобится знание основ тестирования, а именно:
- знание основных практик тест-дизайна;
- понимание видов тестовой документации;
- базовое понимание процессов тестирования и разработки.
Также приветствуются:
- базовое знание любого языка программирования;
- понимание HTTP и HTTPS;
- опыт работы со снифферами: Charles, Fiddler, Wireshark.
Задачи, в которых вы будете принимать участие:
- анализ текущего тестового покрытия;
- создание и поддержание тестовой документации;
- оптимизация тест-кейсов для возможности тестирования сервисов внешними пользователями;
- тестирование новой функциональности в командах;
- взаимодействие с командами разработки и c менеджерами продукта, участие в создании продукта на всех этапах.
Во время стажировки вы:
- углубите свои знания в области фундаментального тестирования;
- научитесь использовать инструменты для упрощения ручного тестирования;
- познакомитесь ближе с процессами производства программного обеспечения в больших продуктах.
Условия:
- срок стажировки от трех до шести месяцев;
- стажировка оплачивается.
Работа в Яндексе
Посмотрите ролик о том, как устроен процесс интервью в Яндексе.
1
Как на него попасть
Почти у каждой вакансии Яндекса есть тестовое задание — с него-то всё и начинается. Ответьте на вопросы на странице вакансии и отправляйте заявку. Если вы успешно справились с тестом и заинтересовали службу найма, то получите приглашение на встречу — обычно в течение недели.
Резюме
Подойдёт в любой форме, а для дизайнеров и разработчиков его заменит портфолио или ссылка на репозиторий. Хорошо сопроводить резюме вольным рассказом о том, почему вас стоит взять на работу. Будьте готовы вкратце пересказать ключевые факты на собеседовании — умение представить себя интересует не меньше биографии.
Сколько будет встреч
Чаще всего проводятся четыре собеседования. В некоторых случаях в зависимости от профессии кандидата решение о найме может быть принято по итогам двух встреч. На особо ответственные должности количество интервью может быть увеличено до пяти-шести.
2
Как оно проходит
Обычно встреча длится час или два. Вам предложат чай-кофе, воду и печеньки. Собеседование с претендентами на вакансию разработчика состоит из серии коротких встреч с разными экспертами. Рекрутер обязательно расскажет вам все подробности.Подробности для технических вакансий
Подробности для дизайнеров
Кто будет на собеседовании
Сотрудник отдела найма и ваш потенциальный руководитель. Если вы подходите на несколько ролей или претендуете на важную должность, к встрече могут присоединиться и другие эксперты.
Чего ожидать
Некоторые вопросы или задачки могут не касаться вакансии напрямую — так проверяется способность рассуждать в неизвестной ситуации. Также будьте готовы начертить схему маркером на стене или написать код на бумаге, без компьютера.
3
Что будет после
Между встречами и особенно после финального собеседования иногда наступает длинная пауза. Пожалуйста, наберитесь терпения. Если рекрутер не ответил на звонок или письмо — это не значит, что вы не справились. В это время служба найма может общаться с другими кандидатами, а итоговое тестовое задание часто проверяют много людей.
В случае успеха
Рекрутер сразу свяжется с вами и озвучит предложение Яндекса. В первый день в офисе вас встретят, помогут оформить документы в отделе кадров, получить оборудование и освоиться на рабочем месте.
Если отказали
Поищите другие вакансии — если вы не прошли тестовое задание или собеседование, ничто не мешает попробовать себя в другой роли. Или повторить заявку через какое-то время, когда наберётесь знаний и опыта.
Одна из лучших точек входа в IT-индустрию — Академия Яндекса
Профессия тестировщика — одна из лучших точек входа в IT-индустрию. Можно начать со стажировки, чтобы освоиться в новой сфере и познакомиться с интересными задачами. О своем опыте рассказывает Николай Овчаренко. Он начал как стажер-тестировщик в Яндекс.Коннекте и Яндекс.Формах, а теперь работает в команде Авто.ру.
С чего все началось?
На стажировку я пошел почти сразу после окончания университета. По специальности я преподаватель математики и информатики, математик. Буквально в последний момент я решил не идти работать в школу или вуз, а попробовать себя в тестировании. Мое образование дало неплохую базу, но никакой специальной подготовки не было. Чтобы попасть на трехмесячную стажировку, нужно было подать заявку, прикрепить резюме и сделать довольно большое тестовое задание. Через пару недель со мной связались и позвали на первое собеседование, затем их было еще три. На собеседованиях задавали вопросы на понимание теории, а начиная со второго — давали потестить конкретные странички.
Для прохождения испытаний мне хватило книги Романа Савина «tестирование dot com» и душевных разговоров со знакомой с релевантным опытом. Стажировка, тем более в крупной IT-компании, — это идеальный способ начать карьеру в тестировании, других рациональных (особенно быстрых и безболезненных) способов я не вижу.
Как проходила стажировка?
Я начал в команде Коннекта — платформе сервисов Яндекса для совместной работы в облаке. На мой взгляд, люди там занимаются именно тем, чем должны заниматься, и делают это хорошо. Они все стали для меня лучшими примерами того, какими должны быть менеджеры, разработчики и тестировщики.
Так как это была моя первая стажировка, я переживал, что не хватит базовых знаний, возникнут сложности, с которыми не удастся справиться, что я буду отвлекать людей по пустяковым вопросам. Боялся что-то не успеть, подвести ребят, оказаться недостаточно полезным, по неопытности пропустить какие-то баги.
Стажировка — идеальный способ начать карьеру в тестировании
Мне помогло хорошее отношение коллег, их проницательность и открытость, готовность поддержать во всех вопросах, желание помочь разобраться в непонятных вещах. Условия работы были очень хорошими, это помогало справляться с трудностями.
Запомнились приятные ощущения от того, что видишь, как при тебе сервис развивается, становится лучше и приятнее, а ты принимаешь непосредственное участие. Через меня проходили новые фичи и интерфейсы, я радовался за сервис и за пользователей.
Чему можно научиться?
Чтобы не расписывать гору терминов, скажу, что на стажировке я научился большинству основополагающих вещей, необходимых для работы тестировщиком. Особенно важным приобретением, помимо зачатков профессиональных скиллов, были навыки общения с командой для быстрого и качественного разрешения любых вопросов, понимание того, как устроены процессы.
Если смотреть на итог стажировки — я многому научился у моего руководителя, хотя, конечно, не сразу. Я все время осознавал ответственность, а также старался выкладываться по полной. Начинал я со знакомства с сервисом, выполняя простые рабочие задачи, затем постепенно учился выполнять более сложные. Думаю, спустя месяц-полтора я уже довольно полноценно выполнял все задачи по тестированию в моей команде.
Сложно лаконично передать море положительных эмоций, с которыми ассоциируется стажировка, и, как бы странно это ни звучало, стажировка в Яндексе для меня — это счастье.
Как остаться в команде Яндекса?
За месяц до конца стажировки, следуя советам знакомых и руководителя, начал смотреть открытые вакансии. Первыми откликнулись Авто.ру. За несколько дней я прошел у них три собеседования, а потом меня позвали на собеседование еще и в Яндекс.Станцию. На него я сходил из профессионального интереса, но продолжать не стал, чтобы не отнимать у людей время. Я посчитал, что Авто.ру — хороший вариант для меня, а Станция мне может оказаться пока не по зубам — не хотел никого подвести. Таким образом, к концу стажировки у меня уже был оффер. Думаю, что этому способствовали полученные опыт и навыки и положительные отзывы руководителей.
Теперь я знакомлюсь с совершенно другим сервисом и с совершенно другими людьми, так что, в каком-то смысле, я все еще почти стажер.
Бывший пиарщик рассказывает, как стать тестировщиком Яндекс.Станции
Маша Капля прошла стажировку в качестве тестировщика и теперь после 11 лет в пиаре и маркетинге посвящает свое время разговорам с Яндекс.Станцией.
Тестирование. Сага. Начало
Стоит начать с того, что мне 36 лет, и я работала пиарщиком и маркетологом в игровой индустрии. Хотя предыдущая работа получалась, мне всегда нравилась сфера IT и хотелось попробовать ею заняться. К тому же в пиаре и маркетинге есть вещи, которые мне совсем не нравились. Например, необходимость агрессивно продавать свой продукт.
Рабочий день с Яндекс.СтанциейИ наоборот, мне очень нравилось придумывать, как сделать продукт лучше. Дорабатывать сайты, на которых рассказывалось об играх, или улучшать сами игры, чтобы они больше понравились пользователям. Ну и плюс ко всему я всегда считала, что внутри я больше редактор, чем писатель, поэтому идея тестирования пришла очень органично. Так что я прошла полуторамесячный курс по тестированию и начала искать работу. Меня поразило, насколько востребованы даже начинающие тестировщики, пришло сразу несколько предложений по работе, в том числе предлагали пройти стажировку в Яндексе, и я ухватилась за эту возможность обеими руками.
«Самый большой страх — не найти ни одного бага»
Я стажировалась в SERP — это отдел Яндекса, который занимается страницами с результатами поиска. Работала над кабинетом Бизнеса в Яндекс.Справочнике, где я тестировала верстку и логику работы. У каждого стажера есть куратор, который знакомит с командой и обязанностями и готов ответить на любые вопросы. Хотя я старалась прежде чем спросить, найти ответ самостоятельно. Вместе с куратором мы налаживали тестирование с нуля. Так, в кабинете Бизнеса раньше не было тестировщика, и мы с моим куратором выстраивали процессы, писали документацию во внутренней «Википедии», чтобы, когда туда придет новый тестировщик, он мог понять, что к чему, с первого дня работы.
Поначалу было сложно. До недавнего времени я была чистым гуманитарием и мало разбиралась в технической стороне вопроса, да и сейчас мне очень многое еще предстоит освоить. В первую неделю я столкнулась с комплексной технической задачей, связанной с бекендом, потратила на нее много времени, но так с ней и не разобралась. На тот момент я решила, что пока ограничусь фронтендом и тестированием пользовательских сценариев. Постепенно разработчики поняли, какие задачи у меня получаются хорошо, а какие плохо. Поняли, что иногда мне удается найти прямо-таки заковыристые баги. И в итоге, как мне кажется, я отлично влилась в коллектив, а главное — смогла принести пользу.
День стажера в ЯндексеМоим самым большим страхом было то, что в Яндексе все так круто устроено, что я не найду ни одного бага и меня с позором выгонят со стажировки. Этот страх оказался беспочвенным. Все вокруг живые люди, и баги я находила в большом количестве. Но поскольку эти разработчики действительно крутые, ошибки быстро исправляются.
Разговоры с Яндекс.Станцией
С первых дней стажировки я поняла, что очень хочу работать в Яндексе и сделаю для этого всё. Я прошла собеседования в несколько команд и выбрала Яндекс.Станцию. Мой куратор советовал выбрать более традиционную область, так как мне пригодился бы классический опыт. Но я решила рискнуть.
Станция — абсолютно новаторский проект, первая техническая штука, выпущенная Яндексом, и она очень классная. Я каждый день вживую с ней общаюсь, и моя задача состоит не только в поиске ошибок, но и в том, чтобы у пользователя был как можно более приятный сценарий общения с колонкой.
Пока еще не существует эмулятора колонки, так что часть моей работы — это разговаривать со Станцией голосом. Также сейчас наращивается база пользовательских сценариев — так называемых тест-кейсов, которые облегчают процесс тестирования. Вообще в тестировании Станции задействовано множество людей (несколько тестировщиков, асессоры), ведь релизы поступают несколько раз в неделю, и нам очень важно не только проверить новые функции, но и убедиться в том, что старые работают хорошо.
Для меня попасть в Яндекс было одним из самых интересных и важных событий в жизни, и я по-хорошему завидую тем, кто имеет возможность начать здесь карьеру сразу после института.
«Стал „тестировщиком“ за два дня» | GeekBrains
Илья Рейзнер — о поиске работы, ожиданиях компаний, тестовых заданиях и профессиональном развитии QA-специалиста
https://d2xzmw6cctk25h.cloudfront.net/post/2088/og_image/07d8f15942d50b724346116b993c6fc3.png
Привет! Меня зовут Илья, и с сентября 2013 года я занимаюсь ручным тестированием. Сейчас работаю ведущим тестировщиком в Bell Integrator. В этой статье я расскажу, как начать карьеру в сфере QA, чем высокооплачиваемый тестировщик отличается от обычного и как прокачаться, чтобы тебя ценили. Главным образом буду говорить о ручном тестировании, но затрону и автоматизированное.
Как я сменил профессию за два дня
Я получил диплом экономиста, пару лет поработал по специальности — и понял, что заниматься этим я себя заставляю. Ушёл. Около года провёл в продажах и параллельно искал, чем заниматься дальше. И вот однажды я вспомнил кое-какую статью про тестирование и разговор со знакомым, который тестировал телефоны Motorola.
В порядке эксперимента я обновил резюме на hh.ru — сменил желаемую должность на «тестировщик». В тот же день получил приглашение на собеседование и совет, что подучить. Основное — виды и уровни тестирования, реляционные базы данных и классы эквивалентности (одна из техник тест-дизайна). Я вбил это в поисковик и попал на сайт protesting.ru. Информация там структурирована и хорошо изложена. Почитал, вник.
На следующий день я успешно прошёл собеседование в компанию с броским названием S&T International. Так начался мой путь в тестирование и IT в целом. Но не всё так просто. Получить работу — ещё не значит стать крутым специалистом. Поэтому самое интересное началось дальше.
Ожидания работодателей
Основная задача тестировщика — дать актуальную информацию о качестве продукта. Это правильный ответ на один из главных вопросов собеседования 🙂
Проверять качество ПО помогают специальные инструкции — тест-кейсы. В них подробно описан каждый шаг и ожидаемый результат. Тестирование по кейсу — работа, которую часто доверяют джуниорам, особенно на крупных проектах.
Чем быстрее ты работаешь и чем лучше понимаешь, в какой последовательности проходить тесты, тем больше тебя ценят.
Чтобы получать высокую зарплату, надо знать теорию тестирования, техники тест-дизайна, терминологию, SQL-запросы. Очень важно представлять себе сферу деятельности компании. Главные заказчики IT-услуг сейчас — банки, страховые фирмы и телеком. Идёшь работать в банк? Подучи банковские термины. А если собираешься тестировать оборудование для нефтегазового сектора, на одной теории далеко не уедешь. Придётся изучать «железо».
Кроме того, нормальный тестировщик умеет пользоваться командной строкой, понимает, что такое клиент-серверная архитектура и реляционные базы данных, зачем нужен XML и какую роль он играет в работе ПО.
О чём спрашивают на собеседовании
Крупные интеграторы любят гонять кандидатов по теории и терминам. Это у них как сито. Чем больше правильных ответов, тем выше твой балл и зарплата, на которую ты можешь претендовать.
Но иногда простые вопросы могут поставить в тупик даже опытного пользователя. Например, какие поля обязательны при заведении бага. Новичку нет смысла такое заучивать — он работает в баг-трекере, где обязательные поля проверяются автоматически. Пока не заполнишь — данные не отправишь. А опытный тестировщик, который всё это вносит уже не глядя, может зависнуть — как автослесарь, которого спросили, что такое машина.
Чтобы войти в профессию, мне хватило материалов с protesting. А в более продвинутых темах я разобрался, обучаясь в GeekBrains по профессии «Тестировщик ПО». Например, освоил более сложные техники тест-дизайна, чем классы эквивалентности. Эти знания пригодились.
Приведу пример «до» и «после». На телефонном собеседовании в крупном банке меня спросили, какие техники тест-дизайна я знаю. Ответ их не устроил, но мне дали ссылку на тест, где надо было набрать от 65% правильных ответов. Увы, в тот раз мне даже поисковик не помог — настолько хитро были поставлены вопросы. А вот после курсов этот же тест на другом собеседовании я уже прошёл и получил предложения от нескольких отделов того же банка. Правда, всё равно к ним не пошёл — отпугнули бюрократией. Но это другая история.
Ясное дело, одной теории мало. Опытный интервьюер спросит, как работает техника на практике и почему в данной ситуации ты предлагаешь именно её. Кроме того, важно уметь пользоваться специализированным ПО. Возможно, кто-нибудь оценит твою обучаемость и поверит, что ты быстро освоишь новые инструменты, но чаще работодатель ищет готового специалиста.
Примеры тестовых заданий
В банке мне дали схему XML-сообщения в виде таблицы с описанием полей и указанием, обязательны ли они. Нужно было проверить все варианты отправки сообщения.
В крупной розничной сети предложили более масштабное задание. Показали схему работы кассового складского оборудования и тестовую БД. Требовалось установить СУБД Firebird, написать несколько SQL-запросов для формирования выборки и составить тестовую модель по схеме работы.
Но обычно на собеседованиях рисуют упрощённую схему и просят описать, как ты будешь это тестировать. Могут предложить нештатную ситуацию: «Не успеваем всё протестировать, но сроки сдачи переносить нельзя». Или: «За день до релиза обнаружены критические баги. Можно ли выходить в продакшен?». На первый вопрос единственного правильного ответа нет, а на второй — «Нельзя».
Другой пример — задание на автотестирование от разработчика ПО. Надо написать на Python класс Deposits, который парсит страничку www.banki.ru и собирает информацию из блока «Предложения месяца > Вклады». Результат должен выглядеть как таблица, где напротив названий вкладов — проценты. Дополнительно просят реализовать дочерний класс, который наследуется от Deposits и подбирает наиболее и наименее выгодный вклад.
Самое обстоятельное собеседование было в HeadHunter. Начали с большого предварительного интервью. Спрашивали, почему занимаюсь тестированием и каким проектом горжусь. Просили рассказать о самом интересном (!) случае из практики, а ещё — в чём состоит тестирование, что такое качество, какой у меня опыт автоматизации, какие пять команд Linux я чаще всего использую в работе. Ещё просили назвать две-три книги или статьи по тестированию и программированию, а затем рассказать, что я из них вынес. На очном собеседовании давали тесты по SQL-запросам и командам Linux.
Кстати, когда вас спросят, какие книги по тестированию вы прочли, рекомендую назвать «Быстрое тестирование» (Калбертсон, Браун, Кобб) и «Тестирование DOT COM» Романа Савина. Чтобы понимать, о чём речь, прочтите хотя бы вступление к каждой из этих книг, а лучше — первую главу 🙂
Этапы развития и как их проходить
Есть несколько уровней мастерства тестировщика.
Джуниор. Ты проходишь подробные тесты, составленные кем-то другим. Задумываешься, на чём они основаны, и внезапно открываешь для себя существование документации. Отныне ориентируйся на неё! Даже если тест-кейс ей противоречит.
Тестировщик. Ты тестируешь программу по документации и ориентируешься на описание функциональности. Тест-дизайнеры как отдельные работники — редкость, поэтому ты сам придумываешь, как протестировать приложение, чтобы отловить все возможные ошибки. Сам пишешь подробный план тестирования и тест-кейсы. Дальше группируешь тест-кейсы логически и раздаёшь джуниорам. Это уровень старшего и ведущего тестировщика.
Исследователь. Самый сложный уровень — exploratory testing. Нет ни тестовой модели, ни подробной документации (в лучшем случае — список задач для разработчиков). Задача — найти все баги ПО. Тут придётся включить фантазию и моделировать работу конечного пользователя. Да не простого, а пользователя-ломателя.
Иногда ты будешь сталкиваться с трудностями тестирования в ограниченной среде. Придётся проверять, как работает твоя программа при получении сообщений из другой системы, к которой у тебя нет доступа. Можно координироваться с коллегами из других систем либо справляться самому. Во втором случае надо уметь пользоваться вспомогательным ПО типа SoapUI и Postman.
Но прежде всего надо разобраться:
- как устроена клиент-серверная архитектура,
- как формировать и обрабатывать интеграционные сообщения,
- как запускать их из командной строки.
Полезно уметь подключаться к серверу или удалённой машине с помощью программ типа WinSCP. Но они только показывают файлы (в том числе логи), а для отправки команд серверу понадобится изучить ещё и Putty либо аналог.
Плюс надо понимать, что такое командная строка, и знать основные команды Linux. Открою секрет: на первых порах можно ограничиться пятью командами, но их придётся запомнить.
Условия карьерного роста
Перефразируем дядю Паркера: «Большая зарплата влечёт большую ответственность» 🙂 В самом начале карьеры, когда что-то не работает, можно поднять лапки и закричать «караул!». Мол, это вопрос не на мою зарплату. Но это плохой способ.
Если хочешь профессионального и зарплатного роста, учись определять, на чьей стороне проблема. Вызвана ошибка сбоем в работе программы или дело в забитом кеше, зависшем сервере, связанном приложении? Порой надо банально проверить соединение с интернетом.
Если «ничего не работает», надо понять, что не работает в первую очередь. И знать, кому звонить и писать, куда бежать с этими неполадками. Я всегда держу под рукой список фамилий и контактов по зонам ответственности.
Важно уметь отвечать на вопросы. Это особенно пригодится, когда придётся вводить в курс дела новичков или подрядчиков-аутсорсеров. А ещё — на презентациях для представителей бизнеса, которые вы наверняка будете проводить (или как минимум в них участвовать).
Горизонталь и вертикаль
Профессиональный рост бывает вертикальным и горизонтальным.
Для вертикального роста надо развивать административные и управленческие навыки, но и про техническую часть не забывать. Пусть ты уже не ловишь баги лично, но как руководитель должен понимать, кому передать задачу и как распознать обман, когда подчинённые говорят: «Сделали всё, что могли, но это надо тестировать четыре дня».
Горизонтальный рост требует выбора. Если ты хочешь развиваться в ручном тестировании, надо глубоко вникнуть в устройство системы и работу программы. Освой все инструменты ручного тестирования — не зацикливайся на одном. Дальше на этом пути возможен рост до аналитика.
Второй вариант — изучить программирование и идти в автоматизацию. Правда, уже есть ПО, где автотесты можно делать без кода. Но привычка решать всё нажатием кнопки снижает потолок развития специалиста. В непонятной ситуации придётся бежать за помощью к тому, кто знает и понимает больше.
В автоматизированном тестировании свой инструментарий, но для успешного роста надо разбираться в системе и архитектуре не хуже «ручника». В дальнейшем с этой дорожки можно свернуть в разработку.
Помимо автоматизации есть ещё нагрузочное тестирование. Тут тоже надо быть немного программистом (писать скрипты) и аналитиком — уметь анализировать результаты.
Третий путь — совместить предыдущие варианты и стать универсальным специалистом. Для этого необходимо подтянуть навыки программиста и аналитика.
Я хочу попробовать себя в Data Science. Тут очень пригодится школьный и университетский курс математики и статистики.
О стереотипах
Некоторые руководители ошибочно полагают, что тестировщик — это личинка программиста или аналитика. Они с недоверием относятся к сотруднику, который «застрял» в тестировщиках. Но всем не угодишь. Тут к месту вспомнить басню про мальчика, мельника, осла и общественное мнение.
О личных качествах тестировщика
Мне запомнилась статья, где сказано, что хороший тестировщик «обладает ломательной психологией» 🙂 Ещё говорят, что он должен понять то, чего не понял разработчик. Лично я считаю, отличие здесь — в направлении внимания к продукту. Разработчик глубоко знает узкую тему, а тестировщик меньше роет вглубь, но смотрит шире.
Ведущий или главный тестировщик представляет, как работает система в целом и как взаимодействуют её компоненты. В этом он похож на архитектора и системного аналитика. Но архитектор знает технические особенности на уровне разработчика и лучше, а аналитик составляет документацию и доносит до разработки требования заказчика.
Очень важное для тестировщика качество — твёрдость характера. В спорах с разработчиками и начальством часто приходится настаивать на своём. Коллеги могут быть недовольны — но если уступить, крайним при проблемах в промышленной эксплуатации всегда будет тестировщик! Об этом стоит помнить.
Как всякий айтишник, тестировщик должен быть любознательным и дотошным, ведь ему предстоит всю жизнь учиться. Немного перфекционизма не повредит.
Хотите узнать больше о выпускниках курсов и факультета тестирования ПО GeekUniversity? Вот их истории:
На этой неделе я вообще не чувствую себя человеком. Я только…
На этой неделе я вообще не чувствую себя человеком. Я только работала, ходила к врачу, занималась уборкой и спала (я даже спала только потому что так надо, чтобы делать всё остальное). А ну ещё я занималась спортом. Но это примерно, как спать, просто так надо. И вместо того, чтобы покупать новогоднее платье я смирненько покупаю швабру и убираюсь. В моё новое окно видны качельки во дворе спального района (в прошлые окна, конечно, были видны тупо стены, но когда на улицу выходишь, то разница очень заметна). И соседи тут не жалуются на шум в пять утра:(Но вот сегодня мне наконец удалось позвонить на другой край земли. За что вообще-то спасибо Люде, из-за которой я сегодня рано подорвалась, и у меня появилось капельку времени на что-то ещё, кроме самого необходимого. Надеюсь, Наташа, там не очень икает, я же вообще-то исключительно в личных целях. Хотя скоро буду не только.
Вам знакомо это чувство, когда приходишь а работу и понимаешь, что раз уж ты сюда дошёл, то ничего плохого с тобой сегодня уже не случится?
А вообще в связи с прошествием трёх месяцев я, наконец, хочу написать историю о том, как же я меняла работу.
Мне с самого начала было понятно, что вечно работать в ООО РОЛИС я не буду, но действительно перестать это делать я созрела только где-то к концу весны-началу лета. Но я решила, что сначала надо отдохнуть, а потом уже что-то делать.
Тем не менее где-то за неделю до отпуска я решила начать чесаться и обновила резюме. Я раньше работу вот так вот с резюме на хх не искала никогда, поэтому думала, что вот, пока я его обновлю, пока кто-то на него посмотрит, пока то да это, я успею съездить в Крым, у нас как раз закончится текущая задача, и я спокойненько уйду. В итоге перед отпуском я успела сходить на 3 собеседования.
Первое собеседование у меня было в компании PetShop. Вообще-то это не IT-компания, но у них есть IT-отдел человек из 15. И когда я туда пришла, оказалось, что ни одного тестировщика там нет вообще, а я — первый собеседуемый кандидат. И вообще по ходу первый живой тестировщик, которого видит начальник отдела. Про тестирование меня на этом собеседовании не спрашивали вообще ничего. Зато рассказали о своих проблемах. И оказалось, что там надеются, что тестирование сэкономит им время. Я сказала, что тестирование — самый долгий процесс вообще, и в крайнем случае они сэкономят разве что время ценных разработчиков, а не время вообще. А ещё я там заполнила какую-то психологическую анкету на три страницы. В общем, по итогам мне оттуда даже не перезвонили.
Потом я сходила на собеседование в компанию Аскон. Там меня собеседовала уже тестировщица. Мне показали прогу, которую там надо тестировать. Это был какой-то пакет для архитекторов. Спрашивали, как бы я протестировала определённую часть этой проги. Вообще, в этой компании всё было хорошо и адекватно, кроме, пожалуй, запредельно, с моей точки зрения, жёсткого графика. В итоге мне предложили там работу. И даже предложили зарплату, немного большую, чем я получаю сейчас. Но я была не готова вот так вот прямо сразу к ним пойти, к тому же Крым. Сказала, что буду думать и ходить на другие собеседования. Бедные, мучила я их с определённым ответом долго. Тамошняя девочка-эйчар даже недоумевала, почему это все кандидаты думают и выбирают. Она первый раз, оказывается, столкнулась с такой ситуацией, что люди ходят в разные места и выбирают себе работу.
Ну и напоследок перед отпуском я сходила на собеседование в компанию Комита. Надо сказать, что я просто ходила на все подряд собеседования, чтобы сама ситуация собеседования в принципе перестала быть для меня стрессовой, потому что раньше-то я на собеседования в жизни особо и не ходила, ну т. е. только на такие, где и так всё было ясно или на такие, где исход меня не очень беспокоил. Собеседование в компании Комита длилось три (!) часа. Там был ещё адский денёк, как щас помню. Я встала очень рано, чтобы после работы успеть на это собеседование, это был последний день перед отпуском, я не успела пообедать и у меня был первый день месячных, плюс адская жара на улице и какая-то ещё левая встреча после собеседования. В общем до этой Комиты я добралась уже не очень бодрой. Там меня собеседовала женщина-начальник отдела тестирования. И ещё какой-то мальчик-тестировщик. Вообще Комита порадовала меня целым прям отделом тестирования из 15 человек. Они пишут что-то там для государства. У меня довольно сильное впечатление от этой женщины осталось. Она была такая лет 35, и я всё время представляла себе во время собеседования, как она ведёт практику по вычам на матмехе. Ей бы вот там было самое место! Сначала мне задавали всякие опять психологические вопросы типа «Что Вам нравится в тестировании?», «Что Вам не нравится в тестировании?», потом перешли к делу. Выдали несколько заданий. В одном надо было написать на бумажке описания известных багов так, как ты бы это сделал в баг-трекере, в другом поправить стилистику-орфографию-пунктуацию в каком-то куске инструкции, в третьем потестировать в определёном ключе унылую форму какой-то денежной операции. форма была типа как в РОЛИСе, в стиле «My App». С заданиями не торопили, наверное, поэтому собеседование так затянулось. Бегло взглянув на результат выполнения заданий, дама-вот-бы-ей-вести-вычи высокомерно сообщила, что результат после двух лет ручного тестирования ожидаемый, сразу видно, что книжек я не читала почти, что я пропустила то, что пропускают все ручные тестировщики (впрочем, что именно я пропустила, она мне сказать отказалась), и что они устраивают среди кандидатов конкурс, и напишут победителю. Там мне посоветовали, какие книжки почитать. Меня ещё потрясла теснота офиса там. Зарплату мне там обещали не очень большую, меньше, по-моему, даже, чем в РОЛИСе + какой-то испытательный срок с обучением и жёсткими экзаменами (жаль только, что не по вычам) в конце. Тем не менее, я вполне могла бы согласиться туда пойти, т. к. у них там, как я поняла, мне было чему поучится, по крайней мере, в плане составления тестовой документации, потому что её там очень даже писали. Т. к. госзаказ. Ну и эта жёсткая тётка меня очень вставила, конечно:) Они мне не написали, я не прошла их суровый конкурс:)
На этом я записала себе насоветованных книжечек и уехала в Крым:)
Приехав из Крыма, я сходила на собеседование в компанию с называнием, кажется, ЗЕД. Там были клёвые мужики, которые поговорили со мной про тестирование калькулятора. Сама контора делает смс-спам. Т. е. как бы высокие нагрузки, это было мне интересно. Хотя я в этой области ноль, но тут как раз был бы шанс перестать им быть. Забавным оказалось то, что на моменте моего рассказа об опыте работы оказалось, что один из этих клёвых мужиков работал в Solvo (Solvo — контора, которая рука об руку с РОЛИСом спасает мир контейнерных перевозок от хаоса, программы РОЛИСа и Solvo много обмениваются данными друг с другом и всячески друг под друга искривлены). В общем там было отличное собеседование. Мужики со мной потом так и не связались, но я реально приятно провела с ними в беседе полтора часа.
Дальше я сходила на «собеседование» в компанию Lenvendo. Это было ужасно. Оказывается, что первый этап собеседования — это 20 минут разговора с эйчаром на темы, на которые вполне можно поговорить по телефону. А я-то встала ни свет ни заря, пришла к ним. Впрочем, на второй этап я согласилась, т. к. мне же надо было сделать процесс собеседование обыденным.
Вооот потом я пришла на собеседование в Яндекс, тестовое задание для которого я сделала ещё перед отпуском. Тестовое задание, кстати, было, с моей точки зрения, прикольное. Про то, что меня спрашивали на собеседовании писать не буду, т. к. удобнее сравнивать кандидатов, задавая им одни и те же задачи. Хотя, я ничего не знаю об их повторяемости, и вообще о том, как в Яндексе устроены собеседования. Потому что я же не сказала там ну ничего сверхъестественного, а меня взяли. Вот не знаю, почему.
После этого я пришла на собеседование в DrWeb, неторопливая переписка с которым у меня тоже началась ещё до отпуска. Вот Ирину-эйчара DrWeb я бы попыталась пригласить в кино, если бы была мальчиком. Она — самая лучшая из всех виденных мной эйчаров! Тестовое задание перед собеседование у меня было протестировать карандаш. Это какая-то популярная задачка. Не знаю, что она там показывает. Я написала мега-тестплан, в котором половина пунктов была чисто поржать. Но посмотрев в него, мне сказали, что это очень ок, и что про мои познания в тестировании им из этого тестплана и так всё ясно, и про тестирование меня на собеседовании даже спрашивать не будут. Там был один такой момент, о котором я их существенно до собеседования предпреждала. Вакансия требовала хорошего знания Windows. У меня вообще Linux, да и системными вопросами я сама особо не озадачивалась, и мне их никогда не преподавали. Поэтому я сразу спросила, что почитать, сказав, что хоть по остальным пунктам я и подхожу, но вот этим важным местом совсем не владею. Меня послали к двум книжкам. Я открыла их, поняла, что там освещаются офигенно интересные фундаментальные вопросы, и мне бы хотелось этим позаниматься, но это всё на 700 страницах, и я даже за весь отпуск скорее всего не успею прочитать. В общем к собеседованию я читала только вики. Но ещё 100500 раз им сказала, что это всё здорово, но я пока в этой теме ничего не понимаю. В итоге на собеседовании мой гипотетический непосредственный начальник (тоже очень обаятельный) позадавал мне всяких вопросов на эти темы, на большую часть из которых я отвечала что-то в духе «пык-мык», а на некоторые и вообще не отвечала. Но тем не менее, там мне тоже предложили работу с низкой стартовой зарплатой и перспективой её увеличения по мере увеличения знаний. И я даже прям немного сомневалась между ними и Яндексом, т. к. перспектива изучить совершенно новый для себя кусок очень привлекала. Если бы я по каким-то причинам не пришла или меня бы не взяли в Яндекс, я бы обязательно к ним пошла.
А после этого я ещё сходила на второй этап собеседования в компанию Lenvendo. Там я поговорила с их гендиром. который рассказал мне про все сложности их работы. И спросил, согласна ли я наконец получить тестовой задание. Я даже согласилась из любопытства:))))) И их тестовое задание было в том, чтобы протестировать их развесистый сайт. В общем это Lenvendo — это что-то убийственное, видимо, они ищут кандидатов с очень крепкими нервами. Не знаю, что они там ещё потом просят.
А потом мне пришлось отменять уже назначенное собеседование в Luxsoft, за что мне до сих пор очень стыдно, т. к. я сделала это поздно вечером накануне назначенного на непозднее утро собеседования. Отменять пришлось из-за того, что мне уже было на тот момент понятно, куда я пойду работать, и было понятно, что не к ним. Хотя, говорят, они клёвые.
А ещё из прикольного было, что меня звали на собеседование в компанию Infra, которая делает по сей день ПО для колл-центров, а на этом ПО работал тот колл-центр, в котором я работала в детстве. Прикольно было бы эту инфру уже тестировать, а не использовать:) Уж я-то знаю всякие сценарии поведения с ней пользователя:)))
В общем, поиск работы очень поднимает ЧСВ. Все такие сразу милые девушки-эйчары тебе звонят, ты всем сразу так нужен.
Моя текущая работа меня пока не разочаровала:) В чём у меня впрочем не было сомнений. Надеюсь, я её тоже. И в паспорте стало капельку меньше хаоса.