Почему профессия 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, четко понимал: это не только про тестирование. Разнообразие активностей в этом направлении подходит практически каждому, кто готов на старте быть усидчивым и внимательным. Нужно просто немного изменить майндсет, чтобы тестировщик позволил себе стать инженером. Тогда перед ним мгновенно открываются десятки новых карьерных возможностей.

👍НравитсяПонравилось13
В избранноеВ избранном4
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Чому коментарі Доу токсичні і цікаві, а не лише технічне вайті вайті.

Из примеров на поверхности — автоматизированное тестирование web UI на Angular намного проще, если использовать тулзы вроде Protractor. При этом работа пройдет гораздо сложнее, если использовать Selenium. В этом случае он не совсем подходит.

Потужна аналітика, прекрасний мем.

Не знаю, як то мем, чомусь виникло почуття «хтонічний жах» :)

Тестировщик может быть инженером. (К сожалению в статье это не раскрыто).

Технические задачи, которые может делать опытный инженер:
— провести анализ системы (алгоритмов работы, обработки данных) и выяснить потенциальные пробелы в тестировании (которые могут привести с сбоям);
— продумывать различные «what-if» сценарии при работе с продуктом (при деплое, репликации данных) и помогать эмулировать и проверять такие сценарии;
— проанализировать архитектуру компонента и озвучить риски имплементации, интеграции, тестируемости;
— помочь разработчику в воспроизведении трудных ошибок и идентификации «узких мест» в перфомансе;
— внести изменения в систему с целью улучшения тестируемости или логгирования;
— анализировать покрытие фичей на разных уровнях с целью убрать лишние тесты и ускорить получение обратной связи;
— внедрить гайды по безопасному коду как на уровне соглашений, так и на уровне автоматических проверок при мердже;
— помочь с внедрением инструментов анализа покрытия кода и следить на уровне процессов, чтобы заданная планка покрытия не уменьшалась;
— проводить вместе с командой разбор post-mortem ошибок найденных в продакшене;
— проводить анализ процессов и инструментов разработки — как результат улучшать текущие библиотеки для тестов или имплементировать новые;
— разрабатывать автоматическую систему сбора (или генерации) тестовых данных для тестирования реалистичных кейсов (а не только замокированного всего);
— еще много всего...

Ну це очевидний булшит. Все те, що ти описав потребує глибок знань девопс частини, CS в загальному і знання специфіки мови програмування і конкретних фреймоворків які проект використувує. Я можу дати голову на відріз, що ні один manual QA не знає цього, тому що, якби він це знав — він би не був manual QA.

В статье же указана професиия QA. Но не manual QA. Поэтому вот QA вполне выше перечисленное может делать. И эти скиллы не за 1-2 и даже 5 лет нарабатываются.

Якщо ти можеш зробити таке

провести анализ системы (алгоритмов работы, обработки данных)

То в мене лише одне питання, нафіга працювати куашкою, замість позиції на 500к у FAANG архітектором?

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

по первому же пункту очевидно, что во-первых нет таких тестировщиков, во-вторых имея эти знания он бы даже не смотрел в сторону тестирования

То что в наших реалиях QA инженера не занимаются выше перечисленным — это только проблема нашего рынка.
Если требуется только «тыкать кнопки по заготовленным тест кейсам» или «писать файнд баи от заката до рассвета» — это совсем не значит, что в других компаниях тест инженеры не могут заниматься технически сложными вещами.
К тому же имея зп, сопоставимую с девелопероской — такой тест инженер уже будет выбирать не «там где больше платят», а там «где интересные задачи и он\она может принести больше пользы».

Да, это уже не тестировщик. Это программист с фокусом на задачах тестируемости/оптимизации кода. Причем, если он выполняет свою работу хорошо, то 99% манагеров перекинут на след спринте фичи писать/баги фиксить.

Тому що по суті, QA — це такий же інженер в команді, як і всі інші, тільки його скоуп задач орієнтований на забезпечення якості і ефективності розробки, починаючи з аналізу вимог і до фінального контролю виконання і автоматизацією цього контролю. Це якраз та людина в команді яка має допомагати розробникам бути ефективними, а не блочить їх перманентним пінг-понгом тікетів, ну якщо там мінорна дичина — візьми і фіксани, нафіга девам перемикати контекст. Навіть якщо доведеться так пару спринтів займатись багофіксом — це може спокійно мати місце, особливо в критичних ситуаціях, коли фокус команди на делівері фіч.
Просто те чим у нас займаються тестувальники — це quality control, зате з личками QA та istqb сертифікатами.

тільки його скоуп задач орієнтований на забезпечення якості і ефективності розробки, починаючи з аналізу вимог і до фінального контролю виконання і автоматизацією цього контролю. Це якраз та людина в команді яка має допомагати розробникам бути ефективними

Просто если он знает как написать качественный безглючный код, то почемубы ему самому не взять да не написать качественный и безглючный код? Слова не мальчика а менеджера. А QC всеравно нужен. Сколько безглючный код не пишы, а баги всеравно будут.

Решаю сложные технические задачи

Интересно, какие?

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

вникание в код приложения

Може краще залишити це розробникам?

сегодня статья на доу, а завтра О1 в штаты и 380к.

Боюсь, що таку статтю не врахують :-)

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

Я работаю в компаниях, в которых всегда были и есть QA.
Как ни пиши и не ревьюй.

А я працював там, де спочатку не було, саме з наведених причин, а потім все-таки їх завели :-)

Дай вгадаю, ви пишете сайти на джаваскрипті?

Хай Б-женька милує, чистий та кривавий дотнет інтерпрайз

я уже семь лет работаю в компаниях, где QA отсутствуют как класс

Т.е. ты 7 лет сидишь в какой-то шараге и считаешь что это хорошо?
А что вы ещё делаете для повышения самодисциплины? Уборку в офисе?

Ну мне лично самому приходилось кег с пивом менять раз в неделю и промывать все эти трубочки и краники. Уборку не доверяли.

Уборку не доверяли.

конечно, ничего себе запросы, ты подучись сначала

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

>

QA отсутствуют как класс

Но присутствуют как метод

А те кто возвышает себя на вершину развития как человек а других не уважает — ничем не могу помочь. Но думаю вам с такими мыслями явно живётся легче чем если бы вы считали себя обычным человеком.

То что сильно много технических знаний для manual QA engineer не нужно это верно, скорее знание тулов и умение находить лучшие подходы к нахождению несоответствий ожиданий заказчика с реальностью а так же проблем в приложении . Но если кто то думает что быть QA это легко то он ничего не понимает, пусть сам так проработает хотя бы года 3 а потом рассказывает) После освоения базовыми знаниями работа разработчика в психологическом плане в разы легче чем тестировщика.

быть QA это легко то он ничего не понимает

Это относится ко всем или почти всем профессиям.

конечно ко всем, если такое скажет какой-нибудь гений или кого готовили к какой то профессии с детства

Но если кто то думает что быть QA это легко то он ничего не понимает,

Шаленчиха — Но єслі хтось думає шо бить суперледі лєгко — то ето ошибка.
Вєнік — ну і трудного тоже нема ні...я
Лесь ©

QA Engineer
Решаю сложные технические задачи

Ну ти знову ? Які до біса «сложные технические задачи» може вирішувати QA, якщо це не automation ? Закінчуй з цим інфантильним ЧСВ. Це виглядає просто убого.

А какие «сложные технические задачи» может решать среднестатический веб-разработчик? Как разместить контролы на странице, подключить их к апи, которое в свою очередь делает выборку в БД?

Как разместить контролы в приличных конторах решает Дизайнер — не перенапрягай веб разработчика )

Наприклад оптимізувати вибірку з БД таким чином, щоб DBA не намагався підсипати тобі отрути в каву.

Опитимизировать выборку..

Семья лилипутов.
Отец — 150 см ростом, мать — 140 см ростом, а сын — 130 см ростом.
Так вот, приводит как-то сын домой свою невесту, а у нее рост 120 см.
Отец смоооотрит так внимательно на нее, и говорит: "Сынок, ты бы подумал еще... не торопился бы жениться, а то мы так и до мышей дотрахаемся...

Убого, взагалі-то, виглядають коменти, які не сильно далекі в темі. Автоматизація не є вже таким геть складним напрямком тестування, раз на те пішло. Це лише написання тестів для автоматичних перевірок певної частини функціоналу. І це лише напрямок. Все) грубо кажучи, це тестування, яке передбачає використання певних інструментів так само.

В статті йде мова в цілому про забезпечення якості як таке. Можливо прийде час, коли такі мамкіни коментатори зрозуміють, що забезпечення якості передбачає роботу інженерів різного напрямку і кваліфікації, бо задача все одно одна — покрити тестами продукт. А як ти називаєшся, і які для цього використовуватимеш тули — для навантаження, для автоматизації і тд — нікого не цікавить особливо.

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

і згоден, і ні. Так, автоматизація може бути непростою задачею. Так само як і робота з перфомансом, чи секюріті. Але по суті — це вс еодно тестування, елемент роботи з якістю. QA не займються взагалі покриттям продукту тестами по великому рахунку, це я написав недеталізовано звісно. QA це про процеси, тестінг це вже ближче прикладні перевірки. Але мій посил в меседжі був абсолютно на інше, сподіваюся, що Ви також це помітили.

хорошая статья, правильно и честно подчеркнули

Это все нетривиальные вещи. Тем не менее их легче освоить, чем какой-то вид программирования, паттерны разработки или основы менеджмента.

Кто захочет вырастет в крутого специалиста а кто не захочет то и не вырастет)

Я когда брал людей на работу еще спрашивал или готовы они 8 часов сидеть и проходить регресионные чек листы, что бы их ожидания соответствовали реальности.

Protractor ж вроде депрекейтнули. нет?

Із переліку альтернатив, схоже playwright найперспективніший (розробляється Microsoft, написаний на TypeScript, і є самим «молодим» фреймворком).

готовы они 8 часов сидеть и проходить регресионные чек листы

Я надеюсь, что правильный ответ — нет. Потому что это уже даже не тестировщик, это, извините, «Оператор ПК»

8 абзаців вступу про те, що куа це надзвичайно складна у технічному плані робота, 0 абзаців про те, а в чому конкретно складність.

В тому, що потрібно все це постійно собі повторювати для зростання «ЧСВ». Бо реальна робота від цього бла-бла-бла відрізняється як «робота» політика від його обіцянок.

Надзвичайно складно жити, якщо твоя професія — куа

Для гуманитариев наверное кажется сложно даже мануалтестирование

а ты оценку Рисков проведи а потом рассказывай про мануал тестирование

Тут и сказочке конетс, вот с вам полки леденетс

Подписаться на комментарии