Привет! Меня зовут Сергей Могилевский, я QA Engineer в NIX, спикер NIXMultiConf. На протяжении пяти лет занимаюсь тестированием, последние три года являюсь Group Lead, два года — Lead тестировщик в проекте.

Тестирование остается одним из самых популярных направлений среди новичков в IT. «Светлые головы» приходят в команды со своим видением и свежими идеями. Но техническое образование есть далеко не у всех. Ребята ищут направления, которые не требуют длительной подготовки и специфических знаний. Действительно ли профессию тестировщика так легко освоить? Давайте разберемся детальнее.

Тестировщик — многогранная профессия

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

+1 челлендж в копилку

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

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

Ожидание VS реальность. В начале моего карьерного пути сложилась ситуация, что я зашел на новый проект одним из первых. Мне дали возможность написать тест-кейсы на пару модулей в системе, затем пришлось оставить проект из-за непредвиденных ротаций. Через несколько лет я вернулся в ту же команду, но уже в роли временного усиления состава. Догадаетесь, какие тест-кейсы мне попались на прогоне мануальной регрессии? Бинго, мои же собственные! Юмор оказался в том, что я это заметил, когда обсуждал с коллегой узость и непродуманность подобных проверок.

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

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

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

Почему тестировщик и QA не одно и то же

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

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

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

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

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

  • автоматизация функциональных проверок;

  • перформанс;

  • секьюрити;

  • аксессибилити.

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

  • вникание в код приложения для поиска новых вариантов проверок или отсечения дубликатных;

  • применение новых техник тест-дизайна к существующим проверкам;

  • построение новых пайплайнов тестирования.

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

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

Комментарии (6)


  1. akhkmed
    03.09.2021 16:42

    Мой довольно скромный опыт подсказывает, что наличие мотивации и амбиций довольно быстро уводит вчерашних тестировщиков в смежные области. Часто есть несколько типовых путей роста:

    Тест-дизайнер -> системный аналитик.

    Тест-лид -> менеджер проекта.

    В моём случае автотесты и произв-ть -> cm(devops)-> разработчик.

    Есть и та область, которая кажется тупиком, но по факту это целая пещера с лабиринтами: тестирование уязвимостей.

    Встречал, что организация не видит потребности тестировщика в росте и развитии, то зачастую у неё не остаётся тестировщиков вовсе, зато "гибкие методологии разработки". Поэтому совет для тестировщика: определитесь с вашими стремлениями по саморазвитию и как можно скорее донесите их до руководства.


    1. tommy_lee
      03.09.2021 18:18
      +2

      Обычное ручное тестирование может быть творческим и требовательным к скиллам: например, исследовательское тестирование.


      1. akhkmed
        03.09.2021 20:12

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


        1. tommy_lee
          03.09.2021 22:47
          +1

          Исследовательское тестирование широко используют продуктовые компании типа Google и Microsoft (Уиттакер о них пишет). При регрессионном тестировании может использоваться исследовательский подход.

          Заказчик участвует только в приемке, а до приемки ещё нужно дойти.


          1. ole325
            08.09.2021 11:48

            широко используют продуктовые компании типа Google и Microsoft (Уиттакер о них пишет)

            Я бы сравнивал исследовательское у Google, когда отработала SDET команда, что то проверили руками, а потом сами же используют свои продукты (как раз исследовательское тестирование). В наших реалиях "исследовательское тестирование" это отсутствие документации как в разработке, так и экономия в тестировании, даже E2E написанный в ворде даст больше результатов - продукт будет выполнять то, что должен.


  1. ole325
    08.09.2021 12:17

    он лишь тестировщик (вспомним деление на testing, QA, QC и вот это вот все)

    Многие QA Engineer работа QA не всегда достается. Работу QC часто выполнят как раз обычный тестировщик, это финальная проверка перед релизом.