Как войти в QA, и что делать если не получилось пройти собеседование с первого раза. Карьера тестировщика с точки зрения директора QA-отдела
“Когда я вошла в QA, много лет назад, мой путь был, в целом, примерно такой же, как у нынешних тестировщиков-новичков. У меня тогда было весьма слабое представление, что такое тестирование с практической точки зрения; мне (и семи другим кандидатам) сказали, что нужно: 1) уметь находить в коде все баги, 2) уметь писать внятные баг-репорты; 3) на все про все — один час. Я нашла абсолютно все баги (чем приятно удивила лида), создала баг-репорты и меня взяли! Я стала тестировщиком и получила первую работу.
Прошли годы, я получила больше опыта, и снова ходила на собеседования. На одном из собеседований интервьюер сказал, что ни один из кандидатов не умеет правильно применять классы эквивалентности и граничные значения. Я учила эти вещи в университете, а позже мне пришлось их изучить на практике — до автоматизма.
Если бы я “вошла в тестирование” сейчас, то мой “вход” был бы в чем-то похож на те времена, а что-то бы я делала по другому. Я поняла со временем, что кандидата сейчас “берут” не столько по знаниям, столько по тому, видят ли потенциал получать эти знания. Твой характер и отношение к работе, а, главное, способность быстро учиться — вот три вещи важные. В начале карьеры я вся была сосредоточена на поиске багов и этого тогда было более чем достаточно для продвижения вверх, а теперь средняя ИТ-компания почти наверняка проверяет тестировщиков-кандидатов на способность писать код и понимать код, для этого дается небольшой “квиз”. Наверное, в постковидном 2022 году тебя уже не посадят вместе с другими кандидатами на тестовое задание на час, а скорее всего отправят задание по мейлу, но от этого не легче — там будет задание на дизайн теста, или на автоматизацию, или оба варианта сразу; а также, возможно, дадут задание сугубо на программирование.
Что делать? Мой совет таков, в двух вариантах.
- Хороший. После того как успешно прошел на позицию (а это зависит только от тебя!) — постарайся удержаться здесь. Это лишь начало, не расслабляйся.
- Плохой. Случилась неприятность — ты не прошел, тебя не взяли. Нельзя отчаиваться — подтягивай теорию и практику, и иди на другие собеседования. В любом случае двигайся дальше.
Тебя взяли
Устроиться на первую работу в QA — это первый этап. Начались трудовые будни. Помни, что твоя карьера слишком важная вещь, чтобы предоставить ее менеджеру/лиду. В первые недели и месяцы тебе будут помогать, тянуть, но это не повод расслабляться и полагаться на “старших”. Сотрудники будут помогать учиться и решать твои проблемы, но далеко не все сотрудники имеют терпение, да и компетентность, в обучении тестировщиков-новичков.
Вот, собственно, мои советы, на первое время, если тебя все-таки взяли.
Сосредоточься на продукте, изучи его, знай его функции. Вложи свое личное время, чтобы хорошо изучить приложение. Конечно, придется читать документацию. Читай документацию, когда пишешь тесты. Старайся понять, как функция должна работать, и смотри, как она работает. Основа твоей работы — практический опыт. Прокачивай его. Не жалей личное время на скорейшее получение практического опыта — оно окупится.
Изучи интерфейс, API, в общем все функции в приложении. Спрашивай себя, почему эта функция здесь, и когда не знаешь, спрашивай старших. Ты станешь экспертом по продукту, тестируя его, а не слепо выполняя запросы других.
Делай заметки. Делай заметки из того важного что ты понял, отмечай их тегами и группируй их. Собирай непонятные моменты, и находи ответы. Задавай вопросы коллегам, начинай обсуждения. Возможно присвой приоритеты некоторым вопросам, и попытайся найти ответы в документации, прежде чем спрашивать коллег. Расшаривай свои заметки.
Активное исследование. Пользуйся тестируемым софтом сам, и многое поймешь. Бери старую версию и сравнивай ее с новой, ищи новые баги. Отслеживай нестыковки, умей видеть главное — так вырабатывается критическое мышление.
Учитывай масштаб. Что есть сейчас? Что меняется в новой версии? Отслеживай изменения кода в трекере. Не обязательно делать это очень часто (это важнее для разработчиков), читай главное — что поменяли разработчики в коде. Все, что только что перестало работать, или добавлено — это ценная информация для разработчиков и владельцев продукта.
Приоритеты багов. Оцени, какая информация сейчас важна. Самая ценная информация по багам превращается в действия — багфикс. Вероятность, что люди будут фиксить, зависит от 3 вещей — от срока обнаружения (от ранних до поздних), от влияния на пользователя, и от количества уже найденных багов. Если ты сможешь показать баг, который важен для команды сейчас, он будет устранен сейчас. Есть проекты, на которых успевают сделать все и сразу, но таких проектов мало.
Когда делаешь репорт, расскажи о новых функциях и багах в них, и желательно составь об этом бумажный отчет (если у вас в компании так принято). Даже если не сейчас ничего не сделают, тебе важно показать, что ты старался.
Составляй словарь терминов. Записывать все новое — это хорошая привычка, поэтому имей под рукой бумагу и ручку, или просто добавляй себе электронные заметки. Услышал незнакомое слово — запиши его, загугли, изучи что это, или спроси. Ты изучаешь новую сферу, ты сам отвечаешь за свой прогресс; возможно тебе будут помогать, а возможно и не очень. Применяй технику запоминания незнакомых слов/понятий по интервалам (мемоизация, интервальное повторение).
Пиши код. Изучай языки программирования, пользуясь функциями тестируемого приложения и документируя их. Если часто приходится листать логи, возможно стОит закодить для себя простую функцию поиска нужного объекта в логах. Если у вас стандартный flow, попытайся его автоматизировать. Скооперируйся с сотрудниками, чтобы сэкономить время, или поищи туториалы для нубов, и применяй то что там написано. Умение программировать приходит с опытом. Сопротивляйся искушению не учить программирование! Упорство в изучении языков программирования потом окупится.
Инвестируй в свои навыки и умения. Языки программирования крайне важны, но этого мало. Воспитывай в себе привычку постоянно учиться. Читай пособия и применяй прочитанное на практике. Подпишись на блоги, на твиттеры авторитетных тестировщиков, на новостные рассылки, стань участником комьюнити.
Приспосабливайся. Ты начинаешь карьеру с простейшего: проверка функций, поиск багов. Когда-нибудь придет время подняться на уровень выше — научиться определять причины багов и доступно описывать их. Хороший способ развивать в себе исследовательские навыки — это “исследовательский подход” к софту. “А что, если?”. Например, меняй значения в произвольных переменных и смотри, что происходит после этого.
Фиксируй свои достижения хотя бы первые 6 месяцев. Что я выучил? Где продвинулся? Какие практические задачи решил? Чем помог сотрудникам? Какую документацию написал?
Пройдет пару месяцев, и появится опыт. Ты выберешь себе QA-специализацию. Начнешь отходить от рутины. Даже появится время на волонтерские проекты.
Тебя не взяли
Я начала пост с описания, что делать, когда взяли на первую работу. Что делать, когда не удалось?
Можно начать делать примерно то же, что описано выше, не имея работы. Создай портфолио из выполненных, не принятых, а затем исправленных тобой “пробных” заданий. Возможно некое условное “портфолио” из своих заметок. Дизайны тестов. Автоматизацию. Приведи это все в порядок, и сделай удобочитаемым.
Когда видишь код, пробуй писать тесты для него. Делай заметки к автотестам. Когда пишешь код, создавай методы, пиши комментарии для важных моментов, и тестируй некорректные вводы.
Если есть время на самостоятельные занятия по вечерам, сохраняй результаты, лучшие решения отправляя в портфолио.
Каков бы ни был твой уровень, надо пробовать где-то стажироваться, или за деньги, или просто за опыт. Первое доступно, например, в краудфандинговых проектах. Второе — в опенсорсных проектах.
Рассылай резюме, и иди на собеседование, каковы бы ни были шансы. Попытаться независимо от шансов на успех — лучше, чем не пытаться, и точно не иметь успеха. Построй себе “социальную сеть” из бывших коллег или просто знакомых в ИТ, и продолжай “искать нужную дверь”, и ты найдешь ее. Стучи во все двери. В QA нужны умные, настойчивые люди.”
***
