Специальность тестировщика часто называют входным билетом в IT: мол, программирование — это сложновато и конкуренция высокая, а в QA попасть проще. Как на самом деле обстоит ситуация с тестировщиками, что нужно знать и чего вообще ожидать от такой работы, мы узнали у Максима Алексейчика, руководителя отдела тестирования Apalon.
— Как оказались в IT и конкретно в тестировании?
— Я десять лет, до 2012 года, работал в милиции. За год до истечения пятилетнего контракта, примерно когда мне было тридцать, захотелось попробовать что-то другое. В детстве я залипал в видеоиграх, потом начал с компьютерами возиться, во времена первых Android-смартфонов увлекался «рутованием», перепрошивками. Решил подыскать то, что будет связано с увлечениями.
Сперва хотел устроиться в техподдержку одной геймдев-компании. Прислали тестовое задание, я хорошо его выполнил, но получил отказ. Не знаю причину — может быть, из-за моего, скажем так, бэкграунда.
Начал искать дальше. По счастливой случайности мне посоветовали обратить внимание на тестирование ПО. Тогда я о нем ничего не знал: думал, что это как программирование, а я ведь ни одного языка не знаю. Оказалось, все совсем по-другому.
Примерно за год до окончания контракта в милиции начал готовиться к смене карьеры: подписался на каналы по тестированию ПО, смотрел ролики на YouTube, читал форумы, участвовал в бесплатных программах бета-тестирования — uTest, Fixber. Набрался опыта, составил резюме. Есть вакансия или нет — не важно, я все равно писал во все IT-компании. В итоге, после сотни писем, одна компания пригласила на собеседование, и после стажировки меня взяли.
По сравнению с милицией, где я и так получал немного, мой доход упал раза в два. Деньги были ну очень символические. Тут стоит понимать: карьера обнулилась, в тридцать лет я был на одном уровне со студентами без опыта. Но было ясно, что работа перспективная и интересная.
Я работал над большими проектами с крутыми заказчиками и благодарен моей первой компании за этот опыт. Сейчас я могу сказать, что нашел себя и счастлив реализовываться в профессиональном плане. Первое время я так хотел помочь другим людям найти себя в тестировании, что даже сделал специальный мануал и консультировал каждого, кто ко мне обращался. И скажу, у нескольких человек это получилось.
— Существует мнение, что через тестирование проще всего попасть в IT. Это так?
— Однозначно такое мнение существует, но мне кажется, что это не совсем верно. Идти в программирование через тестирование, на мой взгляд, не рационально — нужно сразу идти в программирование. Просто потеряете время. А есть вообще одни и те же профессии, которые представлены в IT и не в IT, например HR, маркетинг, поддержка пользователей.
Если говорить про порог вхождения именно в тестирование, то на junior-позицию огромная конкуренция, поэтому будет однозначно сложно. Теперь идет популяризация всего, что связано с IT, и еще больше людей стремятся сюда попасть. Только надо учитывать, что придется много в себя вкладывать, и если работа не нравится — будет особенно тяжело.
— Какая зарплата в среднем возможна по Минску?
— Если без опыта, то 400—1000 рублей. Дальше вообще не важно, сколько ты проработал. Всем реально все равно: что пять, что десять лет. Ведь можно и за год хорошо прокачаться, а можно пять лет сидеть без движения на одном месте. На интервью будут задавать вопросы о том, что нужно для конкретной компании. Если очень усреднять, то зарплата сотрудника с опытом от двух лет будет 2000—4000 рублей и больше.
— А какая ситуация сейчас на рынке? Легко ли найти работу?
— Склонен полагать, что рынок перегрет. Не так сильно, как в случае с программистами, но нехватка тестировщиков есть. Особенно нужны те, которые хорошо разбираются в какой-то одной предметной области. Во-первых, разрастаются крупные аутсорсинговые компании. Во-вторых, появляется очень много продуктовых фирм. Пока компания в стадии стартапа, тестировщик не нужен: ты можешь быть программистом и менеджером проекта одновременно или дизайнером и QA. Когда все поехало, начинают расширяться, но платить большие деньги сразу не готовы. Поэтому в основном нанимают junior’ов.
— Что вообще усредненному тестировщику нужно знать и уметь? Это скорее работа для гуманитария или технаря?
— Думаю, не принципиально. Для старта нужно хорошее логическое мышление и английский язык. В 2012 году, когда я начинал, на это некоторые компании закрывали глаза, потому что работали с Россией. Потом случился кризис, и мы для россиян стали очень дорогими. В итоге почти все белорусские компании переориентировались на Запад. Так что без английского совсем никуда.
Важно понимать, что придется постоянно учиться. Например, если говорить применительно к нашей компании, каждый год выходит новая версия iOS/Android и несколько их апдейтов, свежие девайсы. Надо быть гибким и все время что-то изучать. И не важно, junior ты, middle или senior — конкуренция есть всегда. Естественно, хороших специалистов очень немного.
Из минусов специальности — нужно быть готовым выполнять монотонную работу, особенно в мануальном тестировании.
— Логическое мышление — это про круги Эйлера?
— Нет, скорее нечто абстрактное. Вот как говорят: «У человека все в порядке с логикой». Просто умение выстраивать причинно-следственные связи, решать задачи на рассуждение и так далее. Нанимателю нужно понять, какие логические выводы делает человек.
Допустим, скачиваем приложение будильника и показываем соискателю. Ему нужно составить десять важных проверок за пять минут. Какая главная проверка у будильника? Конечно же, звонит он или нет. Однако уже на этом многие сыплются — лезут в какие-то дебри, проверяют дополнительные экраны, изучают меню, но не говорят о самом очевидном. Вот здесь проявляется нечто среднее между логикой и здравым смыслом: ты должен разложить приложение на функции и понять, что оно делает, для чего предназначено, что самое главное для пользователя.
— Как выглядит работа? Устанавливаете, допустим, бета-версию того же будильника и проверяете на любые баги?
— От тестирования ждут прежде всего не баги, а информацию о качестве текущего продукта. Тестировщик, кстати, работает еще на этапе идеи. Допустим, хотим сделать приложение погоды. Нам озвучивают идею, разработчик продумывает техническую реализацию, а хороший QA-специалист проводит собственное исследование и выражает свою точку зрения: «Я изучил три приложения конкурентов, вот что у них плохо и как нам сделать лучше».
Дальше составляются требования, и по ним пишется тестовая документация, хотя бы для высокоуровневых проверок — это самые базовые и основные вещи. Грубо говоря, чтобы приложение о погоде действительно показывало метеоданные, а не что-то еще. И дальше расширяемся: как все выглядит, у какого провайдера берется информация и так далее. То есть от частного к общему.
Основная задача тестировщика — понять, насколько нынешняя версия продукта соответствует ожиданиям заказчика. И еще насколько она стабильна, правильно ли работает с технической точки зрения.
Но решение о том, каким должен быть продукт, принимает не тестировщик. Хотя не запрещается изучать конкурентов и высказывать свое видение.
— Конфликты с разработчиками бывают? Ведь вы, по сути, ищете ошибки в их работе.
— Мы работаем вместе. У нас общая цель — создать качественный продукт, поэтому наши усилия направлены на создание крутого приложения, а не на конфликты. Разработчики — отличные ребята и часто сами у себя находят баги. Обычно на одного QA приходится по два разработчика, хотя очень многое зависит от бизнес-модели компании — продуктовая она или аутсорсинговая.
Важно умение тестировщика быть тактичным, направлять критику не на личность программиста, а на результат его работы. В целом, главное — все должны понимать, что усилия направлены на создание крутого приложения, а не на поиск ошибок друг у друга.
— Шутка про «не баг, а фича» — такое в реальности случается?
— Все же большинство багов — это именно баги, и их нужно устранять. Но бывают незначительные баги, и в некоторых случаях мы можем не исправлять их вот прямо сейчас, а переносить на следующую версию. Потому что сроки всегда горят. И еще важно понимать, где именно баг: в приложении или операционной системе. И у iOS, и у Android ошибок хватает.
— Сообщаете о них в Apple и Google?
— У Apple есть огромная техподдержка — что-то похожее на собственный stackoverflow (сообщество специалистов по обмену опытом и помощи коллегам. — Прим. Onliner). Иногда мы с ними переписываемся напрямую, общаемся на конференциях.
Допустим, выпустила Apple модуль автопродляемых подписок для приложений со встроенными покупками. И там, например, обнаружился дефект. Пересекаемся с сотрудниками на WWDC, описываем проблему, а они такие: «Ну да, это баг, оформите и перешлите, пофиксим». Просто писать на их форумах — все равно что в космос сообщения отправлять: потеряются. С Google ситуация похожая. Конкретно с Android работать сложнее — он же везде разный.
— Что забагованнее: iOS или Android?
— Вообще, iOS 11 была ужасной. Двенадцатая версия стабильнее. Но здесь нужно разделять: либо ты смотришь на систему как разработчик и тестировщик, либо как обычный пользователь. Если говорить с позиции потребителя, то iOS 11 хуже iOS 12. Последние несколько версий Android, кстати, очень стабильные, но обновления для системы быстро перестают выходить. И в целом Android начиная где-то с пятой версии здорово прогрессирует.
У нас своя специфика: в отличие от веба, где все работает через браузер, мы взаимодействуем в том числе с «железом». Поэтому на стабильность влияют особенности смартфонов. Казалось бы: в обоих случаях iPhone, одна экосистема, с точки зрения кода все должно быть идеально. А приложение для камеры совершенно по-разному ведет себя на девайсах с двумя и одним фотосенсором.
— Вспомните какой-нибудь забавный баг из своей практики.
— Я работал в аутсорсинговой компании, и был заказчик — один из российских сотовых операторов. Он выпускал свой кабинет пользователя, а я занимался тестированием этого приложения. Функционал с виду простой: активировать SIM, посмотреть баланс. Но на деле — огромная куча серверного бэкграунда: что-то отвечает за SIM, что-то за баланс, за платежку, за чат. И все эти маленькие системы подключены к приложению, которое выглядит как один, максимум полтора экрана. Тестировать было жутко сложно.
И вот мы прошли проверку в App Store, команда собралась (человек сто), все радуются. Дружно начали качать это приложение. А оно не работает: просто «падает» на старте. И так у всех. Я готов был съесть все свои локти — лично же отвечал за качество. Оказалось, что не подключили какой-то сервис: то ли платежку, то ли еще что-то. Затем все заработало, но момент, когда на меня недоуменно смотрит вся толпа, я запомнил надолго.
И еще такая шутка ходит — про «телефон директора», то есть главное устройство, на котором приложение должно работать идеально. Так что первым делом проверяйте, как продукт функционирует на смартфоне, которым пользуется ваш директор. Но это, конечно, из разряда юмора.
— Часто говорят о трансформации одних профессий и смерти других. Что в этом плане ждет тестировщиков?
— Думаю, в дальнейшем тестировщик эволюционирует до эксперта в узкой области. Плюс будет наполовину автоматизатор, потому что с каждым годом инструменты автоматизации тоже упрощаются и порог входа снижается. Вы же видите, насколько сами языки программирования становятся удобнее. Что Swift, что Kotlin — они постоянно совершенствуются.
Но ручное тестирование не исчезнет, скорее будут заменены какие-то простейшие проверки. А что касается самых сложных вещей, то их проще додумать и проверить руками, чем писать для этого автотест.
Читайте также:
Наш канал в Telegram. Присоединяйтесь!
Быстрая связь с редакцией: читайте паблик-чат Onliner и пишите нам в Viber!
Перепечатка текста и фотографий Onliner без разрешения редакции запрещена. nak@onliner.by