Привет! Меня зовут Сергей Могилевский, я 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)
ole325
08.09.2021 12:17он лишь тестировщик (вспомним деление на testing, QA, QC и вот это вот все)
Многие QA Engineer работа QA не всегда достается. Работу QC часто выполнят как раз обычный тестировщик, это финальная проверка перед релизом.
akhkmed
Мой довольно скромный опыт подсказывает, что наличие мотивации и амбиций довольно быстро уводит вчерашних тестировщиков в смежные области. Часто есть несколько типовых путей роста:
Тест-дизайнер -> системный аналитик.
Тест-лид -> менеджер проекта.
В моём случае автотесты и произв-ть -> cm(devops)-> разработчик.
Есть и та область, которая кажется тупиком, но по факту это целая пещера с лабиринтами: тестирование уязвимостей.
Встречал, что организация не видит потребности тестировщика в росте и развитии, то зачастую у неё не остаётся тестировщиков вовсе, зато "гибкие методологии разработки". Поэтому совет для тестировщика: определитесь с вашими стремлениями по саморазвитию и как можно скорее донесите их до руководства.
tommy_lee
Обычное ручное тестирование может быть творческим и требовательным к скиллам: например, исследовательское тестирование.
akhkmed
Подскажите, по вашему опыту исследовательское тестирование эффективнее, чем регрессионное? Понятно, что цели немного разные, но если область охвата регрессионного включает предполагаемую область исследовательского, то последнее выглядит не таким надёжным, как первое. Да и заказчик зачастую платит только за тестирование по сценариям с понятными протоколами.
tommy_lee
Исследовательское тестирование широко используют продуктовые компании типа Google и Microsoft (Уиттакер о них пишет). При регрессионном тестировании может использоваться исследовательский подход.
Заказчик участвует только в приемке, а до приемки ещё нужно дойти.
ole325
Я бы сравнивал исследовательское у Google, когда отработала SDET команда, что то проверили руками, а потом сами же используют свои продукты (как раз исследовательское тестирование). В наших реалиях "исследовательское тестирование" это отсутствие документации как в разработке, так и экономия в тестировании, даже E2E написанный в ворде даст больше результатов - продукт будет выполнять то, что должен.