Из тестирования в техподдержку и обратно
В тестирование попала впервые пару лет назад — это была маленькая аутсорсинговая компания, в которую меня позвал их HR, увидев моё резюме в телеграмме. К сожалению, через пару месяцев в компании начались проблемы и бОльшую часть сотрудников уволили или отправили в «отпуск», поэтому пришлось снова выходить на рынок и искать новую работу по факту не только практически не получив опыта (большинство компаний рассматривает людей с опытом от полугода), но и несколько ухудшив своё резюме подобным перескоком.
Пока искала работу знакомая QA Lead порекомендовала попробовать себя в сопровождении, сказала, что это будет полезно для развитии в тестировании. Стоит признаться, что изначально приняла это предложение скептически, но за неимением вариантов получше решила попробовать. Ниже, чтобы вы поняли, чем я занималась и поняли, насколько это будет вам полезно, распишу чем занималась и что мне это дало, а также какие препятствия мне встретились на этом пути.
Из поддержки в тестирование
Что было полезного для карьеры будущего тестировщика из обязанностей, который выполняла во время работы в поддержке:
Обрабатывала запросы пользователей — надо было понять, что беспокоит пользователя и, по ситуации, отправить на вторую-третью линию или помочь самой;
Если нашелся баг (самостоятельно или по обращению пользователя) — необходимо завести его на одну из команд разработки — описать шаги, прикрепить логи и скриншоты — чем понятнее заведешь баг, тем меньше вероятности, что к тебе придут с вопросами и тем меньше ты потом потеряешь времени (и тут бонусом потренироваться в одной из функциональных обязанностей тестировщика);
Приемо-сдаточные испытания до и перед установкой на ПРОМ — необходимо было провести смоук + проверить исправленные дефекты и введенные фичи;
Изредка присоединялась к тестировщикам — ревьюила тест-кейсы и/или проверяла задачи.
В результате выполнения данных обязанностей я подкачала или приобрела следующий набор навыков:
Навык работы с логами — для локализации дефекта необходимо было работать с OpenShift и проанализировать ситуацию в одном или нескольких сервисах;
Много работала с RestAPI — ещё один способ локализации дефекта + хороший способ ускорить массовые операции;
Работа с базой данных — ещё один инструмент для локализации дефекта + возможность сделать выборку для массовой операции и/или статистики для руководства, которую иногда просили сделать;
Видела продукт глазами пользователя — это скорее к софт скиллам. Со временем начинаешь понимать что важно для пользователя, а что нет. Думаю бОльшая часть тестировщиков прошла через этап, когда хотелось тестировать так глубоко, как получится и, в целом, это правильный подход. Но, к сожалению, довольно частая история, когда ресурсов на команду тестирования выделяется в разы меньше, чем нужно, и в этом случае важно понимать когда можно остановиться.
Не смотря на большое количество плюсов в работе техподдержки были и свои минусы:
Самое очевидное — высокий уровень стресса. Даже на продукте для внутреннего пользования, где пользователей мало и все в целом адекватные (кому охото портить отношения с коллегами) могут быть эпизоды, когда что-то поломалось и дергают тебя целый день, а ты дергаешь всех остальных.
Сначала пользователь, потом тестирование. Если задач нет, то, для развития можно самостоятельно покопаться в задаче, которая нравится, чтобы лучше её локализовать. Если есть ещё задачи, то у тебя есть в лучшем случае 10–15 минут на разбор, потом в том виде, насколько удалось её локализовать переносишь на более высокую линию поддержки.
Ненормированный рабочий день. Думаю, тут сильно зависит от компании, продукта и обязанностях команды сопровождения. У меня задержки были не так часто, но они возникали. Причиной этому мог быть инцидент или затянувшаяся установка нового релиза, который, как я писала выше, необходимо было проверить. Иногда задерживалась добровольно — чтобы помочь команде тестирования — эту категорию задержек считаю полезным вкладом в своё будущее.
Команды сопровождения бывают разными + они обычно делятся по линиям, где первая линия напрямую контактируют с пользователями, а третья — чинит возникшие дефекты. Кроме того в разных продуктах функциональные обязанности разных линий могут отличаться как и названия должностей.
Советы по поиску работы
Как написала чуть выше, названия должностей могут отличаться. Возможные названия — «Инженер по сопровождению», «Сотрудник технической поддержки», «сотрудник бизнес-поддержки». Любая из этих должностей может содержать нужную вам практику, поэтому стоит внимательно ознакомиться с обязанностями и желательными навыками.
В желаемых навыках может стоят навык работы с БД (знание SQL будет плюсом), умение работать с системами логирование, консолью разработчика и т.д. Всё, что похоже на инструменты тестировщика в явном виде указывают, что они вам пригодятся и в косвенном — на обязанности, которые вам предстоит выполнять.
По обязанностям сложнее, т.к. «Маршрутизация на 3ю линию» может подразумевать как просто переадресацию задачи, так и её локализацию с последующей передачей. Однако, если повезет, может и в явном виде стоять, что вам предстоит локализовывать дефекты, проводить ПСИ и т.д. — такие вакансии хватаем первыми.
Пара слов про собеседование
Как бы банально это не звучало, но уточняем обязанности и принимаем решение исходя из услышанного. Если в навыках есть указанные выше пункты, но в обязанностях в явном виде не прописано, что вы будете с этим делом — стоит уточнить. Например, в одних конторах вам нужно будет просто поднять логи и перекинуть тикет дальше, в других — оформить полноценный дефект. Если в конторе первый вариант можно уточнить поощряется ли оформление полноценных баг-репортов, если на это есть время и/или дефект оказывается несложным. Тут стоит учесть, что даже при утвердительном ответе времени может просто не быть=)) Т.е. вам предстоит или перерабатывать ради развития, или рисковать его полным отсутствием.
Не стоит лукавить. Если речь заходит о дальнейших планах (а она часто заходит), то о том, что вы хотите в тестирование сказать однозначно стоит. Да, это может стать причиной для отказа (карьерные треки как и их отсутствие в компаниях разные), но с другой стороны в случае найма есть немаленькая вероятность, что вас в будущем могут рассмотреть как возможного кандидата в команду тестирования (особенно, если повезет попасть на технически сложный продукт, в который нового человека придется ещё несколько месяцев погружать).
Заключение
Сейчас я уже почти год как в команде тестирования, перешла сюда спустя полгода после того, как оказалась в команде поддержки. Я всё ещё считаю, что попасть сразу в команду тестирования полезнее, чем идти через саппорт, но свои плюшки тут тоже есть:
ниже конкуренция;
ниже порог входа (особенно важно для самоучек и/или людей без опыта);
получение релевантного опыта для будущего перехода;
есть вероятность перехода внутри компании.
