Как тестируют в google аудиокнига
Как тестируют в Google
Те, кто искали эту книгу – читают
Эта и ещё 2 книги за 299 ₽
В книге описано тестирование программных продуктов в Google: как устроены процессы, как организованы команды, какие техники используются, кто ответственен за качество. Принципы, на которых построено тестирование в Google, применимы в проектах и компаниях любого размера. Авторы книги сами работали над продуктами Google, создавая инструменты тестирования, настраивая процессы и занимаясь непосредственно тестированием. Книга рассчитана на профессионалов из индустрии разработки программного обеспечения: специалистов по тестированию, программистов, менеджеров.
Если пришел к середине проекта, то сделай эту середину золотой.
Если пришел к середине проекта, то сделай эту середину золотой.
Делайте всё правильно с самого начала, не создавайте себе лишних трудностей.
Делайте всё правильно с самого начала, не создавайте себе лишних трудностей.
Но смысл тестирования не в улучшении качества. Качество должно быть встроено в продукт по умолчанию, а не привинчено к нему позже, поэтому качество должен обеспечивать разработчик, и точка.
Но смысл тестирования не в улучшении качества. Качество должно быть встроено в продукт по умолчанию, а не привинчено к нему позже, поэтому качество должен обеспечивать разработчик, и точка.
Всё будет точно так же, только по-другому.
Всё будет точно так же, только по-другому.
Тест-план рождается первым, и первым же должен умереть.
Тест-план рождается первым, и первым же должен умереть.
Отзывы 5
Полезная и легко читаемая книга об автоматизированном тестировании в Google
В книге описано очень интересных технологий, в частности, описан BITE – встроенный в Chrome компонент помогающий сформировать обращение в bugtracking-систему.
Из не имеющей непосредственного к теме книги, но занятной информации, я бы отметил описание роли и места Индии (Хайдарабада) в успехе Google. Так же пикантным моментом, связанным с автором книги является факт его ухода из Google в 2012 году (вернулся в Microsoft) из-за конфликта с руководством по поводу Google+.
Я бы рекомендовал эту книгу как обязательную к прочтению всем, кто серьёзно озабочен проблемой обеспечения качества программного обеспечения. Лично меня эта книга вдохновила на автоматизацию тестирования ПО с использованием Python в нашей компании.
Книга «Как тестируют в Google» — бесплатная электронная версия
Привет, Хаброжители!
В книге описано тестирование программных продуктов в Google: как устроены процессы, как организованы команды, какие техники используются, кто ответственен за качество. Принципы, на которых построено тестирование в Google, применимы в проектах и компаниях любого размера. Авторы книги сами работали над продуктами Google, создавая инструменты тестирования, настраивая процессы и занимаясь непосредственно тестированием.
Книга рассчитана на профессионалов из индустрии разработки программного обеспечения: специалистов по тестированию, программистов, менеджеров.
Отрывок. Снижение рисков
Редко удается полностью устранить риски. Мы водим машину, хоть это и опасно, но ведь нужно добираться до работы? Вообще возможность несчастного случая не означает, что он обязательно произойдет, да и, скорее всего, ничего страшного не случится. Почему? Потому что своими действиями мы снижаем возможный риск. Например, не садимся за руль в нетрезвом состоянии и не водим в условиях недостаточной видимости. Таким образом мы снижаем риски.
В разработке программного продукта самое простое — избегать рискованных областей: чем меньше кода, тем меньше риск. Но кроме использования «топора и секиры», мы можем сделать еще много чего, чтобы снизить риски:
В некоторых проектах именно тестировщиков спрашивают о готовности продукта к выпуску. Хорошему тестировщику достаточно бросить взгляд на тепловую карту, чтобы определить, стоит еще подержать продукт в духовке или пора подавать его на стол. Если речь о запуске экспериментального Google Labs, то наличие красных зон риска не так существенно, если они не относятся к безопасности, конечно. А если это выпуск новой версии Gmail, тогда даже желтые зоны представляют серьезную опасность. Такая простая цветовая градация понятна всем, даже топ-менеджерам.
Опасения по поводу рисков со временем спадают, а большой объем успешно проведенного тестирования — это хороший признак того, что риски на приемлемом уровне. Здесь мы выигрываем от того, что связываем тест-кейсы с отдельными возможностями продукта, а затем и с атрибутами и компонентами в таблице рисков. Для этого дела идеально подходит «ACC — анализ», и вот почему мы создали этот инструмент именно таким.
Тест-план за десять минут по рецепту Джеймса Уиттакера
Любая задача в разработке ПО, которую можно решить за десять минут, считается простой или не заслуживающей внимания. Предположим, что мы верим в это, — тогда что мы можем сказать о планирования тестирования? Конечно же, то, что оно занимает более десяти минут. Когда я работал директором по тестированию в Google, я руководил несколькими командами, которые создавали огромное количество тест-планов. Ответы на вопрос о том, сколько времени займет его составление, могли быть такими: «завтра», «к концу недели» и лишь пару раз — «к концу дня» (если задача озвучивалась рано утром). О’кей, примем к сведению, что составление тест-плана занимает некоторое количество часов, а то и дней.
Стоит ли такая работа усилий — это уже совсем другая история. Я вижу десятки тест-планов, которые пишут мои команды, и каждый раз это мертворожденные документы — они создаются, рецензируются, обновляются один или два раза (если повезет), а потом уверенно откладываются в долгий ящик, как только проект начинает идти не так, как это было предусмотрено. Возникает вопрос: если план не стоит того, чтобы его обновлять, стоило ли
его создавать?
Иногда тест-план нежизнеспособен потому, что содержит слишком много или, наоборот, слишком мало подробностей. Или он способствовал началу работы, а вот процессу — уже нет. И снова вопрос знатокам: стоило ли создавать документ с ограниченной или постоянно уменьшающейся ценностью?
Некоторые тест-планы содержат настолько очевидную информацию, что ее и документировать-то не стоило. Мы просто зря тратим время. Давайте посмотрим правде в глаза: у нас проблема с тест-планами.
Чтобы справиться с этим, я придумал для своей команды простое задание: написать тест-план за десять минут. Если уж он и имеет какую-то ценность, то давайте доберемся до нее как можно скорее.
Когда у вас есть всего десять минут для решения задачи, каждая секунда становится значимой. В этом моя основная идея: ограничение во времени заставляет отсекать при планировании всю шелуху и концентрироваться только на важных моментах. Делайте только то, что абсолютно необходимо, оставьте подробности исполнителям тестов. Я хотел покончить с порочной
практикой написания нежизнеспособных тест-планов, и это упражнение показалось мне верным.
Однако я ничего этого я не говорил участникам эксперимента. Я просто сказал: «Вот приложение, составьте тест-план не более чем за десять минут». Имейте в виду, что эти люди получали зарплату за то, что они выполняли мои задачи. И все же я предполагал, что они испытывали ко мне определенное уважение, а следовательно, знали, что я не поручу им невыполнимую задачу.
Они могли потратить некоторое время на знакомство с приложением, но, так как речь шла о приложениях, которые они используют каждую неделю (Google Docs, App Engine, Talk Video и т. д.), я дал им совсем немного времени на это.
Во всех случаях команды изобретали методы, схожие с методами ACC-анализа. Они оформляли решения в форме таблиц и списков, не используя большие объемы текста. То есть предложениям — да, абзацам текста — нет. Они не тратили время на форматирование текста, не вдавались в излишние объяснения. У всех тест-планов было одно общее — команды документировали возможности. Они признали, что это было лучшим решением, куда потратить весьма ограниченное время.
О’кей, ни одна команда не завершила тест-план вовремя. Тем не менее они успели за десять минут пройтись по атрибутам и компонентам и начали вычленять возможности исследуемого продукта. К концу дополнительных двадцати минут большинство моих подопытных записали довольно большой набор возможностей, который мог бы служить отличной отправной точкой
при создании тест-кейсов и пользовательских историй.
Мне кажется, что эксперимент удался. Я выделил им десять минут, хотя ориентировался на час. В итоге за полчаса было выполнено 80% работы. Разве этого недостаточно? Мы точно знаем, что не будем тестировать все, ну и зачем нам все документировать? Мы отлично знаем, что в ходе тестирования многие вещи (графики, требования, архитектура) будут изменяться. Настаивать на скрупулезной точности планирования, когда завершенность вовсе не требуется, не имеет смысла.
Восемьдесят процентов работы выполнено за тридцать минут или даже меньше. Вот это я называю десятиминутным тест-планом!
Напоследок о рисках
Google Test Analytics берет за основу описанные выше критерии оценки рисков («очень редко», «редко», «иногда», «часто»). Мы специально не хотим превращать анализ рисков в сложную задачу, иначе она не будет выполнена. Нас не интересуют точные математические подробности, потому что цифры мало что значат. Достаточно знать, что «А» рискованнее «Б», не обращая внимания на точное значение рисков. Простое знание, какая возможность рискованнее другой, позволит тест-менеджеру более эффективно распределять работу тестировщиков. А такие люди, как Патрик Коупленд, смогут легко решать, сколько тестировщиков нужно назначить в каждую команду разработки. Понимание рисков приносит пользу на уровне всей компании.
Анализ рисков — это самостоятельная научная область, уважаемая во многих отраслях. Мы используем упрощенную версию методологии, но это не мешает нам интересоваться новыми исследованиями, чтобы улучшить свой подход к тестированию. Если вы хотите узнать больше об анализе рисков, то начните со статьи «Управление рисками» в Википедии.
GTA помогает обозначить риски, а тестирование помогает их снизить. Тестировщик служит посредником в этом процессе. Он может выполнить внутренние тесты по некоторым наиболее рискованным направлениям или поставить задачу разработчикам и разработчикам в тестировании, чтобы они добавили регрессионные тесты. В его арсенале есть и другие инструменты: исследовательское тестирование, привлечение внутренних и бета-пользователей и силы внешнего сообщества.
В ответственности тестировщика знать все подверженные рискам области. Он должен стараться снизить риски любыми способами, которые ему подвластны. Вот несколько рекомендаций, которые мы считаем полезными в борьбе с рисками.
Пользовательские сценарии
Пользовательские истории описывают реальные или смоделированные способы, которыми пользователи используют приложение. Они описывают, чего хотят пользователи, смотрят на продукт их глазами, не учитывая архитектуру приложения и детали реализации.
Истории могут быть связаны с возможностями, но лишь поверхностно, поскольку все-таки подчинены действиям пользователя. Пользователю что-то нужно, а история описывает, как он использует приложение, чтобы это получить. Истории намеренно описаны в общем виде, без конкретных шагов, без жестко заданных входных данных. Только то, что будет делать пользователь, и как это воспроизвести во время тестирования приложения.
Создавая пользовательскую историю, мы смотрим на продукт только через пользовательский интерфейс, мы не включаем в описание технические подробности. Тогда тестировщик будет каждый раз проходить этот путь по-разному, как и разные пользователи по-разному решают одну и ту же задачу в нашем приложении — вот в чем главная идея!
Главное в пользовательских историях — ценность продукта для пользователя. Это не тест-кейсы с их определенными вводными данными и ожидаемыми результатами. Хорошая практика — создавать отдельные учетные записи. Мы в Google часто создаем помногу тестовых учетных записей для пользователей, описанных в историях. Старые аккаунты могут быть полезны по-другому: при тестировании Google Documents мы выявили самые интересные баги как раз для старых учетных записей — при загрузке в новой версии документов, созданных в предыдущих версиях.
Мы стараемся, чтобы тестировщики, исполняя такие сценарии, менялись. Чем больше разных способов прохождения — тем лучше.
Мы не будем слишком придираться к возможностям с низкими рисками. Мы можем решить, что писать тест-кейсы для этих областей — слишком затратное занятие. Вместо этого мы можем ограничиться исследовательским тестированием или оставить на откуп краудсорс-тестированию. Чтобы управлять работой тестировщиков из внешнего сообщества, мы часто пользуемся концепцией туров — это высокоуровневые инструкции для исследовательского тестирования. Проще говоря, такой подход дает вашему запросу нужную конкретику. Например, попросив сообщество: «Проведите FedEx-тур для такого-то набора возможностей», — мы получим намного лучший результат, чем просто отдав приложение и понадеявшись на лучшее. Мы сразу определяем фичи, которые нужно протестировать, и даем инструкции, как это делать.
Краудсорсинг
Краудсорсинг— это новое явление в тестировании. Если тестировщиков не хватает, а их ресурсы ограничены, то краудсорс-тестирование спешит на помощь! Пользователей с разными наборами устройств и программных конфигураций намного больше, чем тестировщиков. О таком количестве тестовых окружений нам остается только мечтать. Наверняка ведь найдутся желающие помочь нам?
Представим, что есть группа опытных пользователей, которые разбираются в тестировании и согласились нам помочь за разумную плату. Все, что им нужно, — это доступ к среде, где они могут работать с приложением, и отлаженный механизм предоставления обратной связи и баг-репортов. Для таких проектов, как наш опенсорсный Chromium, тестирование при помощи большой группы людей подходит идеально. Однако для проектов, открытых только внутри компании, это более проблематично. Нужно отбирать тестировщиков, пользующихся особым доверием.
Еще одна ключевая ценность краудсорсинга (кроме множества конфигураций) — это более широкий взгляд на приложение. Вместо того чтобы один тестировщик имитировал действия тысячи пользователей, у нас есть тысяча пользователей, работающих как тестировщики. Есть ли лучший способ найти сценарии, приводящие приложение к сбою, чем сразу выдать эти сценарии пользователям и получить обратную связь? Разнообразие и масштаб — вот в чем ценность краудсорсинга.
Людей, желающих протестировать программный продукт, в избытке, и доступны они круглосуточно. Допустим, дано: топ-1000 сайтов, задача: протестировать их в последней версии Chrome, тогда решение: 1 тестировщик = 1000 итераций или 20 тестировщиков = 50 итераций. Математика на стороне краудсорсинга.
Главный недостаток тестирования сообществом в том, что им нужно время, чтобы разобраться с приложением и понять, с какой стороны лучше подойти к тестированию. Большая часть этого времени теряется впустую изза количества людей, но мы придумали, как с этим справляться. Для Chrome, например, мы написали туры, и внешние тестировщики следовали им при исследовательском тестировании и при выполнении пользовательских сценариев (примеры есть в приложении Б «Туры тестов для Chrome»). Туры сразу направляли тестировщиков к нужным частям приложения и давали необходимые инструкции. Фокус в том, чтобы сделать разные наборы туров и распределить их между участниками. Так мы избежали варианта «принеси то, не знаю что» и получили именно то, о чем просили.
Краудсорс-тестирование — это следующий этап развития стандартных каналов Google: канареечного канала, канала разработки, тестового канала и канала внутреннего продукта. Это наш способ привлечения ранних пользователей и людей, которым просто нравится искать баги и сообщать о них. Мы уже попробовали набирать тестировщиков внутри компании среди наших коллег, которые любят работать со свежим продуктом, подключать к командам людей из компаний поставщиков, пользоваться услугами коммерческих компаний краудсорсинга (например, uTest). Мы даже запустили программу поощрения лучших искателей багов.
Итак, сила ACC-анализа в том, что мы получаем список возможностей продукта, который можно упорядочить по риску и закрепить за разными исполнителями. Тестировщики, работающие над одним проектом, могут получить разные наборы возможностей для проверки. Внутренние пользователи, «двадцатипроцентные» участники, тестировщики-подрядчики, тестировщики из сообщества, разработчики, разработчики в тестировании — все получат свои списки возможностей, и, к радости тестировщика, важные области будут покрыты с меньшим перекрытием, чем если бы мы просто раздали приложение для тестирования всем желающим.
Работа тестировщика, в отличие от работы разработчика в тестировании, с впуском продукта не заканчивается.
Как получить работу тестировщика? Лайфхаки!
Всем привет! Меня зовут Илья. Мне 24 года и c начала 2021 года я работаю специалистом по тестированию в российской ИТ-компании ITFB Group, которая занимается разработкой и внедрением различных программных решений, в том числе ECM, CRM, BPM, IDM и еще много каких. Но сегодня я хочу поведать свою историю о том, как начать работать в ИТ и нужно ли это. Вероятно, вы уже видели подобные материалы на просторах рунета? Да, действительно есть много различных точек зрения. Я лишь предпринял попытку систематизировать те знания, навыки и факторы, которые действительно пригодились мне при трудоустройстве и в работе, а также предоставить ценные лайфхаки. Итак, поехали….
Для начала попробуем разобраться, почему люди приходят работать в тестирование:
• имеют техническое образование, хотят начать работать в сфере ИТ;
• хотят сменить текущее место работы или специальность, поскольку не нравится или просто ищут себя;
• хотят получать более высокий уровень заработной платы, чем сейчас.
Вариантов может быть много, этот список естественно неокончателен. Насчет «более высокого уровня зарплаты». Подумайте хорошенько. Взвесьте все за и против. Возможно, стоит остаться на текущей позиции, где вас может ждать более быстрый рост, ведь перейдя на новую специальность вы начнете «с нуля». Если вам не нравится текущая работа, быть может, проблема не в профессии, а именно в конкретной компании?
Должно ли быть техническое образование для того, чтобы работать в тестировании? Мой ответ – нет. Лично у меня 2 высших образования: экономическое и менеджмент. Безусловно, университетские знания помогают мне в работе. Например, я являюсь тестировщиком банковского ПО, а также есть желание развиваться по управленческому пути. Нужно ли вообще высшее образование? Для трудоустройства – необязательно, тем не менее, при прочих равных это является большим плюсом при приеме на работу. И для будущего карьерного роста оно может быть необходимо.
Я не знаю английский, меня примут? Да! Если вы планируете работать в русскоязычной компании, то документация и коммуникации с командой у вас, скорее всего, будут на русском языке. Тем не менее, вы не сможете работать в международных корпорациях и участвовать во внутренних проектах с иностранными заказчиками, поскольку в данном случае практически все ТЗ и требования с высокой вероятностью будут на английском. Заметим, что очень много материалов по тестированию выходит именно на английском языке. Их стоит читать (лучше всего в оригинале), чтобы развиваться и добиваться карьерного роста.
А что касается математики и русского языка? По поводу первого: ручным тестировщикам достаточно базовых знаний. Если есть стремление в развитии в автоматизацию тестирования, то необходимо будет изучать язык программирования и специальные программы – тут уже должны быть более продвинутые знания. По поводу второго: у вас должна быть грамотная устная и письменная речь, четкое выражение мысли на бумаге. Тестировщик много общается с аналитиками, разработчиками, заказчиками; составляет отчеты об ошибках, изучает документацию и находит в ней неточности, двойные толкования.
Итак, вы твердо решили стать тестировщиком. Перспективная профессия, по данным HeadHunter, прямо сейчас активно более 7000 вакансий в России.
Из них в каждой 10 позиции не требуется опыт работы:
Но не спешите сразу подавать заявки на все позиции, в надежде получить оффер. Спешу вас огорчить. Этого не произойдет, поскольку на рынке присутствует огромная конкуренция. На каждую из таких позиций могут откликаться десятки, если не сотни человек. Вам предстоит проделать большую работу, чтобы трудоустроиться. Быть может, опыт работы и не требуется (для меня самого это официальное трудоустройство было первым), все с чего-то начинали. Но на 99% позиций будут требоваться знания, демонстрацию которых вы проявите на тестовом задании и собеседовании. Мало компаний, которые хотят брать к себе человека без знаний вообще, особенно при наличии той самой конкуренции и вариантов. Безусловно, нормальные компании (те, которые заинтересованы в росте сотрудников) будут вести программу наставничества джуна, обучать его. Тем не менее, соискатель должен прекрасно ориентироваться в теории, понимать суть этапов тестирования в частности и процесса разработки продукта в целом, иметь начальные представления о работе вспомогательных инструментов. Но обо всем по порядку.
Настройтесь на то, что вам нужно будет время. Много времени. Подготовьте домашнее место для обучения и практики. Для того, чтобы получить те самые знания, а, быть может, и опыт, существует значительное число площадок и ресурсов. Рассмотрим основные из них.
Литература. Прекрасное начало, чтобы изучить теорию и принципы тестирования. Рекомендую следующие книги на русском языке:
• Р. Савин. Тестирование dot com
• Г. Майерс, Т. Баджетт, К. Сандлер. Искусство тестирования программ (3 издание)
• С. Куликов. Тестирование программного обеспечения. Базовый курс
• Дж. Уиттакер, Дж. Арбон, Дж. Каролло. Как тестируют в Google
Авторы многих материалов распространяют их в свободном доступе в виде электронных ресурсов. Я предпочитаю бумажный источник, но здесь как кому удобнее. Изучайте литературу, конспектируйте материал, заведите отдельную тетрадку под глоссарий и терминологию. Прочитав эти книги, вы получите базовые теоретические знания, однако их всё еще недостаточно для того, чтобы начать откликаться на вакансии.
Дополнительные источники. Читайте материалы на тематических ресурсах, подпишитесь на группы по запросам «Тестирование» и «QA» (Quality Assurance) ВКонтакте и Telegram, настройте отдельные новостные ленты и папки для оперативного отслеживания новостей. Выписывайте интересные мысли. Так вы сможете быстрее понять, как устроена сфера IT и какое место в нем занимает ступень тестирования.
Практика. Для того, чтобы понять хотя бы на любительском уровне, что такое тестирование, подключитесь к какой-либо из программ бета-тестирования. Многие крупные IT-компании практикуют подобное, некоторые из них даже премируют активных участников. Если вы хотите развиваться в мобильном тестировании и у вас Android, дополнительно приобретите iOS устройство (я рекомендую рассмотреть iPhone SE1 на вторичном рынке – устройство стоит в районе 5 000 рублей, до сих пор поддерживает актуальную iOS 15, которая еще долго будет актуальна для новых разработок). Если у вас iPhone, то приобретите любой недорогой Android-девайс, самое главное, чтобы у него была актуальная версия ПО. Изучайте приложения, если видите дефекты, попрактикуйтесь в составлении отчетов об ошибках. Подумайте, как бы мог выглядеть чек-лист или тест-кейс по какому-либо модулю в проверяемом приложении.
Образовательные центры. К сожалению, в российских вузах нет отдельной дисциплины «Тестирование ПО». Тем не менее, существует большое количество онлайн-площадок, обучающих по профессии тестировщика. Skillbox, GeekBrains, Нетология, Яндекс.Практикум (не реклама). Обучение платное, стоит денег. И длится обучение достаточно долго, учитывайте это. Прежде чем принять решение, идти или нет, пройдите на данных площадках бесплатные версии. Например, Skillbox и GeekBrains периодически проводят интенсивы и онлайн-вебинары по тестированию, также на данных площадках есть бесплатный курс – «Введение в программирование», а Яндекс.Практикум предоставляет первый модуль программы «Тестирование ПО» на 10 часов практики абсолютно бесплатно.
Таким образом, пройдя несколько пробных версий курсов, прочитав литературу, попробовав бета-тестирование, вы сможете понять, тестирование – ваше или нет. Каждый сам принимает решения, нужно ли идти на платное обучение. Если заниматься самоизучением, то можно потратить значительно больше времени, поскольку информация будет не структурирована и может быть неполной, а что еще хуже – некорректной.
В дополнение ко всем предыдущим пунктам хочу отметить то, что есть компании, которые проводят обучение (почти всегда бесплатно) стажеров для привлечения в штат. Так, например, в ITFB существует программа «Школа тестирования», где на протяжении месяца ученики проходят интенсивный курс по теории тестирования, основам SQL и интеграции систем с основным упором применения знаний на реальных проектах. Обучение проходит бесплатно и дистанционно, зачисление в школу происходит после прохождения тестового задания и собеседования. После выпускных экзаменов лучшим студентам предлагают работу в компании. Это замечательная возможность «войти в IT», не затрачивая финансовые ресурсы на платные дорогие курсы.
Конференции тестировщиков. Скорее всего, не могу порекомендовать эти мероприятия новичкам, поскольку входной билет на них стоит приличных денег за короткий промежуток времени, а информация на них довольно сложна для восприятия. Тем не менее, вы можете изучать открытые материалы с предыдущих форумов, которые размещены на YouTube.
Тестирование тестировщиков. Для трудоустройства на начальную позицию в российских компаниях сертификат ISTQB не требуется. Согласно порталу HeadHunter данный сертификат упоминается всего лишь в 70 вакансиях, большинство из которых или на английском языке или просто в тексте указано, что компания предоставит возможность прохождения экзаменов за ее счет. Стоит учитывать, что получения даже начальной степени ISTQB требует серьезных теоретических и практических знаний, а стоимость сдачи экзамена составляет от 150 €. Если вы планируете развиваться дальше в профессии, расти до старшего специалиста и далее, то, безусловно, данный сертификат будет востребован.
Итак, после того как вы получили теоретические знания и практические навыки работы с инструментами тестировщика, можно идти на карьерные порталы – HeadHunter, Хабр Работа и другие. Исторически сложилось, что, как правило, компания точно опубликует вакансию на HeadHunter. Поработайте над своим резюме. Указывайте только правдивую информацию об образовании, опыте работы, навыках. Актуальные контактные данные, фотография и дополнительная релевантная информация также должны помогут вам достичь цели.
Кстати, анализ уже размещенных открытых резюме тоже полезен. Именно из них можно почерпнуть информацию, например, о ключевых навыках, которые вы могли просто забыть указать или посчитать малозначительными. Разумеется, их стоит также указывать и в своем резюме – при условии, что вы обладаете данными навыками. Если нет, то они вам послужат ориентиром того, что стоит подтянуть. К примеру, в большинстве резюме указан пункт SQL – значит это действительно важно на данной позиции.
Обращайте внимание не только на вакансии своего города / региона, а также на позиции, где предусмотрена удаленная работа (если это для вас возможно). Многие ИТ-компании и до пандемии предоставляли такую возможность, а в текущих условиях многие работают в подобном формате.
Теперь можно перейти к откликам на вакансии. Используйте поисковые фильтры, выбрав пункт: без опыта работы. Откликайтесь от новых вакансий к старым, составляйте индивидуальное Сопроводительное письмо для каждой компании, куда подаете заявку, в котором объясняете: почему решили выбрать тестирование, что ожидаете, что умеете, почему именно вас стоит трудоустроить.
Внимательно читайте описание вакансий. Не нужно откликаться на позиции, где явно указано, что, к примеру, компании требуется специалист с опытом работы от 3-х лет. Также не надо откликаться на те позиции, где в тексте указаны незнакомые вам инструменты, либо то, что конкретно вас может не интересовать (например, тестировщик игр). Вообще, я советую при откликах вести отдельный реестр в Excel. Так будет удобнее понять, кто согласен, от кого ждем ответа, а кто точно отказал. Также бывает, что одна компания размещает несколько однотипных вакансий в разные отделы. Ваш реестр позволит избежать дублирования подачи заявок.
Будьте готовы, что большинство компаний вам не ответит ничего – это нормально: когда подают десятки заявок на вакансию, то их нужно обработать, провести собеседования. А при подборе нужного кандидата, вероятно, другие заявки будут не рассмотрены. Сохраняйте спокойствие при отказах. В этом нет ничего страшного, а причины могут быть многочисленны – компания уже закрыла позицию внутренними ресурсами; нашелся другой кандидат, который успешно прошел собеседование; либо у вас просто в настоящий момент недостаточно знаний – продолжайте их укреплять.
Со всей серьезностью относитесь к тестовому заданию – это первичный этап отбора, после просмотра резюме. Если вы откликнулись на вакансию и находитесь в поиске работы, постарайтесь пройти данный этап как можно быстрее, помня, что помимо вас тестовое задание предлагают и другим кандидатам. Планируйте свое время на то, что вас будут приглашать на собеседования (обычно проходят онлайн, поэтому у вас должно быть доступно устройство с камерой, рабочий фон). Не волнуйтесь на собеседованиях, несмотря на удаленность, не пытайтесь обмануть работодателя. Внимательно слушайте вопросы, при наличии уточнений не бойтесь задавать их в ответ.
После собеседований компаниям нужно определенное время, чтобы принять решение. За этот промежуток вы можете анализировать вопросы, опять-таки вести определенного рода реестр, исследовать свои ответы, изучать пробелы. Всю базу вопросов не собрать, потому что спросить могут что угодно. Но из них примерно 75% одних и тех же вопросов присутствуют на всех стандартных собеседованиях. Если вы что-либо не смогли ответить на собеседовании, либо ответили неправильно – прекрасный повод ознакомится с учебными материалами на данную тему.
Маловероятно, что трудоустроиться получится сразу после первого собеседования (но если вы такой счастливчик, то снимаю шляпу). Не стоит откликаться на чрезмерно большое количество вакансий – вы не справитесь с большим количеством фидбека, прохождениями тестовых заданий и собеседований. Но и не нужно откликаться на малое число вакансий – тут риск неполучения ответов вообще, либо только отрицательные решения. Тут должна быть золотая середина, в зависимости от вашего времени и возможностей.
Что касается меня, до получения оффера я подавал заявки на 100 вакансий за 10 дней (примерно по 10 заявок в день, кроме выходных). На абсолютное большинство сообщений я не получил ответа до сих пор, соответственно не получу никогда. Многие из компаний отвечали отказом, шаблонной отпиской без объяснения причин. Прошел 10 тестовых заданий, некоторые из них автоматически открывались после отправки резюме, где-то их отправляли HR в ручном режиме. Всё это привело к 5 собеседованиям в видеорежиме. А как итог – оффер в виде предложения о работе! Стоит отметить, что я подавал заявки только после того, как обладал теоретическими знаниями и продолжительным практическим опытом, хоть и на любительском уровне. Некоторые из работодателей отвечали настолько медленно, что предложения о прохождении собеседования я получал еще на протяжении 3 месяцев после моего отклика (на тот момент я уже успешно прошел программу испытательного срока на текущем месте работы) – соответственно, подобные компании получали отказ уже с моей стороны.
Однако даже при трудоустройстве необходимо продолжать укреплять навыки, читать специализированную литературу и смотреть обучающие видео, а также писать статьи по тематике работы и быть наставником новых сотрудников. Разумеется, если вы заинтересованы в профессиональном и карьерном росте.
Желаю всем успешного поиска работы и офферов с привлекательными условиями, а тем, кто уже нашел – интересных проектов и локализующихся багов! 🙂