<style>.lazy{display:none}</style>План обучения инженера по качеству

План обучения инженера по качеству

Подпишитесь на наш ТЕЛЕГРАМ КАНАЛ ПО АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ

Руководство для начинающих по навыкам, инструментам и технологиям, необходимым для карьеры инженера по качеству (QE – quality engineer) или разработчика ПО для автоматического тестирования (Software Development Engineer in Test, SDET).

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

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

Роль инженера по качествy

Прежде всего, что это за профессия?

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

Среди этих ролей всегда присутствуют инженеры по качеству (QE). QE – это не просто тестировщики или автоматизаторы, они расширяют возможности команд, привнося качественное мышление в каждый аспект создания программного обеспечения. Они являются экспертами в области обеспечения качества, автоматизации тестирования, анализа рисков, agile-процессов, CI/CD и всего остального, что может повлиять на качество продукта. QE сотрудничают со всеми другими подразделениями для обеспечения качества продукта с самого первого дня, еще до написания первой строки кода. В некоторых компаниях эта роль называется SDET (Software Development Engineer in Test), но в каждой организации она определяется по-своему. Поэтому то, чем занимается SDET или QE в одной компании, может не совпадать с тем, чем занимается QE в другой.

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

План обучения инженеров по качеству

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

(Если диаграмма слишком мала для просмотра на вашем мониторе, загрузите полноразмерное изображение здесь: PDF | PNG | SVG )

Roadmap

Как видите, здесь есть чему поучиться. Роль инженера по качеству очень обширна, и овладение всеми необходимыми навыками требует значительных усилий и временных затрат!

В каждом разделе основные понятия будут выделены белым цветом, подконцепции – зеленым, а инструменты, языки или фреймворки – синим. Зеленые или синие квадратики, прикрепленные к белым квадратикам следует интерпретировать как “пример”. Все приведенные примеры будут отражать лишь то, что, по нашему мнению, является наиболее актуальным или наиболее ценным для начинающего инженера по качеству.

Итак, переходим к плану обучения!

Основы обеспечения качества

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

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

Существуют также действия, описываемые нефункциональным тестированием, — такие, как производительность, безопасность, доступность, совместимость, локализация и т. д. Хотя вам и не нужно быть экспертом ни в одном из них, вы должны знать термины и тип тестирования, которые они описывают.

Кроме того, существуют инструменты для управления проектами, отслеживания дефектов, управления тестовыми случаями и создания баг-репортов. Для общего управления проектами наиболее распространена Jira, а для управления кейсами – такие инструменты, как Zephyr, TestLink и TestRail.

В этом разделе больше тем, чем мы можем описать в нашем пособии. Однако каждая из них важна – именно владение основами позволяет стать отличным инженером по качеству, а уверенное владение этими темами очень важно при дальнейшем обучении и развитии в данной сфере.

Основы жизненного цикла разработки программного обеспечения (SDLC)

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

Здесь вы должны понимать, что люди имеют в виду, когда говорят о водопадной модели и как такие вещи, как V-модель или спиральная модель, предшествовали использованию термина agile. Вам следует изучить основы современных подходов, таких как scrum и kanban, а также аргументы как за, так и против использования этих методологий в современной разработке ПО.

Хотя этот раздел может показаться излишне перегруженным теорией, наличие прочного фундамента в области основ SDLC(Software Development Life Cycle) определенно принесет свои дивиденды на пути к карьере инженера по качеству.

Основы Интернета

В 1995 г. Билл Гейтс написал знаменитую записку для руководителей Microsoft, в которой говорилось, что интернет стал “высшим уровнем важности” для компании. Он не ошибся, и сегодня практически все программное обеспечение в той или иной мере предназначено для интернета. Чтобы понять, как оно работает и почему ломается, необходимо знать, как устроен и работает интернет.

Хотя на первый взгляд это кажется сложным, не стоит отчаиваться. Вам не нужно глубокое понимание какой-то одной конкретной технологии, только базовые знания на уровне того, как все компоненты работают вместе. Например, не обязательно помнить, что приоритет пакета устанавливается во втором 8-битном слове заголовка пакета IPv4, но вы должны знать, что IP (“Internet Protocol”) относится к пакетам и является тем, что составляет IP в TCP/IP.

Другие важные интернет-технологии, с которыми следует ознакомиться, включают такие понятия, как DNS, HTTP и модель OSI. А вот такие вещи, как HTML/JS/CSS, можно отложить на потом.

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

Основы информатики и инженерии

Компьютерная инженерия – звучит пугающе. Не волнуйтесь, есть пара причин, почему вам не стоит переживать по этому поводу:

  1. Существует множество аспектов академической информатики и инженерии, которые просто не имеют отношения к качественному проектированию. Например, знание того, какие классы вычислительных задач можно отнести к категории NP, NP-полным или NP-сложным, является важной темой в академической информатике, но не очень поможет вам как инженеру по качеству.
  2. Хотя формальное образование в области информатики является хорошим фундаментом для качественной инженерии, оно не столько обязательно для будущего инженера по качеству. Все, чему можно научиться в ВУЗе, можно узнать самостоятельно, и почти все это можно бесплатно найти в Интернете.

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

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

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

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

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

Основы веб-приложений

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

Допустимый уровень понимания включает в себя знания о том, как разрабатываются веб-сайты с использованием технологий HTML, CSS и JavaScript. Вы должны понимать, как браузеры воспринимают эти языки и отображают их в виде интерфейса. После этого можно переходить к таким темам, как AJAX, одностраничные приложения (SPA) и прогрессивные веб-приложения (PWA). Затем вы можете изучить шифрование, системы управления контентом, а также рендеринг на стороне клиента и сервера и адаптивные и реактивные веб-приложения.

Нужно ли вам знать, как создавать веб-приложения с нуля? Нет, не обязательно. Но это не помешает. А если сделать это несколько раз на разных фреймворках (Angular, React и т.д.), то это значительно упростит процесс и даст более глубокие знания по их тестированию. Кроме того, тенденция развития веб-технологий такова, что все больше веб-приложений тестируется “под поверхностью”, например, с помощью имитации модели данных и тестирования поведения пользовательского интерфейса в виде модульных тестов или с помощью headless-браузеров. Создание нескольких простых веб-приложений даст вам представление о том, как можно использовать эти различные типы тестов, и позволит определить общую стратегию тестирования и автоматизации.

Программирование

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

Чтобы быть эффективным программистом, необходимо хорошо ориентироваться в среде, в которой будет вестись разработка. Это означает понимание интегрированной среды разработки (IDE) и оболочки. При программировании нужно думать о написании кода, а не о том, как найти ту или иную кнопку или настройку.

Помимо языка, необходимо изучить конструкции более высокого уровня, которые организуют код и являются основой хорошей практики программирования: паттерны проектирования, концепции DRY и SOLID и т.д. Эти концепции – и то, как они реализуются в коде, – зависят от характера языка, который вы решили изучать, например SOLID применяется к объектно-ориентированным языкам, а паттерны типа чистых функций – к функциональным.

В настоящее время мы рассматриваем следующие языки программирования: JavaScript/TypeScript, Java или C#, а также Python.

JavaScript является отличным начальным языком, поскольку лежит в основе всей веб-разработки. Кроме того, он постоянно проникает в другие области предприятия через такие фреймворки, как Node.js. Благодаря своему использованию в веб-разработке этот язык также широко применяется в автоматизации веб-приложений с помощью таких инструментов, как Protractor, WebdriverIO и Cypress.io. JavaScript постоянно входит в число самых популярных языков программирования.

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

После JavaScript/TypeScript мы бы посоветовали выбрать Java или C#. Эти языки очень похожи и широко используются в разработке корпоративных приложений. C# несколько более рискован, так как компании, использующие C#, как правило, “полностью погружены” в экосистему .NET / Microsoft, поэтому вы можете упустить шанс познакомиться с большим количеством других языков. Хотя Java и C# – далеко не новые языки, они являются рабочими лошадками индустрии программного обеспечения.

Говоря об интересных (но не новых!) языках, мы не можем не упомянуть Python. Технически Python существует с начала 90-х годов, но в последнее время наблюдается его активное возрождение из-за его использования в приложениях анализа данных, особенно в AI/ML. Конечно, это еще и просто мощный и доступный язык.

Важное предостережение: программирование – это одна из тех вещей, которые очень легко изучить, но очень трудно освоить. Это часто сбивает с толку людей, которые только начинают свой путь обучения или общаются с теми, кто находится на более высоком уровне. Иногда даже можно услышать такие слова: “Я выучил Python, но меня никто не берет на работу. Нечестно!”.

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

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

Архитектура предприятия

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

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

Помимо понимания того, как устроены корпоративные системы, необходимо также понимать, на чем они построены. Это означает знание вариантов IaaS, PaaS и SaaS, а также глубокое понимание облачных предложений от основных провайдеров, таких как AWS, GCP и Azure. Облачные технологии становятся вездесущими в современных архитектурах, поэтому мы не можем не подчеркнуть их важность. Все основные провайдеры облачных технологий предоставляют обширные учебные ресурсы.

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

Основы автоматизации тестирования

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

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

Нам также необходимо понимание того, как вписывается в эту картину автоматизация с низким или нулевым кодом, каковы преимущества и недостатки инструментов записи и воспроизведения, а также как используются языки BDD, такие как Gherkin.

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

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

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

Современная Agile-доставка

Прежде чем мы перейдем к различным видам автоматизации тестирования, необходимо сделать отступление в некоторые менее технические, но все же очень важные области. Если раньше мы рассматривали основы SDLC, то теперь нам необходимо подробнее остановиться на Agile-доставке.

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

Хотя каждая компания применяет методологию Agile по-своему (наиболее распространенная фраза об Agile — это крайне раздраженное «это не настоящий Agile!»), существует множество общих подходов, церемоний и терминов, с которыми вам, как инженеру по качеству, следует ознакомиться. К ним относятся такие вещи, как определение сюжета, определение критериев приемки, методы оценки сюжета, а также назначение таких распространенных церемоний, как стенд-ап, ретро и шоукейсы. Кроме того, полезным будет знакомство с типичными инструментами управления Agile-проектами. Наиболее распространенным из них является Jira, но также используются Rally, MS Project и другие. Приятным бонусом станет знакомство с такими приложениями, как Scaled Agile (SAFe), LeSS или Nexus.

Знание того, как работает ваша Agile-команда, и умение определить, когда она работает хорошо, а когда нет, очень важно для роли инженера по качеству. Часто это непонимание является первопричиной проблем с качеством ПО в дальнейшем.

Роль инженера по качеству

Чем именно занимается инженер по качеству? Где заканчивается его роль и начинается роль инженера-программиста? Как и когда инженер по качеству взаимодействует со всеми остальными участниками команды Agile-разработчиков? Важно получить четкие и ясные ответы на эти вопросы до начала работы.

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

Независимо от того, как работает ваша конкретная компания, полезно иметь общее представление о том, как различные технологические компании подходят к решению проблемы. Например, вы можете ознакомиться с тем, как Google тестирует программное обеспечение, прочитать о комбинированном инженерном подходе Microsoft, о помощи в обеспечении качества Atlassian, о модели Spotify и особенно (само собой!) об основных принципах инженерии качества Slalom Build.

Модульное тестирование

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

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

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

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

Автоматизация API

Автоматизация API — это еще один тип цикла обратной связи, который имеет решающее значение для любой нетривиальной программной системы и который должны глубоко понимать все инженеры по качеству. Хотя понятие API является достаточно гибким, обычно мы говорим о о службах REST, веб-сервисах, SOAP-сервисах, темах и очередях в потоковых архитектурах, файловых интерфейсах и, возможно, даже о бинарных протоколах нижнего уровня.

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

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

Существует два распространенных фреймворка для API: RestAssured и Karate. Но тестирование API может быть выполнено с помощью только программы запуска тестов (например, JUnit), библиотеки для взаимодействия с сервисом (например, HttpClient) и библиотеки утверждений (например, Hamcrest). Они есть в каждом языке программирования.

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

Автоматизация веб-интерфейса

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

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

Наиболее распространенным из них, безусловно, является Selenium и его оболочки и производные (WebDriver.io, Protractor, Appium и т.д.) Их слишком много, чтобы изучать все. Вместо этого постарайтесь понять, что именно делает Selenium и как он справляется с задачей управления браузерами. Как только вы поймете это и овладеете языками программирования, которые будете использовать, подобрать следующий фреймворк пользовательского интерфейса на основе Selenium не составит труда.

Помимо Selenium, существуют платформы автоматизации браузеров, которые пытаются обеспечить веб-автоматизацию без использования базового протокола Selenium WebDriver. Эти инструменты обычно взаимодействуют с API, специфичными для браузеров, например DevTools в Сhrome, и могут значительно упростить и расширить возможности автоматизации пользовательского интерфейса в этих браузерах, хотя и с некоторыми недостатками. К этой категории относятся такие инструменты, как Puppeteer и Playwright. Cypress.io – еще один новый и многообещающий инструмент из категории, не связанной с Selemium, который стоит изучить. Опять же, сами инструменты менее важны, чем знание принципов работы веб-автоматизации, что в сочетании с основами веб-архитектуры и программирования позволит вам быстро освоить любой новый инструмент.

Помимо selenium и “не selenium” UI автоматизации, существует множество коммерческих, проприетарных инструментов автоматизации. Они обычно ориентированы на менее технически подкованных пользователей и могут быть полезны для выполнения простых задач. Знание того, когда они уместны, а когда нет, а также способность разбираться в большом количестве маркетинговых материалов (мы используем ИИ, чтобы автоматизировать все бесплатно!), важно для понимания их роли по сравнению с подходами, более ориентированными на код.

Непрерывная интеграция, доставка и развертывание

Автоматизация тестирования наиболее ценна, когда она автоматически обеспечивает прямую и немедленную обратную связь со всеми изменениями в системе. Это означает интеграцию автоматизации тестирования с конвейерами непрерывной интеграции и непрерывной доставки/развертывания. Тесты, которые находятся в репозитории и запускаются только тогда, когда кто-то нажимает на них, быстро портятся и неизбежно выбрасываются в мусорное ведро. Как инженер по качеству, вы должны понимать концепции CI/CD, уметь работать с соответствующими инструментами и сотрудничать с инженерами devops и инженерами-программистами для реализации общего подхода к автоматизации тестирования, который будет полезен всем.

Насколько глубоко это понимание перейдет в реализацию, будет зависеть от конкретной команды, но, по нашему опыту, нередко инженеры по качеству принимают непосредственное участие в реализации конвейерной инфраструктуры. Это может означать написание конвейеров Jenkins, работу со сценариями Cloud Formation или другую технологию, используемую вашей командой. Независимо от того, какая технология используется, инженеры по качеству должны быть готовы оказать помощь или поддержку во всех видах CI/CD деятельности.

Стратегия CI/CD обязательно будет пересекаться со стратегией тестовой среды, и это еще одна область, с которой инженеры по качеству должны быть знакомы. Что такое входные проверки, когда следует использовать общие среды, какова зависимость между тестовыми средами и управлением тестовыми данными? Инженеры по качеству должны быть готовы ответить на все эти и другие вопросы.

Тестирование производительности

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

Тестирование производительности само по себе является глубокой и обширной темой. Существуют отдельные специалисты, которые занимаются только этим видом тестирования. Тем не менее вы должны понимать типы и номенклатуру этих тестов, инструменты, которые их поддерживают, и то, как эти тесты могут быть интегрированы в конвейеры CI/CD и Аgile-процессы.

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

Мобильное тестирование

Число пользователей мобильного Интернета превысило число пользователей компьютеров, поэтому тестирование мобильных интерфейсов не менее важно, чем тестирование веб-интерфейсов. Здесь необходимо понимать нюансы тестирования нативных и гибридных приложений и мобильных веб-интерфейсов. При работе с нативными приложениями важно знать, как тестировать платформы Android и iOS, поскольку различия, конечно же, имеются.

Автоматизация мобильных приложений сопряжена с целым рядом проблем, для решения которых используется множество инструментов и фреймворков. Существуют специализированные инструменты, такие как Espresso для Android и XCUITest для iOS, и кроссплатформенные инструменты, например Appium. Как и в случае с веб-автоматизацией, мы рекомендуем изучать инструменты, ориентированные на код, а не на графический интерфейс.

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

Тестирование доступности

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

В США, например, доступность определяется государственными стандартами 508 Accessibility Standards и Web Content Accessibility Guidelines (WCAG), разработанными консорциумом W3. Если вы собираетесь работать с веб- или мобильными интерфейсами, то понимание этих стандартов и инструментов сканирования, используемых для оценки их соответствия, очень важно.

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

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

Сюда входят такие понятия, как использование аутентификации/авторизации для ограничения доступа, принцип наименьших привилегий, принципы работы криптографии (например, шифрование с открытым ключом), а также понимание OWASP Top 10. Вы должны понимать терминологию безопасности, что означают векторы атак и поверхности, как некоторые уязвимости могут быть выявлены с помощью сканеров, а также основы тестирования на проникновение. Если вы не решите строить карьеру именно в области безопасности программного обеспечения, этих тем будет достаточно для начала работы в качестве инженера по качеству.

Подведение итогов

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

Перевод статьи «Quality Engineer Learning Roadmap».

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *