что спрашивать на собеседовании у тестировщика
Чек-лист подготовки к собеседованию на позицию ручного web-тестировщика
Самые популярные вопросы:
Какие методики тестирования Вы знаете?
модульная/компонентная: проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по отдельности;
интеграционная: предназначена для проверки связи между компонентами, а также взаимодействия с различными частями системы.
системная: высокоуровневая проверка функционала всей программы или системы в целом.
приемочная: проводится на этапе сдачи готового продукта заказчику.
Именно в этом порядке программное обеспечение подвергается испытанием.
Расскажите про виды тестирования?
Все виды тестирования программного обеспечения, можно условно разделить на следующие группы:
связанные с изменениями, то есть после исправления бага/дефекта необходимо повторное тестирование, с целью убедиться, что внесенные изменения действительно решили проблему.
Что такое нагрузочное тестирование и чем отличается от стресс тестированием?
Какие бывают подходы тестирования?
Всё зависит от доступа к коду программного обеспечения.
Что такое чек-лист и как его оформлять?
Литературы по тестированию множество и вам всё не перечитать, это и не нужно! Выбирайте книгу более современную и тоньше.
Что такое web приложение? Однозначно, это клиент-серверное приложение, в котором клиент взаимодействует с веб-сервером при помощи браузера. Поэтому не избежать вопросов про сетевые протоколы взаимодействия. Могут быть общие вопросы:
Какие интернет протоколы Вам известны?
На собеседование достаточно будет рассказать про основные протоколы, углубляться в эту тему не следует. Наиболее известные протоколы:
HTTP (Hyper Text Transfer Protocol)
FTP (File Transfer Protocol)
POP3 (Post Office Protocol)
SMTP (Simple Mail Transfer Protocol)
Но основная часть вопросов будет про http и https:
Расскажите какие между ними различие?
http — протокол прикладного уровня передачи данных, изначально — в виде гипертекстовых документов в формате HTML, в настоящее время используется для передачи произвольных данных.
https — расширение протокола HTTP для поддержки шифрования в целях повышения безопасности.
Как же ответить на вопрос «в чем отличия?», ответ кроется в их определении, а именно: https не является отдельным протоколом передачи данных, а представляет собой расширение протокола http с надстройкой шифрования; передаваемые по протоколу http данные не защищены, https обеспечивает конфиденциальность информации путем ее шифрования.
Какие Вам известны методы протокола http, расскажите вкратце о каждом?
HTTP определяет множество методов запроса, которые указывают, какое желаемое действие выполнится для данного ресурса.
Метода GET в HTTP используется для получения информации от сервера. Запросы клиентов, использующие метод GET должны получать только данные и не должны никак влиять на эти данные.
Метод HEAD работает точно так же, как GET, но в ответ сервер посылает только заголовки и статусную строку без тела HTTP сообщения.
Метод POST используется для отправки данных на сервер, например, из HTML форм, которые заполняет посетитель сайта.
Метод PUT заменяет все текущие представления ресурса данными запроса.
Метод DELETE удаляет указанный ресурс.
Метод CONNECT преобразует существующее соединение в тоннель.
Метод OPTIONS используется для получения параметров текущего HTTP соединения.
Метод TRACE создает петлю, благодаря которой клиент может увидеть, что происходит с сообщением на всех узлах передачи.
Метод PATCH используется для частичного изменения ресурса.
Отвечая на этот вопрос можете перечислить только основные методы.
Расскажите о структуре http-запроса и ответа?
Не пугайтесь этого вопроса, здесь следует упомянуть только про основные части http запроса: строка запроса, заголовки, тело сообщения. Нужно обратить внимание, что между заголовками и телом сообщения находится пустая строка (в качестве разделителя), она представляет собой символ перевода строки. При получении ответного запроса от сервера, тело сообщения обычно представляет собой содержимое веб-страницы.
Для расширения кругозора рекомендую прояснить понятия «Транспортный уровень», «Уровень сети интернет», «Канальный уровень».
Основы Web-программирования
Веб-приложение — клиент-серверное приложение, в котором клиент взаимодействует с веб-сервером при помощи браузера. Поэтому вопросы на собеседовании по этой теме обязательно будут!
Почему не открывается гиперссылка?
При ответе на вопрос необходимо уточнить, что у пользователя устойчивое интернет соединение. Даны следующие вводные: пользователь заходит на популярный ресурс с новостями, нажимает на «Срочная новость!», но страница не открывается. Самый простой способ разобраться в причине, это воспользоваться браузерной консолью. Открыли консоль, выбрали элемент с гиперссылкой, и анализируем какой веб-адрес указан. Самая популярная ошибка, которую находят тестировщики, это неверно указанный веб-адрес.
Почему не соответствует цвет кнопки дизайну?
Посмотреть цвет кнопки можно аналогичным способом через браузерную панель, и сравнить кодировки цвета.
Расскажите про браузерную консоль.
Панель Elements показывает разметку страницы точно так же, как она рендерится в браузере, так же можно посмотреть, как бы выглядела открытая страница на каком-нибудь девайсе с другим расширением экрана.
Панель Network. Основная функция данной вкладки – запись сетевого журнала. Она дает представление о запрашиваемых и загружаемых ресурсах в режиме реального времени.
Панель Performance. Данная вкладка используется при необходимости полного обзора затраченного времени.
Панель Memory. Данная панель дает возможность профилировать время исполнения и использование памяти веб приложением или страницей, таким образом помогая понять где именно тратится много ресурсов и как можно оптимизировать код.
Панель Application. Предназначена для исследования загруженных элементов.
Если у вас есть основы знаний HTML, CSS, JS это будет огромным плюсом, хотя бы следует развиваться в этом направлении, чтобы стать хорошим специалистом!
Что же именно входит в основы?
А что же с API?
Сложность тестирования API (программный интерфейс приложения) заключается в отсутствии пользовательского интерфейса. Поэтому нужно настроить с необходимым набором параметров среду тестирующую API, а затем проанализировать результаты теста. Какие же вопросы могут таиться:
Чем отличается REST от SOAP протокола?
REST — это архитектурный стиль. SOAP — это формат обмена сообщениям, имеет веб-сервис WSDL с прописанными методами, которые можно удаленно вызывать.
REST работает только по HTTP/HTTPS, SOAP с любым протоколом прикладного уровня: SMPT, FTP, HTTP, HTTPS, POP3.
REST более простой, гибкий и быстрый, SOAP типизированный, но в некоторых случаях лучше визуализируется за счет применения им синтаксиса похожего на HTML разметку.
Какой формат передачи информации используется в SOAP, а какой в REST?
REST использует Json и XML, SOAP только XML.
Какие инструменты вы знаете для тестирования API?
Отвечая на этот вопрос, опирайтесь на свой опыт. Список самых популярных инструментов: SoapUI, Postman, REST-Assured, Fiddler, Karate, JMeter.
Информации по API в свободном доступе огромное количество, поэтому вы сможете разобраться в этом разделе.
Как быть с автоматизацией?
Во многих компаниях активно используется автоматическое тестирование. Часто разбором результатов прогонов и анализом занимаются ручники. Поэтому нужно иметь небольшое представление, как строится процесс автоматизации и какие инструменты используются.
Если раньше в работе сталкивались с автоматизацией, то расскажите подробнее какой использовался технический стек, как происходил разбор тестов, и какой был алгоритм действий, если автотест падал с ошибкой.
Большим плюсом будет опыт работы с GIT и с базами данных.
Каких ответов я жду на собеседовании по тестированию
Я провожу собеседования на тестировщиков. У меня иногда болит голова.
Долго собирался написать статью… И вот, наконец, выполнил свое намерение. Вопросы, поднимаемые в статье, обсуждались уже не раз и не два, но усердные поиски компиляции ответов на эти вопросы так и не увенчались успехом. Но, как подсказывает мой опыт, такая компиляция очень нужна. Прежде всего она требуется юниорам, ибо в сети по запросу «тестирование» на них (соискателей) обрушивается огромный объем информационного мусора, который плохо структурирован и часто противоречит сам себе.
Вступление
Сначала несколько слов о себе. На данный момент являюсь начальником отдела тестирования и сопровождения компании, занимающейся корпоративными ГИС. До этого работал руководителем группы тестирования в компании, разрабатывающей коммерческие СДО (Системы дистанционного обучения). А еще раньше ведущим инженером по тестированию в компании, которая обеспечивала электронные торги по ФЗ №94. А начинал я свою карьеру более 11 лет назад в роли системного администратора (в трех различных организациях). Стажером-программистом был чуть меньше двух лет (вначале нулевых – VB). Фрилансил инженером-программистом: писал собственный баг-трекер для госкомпании… Исходя из сказанного, можно утверждать, что определенный опыт (тестирования — суммарно более 5 лет) наработан…
Кроме того, по долгу службы мне постоянно приходится подбирать сотрудников в отдел тестирования. И чем больше я этим занимаюсь, тем больше убеждаюсь, что иногда проще взять претендента без опыта, чем человека с опытом тестирования в российской компании (впрочем, не без исключений). Попутно следует отметить, что соискатели без опыта в подавляющей массе используют следующие источники информации о профессии: интернет – ресурсы, книги, мнение знакомых тестировщиков.
Этим текстом я попытаюсь немного подвести вчерашних, сегодняшних и завтрашних соискателей на позицию тестировщика к пониманию, а что же все-таки такое «тестирование». Далее я отвечу на некоторые из вопросов собеседования и обосную свое мнение, а также приведу некоторые из наиболее частых ответов соискателей и объясню, почему считаю их неправильными.
Почему вы решили стать тестировщиком?
Наиболее частый ответ: «потому что это просто и интересно (!)». Т. е. кандидат считает, что ему будут платить деньги за щелканье мышкой в вк… Или дадут софт и скажут – сломай его… Или он просто не готовился к этому вопросу и имеет весьма слабое представление о профессии.
Второй по частоте ответ: «потому что я хочу работать в IT и тестирование – самый простой путь» (читай: у IT специалистов высокая зп, а в тестировании не нужно ни знаний, ни навыков, но зп тоже достаточно высокая!).
Бывали и ответы: «меня мама/муж/жена заставила идти на собеседование».
Единственно правильного ответа нет, но вот указанные три и их производные – точно неправильные, т. к. тестирование – это сложно и однообразно, оно требует определенных навыков, по которым нет учебников, и ведет к профессиональной деформации мировоззрения.
Что бы я хотел услышать? Возможно, что-то вроде: «потому что без тестирования невозможно выявить истинное состояние производимого продукта, и насколько он соответствует ожиданиям потребителя».
Что такое тестирование? В чем его суть как процесса?
Наиболее частый ответ (напрямую прописан у С. Канера и Р.Савина) – «поиск ошибок». И во всей литературе по тестированию почему-то никто не указывает, что это упрощение и весьма грубое, и вообще, этот ответ просто неверен!
Тестирование – комплекс мероприятий, направленный на проведение проверок на соответствие производимого продукта требованиям, к нему предъявляемым (прямым и косвенным).
Да, действительно, в ходе проверок выявляются ошибки/инциденты/замечания, но это лишь побочный продукт процесса. Основным является информация о соответствии продукта требованиям, которые к нему предъявляются.
Что такое ошибка?
Ну, здесь, слава Богу, почти все отвечают: «некорректная работа программы…». А вот дальше начинается хаос, когда спрашиваешь: «а как мы узнаем корректная работа или нет?»
Правильный ответ есть почти на всех известных мне ресурсах о тестировании:
Ошибка – несоответствие производимого продукта требованиям, прямым или косвенным.
Чтобы не блуждать в противоречиях/предположениях и т. п., – это единственно правильный ответ.
В чем цель тестирования?
Здесь люди начинают повторять ответ на второй вопрос с разными вариациями. Наиболее внимательные соискатели пытаются пересказать то, что я им подсказывал при ответе на второй вопрос. А ответ крайне простой:
Цель тестирования – предоставление актуальной информации о соответствии производимого продукта требованиям.
Всё. Не больше и не меньше. Ну, конечно же, можно еще сказать, что цель тестирования – предоставление информации о количестве ошибок в продукте. А именно это и неправильно. Почему? Вот просто-таки каждодневный кейс многих тестировщиков/ПМ/аналитиков: звонок заказчика – «как там мой продукт?». «Вы знаете, в нем еще 60 багов!» – ответ тестировщика/ПМ… И что дальше? Это много? Мало? Нормально? Можно, конечно, рассказать подробно о критичности этих багов, их приоритетах, но это не ответ на вопрос заказчика, это выдача сырой необработанной информации ДВП. Теперь тот же кейс. «Как там мой продукт?», – спрашивает заказчик. «35% процентов требований реализовано полностью, еще 5% – с замечаниями и еще 2% – сейчас в реализации», – отвечает ПМ/тестировщик. Как Вам кажется, такой ответ понятнее? И пусть в эти 5% входят, уже упомянутые 60 багов-замечаний… Ответ на вопрос дан настолько точный, насколько это вообще возможно в данном формате. Вот именно это и является целью тестирования. А, соответственно, и сам процесс по своей сути должен сводиться к достижению этой цели.
Что вы знаете о жизненном цикле ПО?
Про ЖЦ ПО сказано много, да и он сильно зависит от организации процесса реализации в целом. Все же есть некоторая «золотая середина», но и здесь умудряются фантазировать дикие вещи, то сводя все к трем пунктам, то разрисовывая схему на три страницы… Всем, кто проводил/проходил собеседование, и так ясно, какие ошибки совершаются и сколько вариантов у правильных ответов. Останавливаться подробнее не буду, скажу только, что есть целый пул кандидатов, которые намертво стопорились на этом вопросе (примерно 7%).
Какие бывают требования?
До этого вопроса за полтора часа доходят только процентов 50 соискателей… Хотя я и не требую ответов «буква в букву», главное, как это называют юристы, сохранить «дух».
Самый частый кейс: соискатели начинают перечислять виды технической документации, которые они знают или о которых слышали… Обязательно выслушаю, покиваю и спрошу: «что-нибудь еще?». Редко кто вспоминает про деление на «функциональные»/«нефункциональные», а кто вспоминает, часто не может объяснить разницу.
Но есть одна категория, про которую забывают. Я в этой статье уже несколько раз упоминал о «…требованиях прямых и косвенных…». На собеседовании я эту фразу произношу раз пять-шесть. Очень малый процент соискателей переспрашивает и тем самым исключает этот вопрос из собеседования. А полный ответ таков: «Требования бывают прямыми (т. е. формализованными в технической документации, спеках, юзер-стори и прочих формальных артефактах) и косвенными (т. е. проистекающими из прямых, либо являющимися негласным стандартом для данной продукции или основывающиеся на опыте и здравом смысле использования данного продукта или продуктах, подобных ему). Все требования также подразделяются на функциональные (описывающие какие функции должен выполнять продукт) и нефункциональные (требования к окружению, поддерживаемости, надежности и прочим характеристикам продукта). Прямые требования всегда приоритетнее косвенных.»
Самый очевидный и «простой» пример: в ТЗ — «кнопка должна быть красного цвета» – прямое требование, из него проистекают косвенные – она не должна быть синей, зеленой, серой или черной и т. д… Естественно, это сильное упрощение, но очень показательное. А главное – такой подход отсекает излишне формальное отношение к тестированию и поднимает планку квалификации тестирования как такового, ибо для грамотного тестирования мало знать только ТЗ и юзер-стори, надо еще изучить прикладную область и специфику потребления производимого продукта. Такое тестирование значительно эффективнее.
Какие виды/типы/классы/методы тестирования вы знаете, и чем они различаются?
О классификации тестирования имеется очень много информации, вариантов правильных ответов тоже очень много. Я задаю этот вопрос, чтобы увидеть, готовился соискатель хоть в малой степени или вообще не удосужился. Дело в том, что на предыдущие вопросы можно ответить, просто рассуждая и имея общее представление о сфере в целом. Данный вопрос требует элементарного знания терминов. Возможно, я рассмотрю его в других статьях, ибо он достаточно большой и заслуживает отдельной статьи.
Расскажите о тестовой документации: виды, цели.
Тестовая документация – пожалуй, самая большая проблема. По ней идут такие битвы в сообществах, фирмах и т. д.! Про нее столько противоречивой информации. О ней изданы многотомники на разных языках. О ней такая каша в головах… Каких только ответов не приходилось слышать (да-да, включая ТЗ и проектное решение – это тоже тестовая документация)… Поэтому выскажу свои мысли по этому поводу.
Тестовая документация бывает двух видов: внешняя и внутренняя. И та, и другая – инструмент, облегчающий жизнь проектной команде. Не более и не менее.
Естественно, видов документации в тестировании гораздо больше, но без понимания назначения и особенностей этих документов работать в этой профессии очень сложно. И чтобы совсем не увеличивать размеры статьи, рассмотрим последний (для этой статьи) вопрос.
Из каких этапов состоит процесс тестирования?
Инициация – событие, которое извещает команду тестирования о необходимости сессии тестирования, а также гарантирует выполнение требований к продукту для проведения тестирования.
Выявление требований – пожалуй, один из главных шагов в процессе тестирования. Неизвестны требования – нет тестирования. Необходимо собрать всю доступную информацию о предмете тестирования, вариантах использования и т. п. Первый источник – техническая документация и юзер-стори – это прямые требования. Качество же косвенных требований во многом зависят от добросовестности, ответственности, квалификации тестировщика и всей команды проекта.
Генерация тестовых случаев – выявление всех возможных случаев использования продукта, его характеристик и особенностей в процессе эксплуатации. Это значит: всех случаев, которые тестировщик может «придумать» на основе прямых и косвенных требований, известных ему. Этот этап требует высокой квалификации специалиста по тестированию.
Отбор тестовых случаев – отбор наиболее показательных, значимых и воспроизводимых тестовых случаев. От этого этапа зависит, насколько тестирование будет полезным, эффективным и анализируемым. Например, в «простом» примере с красной кнопкой понятно, что количество косвенных требований стремится к бесконечности, и проверять их все подряд – полный абсурд, но подобные кейсы должны быть сгенерированы хотя бы в голове проверяющего. А для того чтобы они не вошли в проверки, необходимо выполнить соответствующий отбор и проверить только, действительно ли кнопка красная.
Пример примитивный, но после его озвучивания соискатели перестают первым делом пытаться налить в стакан радий на тестовом задании J (кто принимал участие в собеседовании на должность тестировщика, тот знает это нехитрое задание на генерацию и отбор тестовых случаев).
Проведение проверок – тут все понятно. Либо согласно документации, либо ad hoc (интуитивно, свободный поиск, без документации). В любом случае это проводится согласно списку отобранных проверок. Почему-то большинство именно этот пункт называет тестированием. И в голове обывателя, незнакомого с профессией, только один этот пункт и содержится J.
Фиксация результатов – создание внутренней и внешней тестовой документации в формализованном виде или в виде записей и т. п. На данном этапе отчет о тестирование даже если и создается, то не считается законченным.
Анализ результатов – вынесение решения о соответствии проверенного продукта требованиям. Формализация данного решения и его обоснование в виде отчета о тестировании. Сюда также входят процедуры по оценке покрытия требований проверками, тайм-шитинг и пр. Таким образом, проводится анализ не только результатов, но и самой сессии тестирования.
Передача информации о соответствии продукта требованиям. Формально: передача внешней тестовой документации заинтересованным в ней сторонам, зачастую инициатору сессии тестирования. В общем случае: помимо документации предоставляется информация о рисках, которые были выявлены в продукте, требованиях, процессах, передаются рекомендации по отработке этих рисков и т. п. Но это – уже QA J!
Вместо послесловия
Внимательный читатель заметил, что вопросы набирают сложность от начала к концу беседы. Вместе с тем, стоит отметить, что все эти вопросы не должны затруднить специалистов по тестированию, то есть тех, кто не «просто кликал мышью – тестировал», а пытался разобраться в сути того, чем он занимается, тех, кто не остановился на одной книжке или одном ресурсе, а продумал и обосновал свои действия… хотя бы для самого себя.
На этом я завершаю данную статью. Если уважаемый читатель найдет предмет для дискуссии в моих утверждениях, буду рад в ней поучаствовать. Если появятся вопросы, то они станут темами для будущих статей. Всегда рад конструктивной критике. В любом случае пишите мне. Если к статье будет проявлен интерес, то продолжу разбор собеседований, а, возможно, попробую осветить и другие аспекты профессии, о которой слышали почти все, но мало тех, кто знает ее изнутри.
Тестирование тестировщиков
Один тестировщик может протестировать что угодно, кроме самого себя. А два, как известно, могут протестировать вообще всё. В этой статье мы расскажем, как на самом деле обстоит процесс подбора тестировщиков в hh.ru.
Существует несколько этапов отбора специалистов и два больших фильтра в лице HR и Технического департамента:
Отбор резюме HR-специалистом
Отбор резюме тестировщиком
Опросник
Техническое собеседование
Тестовое задание и его проверка
Финал – знакомство с одной или с несколькими командами
Для полного счастья не хватает еще несколько кругов, не так ли? Просто представим, что они есть. Ниже мы подробнее разберем каждый из этапов и дадим пару советов, как проскочить их наиболее эффективным способом.
Отбор резюме рекрутером
Тут всё понятно. Рекрутер скринит известные и не очень ресурсы на предмет релевантных резюме, после чего несет лучшие на суд тестировщикам.
Пример резюме, которое нас заинтересует
Опыт работы:
Работа по методологии от Java: scrum/kanban
Принятие участия на самых ранних этапах разработки: от идеи до релиза фичи
Коммуникация с дизайнерами, заказчиками
Оценка возможных рисков
Работа с багтрекингом Jira/Confluence
Ручное тестирование frontend и backend
Проведение функционального, регрессионного, кроссбраузерного тестирования
Чтение логов – Linux, Kibana
Поддержка и написание новых тестов (Maven, TestNg, Selenium WebDriver, Java)
Использование SQL на уровне простых запросов
Работа с NoSQL субд (у нас есть Cassandra, желательно общее понимание)
Знание:
Основных понятий клиент-серверной архитектуры
Протокола http и его расширения https
Базовых команд Linux
Базовые знания Java — Collection Framework, TestNg/Junit
Ключевые навыки:
Devtools – очень желательно. Достаточно редко попадаются соискатели-тестировщики, которые не работали с Devtools
Postman или аналоги. Должно быть представление, как работает инструмент
Любой из снифферов трафика
Что может насторожить
Здесь мы выносим свой вердикт и оставляем комментарии к резюме – что нам нравится, а что настораживает. Вот что может нас насторожить:
Желаемая должность
QA Automation engineer – у нас больше ручного тестирования и 20-30% автоматизации, человеку с такой должностью может быть скучно. В этом случае рекрутер связывается с кандидатами, чтобы уточнить, подходит ли соискателю такое процентное соотношение или нет. В 50% случаях кандидатам подходит такой процент автоматизации. Плюс у нас в компании есть все возможности вырасти в автоматизатора и разработчика.
QA Lead/Head of QA – поскольку мы ищем специалиста на позицию тестировщика, скорее всего кандидат с опытом руководства вряд ли захочет подобного «даунгрейда». Но всегда можно уточнить, ведь есть миллион случаев, когда специалисты «устают» от руководства и уходят обратно в инженеры.
Тестировщик (manual only) – если соискатель хочет работать ручным тестировщиком, мы уточняем этот момент. Бывают случаи, когда люди не хотят развиваться в автоматизации, а это один из этапов прохождения испытательного срока – написать автотест
Опыт работы
Руководство – в опыте указано руководство командой тестировщиков. Например, у соискателя в подчинении находились пять тестировщиков, он распределял задачи и ресурсы. Такие моменты уточняет HR, потому что есть люди, которым не понравилось лидство, и он захотел вернуться в ряды тестировщиков
Только автоматизация – разработка моков, поднятие автотестов с нуля. Таким специалистам, скорее всего, будет скучновато работать на 70% ручного тестирования
Нет опыта Web-тестирования – таких кандидатов мы не рассматриваем совсем.
Указано много видов тестирования в опыте работы, и ничего не написано про инструменты и технологии, которые использовались. С таким резюме шансы дойти до опросника значительно снижаются.
Опросник
После того, как мы просмотрели резюме и выбрали подходящие, отправляем их в опросник. Зачем?
Отсеиваем незаинтересованных кандидатов – такие либо вообще не присылают опросник, либо присылают неразвернутые ответы (да/нет/пч0лы)
Смотрим, рассуждает ли тестировщик в ответах или пользуется лишь заученными терминами
Проверяем «адекватность»: нет ли скрытой агрессии, например
Однако сейчас мы пытаемся ввести практику отказа от опросника, поскольку из-за него у нас нет-нет да отваливаются тестировщики с очень хорошими скиллами и мощными резюме.
Техническое собеседование
После опросника следует техническое собеседование. Успешный собес на практике всегда опирается на два простых правила:
Не более 4 человек от компании на собеседовании: один ведущий, двое помогают ведущему, также может быть один слушатель, который хочет прокачать навыки для проведения собеседований
Ведущий управляет собеседованием по определенному плану и выстраивает диалог
План собеседования:
Рассказываем про позицию (роль тестировщика в компании и команде, его обязанности)
Говорим про команды, в которые идет поиск
Предлагаем кандидату задать нам вопросы
Задаем собственные: про опыт, технические моменты и всё в таком духе
Ждем дополнительных вопросов от кандидата, если они есть
На что обращаем внимание:
Как складывается общение – как отвечает и подает себя соискатель
Готов ли работать без документации – в Техдепе ее мало, в основном – исследовательское тестирование. Это важный пункт, нужно уточнять, будет ли кандидату комфортно работать в таких условиях.
Как отстаивает свои позиции – разработчик закрыл задачу и говорит: «Это не баг, а фича», – вопрос заключается в том, как поступит кандидат
Проявление инициативы – здесь можно уточнить причину ухода соискателя с прошлой работы. Зачастую кандидаты отвечали, что не было развития и автотестов. И тут можно задать вопрос: что сделал кандидат для внедрения автотестов или улучшения качества работы сервиса
Опыт тестирования веба – знание соискателя об устройстве веба
Последний опыт работы – кандидат может рассказать о процессе, проекте, релизах или устройстве тестовых стендов
Что-то пошло не так
Иногда что-то идет не так, и надо плавно завершать собеседование. Вот распространенные кейсы:
Технический бэкграунд слабый, но по общению всё хорошо. У кандидата хорошие мотивация и обучаемость. Но сейчас он еще не готов: слишком «зеленый». В таком случае проверяем софт-скиллы и плавно завершаем собеседование. Обычно в Talantix мы пишем, что готовы рассмотреть такого человека через полгода-год.
С софт-скиллами все сложнее. Бывает довольно сложно определить, сможет ли специалист работать с нашими проектами. Например, иногда из-за специфики работы с госзаказами у людей складывается определенный тип общения. С такими кандидатами бывает тяжело, но через год они, как правило уже готовы к сотрудничеству и дальнейшей работе.
На хамство/агрессию не стоит реагировать остро. Мы плавно завершаем собеседование без каких-либо ответных реакций. Делаем отметку в Talantix, что этот человек совсем конфликтный и общаться мы с ним больше не будем. Главное – не идти эскалацию конфликта.
Больше всего внимания мы уделяем софт-скиллам. У нас нет тестовой документации, поскольку для поддержания ее в актуальном состоянии потребуется еще один отдел. Отдел поддержания документации в актуальном состоянии, you know.
Поэтому важны софт-скиллы тестировщика, так как придется много общаться с заказчиками и другими командами разработки для уточнения требований. Обычно мы спрашиваем, как у кандидата происходило взаимодействие с командой и заказчиками. Какие действия он предпринимал для решения тех или иных проблем. Чтобы он делал в случаe разногласия с разработчиком, на вопрос “баг это или фича”.
Тестовое задание
Если всё прошло как надо, после технического собеседования мы высылаем кандидатам тестовое, которое включает в себя:
Написание тест-кейсов на страницу hh: создание резюме, поиска
Оценку времени тестирования
Найденные баги, которые кандидат заметил, пока составлял тест-кейсы
Буквально неделю-две назад мы начали пропускать этап тестового задания. И заметили тенденцию – когда выдавали тестовое задание хорошему кандидату с оффером из другой компании, он моментально отваливался. Зачем ему делать еще какие-то задания, когда у него уже есть прекрасный оффер?
Поэтому иногда этот шаг может быть включен в этап технического собеседования.
Финалочка
И вот он наш герой: прошел огонь, воду и тест-кейсы. Дошел до финала. Здесь кандидата ожидает знакомство с командой. Здесь уже ребята из команд сами подбирают для себя людей под свои интересы и задачи. Чаще всего используется такой алгоритм:
Анализируем личные качества кандидата
Смотрим, насколько подходит команде по общению/интересам
Кандидат интересуется своей будущей командой и оценивает, насколько она ему подходит