co automation feedback что такое
«Гуманитариям здесь тяжеловато». Правда о работе QA-инженера из первых уст
После университета Андрей сомневался, стоит ли идти в IT, и сперва начал карьеру в другой отрасли. Но со временем интерес к «айтишке» и зарплаты в этой сфере перевесили, что привело к курсам тестировщика и долгим поискам работы. Теперь Андрей занимает позицию QA-инженера в компании BGaming. В рамках спецпроекта BGaming с Onliner айтишник рассказал, почему доходы у QA не такие высокие, как у разработчиков, в чем отличие тестировщика от QA и почему автоматизированное тестирование не заменит ручное.
Из проектировщика в QA
— Как и почему стал работать QA-инженером?
— Это не сразу после университета произошло. Я много лет работал проектировщиком зданий — приложил руку к большинству магазинов крупных сетей. В 2008 году окончил БГУИР, и тогда входной порог в IT был не очень: зарплаты далеко не такие, как сейчас, об IT мало говорили, не было такого количества специальностей. Поэтому часть нашей университетской группы ушла в IT, а часть, включая меня, нет. Думаю, надо было еще тогда выбирать IT: после 2008 года как-то все, кроме IT, развивалось не очень хорошо.
Уже потом, ближе к 30 годам, понял, что хочу работать в IT. Оно накапливалось: я часто менял работу, меня переманивали из одной компании в другую, бюрократия в проектном деле процветала, не хватало ни нервов, ни терпения. И сказались кризисы 2009, 2011 и 2014 годов.
В общем, я окончил курсы QA. И тогда стало ясно, что попасть в IT в моем возрасте не очень-то и просто. Все хотят брать молодых: они, наверное, более гибкие. Возможно, проще было пойти на разработчика: их сейчас дикая нехватка, а QA очень много. И почти всем работодателям нужны люди с опытом. Я бы советовал идти в разработку, автоматизацию или другие технические направления. Но нужно понимать, какая это работа, не всем она зайдет.
На нетехнические направления, такие как проектный менеджмент или бизнес-анализ, тоже не очень просто попасть «джуном». Полгода назад я окончил курс PM+BA, и, судя по чату нашей группы, люди по-прежнему ищут работу. Про чью-то победу в плане трудоустройства не слышно.
— Сколько времени искал работу?
— Долго, но там была интересная ситуация. Я окончил курс лучше всех, и меня пригласили на собеседование в ту же компанию, которая проводила курс. Но есть чувство, что звали скорее ради галочки. Потом пошел на собеседование в похожую компанию, там меня согласились взять. Затем сказали, что их покупают, будет реструктуризация и нужно подождать. Я прождал месяца три, мне надоело — и уже тогда нашел другую работу. То есть я был всего на трех собеседованиях, но суммарно потратил на поиски полгода.
Причем там работал разработчик — человек лет 40, без опыта. И его всячески восхваляли. Думаю, «джунам» и людям в возрасте проще попасть в IT через разработчика.
— Зарплаты у разработчиков выше, чем у QA?
— Если в целом смотреть на одну «весовую категорию» — мидлы в обоих случаях, например, — то да, у разработчиков зарплаты выше. Даже значительно выше. Видимо, потому что работа QA требует знаний «вширь», а разработчика — большей подготовки, большего объема «глубинных» знаний.
Тестировщик и QA — в чем разница
— Опиши суть работы QA.
— Суть — в проверке работоспособности какой-либо системы. Задачи QA сильно связаны с тестированием, и многие QA-специалиста называют тестировщиком. Пожалуй, QA действительно основную часть времени тестирует руками, например, приложение, он выполняет все кейсы прямо как пользователь (если речь о тестировании клиентской части), составляет текстовую документацию. Но все же функции QA шире: здесь речь идет об обеспечении качества в целом.
Нужно на всех этапах разработки смотреть, чтобы продукт не был сложным для его поддержания, вникнуть в природу дефекта: нужно разобраться, почему он возник, и предоставить эту информацию разработчику для «фикса».
Но не всегда это получается без проверки кода. Еще я бы упомянул составление тестовой документации по продукту. То есть мы работаем от момента начала разработки и до поддержки уже после выхода. А тестирование само по себе — это просто проверка работоспособности или всей системы, или какого-то ее компонента согласно тестовой документации.
— Можно сказать, что тестировщик в карьерной лестнице стоит ниже QA?
— Я не видел людей, которые считают тестировщиков более низшими специалистами. На ранних стадиях, сразу после курсов, наверняка все занимаются только тестированием. И мало в каких компаниях больше внимания уделяется чему-то, кроме непосредственно тестирования. Все тестировщики обычно называют себя QA, и какого-то различия нет: мол, я QA, а вот я тестировщик.
Постепенно, узнавая продукт при тестировании, начинаешь понимать, как он устроен — и уже мыслишь как разработчик. Когда тебя зовут на митинги по созданию чего-то, ты можешь прогнозировать, допустим, что такое-то решение будет плохим для проекта. Когда понимаешь, как должен работать продукт не только с бизнес-стороны, но и в техническом плане, и когда можешь не просто выявлять дефекты, а и понимать их природу, тогда тестировщик становится QA.
— Почему разработчики сами не видят, что какое-то решение так себе?
— Разработчикам дают конкретные задачи, а всей картины они порой могут не видеть. Задачу поставили: нужно сделать то и то. А QA тестирует уже все целиком, и он понимает: часть, сделанная одними разработчиками, взаимодействует с другими частями, за которые отвечали другие разработчики. И он может сказать, где какие подводные камни обнаружились.
— Возьмем веб-игру, почтовое приложение и мессенджер: один QA может с одинаково хорошим результатом протестировать настолько разные продукты?
— Если сталкивается в первый раз, наверное, вряд ли. Например, я могу быть крутым QA на каких-нибудь e-commerce-проектах и буду знать все от «а» до «я». Но если меня позовут в игры, то там мидл или даже «джун» окажутся в чем-то толковее меня. То есть нужно знать продукт.
— Тестирование идет на всех поддерживаемых устройствах и версиях ПО?
— В случае с веб-продуктами ситуация простая: почти все браузеры используют ядро Chrome, то есть у них и баги одинаковые. Реально проблемным был Explorer, но потом Microsoft перенесла Edge на Chromium, и дышать стало легче. А так еще мобильный Safari своеобразный, да и в целом iOS. Там и баги нетривиальные появляются, некоторые старые движки тяжело поддерживать. И Apple часто что-то меняет, переделывает, а потом у нас все ломается.
Наши разработчики говорят, что Safari будет хорошим, когда его напишут на Chromium.
QA — это финальная точка в разработке
— Компания делает новую игру, тебе дают первую версию. Как обычно проходит тестирование?
— Обычно целую версию не дают — есть отдельные ее компоненты. И эти компоненты я проверяю на взаимодействие. А полная игра будет готова уже перед релизом, когда происходит приемочное тестирование. Здесь она тестируется уже полностью. Мы тестируем не только то, что видит и с чем взаимодействует пользователь, ведь еще есть серверная часть, которую тоже нужно проверить. Но это, как правило, происходит на более ранних стадиях.
— От QA может зависеть выход игры в срок? Допустим, когда в предрелизной версии находишь что-то критическое.
— Да. QA — это финальная точка. Если игра не будет протестирована, ее не выпустят. Тогда уже либо в ночь перед релизом тестировать, либо переносить выход. Но я не помню, чтобы такое происходило.
— Какие ошибки самые распространенные?
— Чаще всего это минорные UI-баги на клиенте: что-то не так отображается, где-то текстура не такая, как на макетах. Функциональные и большие баги — большая редкость.
— Тестирование идет по чек-листу либо просто перебираешь все подряд функции продукта?
— Есть чек-лист, который я сам же и составлял. Но он, пожалуй, больше подходит для молодых специалистов. Я люблю тестировать все подряд, что в голову придет. В принципе, тот же чек-лист я помню наизусть и по нему тоже прохожусь.
— Чем занимаются тестировщики и QA, когда новых продуктов нет?
— В моем случае такого не бывает, но, вообще, занимаются документацией. Каждую игру нужно подробно описать, потому что у каждой свои фичи. И это полезно, когда приходит новый человек: документация помогает ему быстро влиться и узнать особенности продукта.
— Тестировщика лишают премии за баг в релизной версии продукта?
— Я такого не встречал. (Смеется.) Если случилось что-то серьезное и это повлекло за собой убытки для компании, то, конечно, «косяк» неприятный. Не знаю, стоит ли наказывать за такое, но тестировщик должен чувствовать себя очень плохо, раз пропустил такой баг.
— Автоматизированное тестирование вытеснит ручное?
— Нет. Что такое автоматизированное тестирование? Это та рутинная работа, которую человек не может выполнять каждый день: она слишком нудная. Поэтому автоматизатор пишет код, который автоматизирует часть работы. Все равно будет разрабатываться что-то новое, что нужно будет проверять руками.
Наверное, есть сферы, где мануальщики не нужны, — думаю, это серверная часть. Год назад я окончил курсы автоматизаторов на Python, и там как раз были кейсы про серверы и базы данных. Мы думали покрыть наши игры автотестами, но пока что остаемся на ручном режиме. К тому же мануальное тестирование происходит быстрее, хотя в долгосрочной перспективе автоматизация себя окупает.
Кем может стать QA
— Какой карьерный путь у тестировщика?
— Как и везде: джуниор, мидл, сеньор — можно дойти до лида. А дальше можно пойти куда угодно — к примеру, DevOps или бизнес-анализ. Многие идут в менеджеры или в разработчики. Обычно говорят, что часто QA становятся разработчиками, но почему-то среди моих знакомых больше менеджеров. Если нравится общаться с людьми, тогда есть смысл идти в менеджеры, а когда технарь до мозга костей — лучше, наверное, в разработку.
— Почему считается, что в IT проще всего попасть через тестирование?
— Курсы тестировщика занимают меньше времени, чем, например, разработчика. И на ранних стадиях это довольно просто — думаю, справится практически любой. А развиваться дальше будет труднее. Если ты не технического склада ума, то вряд ли получится.
Гуманитариям здесь тяжеловато. Нужно понимать специфику: как что-то делает разработчик. Когда этого понимания нет, придется тратить много времени на кейс, который может оказаться элементарным и проверяться в два клика.
— Курсы короче, потому что это проще?
— По сути, мы все являемся тестировщиками. Зашел на сайт, прошел форму регистрации — вот ты уже заодно и протестировал ее. Тестировщику нужно показывать на курсах: открываете форму, проверяете поля на валидность, заносите все в баг-трекер. А дальше уже зависит от сферы, в которую попадет тестировщик. То есть входной порог очень низкий, но никто не говорит, что дальше будет так же легко.
BGaming — быстрорастущий игровой провайдер с белорусскими корнями, предлагающий качественные продукты для онлайн-казино по всему миру.
Игрок и его выбор — главная ценность компании, поэтому мы постоянно изучаем и анализируем потребности и предпочтения аудитории, чтобы создавать яркие и запоминающиеся продукты. Студия разрабатывает онлайн-игры на стыке gambling и gaming, в которых идеально сбалансированы визуальные эффекты и математика. Это возможно благодаря команде экспертов с безграничной энергией и более чем 20-летним опытом в индустрии.
Спецпроект подготовлен при поддержке ООО «Меркелеон девелопмент», УНП 193084780.
Читайте также:
Наш канал в Telegram. Присоединяйтесь!
Есть о чем рассказать? Пишите в наш телеграм-бот. Это анонимно и быстро
Automation QA — это отдельная команда?
«Конечно отдельная!», — ответит большая часть читающих. Такой ответ укладывается в их картину мира, потому что “так работали всегда”.
Так работали всегда
Эта фраза обычно означает наличие продукта, уже работающего на продакшене или только готовящегося зарелизиться, но написанного без модульных и интеграционных тестов. Без страховочной сети из тестов, изменения вносятся долго, дорого и с большим количеством новых багов. Такой проект в мире разработки принято называть “легаси”.
Компания понимает, что обойтись без страховочной сети нельзя, поэтому создается QA-отдел, который обычно не обеспечивает качество продукта, а лишь контролирует его. С QA-отделом разработчик может спокойно заниматься любимым делом — писать код, ведь ответственность за качество теперь несет выделенный отдел! Происходит классическое “перебрасывание кода через стену” в отдел тестирования:
Прохождение каждого тест-кейса ручное, поэтому процесс тестирования занимает много времени. Количество тест-кейсов в регрессии по естественным причинам постоянно растет, и принимается решение о создании внутри QA-отдела команды автоматизации.
Так как новоиспеченная команда набиралась из-за необходимости ускорить цикл регрессии, который состоит из black-box тестов, то и автоматизация происходит на уровне black-box: через GUI или API. Автоматизация через GUI наиболее болезненная и дорогостоящая из-за хрупкости и низкой скорости тестов, но зачастую начинают именно с нее.
Тем временем, факт создания новой команды никак не влияет на команду разработки: она все также продолжает отдавать в тестирование некачественный продукт, игнорируя написание модульных и интеграционных тестов. Учитывая огромное количество black-box сценариев, находящихся в очереди на автоматизацию, получаем анти-паттерн тестирования Ice-Cream Cone, в котором количество самых медленных и самых дорогостоящих GUI-автотестов намного больше количества дешевых и быстрых модульных и интеграционных тестов.
Нестабильных и медленных по своей природе GUI-автотестов с каждым релизом становится все больше, а значит больше ресурсов уходит на их поддержку, что ведет к расширению команды автоматизации. Департамент обеспечения качества растет, но не обеспечивает должный рост качества выпускаемого продукта. Вы действительно хотите так работать всегда?
В чем проблема?
Одна из главных причин возникновения ситуации, описанной выше, — это отсутствие культуры разработки, в которой каждый разработчик несет ответственность за написанный им код. А даже минимальная ответственность понимает под собой необходимость удостовериться в работоспособности кода прежде чем радостно восклицать: “Моя работа готова!”.
Eye Driven Development является самым простым способом удостовериться в работоспособности кода, но не самым оптимальным. Прост этот способ тем, что не предполагает практически никакой интеллектуальной работы: мы тестируем руками приложение, сервис, класс и т.д. с точки зрения конечного пользователя, не рассматривая граничные значения, классы эквивалентности, негативные сценарии, сценарии с разными уровнями permissions и прочее. Такой способ не дает быстрой обратной связи при разработке, не позволяет проверить сущность на разнообразной выборке данных, занимает много времени и не улучшает качество продукта.
Наиболее оптимальный способ — это написание автотестов на разрабатываемый код. Говоря об ответственности за код, не важно, когда написаны автотесты: до или после самого кода. Главное, что дает такой способ — это уверенность в том, что работа действительно завершена и можно переходить к другой задаче. Учитывая другие преимущества в виде быстрой обратной связи, возможности проверять сущность на большой выборке, а также высокой скорости, автотесты, написанные разработчиками, являются отличным инструментом для улучшения качества продукта.
Работаем не так как всегда
Предлагаю мысленно смоделировать возможное развитие событий в команде, члены которой несут ответственность за написанный код.
У нас имеется продукт, уже работающий на продакшене или только готовящийся зарелизиться, который покрыт модульными и интеграционными тестами. Код постоянно совершенствуется, а новая функциональность добавляется без страха сломать уже имеющуюся. Чтобы убедиться в работоспособности разрабатываемой функциональности больше не нужно “перебрасывать код через стену” в отдел тестирования и терять время, ожидая вердикта, после чего повторять итерацию снова и снова.
QA-отдел уже создан и активно участвует в процессе разработки, занимаясь действительно обеспечением качества выпускаемого продукта. При разговоре об обеспечении качества, как мне кажется, удобно руководствоваться Testing Quadrants:
Используя Testing Quadrants, тестирование можно разбить на 4 категории.
Первая категория — это тестирование реализации продукта, создающее страховочную сеть для команды разработки. Эта категория отвечает за низкоуровневое тестирование с помощью модульных и интеграционных тестов и позволяет понять разработчикам, что с технической точки зрения они делают вещи правильно (Do Things Right). Очевидно, что низкоуровневые тесты являются полностью автоматизированными и пишутся командой разработки, так как лежат в ее сфере интересов.
Вторая категория — это тестирование бизнес-функций продукта, создающее страховочную сеть для команды разработки. Здесь речь идет о таких видах тестирования как Examples, Story Tests и прочих, направленных в первую очередь на создание правильной коммуникации между бизнесом и командой разработки, и позволяющих команде понять, что она делает правильные вещи (Do Right Things), которые действительно нужны бизнесу.
Автоматизирование Examples или Story Tests представляет из себя End-to-End тесты, которые тестируют не сложные сценарии использования интерфейса, а лишь бизнес-логику, но через интерфейс, который доступен конечному пользователю. Так как данная категория тестирования все еще лежит в сфере интересов разработки, то автоматизация ложится на плечи команды разработки.
Третья категория — это тестирование бизнес-функций продукта, которые критичны для восприятия качества продукта конечным пользователем. В эту категорию попадают исследовательское тестирование, тестирование сложных сценариев использования продукта, тестирование юзабилити, альфа- и бета-тестирование. Тесты из этой категории лежат полностью на плечах QA-команды, а их автоматизация невозможна или слишком сложна.
Если говорить непосредственно про исследовательское тестирование и тестирование сложных сценариев, которые могут находить функциональные ошибки, то стоит заметить, что любая найденная ошибка является ошибкой в коде и может быть покрыта соответствующими модульными или интеграционными тестами. Об этом хорошо написал Мартин Фаулер, а я позволил себе вольности в переводе:
I always argue that high-level tests are there as a second line of test defense. If you get a failure in a high level test, not just do you have a bug in your functional code, you also have a missing or incorrect unit test. Thus I advise that before fixing a bug exposed by a high level test, you should replicate the bug with a unit test. Then the unit test ensures the bug stays dead.
Я утверждаю, что высокоуровневые тесты — всего лишь вторая линия обороны. Упавший высокоуровневый тест означает не только баг в коде продукта, но и отсутствие соответствующего модульного теста или ошибку в уже имеющемся. Мой вам совет: прежде чем фиксить баг, найденный высокоуровневым тестом, воспроизведите его с помощью модульного теста, и вы попрощаетесь с багом навсегда.
Четвертая категория — это тестирование реализации продукта, которая критична для восприятия качества продукта конечным пользователем. Обычно в эту категорию попадают нагрузочное тестирование, тестирование производительности, тестирование безопасности и надежности системы. Такое тестирование проводится с использованием специальных инструментов, зачастую написанных под нужды конкретного проекта. По-хорошему, инфраструктурой для проведения подобных тестов занимается DevOps-отдел, а разработкой соответствующих инструментов —
отдельная команда. Причем инструменты должны позволять проводить тесты по-требованию (Testing as a Service).
Так как созданный QA-отдел теперь отвечает не только за контроль качества продукта, но и за обеспечение качества, то в его обязанности входит:
Бесконечного роста регрессионных ручных black-box тест-кейсов не происходит, потому что большая их часть покрыта в первой и второй категориях командой разработки. В таком случае у нас формируется правильное отношение тестов или, как это принято называть, “пирамида тестирования”:
Рост количества регрессионных ручных тестов минимален, автоматизация на уровне модульных, интеграционных и GUI тестов осуществляется командой разработки. Причем количество GUI-тестов небольшое, они описывают не сложные сценарии использования GUI, а работу бизнес-логики через пользовательский интерфейс, а значит являются менее хрупкими и более дешевыми в поддержке. Отдел QA действительно занимается обеспечением качества, получая и работая с фидбеком от пользователей, проводя исследовательское тестирование, тестирование новой функциональности с помощью сложных сценариев, а также помогая разработчикам общаться с бизнесом. Тестирование в проекте автоматизировано эффективнее чем в первом случае, но команда автоматизации внутри QA-отдела так и не появилась.
И я повторю вопрос: “Automation QA — это отдельная команда?”
Что такое QA Automation и как стать тестировщиком с нуля?
Без технологий QA тестирования айти-продукты не могли бы претендовать на серьезный уровень качества. Разработчики создают программное обеспечение. Но только QA тестировщик может гарантировать его жизнеспособность. Такой специалист нужен каждый команде. Давайте выясним, чем же он занимается.
Что такое QA?
Неправильно воспринимать термин только в разрезе IT. QA – это общее понятие, которое переводится с английского как “обеспечения качества”. Сложный процесс охватывает все этапы создания, выпуска и эксплуатации продукта (причем не обязательно программного). QA Testing предполагает изучение продукта в разных условиях, поиск дефектов и путей их исправления. Это неотъемлемая часть разработки.
Что такое QA Automation? Это, если угодно, продвинутое обеспечение качества продукта, в котором проверки автоматизированные. Давайте разберем подробнее.
QA Automation vs QA Manual
Профессия тестировщика имеет две основные роли. Первая – QA-мануальщик. Он придумывает и пишет сценарии проверки, выявляет лаги и уязвимости, анализирует результаты тестов, ведет документацию, отслеживает исправления. Работа тестером-автоматизатором предполагает перевод написанных коллегой кейсов в программы. Он разрабатывает скрипты для выполнения рутинных функций тестирования. Мануальщик проверяет вручную. Создавать автотесты – задача специалиста по QA Automation. Что это дает команде? Время и ресурсы для других, более творческих видов работ.
Многие приходят в автоматизацию из мануального тестирования. Это происходит, когда специалисту надоедает решать однообразные проблемы, его душа требует челленджа. К тому же Quality Assurance Engineer со специализацией в автоматизации получает больше, чем коллеги-мануальщики. Но нужно быть готовым к серьезному обучению.
Как стать QA Automation инженером?
Необходимо понимать, что курсы – это не панацея. Как стать тестировщиком с нуля? Учиться и работать над собой. А еще не стоит забывать, что тестировщик – это еще и особенный склад ума. Способность видеть ошибки и умение анализировать – неотъемлемые качества.
Что нужно знать тестировщику?
Разберем подробнее хард-скиллс. Для работы на позиции Junior QA Engineer в Automation-направлении нужно овладеть:
инструментами и библиотеками автоматизации;
программированием (ООП, структуры данных, язык для написания тестов).
Кроме того, необходимы знания технического английского, баз данных, а также администрирования Linux.
QA Engineer – это динамичная профессия. Расти и обучаться придется постоянно.
Пути развития QA Automation Engineer
Итак, свершилось, вы тестировщик ПО. С чего начать карьерный рост? Очевидное решение – развиваться в своей сфере. Расти от Junior до Head of Department.
Для многих должность QA Engineer становится точкой входа в программирование. Тестер-автоматизатор может переквалифицироваться в разработчика.
Есть и третий путь. QA инженер может превратиться в менеджера проектов. Понимание аспектов качественного продукта тут как нельзя кстати.