|
Professor Seleznov
|
Привет! Меня зовут Семён. Ещё недавно я отвечал на вопросы пользователей в службе поддержки ЮMoney, а сегодня — ищу баги в том же продукте, но уже как тестировщик. Да, я остался в команде, просто теперь смотрю на сервис с другой стороны.
Этот переход не случился за один день и точно не был спонтанным решением. Скорее, сама работа в поддержке постепенно подталкивала меня в эту сторону — и в какой-то момент я понял, что готов сделать следующий шаг.
Хочу рассказать, как меняется мышление, когда переходишь из поддержки в QA, с какими страхами приходится столкнуться и что реально помогает на этом пути.
Статья будет полезна, если вы:
- уже работаете в IT, но подумываете сменить направление;
- трудитесь в поддержке и чувствуете, что переросли текущую роль;
- только присматриваетесь к тестированию и хотите понять, с чего начать.
Как меняется мышление
Работая в поддержке, в основном реагируешь на уже случившиеся проблемы: пользователь пришёл — значит, что-то сломалось. В тестировании всё иначе.
Теперь моя задача — не просто найти баг, а заранее прокрутить в голове: «А что здесь может пойти не так?». Причём на реальных сценариях: оплаты, переводы, работа кошелька. Со временем это становится автоматическим. Любой сценарий начинаешь воспринимать как набор потенциальных точек риска:
- некорректный ввод данных пользователем;
- вход с редкого устройства или нестандартного окружения;
- превышение лимитов в момент платежа;
- устаревшая версия приложения;
- обрыв сети во время операции;
- задержки при передаче данных между сервисами;
- множественные нажатия на кнопку оплаты.
И здесь важно не просто «сломается или нет», а что произойдёт с деньгами: спишутся ли они один раз, не зависнет ли платёж, сможет ли пользователь потом понять, что произошло. В платёжных сценариях это критично — система должна отработать корректно даже в неидеальных условиях.
Такой образ мышления меняет не только подход к работе, но и слегка — взгляд на жизнь: начинаешь невольно искать «баги» везде 🙂
Страхи перед переходом
Самый большой страх — классика жанра: синдром самозванца. Казалось, что я знаю недостаточно, не справлюсь с задачами, а все вокруг — умнее и опытнее.
И знаете что? Частично это правда — вокруг действительно много более опытных людей. Но оказалось, это вообще не проблема. Когда попадаешь в команду, быстро понимаешь: рядом такие же люди, просто они уже прошли тот путь, на который ты только ступил.
За всё время я ни разу не столкнулся с ситуацией, где мне отказали в помощи. Скорее наоборот — коллеги спокойно объясняют даже то, что им самим кажется очевидным.
Что помогло справиться
Стоит отдельно сказать о том, как в ЮMoney устроены внутренние переходы. Это не история в духе «сам решил — сам как-нибудь разберёшься». В процессе участвуют HR и команда: помогают сориентироваться, подсказывают по шагам и не оставляют один на один с неопределённостью.
Когда я прямо сказал, что хочу глубже разобраться в технической стороне продукта и попробовать себя в QA, реакция была поддерживающей. Не было ощущения, что это что-то нестандартное или нежелательное — скорее наоборот.
Отдельно отмечу, что внутренняя ротация здесь воспринимается как нормальная часть развития сотрудников. Все встречи и собеседования с будущей командой организовали быстро, без лишней бюрократии, — и это сильно снижает порог входа и внутреннее напряжение. В итоге чувствуешь, что компания действительно заинтересована в твоём росте.
Есть ещё несколько простых, но важных вещей:
- Нормально не понимать всё сразу. Это, пожалуй, самое главное открытие. Никто не рождается экспертом.
- Сначала пробуй разобраться сам— погугли, потыкай, поэкспериментируй.
- Но не залипай на сутки. Если застрял — лучше спросить того, кто работает с этим каждый день. Иногда пять минут чужого опыта экономят часы блуждания в темноте.
В какой-то момент замечаешь, что ориентируешься быстрее, решения приходят легче. А страх? Он постепенно растворяется.
Подготовка к собеседованию
К собеседованию я готовился по открытым материалам из интернета — статьям и видео. По общей теории тестирования очень помогла книга Романа Савина «Тестирование DOT COM».
Интересный момент: на собеседование меня пригласили в отдел тестирования мобильных приложений, хотя ранее я работал только с web-приложениями. Поэтому параллельно с теорией тестирования я изучал технические особенности мобильных операционных систем.
Вся подготовка заняла около четырёх месяцев. Само собеседование прошло хорошо, хоть и не без волнения. Мы обсуждали computer science в целом, архитектуру мобильных ОС и жизненный цикл приложений, базы данных, а также теорию тестирования с практическими заданиями.
Как опыт в поддержке подготовил меня к работе в QA
Работа с багами — логичное продолжение поддержки. Половина задач саппорта — это разбор ситуаций, когда у пользователя что-то не получается:
- пользователь пишет, что «ничего не работает»;
- информации мало;
- нужно докопаться до сути.
Опытный специалист поддержки умеет:
- уточнять шаги до проблемы;
- проверять окружение;
- воспроизводить ошибку;
- формулировать проблему так, чтобы разработчики сразу поняли суть.
Когда я перешёл в QA, всё это просто стало официальной обязанностью. Разница оказалась не в действиях, а в системности и глубине подхода.
Главное отличие — направление взгляда
В поддержке цикл выглядит так:
- баг уже случился;
- пользователь уже пострадал;
- ты разбираешься в причинах постфактум.
В QA всё иначе:
- фичу только выкатили;
- жалоб ещё нет;
- но ты уже представляешь, где она может сломаться.
Поддержка научила меня думать как пользователь и задавать правильные вопросы. В тестировании я просто начал задавать их раньше — до того, как проблема доберётся до клиента.
Что делать, если хочешь перейти в тестирование
Мне часто задают вопрос: с чего начать? Ответ довольно простой — с практики. И это необязательно должно быть что-то «про тестирование» в чистом виде.
Делайте свои проекты
Лучшее, что можно сделать, — попробовать создать что-то своё: небольшой сервис, простое приложение или даже автоматизация какой-нибудь бытовой задачи.
Почему это работает:
- сталкиваешься с реальными проблемами разработки;
- начинаешь понимать, как устроены процессы;
- видишь, где и почему возникают баги;
- учишься мыслить одновременно как разработчик и как тестировщик;
- самое приятное — ты быстро видишь результат. Это сильно мотивирует продолжать.
Теория тоже важна
Практику стоит подкрепить базой: виды тестирования, техники тест-дизайна, жизненный цикл разработки, работа с баг-трекингом. Но без практики теория плохо «прилипает». А вот вместе они дают очень сильный эффект.
Начните — остальное по ходу
Когда проходишь этот путь, происходит интересная вещь: начинаешь понимать IT глубже, а не просто работать внутри него. Видишь связи между компонентами, учишься мыслить системно — и этот навык ценен в любой технической роли. К тому же у тебя уже есть база знаний и опыта, на которую можно опереться.
Этот рост заметен не только тебе самому. Как отметил мой руководитель:
Уже при первом общении с Сёмой стало понятно, что перед тобой человек с хорошей технической базой и широким кругозором. Он не остановился на мобильном тестировании и довольно быстро перешёл к web‑приложениям, последовательно расширяя компетенции.
Особенно ценно, что Семён не избегает сложных задач — наоборот, берётся за те, где нужно подумать и разобраться глубже. Такой подход приносит ему признание коллег и помогает расти профессионально.
Если вы думаете о переходе — начните с практики уже сейчас. Развивайте привычку задавать себе вопрос: «Что здесь может сломаться?». Не бойтесь уточнять непонятное и ищите среду, где рост — часть культуры.
Мой путь показал: дело не в том, чтобы изучить всё сразу и стать готовым специалистом, а в том, чтобы двигаться вперёд и разбираться по ходу. При правильной поддержке этот путь оказывается гораздо легче, чем кажется на старте.-А какой навык из вашей текущей профессии, как вам кажется, мог бы пригодиться в тестировании?-Источник
|
