Новички в профессии

Итак, предположим, Вы разобрались кто такой разработчик, дизайнер, аналитик, тестировщик и определили для себя, что ваш путь это QA. Теперь нужен план действий:

Поиск курсов.

Поиск школы, курсов, книг, видеоуроков и т.д.
Как не утонуть в море информации и предложений?

Поиск работы.

Обучение прошло, прочитано много дополнительной информации, на руках сертификат (помните, не важно сертификат, важно чему научились). Резюме составлено, приступаем к поиску работы:

2.1. Первое с чем сталкиваются новички, это опыт работы. Обычно в вакансиях указывают опыт работы для Junior от 6 мес до 1-го года, где его взять? В хорошей школе, практика проходит на реальных проектах или в коммерческих компаниях. И чем больше практики, тем больше уверенности в первую очередь у вас. И эту практику можно включить в резюме с полным описанием выполнения задач и результатов.

2.2. Требования в вакансиях зачастую больше, чем будет использовать специалист во время выполнения работы в первое время. Вас это не должно пугать, во первых вы должны много заниматься над самообучением и ориентироваться (как минимум) во всех дополнительных смежных с профессией знаниях, инструментах, программах. Это дает уверенность интервьюеру, что вы понимаете профессию в целом, сможете на одном языке разговаривать со всеми членами команды. Когда компания берет на работу Junior специалиста, она заранее готова вкладывать в вас деньги и время, ожидая, что вы будете расти и развиваться, тем самым быть хорошим специалистым и сильным членом команды в будущем.

2.3. Подготовка и прохождение собеседования. Для джуниора это 60-70% знания теории. При чем как “книжка пишет” четко, дословно, уверенно. Вы можете быть самым внимательным в поисках багов, или виртуозом написании техдокументации (тест планов, тест кейсов, баг репортов). Но что бы пройти собеседование, придется потрудиться и изучить теоретическую часть, хорошо выполнить практическое техзадание.

Выводы: теория нужна и важна, применение на практике архиважно.

Испытательный срок.

В этой главе, хочу остановиться более подробнее. Потому что исходя из вопросов здесь, вы будете знать, где делать акцент при обучении.
Уверена, вы уже имеете представление о работе тестировщика — увлекательная, креативная и динамичная работа. Но она может быть и монотонной, требующая усидчивости и внимания.

Проблемы на старте в любой компании я бы выделила на три категории: престижность профессии, адаптация в коллективе, технические ошибки.

3.1. Престижность.

Вам может показаться, что профессия тестировщик не такая сложная как разработчика. Разработчик знает языки программирования, выстраивает сложные логические связи и т.д. После его работы получают продукт. Тестировщику остается всего лишь проверить как работает ПО. Но тестирование и разработка — это взаимосвязанные процессы. Связь не только с разработкой, а ответственность за весь продукт от стадии идеи, планирования, реализации и до выпуска. И поверьте, это большой груз ответственности за размер бюджета, сроки выпуска и взаимодействие всей команды на всех уровнях.

Конечно, командой руководит менеджер, ошибки в коде допускают разработчики, плохие требования пишут аналитики, но крайней точкой ответственности это отдел QA.

Тестирование (качественное тестирование) требует серьезной подготовки. Анализ требований, тест-дизайн, общение с командой и т.д. Это не просто взять и проверить. Очень часто на тестирование (во время спринта) выделено мало времени, а релизить нужно уже завтра и тут нужны все умения: технические, психологические, мотивационные, личные качества и навыки. Потому что ответственность никто не отменял, и продукт должен быть проверен. Вот почему тестировщика можно сравнить с “поводырем”, “ангелом хранителем” ПО и команды на всех жизненных этапах продукта.

Выводы: профессия тестировщика очень ответственна и важна, которая требует всесторонних навыков и умений.

3.2. Адаптация в коллективе

3.2.1. Общность IТ общества заключается в целях достижения поставленных задач, а корпоративная культура может отличаться совершенно разным образом. Право на существование имеют как путь строжайшего корпоративного порядка, так и в меру дозволенность. В любом случае нужно искать золотую середину и приспосабливаться к окружающим порядкам и правилам. По возможности вносить свои идеи и предложения.

3.2.2. Все члены команды могут находиться в разных часовых поясах и соответственно это очень влияет на совместные встречи и задачи, учитывая физиологическую активность человека в разное время суток.

3.3.3. Сотрудники компании в целом как и в отделе QA могут включать разные национальности, культуры, этнические группы. На практике это разные поведенческие особенности при взаимодействии с друг другом. Понимание таких деталей позволит учитывать нюансы при работе.

Выводы: найдите золотую середину в правилах и порядках. Узнайте из каких стран члены команды и где сейчас они находятся, чтобы учесть особенности и нюансы взаимодействия.

3.3. Технические ошибки

3.3.1. Зачастую Junior хочет сразу показать и доказать свой профессионализм и пытается найти сложные баги. И может быть там, где их нет. Но не нужно видеть угрозу в каждой строчке кода. Нужно хорошо все проверить и убедиться, что это баги, это не фича. Создание многих непроверенных баг репортов оборачивается потерей времени нескольких человек команды, что переворачивает намерение сделать хорошо работу против вас.

3.3.2. Перед тем как задавать часто и постоянно вопросы, ответы на которых вы не знаете, потратьте несколько минут на изучение, попробуйте найти ответ сами. И только потом обращайтесь с вопросом, если нет у вас ответа. Но и здесь должна быть мера, не замыкайтесь и спрашивайте. Потому что могут быть нюансы рабочих процессов в конкретной компании. Есть негласное правило 30 минут. Если вы не смогли решить проблему, то обязательно обратитесь за помощью.

3.3.3. Создание тест-кейсов одна из основных задач тестировщика. Главное помнить, что одним из условий качества ПО является его соответствие требованиям. Не нужно переписывать требования к ПО, описывать возможности уже готового ПО. Вовремя делать отметки о состоянии (прохождение/сбой), чтобы точно отслеживать выполнение тест-кейсов.

3.3.4. Некорректное оформление баг репортов (название, недостаточность или излишность шагов воспроизведения) опять же приводит к потере времени, позаботьтесь о своих коллегах.

3.3.5. Начинающий тестировщик часто концентрируется на задачах и после окончания рабочего дня. Это большая ошибка, так как падает эффективность, нарастает нервозность и усталость. Нужен отдых.

Выводы: не стоит бояться ошибок на старте своей карьеры. Важно не отсутствие ошибок в первые недели работы, а умение их принимать и исправлять, учиться на собственном опыте.

Но, чтобы получать опыт было проще, обратитесь к этим простым рекомендациям: