Home

Оригинальная публикация

В тестирование попала впервые пару лет назад - это была маленькая аутсорсинговая компания, в которую меня позвал их HR, увидев моё резюме в телеграмме. К сожалению, через пару месяцев в компании начались проблемы и бОльшую часть сотрудников уволили или отправили в “отпуск”, поэтому пришлось снова выходить на рынок и искать новую работу по факту не только практически не получив опыта (большинство компаний рассматривает людей с опытом от полугода), но и несколько ухудшив своё резюме подобным перескоком.

Пока искала работу знакомая QA Lead порекомендовала попробовать себя в сопровождении, сказала, что это будет полезно для развитии в тестировании. Стоит признаться, что изначально приняла это предложение скептически, но за неимением вариантов получше решила попробовать. Ниже, чтобы вы поняли, чем я занималась и поняли, насколько это будет вам полезно, распишу чем занималась и что мне это дало, а также какие препятствия мне встретились на этом пути.

Что было полезного для карьеры будущего тестировщика из обязанностей, который выполняла во время работы в поддержке:

1. Обрабатывала запросы пользователей - надо было понять, что беспокоит пользователя и, по ситуации, отправить на вторую-третью линию или помочь самой;

2. Если нашелся баг (самостоятельно или по обращению пользователя) - необходимо завести его на одну из команд разработки - описать шаги, прикрепить логи и скриншоты - чем понятнее заведешь баг, тем меньше вероятности, что к тебе придут с вопросами и тем меньше ты потом потеряешь времени (и тут бонусом потренироваться в одной из функциональных обязанностей тестировщика);

3. Приемо-сдаточные испытания до и перед установкой на ПРОМ - необходимо было провести смоук + проверить исправленные дефекты и введенные фичи;

4. Изредка присоединялась к тестировщикам - ревьюила тест-кейсы и/или проверяла задачи.

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

1. Навык работы с логами - для локализации дефекта необходимо было работать с OpenShift и проанализировать ситуацию в одном или нескольких сервисах;

2. Много работала с RestAPI - ещё один способ локализации дефекта + хороший способ ускорить массовые операции;

3. Работа с базой данных - ещё один инструмент для локализации дефекта + возможность сделать выборку для массовой операции и/или статистики для руководства, которую иногда просили сделать;

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

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

1. Самое очевидное - высокий уровень стресса. Даже на продукте для внутреннего пользования, где пользователей мало и все в целом адекватные (кому охота портить отношения с коллегами) могут быть эпизоды, когда что-то поломалось и дергают тебя целый день, а ты дергаешь всех остальных.

2. Сначала пользователь, потом тестирование. Если задач нет, то, для развития можно  самостоятельно покопаться в задаче, которая нравится, чтобы лучше её локализовать. Если есть ещё задачи, то у тебя есть в лучшем случае 10-15 минут на разбор, потом в том виде, насколько удалось её локализовать переносишь на более высокую линию поддержки.

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

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

Советы по поиску работы

1. Как написала чуть выше, названия должностей могут отличаться. Возможные названия - “Инженер по сопровождению”, “Сотрудник технической поддержки”, “сотрудник бизнес-поддержки”. Любая из этих должностей может содержать нужную вам практику, поэтому стоит внимательно ознакомиться с обязанностями и желательными навыками.

2. В желаемых навыках может стоят навык работы с БД (знание SQL будет плюсом), умение работать с системами логирование, консолью разработчика и т.д. Всё, что похоже на инструменты тестировщика в явном виде указывают, что они вам пригодятся и в косвенном - на обязанности, которые вам предстоит выполнять.

3. По обязанностям сложнее, т.к. “Маршрутизация на 3ю линию” может подразумевать как просто переадресацию задачи, так и её локализацию с последующей передачей. Однако, если повезет, может и в явном виде стоять, что вам предстоит локализовывать дефекты, проводить ПСИ и т.д. - такие вакансии хватаем первыми.

Пара слов про собеседование

1. Как бы банально это не звучало, но уточняем обязанности и принимаем решение исходя из услышанного. Если в навыках есть указанные выше пункты, но в обязанностях в явном виде не прописано, что вы будете с этим делом - стоит уточнить. Например, в одних конторах вам нужно будет просто поднять логи и перекинуть тикет дальше, в других - оформить полноценный дефект. Если в конторе первый вариант можно уточнить поощряется ли оформление полноценных баг-репортов, если на это есть время и/или дефект оказывается несложным. Тут стоит учесть, что даже при утвердительном ответе времени может просто не быть=)) Т.е. вам предстоит или перерабатывать ради развития, или рисковать его полным отсутствием.

2. Не стоит лукавить. Если речь заходит о дальнейших планах (а она часто заходит), то о том, что вы хотите в тестирование сказать однозначно стоит. Да, это может стать причиной для отказа (карьерные треки как и их отсутствие в компаниях разные), но с другой стороны в случае найма есть немаленькая вероятность, что вас в будущем могут рассмотреть как возможного кандидата в команду тестирования (особенно, если повезет попасть на технически сложный продукт, в который нового человека придется ещё несколько месяцев погружать).

Заключение

Сейчас я уже почти год как в команде тестирования, перешла сюда спустя полгода после того, как оказалась в команде поддержки. Я всё ещё считаю, что попасть сразу в команду тестирования полезнее, чем идти через саппорт, но свои плюшки тут тоже есть:

• ниже конкуренция;

• ниже порог входа (особенно важно для самоучек и/или людей без опыта);

• получение релевантного опыта для будущего перехода;

• есть вероятность перехода внутри компании.