Работа тестировщиком что это
Тестировщик — больше, чем профессия
За время своей работы в сфере тестирования, у меня сложилось своё, особое мнение об этой области, начиная с позиции младшего тестировщика (junior tester) до руководителя отдела тестирования (test manager). И, в целом, это мнение достаточно критичное с долей любви и обожания к этой замечательной профессии.
В качестве вступления
Я никогда не собирался становиться тестировщиком — меня больше привлекала разработка. Со школьной скамьи я писал программы, которые уже обкатывались моими одноклассниками, а затем одногруппниками: мне было интересно решать задачи и оживлять вещи, а уж решением возникающих проблем и багов я занимался после того, как мне о них сообщали пользователи. К версии я приписывал минорную циферку, и… и в каком-то балансе между функциональностью и качеством программа оставалась навсегда, уступая место новым проектам и программам.
Забегая вперёд, скажу, что отчасти в этом кроется ключ к успешному ведению проектов — в нахождении баланса между затратами на разработку продукта и его качеством. Любой продукт схож с биологическим организмом, в формировании которого участвуют не один человек, а многие — прямым или косвенным образом. В формировании хорошего продукта должны участвовать все заинтересованные стороны, и каждая из них должна делать весомый вклад в общее дело. Но, к моему удивлению, тестировщики в этом отношении занимают особую нишу: во-первых, они являются связующим звеном в процессе, а во-вторых, они одни единственные из инженеров имеют право вето на выпуск версии продукта.
Обо всём об этом я узнал на первом своём месте в качестве тестировщика с неугасшими амбициями разработчика. В первую очередь, меня очаровала возможность получения доступа к управлению продуктом, власть, на которую я не особо рассчитывал. Это было здорово, что-то особенное, выше написания очередной функциональности. Во-вторых, тестировщики в силу особенностей профессии имеют большее представление о процессах и целях продукта, отчасти транслируют бизнес цели разработчикам, а результат разработчиков —руководителям. К сожалению, в мире и, тем более, в России, представление о роли тестировщика весьма сумбурное, и её значение сильно преуменьшается. А те компании, которые всё-таки находятся в тренде, стараются развить направления тестирования и управления качеством, хотя и ставят несколько завышенные цели: «найти все ошибки, снизить до минимума стоимость разработки через тестирование».
Эта статья, в первую очередь написана по мотивам общения с различными компаниями, является квинтэссенцией ответов на их вопросы. Во-вторых, обращена к начинающим тестировщикам и тем людям, которые хотят узнать о тестировании побольше с точки зрения внутренней кухни. В- третьих, базируется исключительно на моём (субъективном) опыте.
Тезис №1: Тестировщик — не обезьяна
В Android SDK входит замечательный инструмент под названием MonkeyRunner, который позволяет автоматизировать процесс тестирования Android приложений в идеале без исходного кода, без особых знаний языков программирования (лишь общего представления о скриптовых языках достаточно) и, главное — имитировать любое поведение настоящего пользователя. В итоге получается эдакая скриптовая обезьяна, которая тыкает, печатает, читает приложение. Самое то, что можно «отдать на аутсорс» машине. Для меня такое понимание тестирования в порядке вещей. Но, к моему удивлению, когда я искал работу в первый раз после своей первой должности в роли тестировщика, выяснилось, что на рынке существуют (и по сей день!) странное разделение на «ручных» и «автоматических» тестировщиков, более того, лестница грейдов и вовсе столь смешана и растянута, что диву даёшься. Не говоря уже о том, что от компании к компании одни и те же должности подразумевают разные должностные обязанности, особенно это актуально для старших должностей.
В мои должностные обязанности входило: составление тест-дизайна, тест-кейсов, стратегии тестирования (если это был назначенный на меня проект), репорт багов, проверка документации и создание тестовой документации. Это было само собой разумеющимся для меня, хотя несколько удивляло, что у западных коллег эти обязанности были разделены. На рынке же оказалось, что вполне обычным явлением считается, что дизайн пишется с помощью CTE/UML (в лучшем случае) Test Lead/Senior Tester/Test Designer. Тест кейсы (разнообразные стратегии проверки границ, интерфейсное тестирование, нагрузочное, стендовые кейсы) — Senior Tester’ы. И, наконец, существуют низшие должности «исполнителей» — Tester. В некоторых компаниях и отделах их число может доходить до 20 и более человек! Другими словами, в штате проекта числились обезьяны, в лучшем случае, обладающие навыками пользователя компьютером и каким-то продуктом.
На деле же это… несколько неправильно. Потому что тестировщик не обезьяна. Если это не так, то либо вы, как компания, выпускаете разные продукты в короткий срок, без последующей поддержки и качества, прогоняя формальные smoke-тесты, либо, что более вероятно, ваш менеджер/архитектор — баран.
Затраты на автоматизацию тестирования окупаются далеко не сразу.
Для знакомых с теорией тестирования (коих, как показывает практика, не так уж и много), вполне очевидно, что необходимость автоматизации сильно зависит от специфики проекта (его сроков, поддержки, повторяемости, и пр.). В некоторых случаях куда предпочтительнее обойтись smoke тестами и пользовательским бета-тестированием и выполнять приёмку через product owner’a, чем усложнять процессы. Так же должно быть чёткое понимание приёмки продукта: верхнеуровневая и низкоуровневая. В первом случае, внутри проекта, можно определить роли и принять продукт владельцу продукта, во втором возможно ограничиться, если допускают это требования, приёмкой самими инженерами-разработчиками с выпуском release notes. В случае, когда тестирование требуется всё-таки отдельное, то куда проще и эффективнее иметь поставленный менеджментом процесс жизненного цикла продукта и человека или команду инженеров, способных самостоятельно покрыть задачи развёртывания и тестирования продукта, т. е. людей, которые априори знают область, инструменты и методы, а не стадо обезьян, которых повесили на разработчиков или одного руководителя проекта.
Как ни удивительно, но этот простой тезис зачастую сознательно нарушается. Например, для аутсорсинговых компаний это хороший способ получить дополнительные FTE. В плане бизнеса попросту выгоднее продать побольше, что-то, имеющее низкую себестоимость. В опыте моей работы на Auriga, где заказчикам предоставлялись на почасовую оплату соответствующие ресурсы в количестве десятков человек — не единичный случай. Более того, такой план хорошо покрывает цели стаффирования проекта для клиента при минимальных затратах. Несмотря на то, что нагрузка на менеджера проектов значительно возрастает, при грамотном руководстве это пусть к созданию «кузницы кадров» за счёт проекта, привязки кадров к компании (обучение и рост навыка) при сравнительно большей цене покупке специалиста с рынка, и последующая перепродажа, ротация персонала на более требовательные проекты.
Ещё одной причиной такой стратегии является возможность покупки нецелевых кадров для клиента. Так уж получается, что требования к кадрам ваших работодателей или клиентов иногда бывают недальновидны (о чём речь пойдёт ниже), и меньшими затратами для компании (по деньгам и времени) является возможность покупки фиктивных кадров. Скажем, покупка такого рода «обезьян» на проект с параметром «20 лет стажа» (но, возможно будучи весьма посредственным специалистом). Это особо актуально в системе грейдов Junior/Standard/Senior многих компаний, особенно за пределами России, где требования к стажу и реалии немного иные.
Поэтому этот первый тезис стоит рассматривать как проблему в стратегической перспективе для любой компании, проблему роли тестирования и выстраивания инженерных процессов. Разрешение её, грамотная градация и использования сугубо инженерных кадров, является признаком грамотного руководства и долговременного планирования в компаниях.
Тезис №2: Тестировщик — это инженерная профессия
Из-за мешанины с обезьянами в профессии тестировщиков хватает людей, далёких от инженерной сферы, и не имеющих подчас даже соответствующего технического образования. Это действительно грустно и печально, т. к. квалифицированных ресурсов на рынке тестировщиков сегодня действительно не хватает — грамотные специалисты предпочитают уходить в разработку (в лучшем случая близкую к теме аналитику), а те, что остаются, имеют скудное представление о жизненном цикле ПО, тестировании и языках программирования.
На мой взгляд, любой тестировщик должен обладать техническими знаниями, уверенным владением и хотя бы базовыми навыками администрирования прикладных программ и популярных ОС. Кроме того, тестировщик должен иметь хотя бы базовое представление о языках программирования, уметь читать код хотя бы на интуитивном уровне, а также быстро адаптироваться к новым языкам и программам/средам. Вообще, главные особенности тестировщика — это гибкость и обучаемость. Поэтому, имея опыт в программировании и общее представление о скриптовых языках и языках высокого уровня, человек сможет обучиться и адаптироваться без особых проблем. В идеале требуется знание скриптового языка и основ языка разработки, на котором и базируется проект.
Из всего этого вытекает, что тестировщик обязан уметь работать с кодом. Хотя, в идеале, хороший процесс должен исполняться по модели чёрного ящика. Тем не менее в него, в этот ящик Пандоры, тестировщик должен не бояться заглянуть и помочь разобраться с проблемой разработчику. То есть быть как рыба в воде в системе не только багтрекера, но и контроля версий кода, и быть способным провести ревью кода.
Несмотря на то, что я в подавляющем большинстве случаев слышу мнение, что процесс ревью кода, отладки (дебаггинг) и юнит-тестирования — прерогатива исключительно разработчиков, возьму на себя смелость утверждать, что это неправильный подход. Проблема исходит из недостаточной квалификации тестировщиков и неверного управления жизненным циклом ПО. Возможно, этот подход хорошо работает в маленьких проектах по TDD, но главная сила и возможность обеспечить высокое качество продукта — разбить сферы влияния, ответственности, обеспечить принцип раздельности (dissimilarity).Это сделает процесс разработки более прозрачным, отслеживаемым и позволит скомпенсировать «эффект замыленности глаза» у разработчиков, избежать «трюков» с их стороны.
В компании Liebherr Aerospace жёстко выстроены процессы и роли в компании. Чёткое следование специфичным для отрасли итеративным моделям. Тем не менее, инженерное крыло, инженерные должности называются для всех одинаково — Software Engineer. Акцент делается на том, что сотрудник в компании в первую очередь — специалист, инженер в области ПО. Значит, сотрудник должен разбираться в инженерных процессах, процессе разработки, тестирования, схемотехники и т.д. Тем не менее, среди инженеров присутствует обязательное разделение на специализацию: in Test, in Development, in Requirements, и пр.
Так как компания следует жёстко инженерным процессам с целью соблюдения высочайшего качества, каждая часть процесса разделена на независимых участников. На практике это означает, что каждый уровень требований пишется отдельным человеком (группой), дизайн другими, код пишется третьими, юнит-тестирование четвёртыми, функциональное тестирование — пятыми и так далее. При этом, чтобы не дать «заскучать» и «увязнуть» в рутине, людей в проекте стараются вращать по функциям, и, вполне возможно, даже на одном проекте, в разных итерациях инженер, по мере своих возможностей будет покрывать разные обязанности, и охватит различные этапы разработки ПО.
То, что каждый из этапов и типов разработки и тестирования должен покрывать разные люди следует из требований международных стандартов, таких как DO-178B (для авиации), EN 50128 (для железнодорожного транспорта) или ГОСТ Р МЭК 60880 (для атомных электростанций), и обеспечивает, в конечном итоге высочайшую отказоустойчивость на уровне процессов и в том числе в части тестирования ПО.
Тезис №3: Метрики — ерунда, если нет работы в команде
Во время почти каждого собеседования на должность тест менеджера можно услышать вопрос по поводу того, как соискатель собирается выстраивать процесс тестирования и какие метрики с проекта он собирается снимать, какие метрики будет использовать по отношению к себе. На самом деле, вариантов метрик — количественных и качественных — можно придумать немало, но особого смысла они не будут иметь до той поры, пока не будет в проекте эффективности в команде. В команде в широком смысле слова, т. е. как внутри отдела/команды тестирования, так и при взаимодействии с командой разработчиков и заказчиков из бизнеса.
На практике это означает, что бесполезно считать количество разработанных тестов (это метрика прогресса), найденных багов (в худшем случае) показателем эффективности команды тестирования, даже рейт регрессий, даже синтетических метрик на проекте (с использованием критериев важности и трудоймкости), не говоря уж о идиотских (но по-прежнему применяемых и для команды тестирования KSLOC\hour). Для менеджера проекта, возможно, будет неплохой метрикой CPI/SPI как KPI проекта, которая может базироваться на всех обозначенных и собранных тест-менеджером метриках. То есть, достаточно абстрактная и высокоуровневая оценка в зависимости от затраченных усилий и полученного результата. Но при условии, что команды работают как единый организм.
Для тестировщиков это означает, что они связующее, ведущее колесо процесса, которое сделает программное обеспечение работоспособным и соответствующим требованиям. В процессе тестирования это означает как само тестирование, так и предоставление теста повторяемости, документируемости, возможных проблем и решений проблемы (если это видно со стороны тестирования, если хватает квалификации), а так же перепроверку тестирования (VoV). Другими словами, задачей тестирования является как перепрогон и перепроверка всех возможных состояний, так и (в необходимом и достаточном случае) покрытие полной тест-стратегии и тест-плана (по крайней мере то, что обозначено в Quality Gates), вынесение багов и их разрешение через разработчиков ПО и спецификации. Т. е., с момента проверки и обнаружения бага ответственность на нём не «перекидывается» на разработчика, а сопровождается тестировщиком до его разрешения. Грубо говоря, тестировщик отвечает за баги, а разработчик — за фичи.
Тут мы подошли к ключевым различиям между тестировщиком и разработчиком, кои в моей статье получаются очень близки и похожи. Тем не менее, по стилю работы разработчики обычно либо перфекционисты, либо «фичеделы» (которые любят кодить ради кода, функциональности и алгоритмов); тестировщики же — либо педанты, либо автоматизаторы (стремящиеся автоматизировать автоматизацию). Поэтому в проекте тестировщик знает, как правильно сделать, а разработчик — как именно.
Исходя из этого, повторюсь, что главное — это результат, зависящий от единой команды, а не только от метрик в одном прогрессе, скажем, разработки дизайна. И где процесс проседает больше — там и кроется проблема, там и падают реальные метрики, которые уже в контексте работающего синергического проекта обретают смысл. Вполне возможно, что долгая разработка тестов не вина дизайнера, а вина аналитика, транстировавшего требования слишком сложно.
Тезис №4: Тестировщик — центр процесса разработки ПО
В V-модели разработки ПО наглядно видно, что тестировщик участвует на всех этапах жизненного цикла.
Схожесть разработчика и тестировщика, размазанность границ области при наличии хорошей квалификации — главный показатель интереса в работе тестировщика. Конечно, можно утверждать, что причастность к продукту и его качеству в случае тестирования чёрного ящика является мотивационным фактором, но, на мой взгляд, человек, пришедший в техническую, инженерную область сделал это осознанно, с желанием развиваться и работать над собой. Поэтому возможность расширять свой кругозор, влиять на качество продукта, (пусть даже небольших вещей), проявлять активность, а также накладывать вето на выпуск продукта у тестировщика, по моему мнению, более весомые аргументы за профессию. А раз так, раз хороший тестировщик — не обезьяна, а инженер-исследователь, знаток, принимающий участие на почти на всех этапах жизненного цикла по (в отличие от ролей аналитиков, дизайнеров, разработчиков, и технических писателей), ответственный за качество продукта (не процесса, это к QA, так что под «качеством продукта» будем подразумевать соответствие заявленным и утверждённым требованиям и стандартам, чеклистам и прочая), то для поднятия качества продукта и развития себя, как специалиста, тест-инженер должен проявлять активную позицию. Он знает, как улучшить продукт. Знает, что такое «достаточно хорош», и как его, продукт или процесс, таким сделать, инициировать движение как инженера-разработчика, так и других команд и даже компаний. Например, в любых проектах бывают моменты простоя, который может быть допустим со стороны руководства. Обычно в это время сотрудники решают личные проблемы или занимаются самообразованием. В отношении работы разработчик может заняться рефакторингом, поизучать алгоритмы и перенести на свои проекты. А что делать тестировщику? Осваивать новые средства тестирования? Он-то ничего не делает без изначального пакета от разработчиков/аналитиков. В действительности, он может заняться автоматизацией своей деятельности или улучшением продуктов, им используемых, даже если он далёк от инфраструктуры и devops.
Тезис №5: Тестирование — не место для фиксации на ключевых словах
Последней и самой странной темой, на мой взгляд, является весьма смутное представление о тестировании (даже о теории, не говоря о практике). Во многих компаниях отделы тестирования не оправдывают надежд, в некоторых даже дискредитировали себя и функционируют на малую часть от своей потенциальной эффективности по ряду факторов. Проблема проистекает как из-за отсутствия школы, так и из-за некомпетентности менеджмента. Ситуация весьма плачевная в отраслях, отдалённых от IT, даже где «деньги — не проблема» — там задачи ставятся по принципу «повысить качество продукта». Даже в IT-компаниях, где есть общее представление о процессах, есть целый ряд проблем, связанных с фиксацией на определённых ролях или инструментах, хотя к тестированию, повторюсь, такой подход плохо применим.
В одном из крупных инвестиционных банков, в котором у меня проходило собеседование, было схожее требование на позицию тест-менеджера: «повысить качество и уменьшить брак». Любую задачу можно решить. Хотя под покровом задач скрывается координация отделов по ряду различных продуктов, составление планов тестирования, организация тестирования, работа с разработчиками, составление базы кейсов и прочая. В действительности, ответственность за качество продуктов в компании логично взять на себя какому-нибудь «директору по качеству», оно же QA Director, а не просто руководителю отдела тестирования. Однако тут дело упирается в полномочия, которых на этой позиции нет, и в отсутствие группы, которая не планировалась вовсе (которая могла бы помочь тому-тому тому-то). То есть в компанию нужен человек-оркестр без команды. Разгадка тут простая: менеджмент ищет по ключевым словам, и считая качество в аббревиатуре QA панацеей от всех проблем, хотя она лежит в сфере стратегического топ-менеджмента и процессов, которые нужно спускать сверху с соответсвующими полномочиями и ресурсами.
В идеале управление качеством (QA) и тестирование две непересекающиеся сущности.
Проблема системная, т. к. весьма неплохо, когда HR ищут по ключевым словам вроде «нагрузочное тестирование», «функциональное». Но когда в процессе рассмотрения делается акцент не на навыки тестирования, не на активность и гибкость кандидата, а на конкретный инструмент — это уже проблема, особенно когда никакого тестирования нет в помине (есть обезьянничество), и не факт, что требуемый инструмент эффективнее того, который знает соискатель. Проблема в том, что знание мелкого нюанса или инструмента, на освоение которого уйдёт несколько часов, ставится во главе угла, выше знания языков программирования или теории. В одном из интервью было достаточно смешно было отвечать на вопросы: «назовите какую-нибудь книгу по тестированию» и, ответив про Сэма Канера, услышать: «мы такого не знаем, а про жизненный цикл бага что-нибудь читали?». Это было бы смешно, если бы не было так грустно. Грустно, когда HR сообщает об отказе из-за отсутствия опыта у кандидата, хотя дело к неправильном расставлении акцентов.
Найти хорошего тестировщика — большая проблема, т. к. инженер-тестировщик — это, в идеале, человек, который разрешает технические проблемы, связанные с разработкой ПО, эдакий problem solver. Такому человеку, помимо технических навыков очень важно иметь внимательность, пытливый ум, быть активным и уметь донести мысль и отстоять свою точку зрения на любом уровне.В каком-то роде, тестировщики — это исследователи из мира разработки ПО. Поэтому в руках инженера-тестировщика легко узнаваемый символ — лупа (линза), наблюдающая за жучками. Как нельзя лучше характеризует она работу тестировщика: используется как по прямому назначению для выявления дефектов, так и для «прожигания дырочек», с её помощью можно добывать огонь и даже, имея целую систему линз, наблюдать за звёздами. Главное — уметь это делать.
Вместо выводов
Тестировщик — это больше, чем профессия. Это образ проактивной жизни и стремления эту жизнь сделать лучше для всех посильными и эффективными средствами. Цели тестировщика в отношении продукта наиболее близки к целям бизнеса и стратегической цели компании в отношении этого продукта, и в то же время глубоки внутри компании в роли исследователя. А раз так, то главные его качества — это энергия, знания и гибкость. Но в тоже время работа тестировщика – это не всеобщее знание и ответственность за качество продукта и качество услуг. У тестирования есть границы: с одной стороны ограниченные проектом и требованиями в нём (менеджмент проекта и установленный жизненный цикл программы), и с другой – процессами, за которые отвечает QA. Но о различия QA от тестирования совсем другой разговор.
Гид по профессии тестировщик: чем занимается специалист в сфере QA, сколько зарабатывает, что надо знать и где учиться
Позиция тестировщика считается одним из самых простых способов быстро войти в отрасль информационных технологий. Ходят слухи, что эту профессию легко освоить, работа у тестировщика — не бей лежачего, да и платят специалисту по тестированию программного обеспечения почти как программисту. Насколько эта информация достоверна? Давайте разбираться.
Кто такой тестировщик, за что отвечает и чем занимается
Тестировщик программного обеспечения планирует и выполняет тестирование приложений, отлаживает код, улучшает юзабилити программ. Часто к названию профессии добавляют латинские буквы q и a: qa тестировщик. Также употребляют название qa инженер. В латинских буквах спрятана суть деятельности тестировщика. Подробности ниже.
За что отвечает тестировщик
QA произошло от английских слов quality assurance — обеспечение качества. Это часть разработки, которая управляет качеством продукта. QA — широкое понятие, а работа над обеспечением качества начинается задолго до написания первой строки кода будущего приложения. В идеальном мире инженер по качеству работает над продуктом если не на этапе генерации идей, то на этапе исследования рынка и изучения потребностей целевой аудитории.
В широкое понятие QA входит ещё одно направление деятельности: QC, quality control или контроль качества. Инженеры QC контролируют продукт на этапе разработки и поддержки. Тестирование программного обеспечения — один из инструментов контроля качества. То есть тестировщик проверяет приложение в рамках мероприятий по контролю качества (QC), которые входят в комплекс работ по обеспечению качества (QA).
В широком смысле тестировщики участвуют в создании полезного для пользователей программного обеспечения. Если конкретизировать, тестировщики контролируют качество приложений, над которыми работает организация.
Чем занимается тестировщик
Как сказано выше, тестировщики проверяют программное обеспечение. Разберёмся, как они работают.
Есть ручное и автоматизированное тестирование ПО. Соответственно, специалисты по ручному тестированию проверяют приложения вручную, а специалисты по автоматизированному тестированию работают с помощью программ.
Ручной тестировщик по сути вручную имитирует действия пользователя приложения. Специалист убеждается, что программа работает как ожидается в разных сценариях взаимодействия. Ручное тестирование иногда называют поведенческим или тестированием методом чёрного ящика. Но автоматические тесты тоже чаще всего проводятся с использованием стратегии чёрного ящика.
Стратегией чёрного ящика называется подход, при котором объект тестируется без использования знаний о его внутреннем устройстве.
При планировании поведенческих тестов специалист учитывает технические требования к программному обеспечению. Пример: в спецификации указано, что после регистрации нового пользователя приложение отправляет письмо с подтверждением на указанный электронный адрес. Тестировщик регистрируется в приложении и проверяет, пришло ли соответствующее письмо.
Ручное тестирование — самый простой способ оценки качества приложения. Тестировать приложение вручную — «дорогая» операция, так как скорость и точность проверок ограничена возможностями тестировщиков.
Автоматизированное тестирование подразумевает проверку приложений с помощью программного обеспечения. Это не значит, что для автоматических проверок не нужны тестировщики. Напротив, специалист по автотестам должен знать и уметь больше, чем ручной тестировщик.
Вот примерное описание работы эксперта по автоматизированному тестированию. В первую очередь он выбирает тест-кейсы или функции приложения, которые нужно проверить. Обычно для автотестов выбирают критичные для работы ПО функции, например, обработку платежей, сохранение пользовательских данных. Автотестирование подходит, когда тесты повторяются неоднократно или для проверки функции приложения нужно использовать большие объёмы данных.
Затем тестировщик выбирает инструменты, планирует и реализует дизайн проверки. На этом этапе специалист готовит данные для тестов, настраивает инструменты, устанавливает расписание тестирования. Тесты запускаются, результаты тестирования автоматически фиксируются. Специалист анализирует полученные данные и передаёт информацию разработчикам.
Автоматизация тестов экономит ресурсы организации. Она позволяет с минимальными усилиями повторно тестировать приложения, требует меньше времени по сравнению с ручными тестами, сокращает количество ошибок.
Промежуточный итог: тестировщики контролируют качество программного обеспечения. Эта деятельность входит в комплекс работ по QA — обеспечению качества приложений. Тестирование бывает ручным и автоматизированным. Ручное тестирование предполагает проверку приложений вручную, а для автоматических тестов специалисты используют программы.
Учитесь с нами На Хекслете есть интенсив по тестированию фронтенда для разработчиков с опытом
Работа тестировщиком: где работают QA-инженеры, сколько зарабатывают, какие вакансии есть на рынке
Тестировщики трудятся в командах, которые занимаются разработкой программного обеспечения. Это скорее средние и крупные компании, которые делают собственный продукт или работают по модели аутсорсинга.
QA-инженеров и QC-тестировщиков часто привлекают команды, которые используют DevOps. В таких командах разработка, тестирование и поддержка ПО выполняется циклически с использованием подходов Agile или Scrum.
Сколько зарабатывают тестировщики
По состоянию на весну 2021 года на сайте hh.ru по запросу «тестировщик» есть 6646 вакансий во всех регионах России. При этом в начале 2020 года вакансий по этому направлению было в два раза меньше. Сотрудников ищут такие компании, как «Сбербанк», «Билайн», МТС, «Магнит» и другие. Максимальная зарплата составляет 400 000 рублей в месяц. Минимальная указанная зарплата — от 50 000 рублей в месяц.
Большая часть вакансий открыта в Москве и Санкт-Петербурге. Но тестировщики требуются и в регионах. Например, в Новосибирской области открыто 293 вакансии по тестированию, в Татарстане — 219 вакансий, в Свердловской области — 210 вакансий.
Тестировщики могут работать удалённо: на hh.ru есть 1614 вакансий для удалёнщиков. При этом до начала пандемии коронавируса на hh.ru было всего 215 вакансий для тестировщиков на удаленкее. Большинство работодателей хочет видеть кандидатов хотя бы с минимальным опытом. Но 600 вакансий подходят для начинающих тестировщиков без опыта работы.
Как стать тестировщиком: что надо знать и где учиться
В этом разделе говорим о необходимых для тестировщиков знаниях и об обучении. Важно понимать, что требования к соискателям отличаются от компании к компании, поэтому ниже вы найдёте обобщённую информацию.
Что должен знать и уметь тестировщик, какие софт-скилы нужны этому специалисту
В первую очередь специалист должен изучить основы тестирования. Классификация тестирования, методы и инструменты, создание сценариев тестирования, — вот базовый набор знаний, с которого будущие QA-тестеры начинают знакомство с профессией.
Понадобятся знания основ программирования, протокола HTTP, умение работать с базами данных и системами контроля версий, хотя бы базовое знание HTML и CSS.
Тестировщик должен уметь работать с командной строкой, знать браузеры и инструменты разработчиков. Также понадобится умение работать с инструментами автоматического тестирования, например, HP-UFT (бывший QTP), Selenium, Sahi и так далее.
Специалисты называют разные софт-скилы, которыми должны обладать тестировщики. К специфичным для этой профессии мягким навыкам можно отнести внимательность к мелочам, критическое мышление, умение анализировать информацию.
Где учиться тестированию
Профессии «Тестировщик» на Хекслете пока нет. Тем не менее у нас есть полезные для будущих тестировщиков курсы и интенсивы. Вот некоторые из них:
Также вы можете посмотреть программы обучения в других школах. Например, курсы для будущих специалистов в области QA есть в «Тинькофф Образование», «Нетологии», GeekBrains, Skillbox и в других русскоязычных школах. А если вы владеете английским языком, можете пройти курсы на известных англоязычных площадках, включая Udacity, edX, Udemy, Coursera и так далее.
Промежуточный итог: чтобы работать тестировщиком, нужны специальные знания, включая основы тестирования, основы программирования, системы контроля версий, инструменты автоматизации и так далее. Часть знаний будущие тестировщики могут получить на Хекслете.
Профессия глазами профессионалов: комментарии экспертов о работе тестировщиков, перспективах и обучении
Мы обратились к опытным специалистам в сфере QA, чтобы узнать о нюансах профессии тестировщик. Они ответили на несколько вопросов о профессии.
Константин Виноградов: после курсов программистов можно смело становиться тестировщиком
Дмитрий Дементий: Чем работа тестировщика отличается от работы программиста? И что есть общего в работе тестировщика и программиста?
Константин Виноградов: Проще сказать, чем они похожи: оба специалиста работают над тем, чтобы на выходе получился качественный продукт, отвечающий требованиям заказчика. В остальном это совершенно разные направления работы.
Конечно, есть отдельные специализации, такие, как специалист по автоматизации тестирования (test automation engineer) или разработчик в тестировании (software development engineer in tests), чья работа почти идентична работе программиста. Она предполагает написание кода автоматических тестов и тестовых фреймворков.
Но в целом задачи тестировщика слабо перекликаются с задачами программиста. Анализ требований, составление тестового плана с учетом покрытия требований, выполнение ручного тестирование и запуск автотестов, подготовка отчетов — вот работа тестировщика. Если не рассматривать уровень простого мануального тестирования, я бы сказал, что такая работа имеет значительно большую аналитическую составляющую, чем техническую.
Валидация продукта требует от тестировщика достаточно большого кругозора, так как приходится смотреть на продукт глазами пользователя, понимать его потребности. Надо уметь «быть пользователем» и знать его потребности, что непросто, если речь идет о специализированных решениях. Надо знать отраслевые стандарты, которым должно соответствовать решение, и уметь это соответствие проверить. Надо уметь находить способы тестирования совместимости с конкурентными решениями.
Кроме того, от тестировщика требуется другое мышление. Способ думать разработчика должен привести его к одному правильному и оптимальному сценарию решения проблемы. Способ думать тестировщика ведёт его ко всему многообразию сценариев, которых, по определению, больше.
Еще раз повторюсь: мы не рассматриваем автоматизаторов и разработчиков в тестировании, потому что они, на мой взгляд, всё же разработчики, а не тестировщики.
Д. Д.: Кем проще стать: разработчиком или тестировщиком?
К. В.: Тестировщиком. Но не потому, что им быть проще. Просто порог входа ниже. Карьера разработчика начинается с позиции junior software developer, которая требует наличия минимальных знаний: язык программирования, основные алгоритмов и структур данных, знакомство с фреймворками и так далее. Чтобы стать джуном, ты уже должен быть разработчиком.
Карьера тестировщика начинается с уровня специалиста по ручному тестированию (manual testing): есть описание тестов, делай руками, вноси результаты в отчет. Очевидно, что начинать во втором случае проще.
Д. Д.: С финансовой точки зрения к чему выгоднее стремиться: к позиции тестировщика или программиста?
К. В.: С финансовой — к позиции программиста. Вот только смотри пункт про образ мышления. Есть мнение, что тот, кто рожден быть хорошим тестировщиком, будет паршивым программистом. И наоборот.
И опять особняком автоматизаторы: часто их зарплаты сопоставимы с программистами. Именно потому, что они, по факту, занимаются разработкой, и им платят, чтобы они действительно не ушли в разработку.
Д. Д.: Чтобы проверять написанные программистами приложения, тестировщик должен разбираться в коде лучше программистов. Этот тезис верный или нет?
К. В.: Это очень сильно зависит от подхода к тестированию в конкретной компании. Часто бывают случаи, что тестировщику вообще не приходится заглядывать в код. Особенно это может касаться различных embedded решений или прошивок устройств. Но знать, как разрабатывается продукт, как он работает, и почему сделано именно так, тестировщик должен.
Д. Д.: Можно ли рассматривать позицию тестировщика как один из простых способов войти в IT?
Д. Д.: Какими инструментами пользуются тестировщики: окружение, редакторы и IDE, библиотеки и фреймворки?
Все зависит от продуктового стека и того, чем автоматизируется тестирование. У меня:
Д. Д.: Где можно научиться тестировать ПО? Можно ли стать тестировщиком после курсов программирования?
К. В.: Не буду приводить примеров курсов, потому что ничего не могу о них сказать. Все коллеги-тестировщики учились сразу на производстве. После курсов программистов можно смело становится тестировщиком. Как и после других курсов. Потому как профессии отражают совершенно различный подход.
Станислав Урюпин: тестированию можно научиться только на практике
Станислав Урюпин, QA-инженер, руководитель волонтёрского образовательного проекта Sciberia
Дмитрий Дементий: Чем работа тестировщика отличается от работы программиста? И что есть общего в работе тестировщика и программиста?
Станислав Урюпин: Избегая формальных определений, отсылающих к различным стандартам, описание разницы в работе программиста и тестировщика можно свести к следующему виду — работа программиста заключается в создании приложений, а работа тестировщика заключается в обеспечении их гарантированной работоспособности. Тем не менее у этих профессий общие цели — создание полноценных программ, которые используют другие люди и системы.
Д. Д.: Кем проще стать: разработчиком или тестировщиком?
С. У.: Начать карьеру в IT проще тестировщиком, чем разработчиком. Но за последние годы сложность разрабатываемых программ и предъявляемых требований сильно возросли. Данные изменения не могли не отразиться на работе тестировщика. В связи с этим повысился порог вхождения в профессию.
Теперь начинающему тестировщику уже недостаточно знать в общих чертах теорию и то, как составляются тест-кейсы. Нужно знать многое: начиная от того, как устроена специфика работы в конкретной области тестирования, заканчивая представлениями о современных методологиях разработки.
Д. Д.: С финансовой точки зрения к чему выгоднее стремиться: к позиции тестировщика или программиста?
С. У.: На мой взгляд, неправильно подходить к выбору профессии, когда главным критерием выбора является уровень зарплаты. В этой позиции кроется одна уловка: очень сложно динамично развиваться в той профессиональной области, интерес к которой находится не на вершине мотивационного выбора. А не развиваясь динамично, нельзя рассчитывать на реальный рост зарплатных ожиданий. В любой области IT профессионалы высокого уровня могут получать достойную зарплату.
Д. Д.: Чтобы проверять написанные программистами приложения, тестировщик должен разбираться в коде лучше программистов. Этот тезис верный или нет?
С. У.: Этот тезис не является верным. Лучше самих программистов в коде не может и не должен разбираться кто-либо ещё. Тестировщики работают чаще всего по стратегии черного ящика, когда непосредственный доступ к коду закрыт для анализа. Зато тестировщику доступны различные способы и инструменты для определения работоспособности программ.
Д. Д.: Можно ли рассматривать позицию тестировщика как один из простых способов войти в IT?
С. У.: Можно, но лишь отчасти. Всё зависит от конкретных целей. Например, часто новички работу в тестировании рассматривают как промежуточный этап перед переходом в разработку. Тестирование и разработка — это разные области деятельности. В каждой из них найдутся характерные особенности, без которых продуктивная работа невозможна. Потому неизбежно придётся тратить ресурсы на погружение в предметную область.
Если цель — пройти в разработчики или иные направления работы в IT, такие, как DevOps или аналитика, стоит отдельно изучать эти направления. Но получится ли это делать без падения продуктивности работы в тестировании, вопрос открытый.
Д. Д.: Какими инструментами пользуются тестировщики: окружение, редакторы и IDE, библиотеки и фреймворки?
С. У.: Область тестирования обширна, и в ней много направлений, в которых найдутся свои инструменты. Есть инструменты, которыми пользуются тестировщики независимо от направления. Например, cистемы управления тестированием или системы отслеживания ошибок.
Д. Д.: Где можно научиться тестировать ПО? Можно ли стать тестировщиком после курсов программирования?
С. У.: Тестированию, как и многому другому, можно научиться только на практике. Если нет опыта, с которым можно начать карьеру, стоит изучить теорию и воспользоваться готовыми решениями для практики. Например, выбрать сайт или мобильное приложение и попробовать научиться составлять тест-кейсы или изучить на предмет возможных ошибок.
Необходимо отдавать себе отчет в том, что ни одни курсы в мире не могут гарантировать трудоустройства, пока человек сам не будет стараться найти работу. Если пройти успешно курсы по программированию, и появится желание попробовать себя в тестировании, то знания, полученные на курсах, облегчают вход в профессию, так как области деятельности тесно связаны между собой.
Заключение: работодателям нужны тестировщики, а соискателям нужно учиться и практиковаться
Тестировщик — не человек с улицы, а квалифицированный специалист, который должен много знать и уметь, постоянно практиковаться и развиваться. Работодатели готовы платить достойные зарплаты специалистам по автоматизированному тестированию. Чтобы стать тестировщиком, нужно учиться самостоятельно или на курсах. По мнению экспертов, позицию тестировщика можно считать одним из простых способов войти в отрасль информационных технологий.
Никогда не останавливайтесь: В программировании говорят, что нужно постоянно учиться даже для того, чтобы просто находиться на месте. Развивайтесь с нами — на Хекслете есть сотни курсов по разработке на разных языках и технологиях