Привет! Меня зовут Юра Байков, я ведущий QA-инженер и много раз проводил собеседования на позицию тестировщика в свою команду. Да, на Хабре много постов о том, как проходят такие встречи и как к ним подготовиться. Но сегодня хочу поделиться именно своим опытом: подскажу, какие книги прочитать, чтобы укрепить базу, — шок-контент, но их всего две. А еще расскажу, о чем я спрашиваю джунов на собеседовании.
Во избежание недопониманий подчеркну, что это исключительно мой опыт и в моей практике он работает. У вас может быть другое видение — и это нормально.
Какие книги рекомендую почитать, чтобы уверенно чувствовать себя на собесе
«Тестирование dot com, или Пособие по жестокому обращению с багами в интернет-стартапах». Автор: Роман Савин
Ее еще называют библией тестировщика. Эта книжка дает все основы. Даже если ты не был знаком с ИТ, после ее прочтения база станет плюс-минус ясной. Правда, советую прочитать ее дважды: сначала для ознакомления, потом — чтобы погрузиться глубже. У меня так и было. В свое время я дочитал последнюю страницу и открыл книгу заново. Потом уже более детально останавливался на конкретных разделах, искал дополнительную информацию в инете, что-то пробовал на практике.
В книге разобраны основные понятия в тестировании, подробно описана роль тестировщика — чем занимается специалист, какую пользу приносит бизнесу. И конечно, даны виды тестирования: функциональное, регрессионное, нагрузочное. Про ручное и автоматизированное тестирование тоже все есть.
Еще мне понравилось, что тут много практических советов по организации тестирования, написанию тест-кейсов, баг-трекингу и взаимодействию с разработчиками. Язык доступный, читается легко.
Обратите внимание: техническая часть писалась почти 20 лет назад, но актуальна по сей день.
«Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений». Автор: Сэм Канер
Это уже более сложная и даже научная вещь. Книга была опубликована в 1988 году и считается одной из классических работ по тестированию ПО. На сегодняшний день ее ценность не утрачена. В ней подробно описано, как проходит тестирование в реальных условиях разработки, как его организовать, какие виды тестов бывают, как документировать баги. Книга планомерно и последовательно вдалбливает в голову фундаментальные знания о тестировании.
Чем книга особенно хороша? В ней сделан упор на практический опыт в крупных компаниях, детально разобрано, как решать проблемы в сложных системах. Есть и управленческие моменты: можно не только разобраться с тестированием, но и увидеть, как оно встроено во все процессы в разработке.
Читается нелегко. Браться за нее лучше после того, как усвоилась инфа из первой книги. По сути, вопросы, которые есть в библии тестировщика, тут раскрываются глубже.
Про две обещанные книги рассказал. А теперь — бонус!
«Постигая Agile. Ценности, принципы, методологии». Авторы: Эндрю Стеллман, Дженнифер Грин
Всем новичкам в тестировании я бы рекомендовал внимательно изучить любую книгу по Agile. Прежде чем влиться в тестирование, важно понять, по каким принципам вообще строится работа команд, какого темпа ожидать, как работает проект изнутри. Это существенно отличается от организации работы, к которой привыкли за пределами ИТ.
Например, неплохая книга «Постигая Agile». Авторы подробно рассказывают о четырех Agile-методологиях: Scrum, экстремальном программировании (XP), бережливом программировании (Lean) и Канбане. Она хорошо структурирована и в целом дает понять, что для Agile нужна не только техническая база, но и разделение командой философии подхода. Это как раз поможет новичкам понять, к чему быть готовым, и перестроить привычное мышление. А еще — чтобы на собеседовании говорить на одном языке с тем, кто тебя собеседует.
Миссия — пройти собеседование на джуна: что нужно знать
Если человек владеет базой, описанной в книгах выше, у меня он пройдет собеседование. Хотя многие мои коллеги сейчас говорят, что этой информации уже недостаточно и требования стали выше. Тут я готов поспорить: если мы говорим о джунах, какие дополнительные навыки от них требовать? Их главная задача — наложить базу на рабочий опыт, так они и будут расти.
Роман Савин в «Тестировании dot com» дает основы: что такое баг, баг-репорт, тест-кейс, чек-лист, для чего все это нужно. Как раз об этом я обязательно спрашиваю на собеседовании. А еще:
что такое тестирование;
какие атрибуты бага необходимы;
как должен быть выстроен тест-кейс;
какие есть атрибуты тест-кейса.
Что касается багов — нужно знать такие понятия, как айдишник, приоритет, severity. Название, которое отвечает на вопросы: что, где, когда? Краткое описание. Шаги для воспроизведения. Ожидаемый результат, фактический результат. Еще инстанс, на котором это воспроизведено, релиз, версия ПО и так далее. Дальше обязательно нужно понимать техники тест-дизайна.
Потом классы эквивалентности, граничные значения. Pairwise testing — необязательный пункт, но если ты его знаешь, на собеседовании это будет плюсом. В жизни мало кто им пользуется.
Обязательно понимание всех атрибутов баг-репорта. Обычно я спрашиваю, чем отличается тест-кейс от чек-листа. С 99%-ной вероятностью попрошу привести два примера: баг с высоким приоритетом и низким severity, и наоборот — с низким приоритетом и высоким severity.
Еще даю какую-нибудь задачку, прошу потестировать. Возможно, я попрошу протестировать шариковую ручку и объяснить, что это за вид тестирования. Будет интересно посмотреть, какой кейс человек придумает и как это соотносится с теорией.
Как-то раз мне самому на собеседовании задали хороший вопрос, и я его запомнил: «У нас пять минут до релиза, произошли изменения на формах для ввода — логин, пароль, кнопка „Отправить“. Как человек будет это тестировать?»
Что нужно знать о команде разработки
Для собеседования джуну QA важно понимать, что ИТ-команда работает над проектом по определенным этапам и правилам. Есть продуктовая команда, включающая разработчиков, тестировщиков, менеджеров проекта и специалистов по дизайну. В хорошей компании будет Agile, но в современной разработке его часто нет. В таких конторах можно набраться опыта через боль и слезы, но потом лучше поискать место получше, где работа разбивается на спринты — короткие циклы с конкретными задачами.
В каждом спринте команда планирует, выполняет задачи и устраняет ошибки. Тестировщики работают параллельно с разработчиками, проверяя качество и исправляя баги. Регулярные совещания (стендапы) позволяют синхронизировать работу и быстро решать проблемы. Поэтому понимание Agile и жизненного цикла разработки помогает новичку быстро адаптироваться, понять свою роль и эффективно взаимодействовать с командой.
Еще важно знать, что в команде есть product owner, который хочет получить какую-то ценность (value) от своих идей. Он собирает статистику, маркетологи работают, анализируют, что нужно пользователю, чтобы заработать деньги. Или, может, цель — захватить рынок каким-то бесплатным опенсорсом, получить выгоду, которая нужна.
Product owner руководит собственной командой. Он назначает project-менеджера, который управляет процессом. В команду входят аналитики, они придумывают какие-то фичи, расписывают их.
Аналитики пишут acceptance criteria, definition of done, definition of ready, придумывают концепцию. Далее приходит команда: у нее есть лид, разработчики, тестировщики. Возможно, еще DevOps.
Если работаем со Scrum (а это, на мой взгляд, самая удобная система, которая подходит для большинства проектов) — получаем какой-то пул фичей в бэклоге. Мы эти фичи смотрим, читаем, анализируем и говорим, что собираемся сделать. Итоговый список в планах начинаем декомпозировать на какие-то задачи поменьше.
У тестировщиков бывают задачки на кейс, задачи на самотестирование, еще бывают задачи на автотест. Оцениваем, сколько будем писать тест-кейс, как понимаем конкретную фичу, что видим в ТЗ. Применяя какие-то техники тест-дизайна, разрабатываем инструкцию, по которой будем это тестировать. После того как напишем инструкцию, а разработчики закончат код, можем приступать к самому тестированию. И так по каждой задаче, которая у нас есть в спринте. Весь этот процесс происходит в каждой команде по-своему, участники команды постоянно друг с другом взаимодействуют, дейлики проходят каждый день. Мы делимся прогрессом, чтобы понимать, что придем в одну точку в одно и то же время и что вообще укладываемся в спринт.
Хорошо, когда джун понимает, зачем нужны все скрам-церемонии, которые происходят: рефайнменты с бизнесом, груминги, ревью. Что это в том числе время, когда он может задать накопившиеся вопросы и что-то решить.
Важно ли образование для входа в QA
Вспомнился случай. В далеком 2015 году, когда я получал второе высшее, как-то на паре нам показывали презентацию по новой теме. Она была очень компактной, а сразу после преподаватель сказал: «А теперь вот вам задание — решайте!» Я говорю: «Подождите, а конспект и это вот все мы писать не будем?» В ответ: «Не-не-не, мы вам показали, какие есть возможности, а дальше уже сами разбирайтесь, как все работает».
Когда я получал первое высшее за 15 лет до описанного случая, любую, даже самую простую тему мы записывали под диктовку. Да, в этом есть свои плюсы и минусы. Но книга Сэма Канера — она как тот самый базис: душная, но в хорошем смысле.
А написал я это вот к чму. У человека, который приходит ко мне в команду, может быть самое разное образование. Иногда я вообще на это не смотрю — сам менял карьерный трек уже в зрелом возрасте. Если кандидат прошел онлайн-курсы, прочитал вот эти 2–3 книги, о которых писал выше, хотя бы немного отработал базу на практике и понимает, как все устроено, этого при наличии мотивации вполне может быть достаточно. То есть оканчивать математический или ФКН необязательно. А вот без желания учиться и вникать в процессы не получится ничего.