Тестировщик, тестер, QA-инженер, Software Quality Assurance Engineer - специалистов по функциональному тестированию программного обеспечения называют по-разному, но суть работы у всех одна: совместно с разработчиком программного обеспечения (ПО) они обеспечивают наилучшее качество программного продукта.

Общее описание

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

Моделируя различные ситуации, которые могут возникнуть в процессе использования программы, тестировщики пытаются выяснить, совпадает ли результат с первоначальными ожиданиями. О возникающих ошибках и некорректном поведении программы они сообщают разработчикам ПО, чтобы те смогли исправить их до того момента, когда приложение попадет в руки конечному потребителю.

Тестирование программного обеспечения многими молодыми ИТ-специалистами рассматривается как начало карьеры в сфере информационных технологий и первая ступень для получения опыта и накопления знаний в разработке ПО с целью дальнейшей работы программистом.

Образование

Ни в одном российском вузе не обучают такой профессии, как специалист по функциональному тестированию программного обеспечения, потому что в России только недавно стала формироваться индустрия производства ПО, и началось настоящее разделение труда в этой сфере.

Высшее техническое образование в области информационных технологий хоть и не является необходимым условием для соискателя на вакансию тестировщика, но, как правило, работодатели в первую очередь рассматривают именно таких кандидатов, поскольку подобный диплом свидетельствует о наличии у специалиста базовых навыков в программировании и знаний основных технологий. Читатель «Энциклопедии карьеры» Виталий Анатольевич Мальцев замечает: «Лично я жду от программиста знания принципов программирования, хорошего владения здравой логикой, умения учиться и адаптироваться к существующим задачам. И обязательно этот человек должен иметь определенный склад мышления. Если он не знает сегодня PHP, а завтра это знание ему понадобится, то он его изучит и будет применять».

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

Смежные карьеры

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

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

Функциональные обязанности

Среди основных обязанностей специалиста по функциональному тестированию ПО выделяются следующие:

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

Навыки

Тестировщик – специалист, обладающий хорошей памятью, умеющий быстро переключаться с одного типа задач на другой, способный не только написать код, покрывающий функционал, но придумать различные тесты и даже интуитивно предугадать, где может «свалиться» программа. Он должен разбираться хотя бы на уровне продвинутого пользователя в особенностях операционной системы, в которой производится тестирование, уметь пользоваться специальным ПО для автоматизированного тестирования и регистрации ошибок (WinRunner, TestComplete, TestExecute, TestRecorder), работать с необходимыми в профессиональной деятельности пакетами (различные bug-tracking системы), иметь базовые знания того языка программирования, на котором написана тестируемая программа. Также желательно наличие знаний в конкретной сфере, для которой разрабатывается софт. Например, если речь идет о программе 1С, то минимальные сведения в области бухгалтерии просто необходимы.

Из качеств, которыми необходимо обладать специалисту, можно выделить коммуникабельность и умение работать в команде, ведь в некоторых компаниях, к примеру, применяется XP-тестирование (работа в паре с другим тестировщиком). Не менее важны для соискателей терпение и усидчивость. Во-первых, потому что работа тестировщика – это кропотливый труд по проверке сотен вариантов функционирования одного модуля. Во-вторых, поскольку одной из основных обязанностей специалиста является документирование результатов своей работы (подготовка test-cases, test-plans и check-lists), а это достаточно трудоемкая задача, тем более что нередко документы приходится переписывать или редактировать от версии к версии. К тому же соискатель должен обладать здоровым любопытством, чтобы ему было интересно делать не только то, что указано в документации, а еще и пытаться экспериментировать.

Плюсы и минусы

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

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

Очевидный плюс профессии – возможность удаленной работы, причем расстояние отнюдь не имеет значения, будь то другой город или даже другая страна. Эта позиция является хорошим стартом для соискателей, готовых связать свою будущую деятельность со сферой ИТ, так как позволяет «войти в курс дела», на практике вникнув во все нюансы этой профессиональной области.

Оплата труда

В большинстве случаев уровень дохода тестировщиков составляет примерно 80% от размера оплаты труда программиста и в зависимости от их опыта работы варьируется от $700–800 у новичков до $1500–2000 у профессионалов.

Перспективы

Высококвалифицированные тестировщики на сегодняшний день очень востребованы на рынке труда. Таким специалистам имеет смысл строить свою карьеру в горизонтальном направлении – осваивать новые методики и технологии тестирования ПО, участвовать в различных проектах. Вертикальный же рост ограничен небольшим количеством ступеней, на которые можно подняться: ведущий тестировщик, руководитель группы тестирования, системный аналитик, руководитель проекта. Имея солидный опыт работы на последних двух позициях, довольно высоки шансы занять должность начальника отдела технического контроля компании.

За время своей работы в сфере тестирования, у меня сложилось своё, особое мнение об этой области, начиная с позиции младшего тестировщика (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. В случае, когда тестирование требуется всё-таки отдельное, то куда проще и эффективнее иметь поставленный менеджментом процесс жизненного цикла продукта и человека или команду инженеров, способных самостоятельно покрыть задачи развёртывания и тестирования продукта, т. е. людей, которые априори знают область, инструменты и методы, а не стадо обезьян, которых повесили на разработчиков или одного руководителя проекта.

Ремарка №1

Как ни удивительно, но этот простой тезис зачастую сознательно нарушается. Например, для аутсорсинговых компаний это хороший способ получить дополнительные FTE. В плане бизнеса попросту выгоднее продать побольше, что-то, имеющее низкую себестоимость. В опыте моей работы на Auriga, где заказчикам предоставлялись на почасовую оплату соответствующие ресурсы в количестве десятков человек - не единичный случай. Более того, такой план хорошо покрывает цели стаффирования проекта для клиента при минимальных затратах. Несмотря на то, что нагрузка на менеджера проектов значительно возрастает, при грамотном руководстве это пусть к созданию «кузницы кадров» за счёт проекта, привязки кадров к компании (обучение и рост навыка) при сравнительно большей цене покупке специалиста с рынка, и последующая перепродажа, ротация персонала на более требовательные проекты.

Ещё одной причиной такой стратегии является возможность покупки нецелевых кадров для клиента. Так уж получается, что требования к кадрам ваших работодателей или клиентов иногда бывают недальновидны (о чём речь пойдёт ниже), и меньшими затратами для компании (по деньгам и времени) является возможность покупки фиктивных кадров. Скажем, покупка такого рода «обезьян» на проект с параметром «20 лет стажа» (но, возможно будучи весьма посредственным специалистом). Это особо актуально в системе грейдов Junior/Standard/Senior многих компаний, особенно за пределами России, где требования к стажу и реалии немного иные.

Следующей, и, на мой взгляд, главной причиной, являются риски. Постановка задач на проекте для тестирования - это покрытие определённой функциональности и действий. Зачастую процессы можно автоматизировать, особенно в отношении регулярных активностей, регрессионного тестирования, т. е. в процессе тестирования создать ферму, процесс и инфраструктуру, часто масштабируемую, портируемую и переносимую на другие продукты и проекты с минимальными издержками. Сокращение «непосредственной» работы на проекте для тестировщика ведёт к двум следующим следствиям:

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

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

Тезис №2: Тестировщик - это инженерная профессия

Из-за мешанины с обезьянами в профессии тестировщиков хватает людей, далёких от инженерной сферы, и не имеющих подчас даже соответствующего технического образования. Это действительно грустно и печально, т. к. квалифицированных ресурсов на рынке тестировщиков сегодня действительно не хватает - грамотные специалисты предпочитают уходить в разработку (в лучшем случая близкую к теме аналитику), а те, что остаются, имеют скудное представление о жизненном цикле ПО, тестировании и языках программирования.

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

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

Несмотря на то, что я в подавляющем большинстве случаев слышу мнение, что процесс ревью кода, отладки (дебаггинг) и юнит-тестирования - прерогатива исключительно разработчиков, возьму на себя смелость утверждать, что это неправильный подход. Проблема исходит из недостаточной квалификации тестировщиков и неверного управления жизненным циклом ПО. Возможно, этот подход хорошо работает в маленьких проектах по TDD, но главная сила и возможность обеспечить высокое качество продукта - разбить сферы влияния, ответственности, обеспечить принцип раздельности (dissimilarity).Это сделает процесс разработки более прозрачным, отслеживаемым и позволит скомпенсировать «эффект замыленности глаза» у разработчиков, избежать «трюков» с их стороны.

Ремарка №2

В компании Liebherr Aerospace жёстко выстроены процессы и роли в компании. Чёткое следование специфичным для отрасли итеративным моделям. Тем не менее, инженерное крыло, инженерные должности называются для всех одинаково - Software Engineer. Акцент делается на том, что сотрудник в компании в первую очередь - специалист, инженер в области ПО. Значит, сотрудник должен разбираться в инженерных процессах, процессе разработки, тестирования, схемотехники и т.д. Тем не менее, среди инженеров присутствует обязательное разделение на специализацию: in Test, in Development, in Requirements, и пр.

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

То, что каждый из этапов и типов разработки и тестирования должен покрывать разные люди следует из требований международных стандартов, таких как DO-178B (для авиации), EN 50128 (для железнодорожного транспорта) или ГОСТ Р МЭК 60880 (для атомных электростанций), и обеспечивает, в конечном итоге высочайшую отказоустойчивость на уровне процессов и в том числе в части тестирования ПО.

Тезис №3: Метрики - ерунда, если нет работы в команде

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

На практике это означает, что бесполезно считать количество разработанных тестов (это метрика прогресса), найденных багов (в худшем случае) показателем эффективности команды тестирования, даже рейт регрессий, даже синтетических метрик на проекте (с использованием критериев важности и трудоймкости), не говоря уж о идиотских (но по-прежнему применяемых и для команды тестирования KSLOC\hour). Для менеджера проекта, возможно, будет неплохой метрикой CPI/SPI как KPI проекта, которая может базироваться на всех обозначенных и собранных тест-менеджером метриках. То есть, достаточно абстрактная и высокоуровневая оценка в зависимости от затраченных усилий и полученного результата. Но при условии, что команды работают как единый организм.

Для тестировщиков это означает, что они связующее, ведущее колесо процесса, которое сделает программное обеспечение работоспособным и соответствующим требованиям. В процессе тестирования это означает как само тестирование, так и предоставление теста повторяемости, документируемости, возможных проблем и решений проблемы (если это видно со стороны тестирования, если хватает квалификации), а так же перепроверку тестирования (VoV). Другими словами, задачей тестирования является как перепрогон и перепроверка всех возможных состояний, так и (в необходимом и достаточном случае) покрытие полной тест-стратегии и тест-плана (по крайней мере то, что обозначено в Quality Gates), вынесение багов и их разрешение через разработчиков ПО и спецификации. Т. е., с момента проверки и обнаружения бага ответственность на нём не «перекидывается» на разработчика, а сопровождается тестировщиком до его разрешения. Грубо говоря, тестировщик отвечает за баги, а разработчик - за фичи.

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

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

Ремарка №3

Несмотря на то, что описанная мною модель говорит о единстве и взаимосвязанности всех этапов процессов, сегодня тестировщиков правильнее классифицировать всё-таки на разработчиков самих тестов (акцентирующих силы и знания на методологии тестирования) и devops инженеров, обслуживающих инфраструктуру. Сегрегация функций имеет свои плюсы при достаточно большом размере проекта и хорошем финансировании, когда развитие, поддержку и тестирование инфраструктуры можно разнести между инженерами, в идеале - между экспертами-специалистами. Важным моментом является то, что тест-инженер всё-таки в первую очередь инженер, разработчик в тестировании, способный использовать различные инструменты для разрешения поставленной задачи. И только во вторую очередь - эксперт в какой-то определённом инструменте и программе. Знатоков инструментария, возможностей фреймворков правильнее классифицировать как отдельных инженеров, инженеров-инструменталистов (tool engineer).

Тезис №4: Тестировщик - центр процесса разработки ПО

В V-модели разработки ПО наглядно видно, что тестировщик участвует на всех этапах жизненного цикла.

Схожесть разработчика и тестировщика, размазанность границ области при наличии хорошей квалификации - главный показатель интереса в работе тестировщика. Конечно, можно утверждать, что причастность к продукту и его качеству в случае тестирования чёрного ящика является мотивационным фактором, но, на мой взгляд, человек, пришедший в техническую, инженерную область сделал это осознанно, с желанием развиваться и работать над собой. Поэтому возможность расширять свой кругозор, влиять на качество продукта, (пусть даже небольших вещей), проявлять активность, а также накладывать вето на выпуск продукта у тестировщика, по моему мнению, более весомые аргументы за профессию. А раз так, раз хороший тестировщик - не обезьяна, а инженер-исследователь, знаток, принимающий участие на почти на всех этапах жизненного цикла по (в отличие от ролей аналитиков, дизайнеров, разработчиков, и технических писателей), ответственный за качество продукта (не процесса, это к QA, так что под «качеством продукта» будем подразумевать соответствие заявленным и утверждённым требованиям и стандартам, чеклистам и прочая), то для поднятия качества продукта и развития себя, как специалиста, тест-инженер должен проявлять активную позицию. Он знает, как улучшить продукт. Знает, что такое «достаточно хорош», и как его, продукт или процесс, таким сделать, инициировать движение как инженера-разработчика, так и других команд и даже компаний. Например, в любых проектах бывают моменты простоя, который может быть допустим со стороны руководства. Обычно в это время сотрудники решают личные проблемы или занимаются самообразованием. В отношении работы разработчик может заняться рефакторингом, поизучать алгоритмы и перенести на свои проекты. А что делать тестировщику? Осваивать новые средства тестирования? Он-то ничего не делает без изначального пакета от разработчиков/аналитиков. В действительности, он может заняться автоматизацией своей деятельности или улучшением продуктов, им используемых, даже если он далёк от инфраструктуры и devops.

Ремарка №3

В Liebherr Aerospace жёсткий процесс резко ограничивал использование любых инструментов и жёстко формализовал процесс разработки и тестирования, т. е. простора для автоматизации оставалось не так много - даже вмешательство в багтрекер было запрещено. Тем не менее, такой процесс, как подготовка документации, был в такие периоды автоматизирован, пусть и с использованием не находящегося под запретом VBA для MS Office. А для процесса код ревью можно было улучшить статические анализаторы кода. Они не совсем удовлетворяли стандартам на проекте и порождали лишние сообщения, которые не фильтровались даже элементарным grep. Тем не менее, чтобы уменьшить время на ручное ревью кода, в рамках простоя мы работали на перспективу, улучшая сторонний продукт, такой как статический анализатор, подготавливая набор кейсов для него для имплементации нужных нам проверок.

Тезис №5: Тестирование - не место для фиксации на ключевых словах

Последней и самой странной темой, на мой взгляд, является весьма смутное представление о тестировании (даже о теории, не говоря о практике). Во многих компаниях отделы тестирования не оправдывают надежд, в некоторых даже дискредитировали себя и функционируют на малую часть от своей потенциальной эффективности по ряду факторов. Проблема проистекает как из-за отсутствия школы, так и из-за некомпетентности менеджмента. Ситуация весьма плачевная в отраслях, отдалённых от IT, даже где «деньги - не проблема» - там задачи ставятся по принципу «повысить качество продукта». Даже в IT-компаниях, где есть общее представление о процессах, есть целый ряд проблем, связанных с фиксацией на определённых ролях или инструментах, хотя к тестированию, повторюсь, такой подход плохо применим.

В одном из крупных инвестиционных банков, в котором у меня проходило собеседование, было схожее требование на позицию тест-менеджера: «повысить качество и уменьшить брак». Любую задачу можно решить. Хотя под покровом задач скрывается координация отделов по ряду различных продуктов, составление планов тестирования, организация тестирования, работа с разработчиками, составление базы кейсов и прочая. В действительности, ответственность за качество продуктов в компании логично взять на себя какому-нибудь «директору по качеству», оно же QA Director, а не просто руководителю отдела тестирования. Однако тут дело упирается в полномочия, которых на этой позиции нет, и в отсутствие группы, которая не планировалась вовсе (которая могла бы помочь тому-тому тому-то). То есть в компанию нужен человек-оркестр без команды. Разгадка тут простая: менеджмент ищет по ключевым словам, и считая качество в аббревиатуре QA панацеей от всех проблем, хотя она лежит в сфере стратегического топ-менеджмента и процессов, которые нужно спускать сверху с соответсвующими полномочиями и ресурсами.

В идеале управление качеством (QA) и тестирование две .

Проблема системная, т. к. весьма неплохо, когда HR ищут по ключевым словам вроде «нагрузочное тестирование», «функциональное». Но когда в процессе рассмотрения делается акцент не на навыки тестирования, не на активность и гибкость кандидата, а на конкретный инструмент - это уже проблема, особенно когда никакого тестирования нет в помине (есть обезьянничество), и не факт, что требуемый инструмент эффективнее того, который знает соискатель. Проблема в том, что знание мелкого нюанса или инструмента, на освоение которого уйдёт несколько часов, ставится во главе угла, выше знания языков программирования или теории. В одном из интервью было достаточно смешно было отвечать на вопросы: «назовите какую-нибудь книгу по тестированию» и, ответив про Сэма Канера, услышать: «мы такого не знаем, а про жизненный цикл бага что-нибудь читали?». Это было бы смешно, если бы не было так грустно. Грустно, когда HR сообщает об отказе из-за отсутствия опыта у кандидата, хотя дело к неправильном расставлении акцентов.

Найти хорошего тестировщика - большая проблема, т. к. инженер-тестировщик - это, в идеале, человек, который разрешает технические проблемы, связанные с разработкой ПО, эдакий problem solver. Такому человеку, помимо технических навыков очень важно иметь внимательность, пытливый ум, быть активным и уметь донести мысль и отстоять свою точку зрения на любом уровне.В каком-то роде, тестировщики - это исследователи из мира разработки ПО. Поэтому в руках инженера-тестировщика легко узнаваемый символ - лупа (линза), наблюдающая за жучками. Как нельзя лучше характеризует она работу тестировщика: используется как по прямому назначению для выявления дефектов, так и для «прожигания дырочек», с её помощью можно добывать огонь и даже, имея целую систему линз, наблюдать за звёздами. Главное - уметь это делать.

Ремарка №5

В компании Intel главенствует подход, в котором инструменты выбираются из предпочтений сотрудников на проекте. Это означает, что, в целом, неважно, какой инструмент и язык выбрать для решения задачи, главное - её решить. Сосуществование трёх разных тест инженеров, пишущих на трёх разных языках вполне допустимо, если проблема решается, решается эффективно и накладные расходы на поддержку разумны, а процесс документируется. Кроме того, многие используемые инструменты являются бесплатными, open-source или собственной разработки. На сегодняшний день существует огромное количество инструментов, с помощью которых возможно решать разнообразные задачи, и выбор инструментов не должен ограничивать возможности инженера. Однако, если для задачи действительно требуется использовать какой-то инструмент, отличный от свободно доступного, то при наличии чёткого понимания и обоснования, можно купить и использовать его. Это опять-таки соответствует целям бизнеса - не забивать гвозди микроскопом, не работать эффективно, выжимая максимум из инструментов, если квалификация инженеров позволяет обойтись «малыми потерями». Хорошей альтернативой является также участие в открытых проектах и инвестиции в них для последующего использования для собственных нужд. Такой подход убивает двух зайцев (свои нужды) и задачи и создаёт инструменты для всего общества в свободном использовании.

Вместо выводов

Тестировщик - это больше, чем профессия. Это образ проактивной жизни и стремления эту жизнь сделать лучше для всех посильными и эффективными средствами. Цели тестировщика в отношении продукта наиболее близки к целям бизнеса и стратегической цели компании в отношении этого продукта, и в то же время глубоки внутри компании в роли исследователя. А раз так, то главные его качества - это энергия, знания и гибкость. Но в тоже время работа тестировщика – это не всеобщее знание и ответственность за качество продукта и качество услуг. У тестирования есть границы: с одной стороны ограниченные проектом и требованиями в нём (менеджмент проекта и установленный жизненный цикл программы), и с другой – процессами, за которые отвечает QA. Но о различия QA от тестирования совсем другой разговор.

IT развивается, постоянно создаются новые продукты, которые требуют проверки перед тем, как выйти на рынок, чтобы конечный пользователь получил качественный продукт. Именно от тестировщика зависит, в каком состоянии продукт попадет на рынок.

Кто такой тестировщик

В любом деле важно вовремя получать отклик, отзыв о своей работе, желательно, чтобы они были объективными. С программистами то же самое - чтобы достигать высоких результатов, нужно как можно скорее получать положительные и отрицательные отзывы о проделанной работе. Задача тестировщика - давать программистам обратную связь. Чем быстрее получен отклик, тем скорее программисты исправят ошибку, если она есть.

Если говорить конкретно кто такой тестировщик и чем он занимается, то это человек, который проверяет работу, сделанную командой разработки, указывает на ошибки в работе программного обеспечения (сайта, приложения, чатбота и т.д.).

Достаточно сложно дать определение слову «тестирование», но это не:

• разработка - даже если тестировщик умеет писать код, тестирование - это не разработка ПО;
• анализ и сбор данных - хоть в работе и приходится уточнять данные, анализировать их, но эта работа делается только по надобности, не постоянно;
• техническое писательство - при этом тестировщику приходится документировать свою работу и тесты.

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

Виды тестирования

Не бывает универсальных тестировщиков, иначе работа была бы некачественной. Есть несколько видов тестирования со своими особенностями.

Функциональное тестирование

Функциональное тестирование в своей основе имеет анализ спецификаций функциональности определенных компонентов или системы в целом. Тесты в этом виде основываются на функциях, которые выполняет система. Обычно эти функции описаны в требованиях, спецификациях.

Основное достоинство функционального тестирования - имитация фактического использования системы во время тестирования. Недостатка 2:

• возможность упущения логических ошибок в ПО;
• избыточное тестирование.

Нагрузочное тестирование

Нагрузочное тестирование еще называют тестированием производительности. Это автоматизированный вид тестирования, при котором имитируется работа системы.

Основная задача такого вида тестирования - определение возможностей работы приложения под определенными нагрузками. При этом обязательно учитываются:

• время выполнения операций при определенной интенсивности их выполнения;
• количество пользователей, которые единовременно используют приложение;
• границы приемлемой производительности при усилении нагрузки;
• производительность на очень высоких уровнях нагрузки.

Также здесь тестируется надежность приложения. Это определяется по работоспособности приложения при многочасовом тестированием ПО со средней нагрузкой.

Автоматизированное тестирование

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

• запуск;
• инициализация;
• выполнение теста;
• анализ;
• выдача результата.

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

Юзабилити-тестирование

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

Юзабилити-тестирование может пригодиться в нескольких случаях:

• тестирование удобства интерфейса;
• сравнение продукта с конкурентами;
• сравнение нескольких версий интерфейсов одного продукта.

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

Интеграционное тестирование

Суть интеграционного тестирования - в проверке связи компонентов целого продукта и их взаимодействия с другими частями системы.

Есть несколько типов этого тестирования:

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

Конфигурационное тестирование

Направлено на проверку работоспособности продукта в различных конфигурациях:

• платформы;
• драйверы;
• компьютерные конфигурации.

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

На клиентском уровне выясняется насколько удобно пользоваться продуктом, его функциональность.

Тестирование безопасности

Тестирование безопасности проводится для проверки безопасности, анализа рисков, связанных с хаккер-атаками и вирусами. Главная задача тестирования безопасности - установить максимальную безопасность и комфорт при использовании продукта.

Принципы тестирования:

• доступность;
• конфиденциальность;
• целостность.

Игровое тестирование

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

Какие навыки нужны тестировщику?

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

Требования к тестировщику ПО (плюс / минус в зависимости от компании):

• Понимание что такое баг, тест-кейс, стратегия тестирования (и умение ее выстраивать), отчет об ошибке;
• Базовое знакомство с автоматизированным тестированием;
• Быстрая обучаемость, приспосабливаемость к стремительно меняющейся среде;
• Умение работать с базой данных - основными понятиями и запросами;
• Коммуникабельность - важно для взаимодействия с командой;
• Аналитический склад ума;
• Умение быстро обрабатывать большое количество информации.

Также могут пригодиться знания java, python для тестировщика и другие языки программирования. Но в то же время их знание может мешать работе, так как тестировщик может пытаться исправить чужие ошибки, то есть, заниматься не своей работой. А это снижает качество.

Зарплата тестировщика

Средняя зарплата тестировщика в Москве - около 70 тысяч рублей, в Питере - 50. Немного отстает Екатеринбург - 45 тысяч рублей. В городах поменьше и зарплата меньше. В Волгограде, Воронеже, Перми, Уфе, Казани зарплата составляет 33-40 тысяч рублей.

Начинающие тестировщики без опыта могут рассчитывать на зарплату, составляющую половину или 2/3 части от средней платы тестировщика по городу.

Тестировщик с высшим образованием и опытом работы от 1 года может рассчитывать на зарплату от 65 тысяч в Питере и от 80 в Москве. Максимальный доход в столице - 150 тысяч, в Санкт-Петербурге - 120 тысяч рублей.

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

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

Как стать тестировщиком

Чтобы стать тестировщиком, не обязательно иметь высшее образование. Важно уметь концентрировать внимание, не упускать мелочи. Стать тестировщиком можно даже с нуля, но при этом стоит все же иметь какие-то знания. Например, нужно уметь обращаться с компьютером и программами на “ты”, уметь ориентироваться в незнакомых средах. Также хорошо знать хотя бы один язык программирования, понимать основы базы данных.

Если есть высшее образование - хорошо. В компаниях предпочитают соискателей с техническим образованием, так как именно они имеют аналитический склад ума. Но если образование гуманитарное, не стоит отчаиваться. Нужно создать резюме, в котором разместить информацию о том, какими проектами приходилось заниматься. Даже если нет опыта работы, но есть курсовые работы с практической частью, дипломная работа, опыт прохождения практики в IT - все это стоит вписать в резюме для привлечения внимания. Обязательно указать свои основные достоинства, которые могут пригодиться в работе тестировщиком. Это могут быть: внимание к деталям, усидчивость, знакомство с компьютерным софтом, эмпатия, знание языков программирования, знание иностранных языков.

Подготавливаясь к собеседованию, стоит ознакомиться с темами:

• обеспечение качества ПО;
• что такое тестирование;
• виды тестирования;
• уровни тестирования;
• тестовые артефакты и их предназначение;
• знакомство с тест-дизайном;
• автоматизация тестирования и ее виды;
• метрики тестирования, как их использовать.

Курсы для тестировщиков

Самый простой способ изучить азы тестирования - . Главное - чтобы они были качественные, а кураторы не лили “воду”.

Существуют такие площадки и школы как ГикБрейнс, Testbase, академия Алексея Сухорукова и другие. Можно выбрать уровень обучения, а можно пройти стресс-курс, чтобы узнать, каких знаний недостаточно.

При МГТУ имени Баумана действует учебный центр, регулярно проводящий курсы по тестированию. Их ведут преподаватели-практики.

Нельзя упускать возможности посетить стажировки. Придется работать бесплатно, но можно набраться опыта. Найти стажировки можно на сайте хедхатера или по запросу в гугл “стажировка тестировщик в городе (название города)”.

Открытых предложений о стажировке не так много, но можно самостоятельно предлагать свои услуги компаниям, производящим софт, игры, приложения, сайты.

Стоит ли быть тестировщиком?

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

• нужно быть предельно внимательным, педантичным, усидчивым;
• большая ответственность;
• тестированию не обучают в университете.

• достаточно просто самому изучить хотя бы основы тестирования;
• работодатели берут на работу тестировщиков без опыта;
• воспитание в себе силы воли, терпения.

Тестирование ПО. Уровень 1. 1 месяц.
Теоретические знания и начальный опыт

В настоящее время в IT-сфере как никогда стала актуальной профессия тестировщика. В первую очередь, высок спрос на специалистов, занимающихся тестированием программного обеспечения. Основными обязанностями таких сотрудников являются выявление ошибок в работе программ и моделирование различных ситуаций, связанных с их дополнительной нагрузкой. Таким образом, обнаруживая и описывая погрешности, направляя отчеты о них для внесения исправлений в программу, тестировщики постоянно взаимодействуют с командой разработки. Курс "Тестировщик ПО. Уровень 1" от GeekBrains предназначен для тех, кто хочет начать карьеру в тестировании программных продуктов. В его рамках рассматриваются теория и практика создания тест-кейсов, тест-комплектов, оформления багов и отчетов по результатам тестирования. Данный курс - это 8 практических занятий, где Вы получите знания и навыки, необходимые для того, чтоб легко включиться в работу над созданием и улучшением IT-проекта.

Урок 1. Основные понятия в тестировании

Что представляет собой тестирование. Как определить качество ПО (стандарты ISO, критерии качества, метрики). Категории программных ошибок. Терминология.

Урок 2. Место тестирования в процессе разработки ПО

Цикл разработки ПО. Цикл тестирования ПО. Типы тестов в процессе разработки ПО. Соответствие тестирования методологии разработки ПО.

Урок 3. Разработка тест-кейсов

Определение и структура тест-кейсов. Характеристики хорошего теста. Аксиомы тестирования. Поддерживаемость тест-кейсов. Системы менеджмента качества. Тест-комплекты. Чек-листы. Подготовка тестовых данных.

Урок 4. Классы эквивалентности и граничные условия. Планирование и работа с требованиями

Определение и поиск Классов эквивалентности. Границы классов эквивалентности. Работа с требованиями к ПО. Участие в планировании релиза ПО. Что делать, если нет документации.

Урок 5. Работа с багтрекером

Определение и функции багтрекера. Как правильно формулировать задачи. Жизненный цикл (workflow) ошибок. Оперативное отслеживание задач в багтрекере.

Урок 6. Регрессионное тестирование

Назначение регрессионного тестирования. В каких случаях требуется проводить регрессионное тестирование. Выбор тест-комплектов для регрессионного тестирования. Приоритизация и оптимизация тест-комплектов.

Урок 7. Организация процесса тестирования

Должностная иерархия в тестировании. Планирование и оценка сроков на тестирование. Критерий начала/завершения тестирования. Отчетность по результатам тестирования. Подготовка рабочего места.

Урок 8. Тестирование пользовательского интерфейса

Особенности тестирования пользовательских интерфейсов GUI и web-приложений.

Тестирование ПО. Уровень 2. 1 месяц.
Работа с документацией и тестирование приложений

Многие считают, что профессия тестировщика является скучной и однообразной. Однако это мнение несправедливо. Профессиональный тестировщик - это, в первую очередь, человек, умеющий творчески подойти к решению стоящих перед ним задач. Опыт, приобретаемый в рамках этой профессии, может стать ступенью к карьере программиста. Важной особенностью работы тестировщика является возможность полноценного аутсорса и фриланса. Курс "Тестировщик ПО. Уровень 2" от GeekBrains предназначен для тех, кто уже знаком с основами тестирования и хочет получить более глубокие знания и навыки, требуемые для начала карьеры в IT-сфере. В его рамках разбираются способы исследования тестируемого ПО, изучаются техники определения необходимого количества тестов и способы визуализации тестируемого функционала. Данный курс - это 8 практических занятий, после которых Вы сможете проявить себя в качестве экспертного пользователя программного обеспечения, имеющего собственное видение наилучшей организации процесса тестирования.

Урок 1. Тест-анализ. Исследование ПО

Типы и цели исследования ПО. Декомпозиция приложения.

Урок 2. Доменное тестирование и комбинации параметров

Урок 3. Тестовая комбинаторика

Создание тестового набора. Минимальные проверки. Перебор значений. Атомарные проверки. Pairwise. Метод взаимосвязанных проверок.

Урок 4. Тестирование состояний и переходов

Анализ ПО на возможные состояния и переходы. Выявление жизненных циклов сущностей и комбинация состояний. Выбор валидных проверок.

Урок 5. Тест-анализ на основе бизнес-логики

Выбор условий бизнес-требования. Создание таблиц решений. Комбинирование тестов на основе таблицы решений.

Урок 6. Тест-анализ на основе рисков (предугадывание ошибок)

Определение тестируемого функционала ПО. Выявление потенциальных ошибок и их градация. Определение стратегии.

Урок 7. Стратегия тестирования

Цели и задачи стратегии тестирования. Выбор подходящих техник в зависимости от функционала и особенностей. Учёт нефункционального тестирования.

Урок 8. Оценка эффективности тестов

Оценка тестового покрытия. Оценка эффективности тестов.

Введение в автоматизацию тестирования. 1 месяц.
Автоматизированное тестирование

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

Урок 1. Введение в автоматизированное тестирование

Что такое автоматизированное тестирование; какие разновидности автоматизированного тестирования бывают; проектный выбор: ручное или автоматизированное; черный и белый ящик при автоматизации; обзор и выбор инструментария.

Урок 2. Стратегия автоматизированного тестирования. Практическое создание тестов при помощи Autoit.

Принятие решения о введении автоматизации; проектирование автотестов; стратегии автоматизированного тестирования; процесс развертывания автоматизации; тестовое окружение для проведения автоматизации; создание автотеста при помощи Autoit.

Урок 3. Виды автоматизированного тестирования

Виды автоматизированного тестирования; автоматизированное функциональное тестирование; инструменты юзабилити тестирования; автоматизированное нагрузочное тестирование.

Урок 4. Проект Selenium и его составляющие.

Цели, задачи, особенности Selenium. Selenium WebDriver. Selenium RC. Selenium Server. Selenium Grid. Пример использования Selenium IDE на практике.

Урок 5. Автоматизированное нагрузочное тестирование на примере Apache Jmeter

Нагрузочное тестирование; принципы и практика построения нагрузочных тестов; обзор инструментов; пример использования Apache Jmeter.

Урок 6. Автоматизированное мобильное тестирование

Тестирование мобильных приложений; автоматизированные инструменты – обзор, выбор; нагрузочное тестирование; мобильные эмуляторы; мобильные фермы.

Урок 7. Автоматизация процесса тестирования

Автоматизация процесса тестирование и создания тестов; утилиты для автоматизации процессов тестирования; генерация тестов; фреймворки; плагины.

Урок 8. Работа с требованиями и постановками задач

Требования, задачи; системы работы с требованиями и постановкой задач; системы багтрекинга; настраивание процессов проведения тестирования и их автоматизация и инструментарий.

Основы баз данных. 20 уроков.
Проектирование БД и запросы SQL

Базы данных (БД) - это системы хранения и обработки данных, для доступа к которым используется язык SQL (Structured Query Language). Любой современный сайт, игра или настольное приложение нуждаются в хранении данных. На данный момент существует множество различных систем управления базами данных (СУБД), самой популярной является MySQL. “Основы баз данных” - это 20 интенсивных видео-уроков (по 10 минут), где мы вместе пройдём все этапы проектирования БД на примере интернет-магазина с использованием языка запросов SQL. После этого курса вы сможете использовать различные базы данных, такие как MS SQL и Postgre Sql, так как синтаксис языка SQL для них практически не отличается.

Урок 1. Реляционные базы данных

Чем отличается БД от СУБД; какие базы данных называются реляционными; обзор современных СУБД.

Урок 2. Установка СУБД

Установка СУБД MySql и графического приложения Mysql Workbench.

Урок 3. Проектирование базы данных, нормальные формы

Проектирование данных в Excel; нормальные формы; первичный ключ.

Урок 4. SQL-команда CREATE

Создание таблиц в графическом интерфейсе MySql Workbench; команда CREATE; типы данных; работа в консоли.

Урок 5. SQL-команда INSERT

Заполнение таблиц данными с помощью графического интерфейса; команда INSERT; AUTO INCREMENT.

Урок 7. SQL-команды DISTINCT, ORDER BY, LIMIT

Получение и фильтрация данных с помощью SQL-команд DISTINCT и LIMIT; сортировка с помощью команды ORDER BY.

Урок 9. Согласованность данных

Понятие согласованности или консистентности данных.

Урок 10. Внешний ключ

Понятие внешнего ключа и ограничений на значения столбцов; FOREIGN KEY CONSTRAINTS.

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

Тестировщик ПО: что это такое

Сегодня большинство электронных устройств работает корректно только благодаря встроенным в них программам. Их написанием занимаются программисты всех мастей и уровня подготовки. И поверьте, их количество действительно захватывает дух. Так, ежедневно создается не одна тысяча программ: начиная с простых калькуляторов и заканчивая искусственным интеллектом для высокотехнологических машин.

И, как в любом производстве, продукт нельзя выпустить в широкие массы, заранее не проверив его на дефекты. Так вот, тестировщик ПО (программного обеспечения) - это человек, который занимается полевым испытанием программ. При этом он может быть как штатным сотрудником компании, так работающим на себя фрилансером.

Зачем нужны тестировщики программ

При создании программ используются различные языки программирования. Это может быть C++, JavaScript, Python и так далее. После того как продукт будет завершен, его первым делом проверяет сам автор. Но, так как он является творцом программы, он не всегда может объективно оценить качество полученного товара. Не говоря уже о том, что у него может попросту не хватить времени для модуляции всех возможных способов ее применения.

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

Основные обязанности тестировщика программ

Тестировщик ПО - это профессия, которая требует основательного подхода к делу. Здесь нельзя работать в полсилы, так как это непременно скажется на репутации специалиста. Что же касается самих обязанностей, то они состоят из следующих пунктов:

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

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

Обучение профессии

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

Однако, стать тестировщиком ПО можно и без специализированного образования. Так сказать, обучиться всему самостоятельно. Благо, сегодня это не проблема, так как в сети есть множество познавательных курсов, способных наглядно продемонстрировать все тонкости данной работы.

К тому же можно испытать свою судьбу и попытаться попасть на подготовленные семинары, которые проводятся во многих организациях, производящих ПО. Например, компания GlobalLogic периодически проводит обучающие курсы специально для тестировщиков ПО. Более того, окончив их, человек может стать одним из ее сотрудников, после чего начать работать в ее штате или удаленно, в качестве фрилансера.

Какими навыками должен обладать уважающий себя специалист

Тестировщик ПО без опыта может найти себе работу, а вот специалист, не знающий основ - никогда. Однако, какие они, азы профессии? Каким же багажом знаний должен обладать каждый уважающий себя тестер?

• Во-первых, такой специалист должен быть знаком с основами программирования, дабы иметь возможность конкурировать на рынке труда.
• Во-вторых, придется запомнить принципы построения программного обеспечения и администрирования ОС.
• В-третьих, научиться работать с общепринятыми базами данных.
• В-четвертых, изучить особый язык без которого сегодня уже не обойтись.

Помимо этого, тестировщик должен хорошо владеть английским языком, так как он является доминантным в мире программирования. Более того, со временем придется довести его уровень до идеального, а также изучить все тонкости технического стиля.

Наработка практических навыков

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

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

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

Где искать прибыльную работу

Итак, допустим, вы уже опытный тестировщик ПО: с чего начать поиски перспективной работы? Что же, первым делом стоит просмотреть объявления на онлайн-биржах труда и форумах программистов. Периодически там попадаются хорошие предложения, способные приносить стабильный доход.

Однако, не стоит рассчитывать только на удачу. Если у вас есть и неплохое резюме, то можно подать несколько заявок в ИТ-компании. Руководство любит целеустремленных специалистов, а посему, подобная инициатива может принести свои плоды. Особенно если нацелиться на те компании, которые занимаются производством качественного софта.

Если же с постоянным местом на данном этапе не везет, то можно стать фрилансером. Хорошо проявивший себя тестировщик ПО, удаленно работающий на дому, способен заработать не меньше штатного коллеги. Единственная разница заключается в том, что вместо одного нанимателя у него будет несколько.

Плюсы и минусы профессии

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

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

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

Оплата труда

Довольно сложно вывести среднеарифметическую зарплату тестировщика ПО. Это связано с тем, что она зависит от того, насколько удачлив специалист. Так, можно взять один заказ на 10 тыс. рублей и сделать его за неделю, а можно получить работу на 20 тыс. рублей и не одолеть ее за целый месяц.

И все же можно с уверенностью сказать, что доход начинающего тестера варьируется в пределах 10-15 тыс. рублей в месяц. Опытный специалист может заработать эти же деньги в два раза быстрее. А штатный сотрудник престижной фирмы и вовсе получает около 40-45 тыс. рублей.