Почему профессия QA сложная и интересная, а не только простой «вход в IT»

Привет! Я Сергей Могилевский, QA Engineer в NIX и спикер NIXMultiConf. Уже пять лет занимаюсь тестированием, последние три года групплид и два года лид тестирования на проекте. Решаю сложные технические задачи и занимаюсь менеджментом подопечных.

Последние годы так сложилось, что чуть ли не каждый пытается или хотя бы раз задумывался войти в IT. Техническое образование есть далеко не у всех. Поэтому некоторые новички ищут направления, которые не требуют длительной подготовки и слишком специфических знаний. Часто выбор падает на QA. Но так ли проста профессия тестировщика на самом деле? Я считаю, и да и нет. И вот почему.

Иллюстрация Алины Самолюк

«Каждый может стать тестировщиком»

Почти. Сначала специалисту, отвечающему за контроль качества IT-продукта, пригодятся базовые скилы: внимательность, усидчивость и понимание особенностей тестируемого приложения. Все это основа, которую в процессе работы дополняет умение пользоваться специфическими вспомогательными инструментами (баг-трекинговыми системами, мессенджерами и так далее). Когда складывается весь набор навыков, можно пробовать себя на должности QA. В современном мире IT для уверенного входа в профессию этого будет маловато. Чтобы сойти за трейни QA, нужно знать теорию и основы предметной области, попрактиковаться с несколькими приложениями, узнать распространенные подходы к тестированию. Это все нетривиальные вещи. Тем не менее их легче освоить, чем какой-то вид программирования, паттерны разработки или основы менеджмента.

И уверяю вас: здесь вы не соскучитесь даже на старте, какими бы примитивными не казались таски. Это только первое впечатление и зачастую обманчивое. Если вы искренне хотите стать тестировщиком и готовы приложить к этому максимум усилий, то быстро убедитесь на практике, насколько это многогранная профессия. В этом направлении всегда есть куда расти, но без челленджей не обойдется.

Идеальный сценарий для новичка — спустя пару месяцев подготовки найти и получить оффер мечты в команде профессионалов и уже видеть себя в уютном офисе в роли перспективного QA. Но этот путь доступен немногим. Даже если у кого-то все сложилось так позитивно, это не значит, что тестирование — несложная работа.

Поговорим о челленджах

Ступая на путь QA, важно уяснить, что с первой в своей жизни работой тестировщика специалист не становится инженером в чистом виде, он лишь тестировщик (вспомним деление на testing, QA, QC и вот это вот все). Перед ним открывается разнообразный мир новой профессии, который он только начинает осваивать. Тут-то и появляются первые сложности. Однако, справившись с каждой из них, новичок получает отличный профит.

Приходится развивать системное мышление. Далеко не у каждого от природы хорошо прокачена «мышца» системного мышления. Это умение, которое можно и нужно развивать. Обладая таким видом мышления, QA смотрит на проект шире, придумывает более правильные и оптимальные способы тестирования и тест-кейсы. Условно, когда молодой специалист смотрит на фичу, он видит только ее и больше ничего вокруг. Максимум — несколько близких очевидных зависимостей. Этот навык наиболее ярко проявляется, когда перед QA стоит проблема планирования тестирования для масштабного проекта. Если специалист не умеет рассматривать проект как цельную систему со всеми внутренними зависимостями и взаимосвязями, велика вероятность неоптимально выстроить в команде стратегию тестирования.

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

А что происходит в реальности? Лично у меня в самом начале моего карьерного пути сложилась ситуация, что я зашел на новый проект одним из первых. Мне дали возможность написать тест-кейсы на пару модулей в системе, и потом пришлось оставить проект из-за непредвиденных ротаций. Через несколько лет я вернулся в ту же команду, но уже в роли временного усиления состава. Как вы думаете, какие тест-кейсы мне попались на прогоне мануальной регрессии? Верно, мои же собственные! Только юмор оказался в том, что я это заметил, когда обсуждал с коллегой узость и непродуманность подобных проверок.

Оказалось, за прошедшие месяцы ни у кого не дошли руки актуализировать или проверить эти тест-кейсы. Все в целом проверяли функционал. А вот с более прокачанной «мышцей» системного мышления я буквально за пять минут понял то, что не смог заметить, будучи новичком. Проверки, которые казались тогда чуть ли не идеальными, на самом деле были поверхностными и плохо продуманными.

Очень много коммуницировать. QA — это не только тестирование, но и регулярный сбор информации, документации, построение слаженного общения в команде (а иногда тестировщика привлекают маркетологи и ВА на митинги с клиентом), а также эффективных рабочих процессов. Специалист, умеющий быстро добывать нужную информацию и грамотно ее распределять в задачах для тиммейтов или поделиться с заказчиком — профи на вес золота. Такой человек — величайшая находка для команды. Молодой специалист не всегда понимает, какие вопросы, кому конкретно и когда лучше задавать, кому расшаривать результаты работы и что потом делать с фидбэком. Но, когда он этому научился, это умение позитивно влияет на информированность и осознанность всей команды. Таким образом проект продвигается. Коммуникабельность тестировщика, как и всех остальных участников команды, помогает не упускать важные для всего проекта моменты и оставаться на острие IT-сферы.

Сейчас я нахожусь в проекте, где изначально для меня была очень большая проблема в коммуникации. Трудности испытывала не только QA-команда, но каждая тима решала эту проблему по-своему. В этом случае для меня уроком стал не процесс решения, а результат. Моя QA-команда спокойно работала весь год, и казалось, что все абсолютно отлично: тесты пишутся, тикеты закрываются, баги находятся. В общем, полный фэн-шуй. А потом настал локальный апокалипсис. Вдруг оказалось, что ни команда разработки, ни менеджеры со стороны заказчика абсолютно никакого понятия не имеют о том, что делает QA-команда. То есть что-то как бы делается, но что, как, когда и почему — вопросы, на которые могут ответить только QA-инженеры, и то не каждый и не на все. Анализируя ситуацию, я понял, что все наши тестировщики практически никогда не обсуждают свои задачи и действия ни с кем, кроме ближайших коллег. Решить проблему удалось с внедрением постоянных отчетов и созвонов раз в пару недель для шаринга новостей тестирования с заказчиком. Постепенно все участники команды прояснили для себя, зачем нужна постоянная качественная коммуникация и как ее настроить эффективно. Но это уже совсем другая история :)

Необходимо постоянно овладевать техническими навыками. Обновлять и пополнять имеющийся инструментарий — мастхев для QA-инженера. Трудно переоценить то, насколько быстро и качественнее может выполняться работа, если выбрать для нее подходящий инструмент. Из примеров на поверхности — автоматизированное тестирование web UI на Angular намного проще, если использовать тулзы вроде Protractor. При этом работа пройдет гораздо сложнее, если использовать Selenium. В этом случае он не совсем подходит. Умение быстро выбрать правильный инструмент и изучить его, если он еще не освоен — сложная, но каждый раз необычная и интересная задача, которая всегда развивает специалиста.

Из тестировщика — в QA

Как ни парадоксально, но на практике основные задачи тестировщика отличаются от обязанностей QA-инженера. Тестировщик запускает тесты, проверяет и сверяет фактический результат с ожидаемым. У QA-инженера — масса задач для поддержания качества продукта. Общение с командой или заказчиком, планирование работ по тестированию, генерация специфической проектной документации и множество других тасков. Но если относиться к такой работе как к длительному процессу развития, то большая часть умений приходит к тестировщику с опытом. Он участвует в командных активностях, постепенно получает доступ ко все большему количеству интересных заданий и усиливает свою экспертизу. Потихоньку начинающий тестировщик приближается к гордому званию настоящего QA.

Опыт получен. В запасе появились новые скилы. Что дальше? Всегда можно придумать другой подход к тестированию того, что уже сотню раз проверяли, и найти то, что можно оптимизировать.

QA — в первую очередь инженер

Для многих это звучит непривычно и вызывает небольшое сопротивление. Не стоит нервничать :) Идеальный QA — это специалист, который каждый новый таск воспринимает как челлендж и рвется его преодолеть с помощью имеющегося тулсета. Столкнувшись с незнакомой задачей, тестировщик скажет: «Я такого не умею. Найдите того, кто умеет», а инженер просто ответит: «Дайте разберусь и объясню, как могу решить эту задачу». А потом еще может сразу сказать, в чем ему надо дополнительно разобраться.

В моей команде есть несколько специалистов, которые постепенно начали разделять и поддерживать этот подход. И ровно в тот момент, когда они приняли новые правила игры, когда страха неудачи не существует, а очередная задача — это всегда увлекательный и посильный челлендж — они стали получать от работы больше удовольствия и постоянный респект от коллег. Этим же ребятам достаются новые, «непонятные» таски и в них они находят для себя постоянный рост.

Какие активности доступны с описанным выше майндсетом? Да любые! Ограничений практически нет. За любую задачу можно взяться и почерпнуть из нее что-то новое. Например, те же виды тестирования, помимо простого мануального, это же кладезь интересных, разной сложности задач:

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

Среди других активностей, могу выделить такие:

• вникание в код приложения для поиска новых вариантов проверок или отсечения дубликатных;
• применение новых техник тест-дизайна к существующим проверкам;
• построение новых пайплайнов тестирования.

Этот список можно продолжать. Под свои интересы и навыки каждый специалист найдет что-нибудь полезное для профессионального роста. Чтобы получать доступ ко все новым активностям, чаще говорите «да» и меньше — «я не умею». Крутой инженер умеет все. А во всем, с чем еще не знаком, всегда готов разобраться и сделать самостоятельно.

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

Лично мне хотелось бы, чтобы каждый, кто покоряет профессию QA, четко понимал: это не только про тестирование. Разнообразие активностей в этом направлении подходит практически каждому, кто готов на старте быть усидчивым и внимательным. Нужно просто немного изменить майндсет, чтобы тестировщик позволил себе стать инженером. Тогда перед ним мгновенно открываются десятки новых карьерных возможностей.