Базовое руководство для тестировщиков и разработчиков — навыки, инструменты, технологии.
Что нужно знать чтобы стать тестировщиком? Какие языки программирования надо знать, какие инструменты освоить, какие навыки шлифовать? Что является критически важным, что является важным но необязательным, или может быть есть технологии уже нерелевантные в 2021 году?
Ответить сложно. В идеале тестировщик должен владеть базовыми компьютерными дисциплинами, базовыми понятиями в своей специальности коротко именуемой “QA”, и далее вплоть до свежайших фреймворков для автоматизации, он должен знать специфические наборы приложений работающих в связке, и специальные инструменты тестирования. Всё перечислить невозможно. В данном руководстве мы пройдемся по всем навыкам, инструментам и технологиям для начинающих тестировщиков.
Роль тестировщика
Во первых, нужно разобраться, кто такой тестировщик?
Делать хороший софт, мы считаем, лучше всего получается у небольших, многофункциональных, и дружных команд. “Многофункциональный” здесь значит, что команда сама обладает всеми ролями и навыками, нужными для создания программного решения, и не привлекает к разработке какие-то внешние команды, обладающие специфическими умениями.
Одна из важнейших ролей в команде — тестировщик. Тестировщики не просто тестируют или автоматизируют тестирование, они усиливают команду тем, что смотрят на софт с точки зрения качества.
Хороший тестировщик является экспертом в собственно том, что называется quality assurance — обеспечении качества программного обеспечения, но также и в автоматизации тестирования, он умеет анализировать риски, разбирается в Agile, участвует в непрерывной интеграции и развертывании (CI/CD), и в других важных вещах, влияющих на качество итогового продукта. Тестировщики взаимодействуют с другими участниками команды, гарантируя качество начиная с первого дня, с первой презентации, еще до того как написана первая строчка кода.
В некоторых компаниях эта роль обозначается как SDET (Software Development Engineer in Test, разработчик в должности тестировщика), но в разных компаниях роли могут расписываться немного по-разному, и то что делает SDET/QA в одной компании, может отличаться от того, что он делает в другой.
Данное руководство описывает роль тестировщика, характерную для большинства компаний и оно несомненно будет релевантным для любого человека, приходящего в тестирование.
Дорожная карта обучения тестировщика
Сначала мы планировали делать нашу дорожную карту простой, но количество тем и скиллов оказалось столь большим, что мы решили разделить их по темам. Как будет понятно далее, в этой сфере существуют сотни тем, здесь все они собраны в более-менее понятный вид из 18 самых важных тем. Не нужно пытаться охватить все сразу, далее в статье мы остановимся на каждой теме подробнее.
(если карта не помещается на ваш экран, откройте картинку в новой вкладке или скачайте полноразмерную версию: PDF | PNG | SVG)
Как видно выше, придется учиться много. Роль тестировщика широка, и обучение всем релевантным скиллам — важная инвестиция в себя!
Итак, перейдем к карте.
Quality Assurance — обеспечение качества ПО
Начнем с основ. Сильная теоретическая база критически важна для успешной карьеры, каждая тема далее — обязательна для изучения, поскольку эти темы являются фундаментальными.
Для начала давайте уточним, что имеется в виду под понятием «качество программного обеспечения». Далее рассмотрим, что такое тест-кейсы, как группировать тест-кейсы в наборы (test suites), как писать планы тестирования, применяя определенные методики поиска дефектов. Это так называемые кейсы с экстремальными значениями (edge cases), классы эквивалентности (equivalence classes), анализ граничных значений (boundary analysis), комбинаторный анализ данных (combinatorial analysis), и тестирование исходя из рисков (risk-based testing).
Как видим, для описания методики тестирования используется достаточно специфическая терминология, поэтому важно овладеть понятиями, позволяющими описывать, классифицировать и группировать тест-кейсы и типы тестов. В первую очередь важно понимание, что такое тестирование методом белого/черного/серого ящика (black box, white box, grey box), функциональное и нефункциональное тестирование, так называемые позитивные и негативные сценарии тестирования, статическое и динамическое тестирование.
Нефункциональное тестирование касается таких характеристик софта, как производительность, безопасность, удобство пользования, совместимость, локализация, и подобное. Необязательно быть экспертом в каждой из этих сфер, и от новичка этого не ждут, но нужно иметь понятие о них, и их тестировании.
Прежде всего, нужно освоить следующие инструменты — для управления проектами, для отслеживания багов, и инструменты отчетности. Речь идет о Jira — инструменте управления проектами, и об инструментах управления тест-кейсами (Zephyr, TestLink, и TestRail).
Хорошее владение фундаментальными для тестировщика инструментами делает его востребованным специалистом, является критически важным для быстрого продвижения в профессии.
Жизненный цикл разработки (SDLC)
Разработка уже давно перестала быть делом одиночек, и за некоторыми исключениями вроде Git или Minecraft, весь современный софт пишется командами разработчиков. Даже тестировщик-новичок знает, как много нужно людей, чтобы разработать и отправить клиенту качественный продукт. Жизненный цикл разработки — достаточно широкое понятие, мы не будем углубляться в методологии и философию разработки (сделаем это позже), сейчас надо выяснить, какие методологии сейчас релевантны, а какие вышли из употребления.
На этом этапе нужно усвоить, что такое модель водопада, как V-модель (у нас есть отдельная статья на эту тему) и спиральная модель повлияли на создание концепции Agile. Мы должны ознакомиться с основами современных методологий — это Scrum (скрам) и Канбан (kanban), и понять, когда и почему применять их.
Хотя этот этап может показаться “слишком теоретическим” и утомительным, глубокое понимание жизненного цикла разработки обязательно скажется в виде быстрой карьеры.
Интернет
В далеком 1995 году Билл Гейтс написал записку директорам Майкрософта, в которой утверждал, что интернет стал невероятно важным для развития его компании. Он не ошибся тогда, а сейчас в 2021 году почти весь софт, в том или ином виде является «интернет-софтом», то есть функционально привязан к Сети. Чтобы понять, как работает современный софт, (и почему иногда не работает), нужно сначала понимать, как устроен интернет.
Это лишь кажется теоретическим и не очень нужным обычному тестировщику. Глубокого понимания в каждой из технологий интернета может и не нужно, но необходимо знать, как это все работает в связке. К примеру, необязательно знать, что приоритет пакета выставляется во втором 8-битном слове в заголовке IPv4-пакета, но обязательно знать, что понятие IP относится к пакетам, и что означает IP в слове TCP-IP.
Среди других важных интернет-технологий, с которыми нужно ознакомиться — понятия DNS, HTTP, и модель OSI. Фундаментальные основы интернета останутся таковыми и в далеком будущем, а даже такие незыблемые вещи как HTML, CSS и JS, теоретически могут и выйти из употребления со временем.
Хотя основы интернета не будут критически важны в повседневной работе, они все-таки являются основой для других важных технологий, концепций и инструментов. К примеру, понимание, как AWS Route 53 работает со стандартным стеком облачных приложений, будет значительно проще, если основы работы сетей.
Основы компьютерной инженерии
Может возникнуть вопрос: если есть диплом бакалавра по специальности «Компьютерная инженерия» или «Программная инженерия», разве всем этим вещам не учили в университете? Да, но есть некоторые особенности.
1. Во первых, «классическая» компьютерная инженерия, в том виде как она преподается в университетах, достаточно мало приспособлена к специальности «тестировщик». Например, там преподаются сложные математические концепции вроде “NP-полноты” и они считаются необходимыми для разработчика с академической точки зрения, но для тестировщика они, объективно, не нужны.
2. При этом, университетское образование по специальности «инженер программного обеспечения» — это все еще солидная база для тестировщика, но университеты не дают каких-то волшебных знаний. Все что учат в университете, можно учить и вне его, и 99% нужного материала есть в открытом доступе в интернете.
Итак, подробнее, какие области академической программной инженерии релевантны для тестировщика.
- Компьютерное «железо», как оно управляется операционной системой и пользовательскими программами.
- Как эти программы создаются. Эволюция языков программирования: как языки исторически развивались и приспосабливались к задачам.
- Особенности языков программирования, их типы — высокоуровневые и низкоуровневые, компилируемые и интерпретируемые, функциональные и объектно-ориентированные, классификация языков по разным задачам.
- Кроме этих фундаментальных понятий, нужно знать алгоритмы (в том числе сложные), основы анализа данных, иметь представление о многопоточности и других основополагающих вещах в современном программировании.
Необходимо понимать, что изучение языков программирования — задача второго плана, поскольку все эти языки построены на основе фундаментальных концепций программирования, и вот эти концепции надо стараться постичь.
Кто-то может сказать, что «такой старт слишком теоретический». Неужели нужно досконально знать те же типы переменных и все их особенности, если ты просто работаешь со скриптами автоматизации?
Считается, что автоматизация тестирования проще программирования. Это не так, и вообще неправильно говорить, что написание автоматических тестов это «написание скриптов». Второе заблуждение это уверенность, что можно выучить язык программирования, поняв его базовые конструкции и решая какие-то практические задачи. Этого недостаточно, надо знать фундаментальные концепции, на которых основаны все языки программирования. Разумеется, человек с глубоким пониманием фундаментальных концепций легче и быстрее освоит абсолютно любой язык программирования.
Есть тестировщики (да и программисты), которые несколько лет безуспешно «сражаются» с концепцией closures (замыкания) в JavaScript, хотя работают с JS много лет. А тот кто владеет фундаментальными концепциями, освоит closures почти сразу.
Тестировщик — лишь подвид в “семействе инженеров программного обеспечения». Крепкий фундамент в том что называется computer science, обязательно сэкономит много времени в дальнейшем. Он позволяет “понимать, а не только знать”. Нельзя недооценивать важность этого фундамента лишь потому, что он кажется бесполезным в данный момент.
Веб-приложения
Теперь, когда у нас есть фундамент, в виде крепкого понимания основ компьютерной инженерии и интернета, мы готовы учить веб-приложения. Хотя не весь софт, с которым вы будете работать, будет иметь веб-интерфейс, веб-технологии столь распространены, что на них должно быть обращено особое внимание.
Приемлемый уровень знаний обязательно включает технологии веб-разработки, то есть базовую триаду HTML+CSS+JS. Надо знать, как эти технологии работают в браузере, то есть как он отрисовывает интерфейс. После изучения основ “триады”, можно переходить к AJAX, одностраничным приложениям (SPA) и PWA-приложениям (с подгружаемым контентом). Далее путь тестировщика проходит через: изучение хотя бы базовой криптографии; систем управления контентом; и других более специализированных тем, например выбор между отрисовкой в приложении или на сервере, адаптивные/реактивные приложения.
Надо ли знать, как сделать веб-приложение с нуля? Не помешает. Сделать это несколько раз в разных фреймворках (Angular, React) — и процесс прояснится, и это даст более ясное понимание тестирования таких приложений. Нынешний тренд в веб-технологиях: тестирование «под капотом», например с наброском дата-модели и тестирования интерфейса, и это делается юнит-тестами или в т.н. headless-браузере. Написание нескольких простейших веб-приложений позволит понять, зачем и какие нужны тесты, уже позволит понимать общую стратегию тестирования, и автоматизацию тестирования.
Программирование
Ранее шла речь о компьютерных науках, но пока не о программировании как таковом. Вы уже овладели типизацией и управлением памятью, операционными системами, но сейчас настало время перейти к практике, то есть учиться собственно программированию.
Чтобы быть успешным разработчиком, надо чувствовать себя комфортно в среде разработки, то есть хорошо разбираться в IDE-редакторах и оболочках с командной строкой. Когда программируешь, нужно думать о коде, а не о том как найти кнопку или настройку.
Кроме языка, надо знать конструкции высокого уровня, для приведения кода к правильному виду, и владеть так называемыми хорошими практиками программирования: паттернами дизайна, концепциями DRY и SOLID. Эти концепции, и степень их применения в коде, зависит от языка программирования. К примеру, SOLID применяется в объектно-ориентированных языках, а так называемые «чистые функции» применяются в функциональных языках.
В данное время языки, на которых нужно сосредоточиться, это JavaScript/TypeScript, Java (или как вариант C#), и Python.
JavaScript отличный как «язык входа в программирование», поскольку это основной язык веб-программирования. Также он стабильно расширяет влияние в других сферах, в частности стОит назвать такое явление как Node.js. Из-за своего активного задействования в веб-разработке, JS также активно применяется в веб-автоматизации, в виде инструментов Protractor, WebdriverIO, и Cypress.io. В последние тел 10 JavaScript на верхушке топа самых популярных языков.
TypeScript с “фундаментальной” точки зрения отличается от JavaScript, но здесь нужно “объединить” их. Поскольку TypeScript-код «транс-компилируется» (еще говорят, «транспилируется») в JavaScript-код, то большая часть экосистемы остается той же, и изучение TypeScript параллельно с JavaScript — обеспечит владение дополнительным языком с усовершенствованной типизацией.
После знакомства с JS/TS рекомендуем постепенно изучать Java, или как вариант C#. Эти языки очень похожи, оба активно задействуются в крупных компаниях. С# может быть немного невыгоден тем, что компании, принявшие C# как условно «основной язык», чаще всего принимают всю экосистему .NET/Microsoft, что немного ограничивает. Java и C# — языки не новые, не хайповые, это «надежные рабочие лошадки» в корпоративном бизнесе.
Что же касается именно хайпа, то это старый добрый Python, переживший реинкарнацию. Язык существует с начала 1990-х, но в последние годы, можно сказать, «заново родился», по своей внезапной популярности в обработке крупных массивов данных, и в искусственном интеллекте. Мощный и вместе с тем простой язык, который нужно знать интересующимся.
Важная фраза, которую нужно сказать об изучении языков: программирование это сфера, в которой очень легко научиться программировать на базовом уровне; но вот достичь подлинного (и высокооплачиваемого) мастерства — весьма трудно. Это приводит к недоразумениям и даже конфликтам, когда люди лишь начинают свой путь в программировании и еще не понимают своей ограниченности, и взаимодействуют с людьми намного более опытными. Иногда можно услышать «Я хорошо знаю Python, но на работу никто не приглашает. Печаль!»
Программирование можно изобразить как игру в шахматы. Большинство людей знает на 100% правила игры, или может их узнать за один вечер. Делает ли знание правил гроссмейстером? Так же и с программированием, выучить основы языка можно за пару недель, но не стоит себя считать профессионалом. Разумеется, такого человека нельзя озадачить разработкой на серьезных ролях. Ты выучишь язык за две недели, это правда, но потратишь остаток своей карьеры на шлифование навыков.
В индустрии тестирования все еще есть люди, которые говорят, что тестировщику не очень-то нужны скиллы программирования. Как уже можно было понять, это не так. Постоянное изучение языков и их совершенствование — есть ключевая обязанность хорошего тестировщика. Это будет понятно, когда придется приступить к написанию сложных тестов автоматизации, или предметно общаться с разработчиками, написавшими тестируемый софт.
Энтерпрайз-архитектура
Вообще такой софт бывает самых разных типов, видов, объемов, и в самых разных конфигурациях. Чтобы понимать как устроены такие системы (и когда они отказывают), надо вкратце понять основы энтерпрайз-архитектуры.
Это широкая категория, включающая темы: трехслойная архитектура, REST-сервисы, микросервисная архитектура, стриминговые и событийные архитектуры, стратегии устойчивости (реляционных и объектных хранилищ), репликация, управление кэшем, прокси, и многое другое. Темы раздела не перечислены по значимости, поскольку они независимы друг от друга и могут изучаться в любом порядке.
Помимо понимания, как организованы энтерпрайз-системы, нужно понимать, “на чем они строятся”. Это значит базовое понимание что такое IaaS, PaaS, SaaS, а также глубокое понимание облачных решений от крупных провайдеров AWS, GCP и Azure. Облачные технологии становятся вездесущими в современных энтерпрайз-архитектурах, так что никак нельзя недооценивать важность этих тем. Все крупные облачные провайдеры предоставляют разработчикам обширные ресурсы для обучения, и существует множество сторонних ресурсов, как платных так и бесплатных, для желающих освоить облачные технологии.
Энтерпрайз-архитектура — широкая область знаний, так что стоит фокусироваться на узких сферах, релевантных по работе, или хотя бы интересных лично. Некоторые из тем применимы ко многим типам архитектуры (стратегии устойчивости), другие применимы лишь в некоторых (обработка потоков событий). Вместе с тем, понимание тестируемых энтерпрайз-систем — важно, если стоит задача стать успешным тестировщиком (особенно в больших компаниях), поскольку ожидания работодателей на enterprise-проектах очень высокие и часто включают и базовые знания архитектуры.
Автоматизация тестов
Теперь перейдем к автоматизации. Существует много видов автоматизации: юнит-тестирование, тестирование API, и прочее. Тестировщик должен иметь опыт во всём этом. Перед тем как перейти к рассмотрению этих видов, нужно посмотреть на автоматизацию с теоретической точки зрения.
Чтобы автоматизация тестов оправдывала себя, нужно хорошо понимать, зачем пишутся такие тесты. Нужно смотреть на автоматизацию как на инвестицию, как автоматизация может описываться концепциями типа пирамиды тестирования, и ознакомиться с концепциями test oracles и test surfaces.
Понадобится понимание, как low-code или no-code-автоматизация встраивается в систему, преимущества и недостатки инструментов записи и воспроизведения тестов, и ознакомиться с BDD-языками типа Gherkin.
Мы рассмотрим позже unit-тестирование, тестирование API и интерфейса, но понимание что это, их преимуществ и недостатков — понадобится позже, когда концепции “пирамида тестирования” и “автоматизация как инвестиция” будут частью рабочего процесса.
Хотя еще рано переходить к ознакомлению с инструментами автоматизации, знание категорий инструментов и некоторых распространенных примеров по каждой категории — уже будет полезным на этом этапе. Например, изоляция тестируемой системы “мокингом” или “спуфингом” являются центральным вопросом в большинстве стратегий автоматизации. Так что ознакомление как работает WireMock или Montebank — не помешает.
Автоматизация быстро развивается, и есть некие авторитетные мнения и временами конфликты в индустрии. Не помешает узнавать точки зрения всех сторон, вместо того чтобы просто получать уведомления об изменениях, это поможет выделяться среди других тестировщиков, менее информированных.
Agile
Перед тем как перейти к различным типам автоматизации, надо затронуть менее “технические”, но не менее важные вещи. Выше мы знакомились с основами жизненного цикла разработки, сейчас давайте посмотрим на на Agile.
Чтобы эффективно работать в команде, исповедующей Agile, надо знать чуть больше чем просто теорию Agile, надо хорошо знать теоретические и практические нюансы. Конечно же, лучший способ получить знания — это поработать в agile-команде, но не помешает сначала получить некоторые теоретические знания.
Каждая команда “делает Agile” по своему, и как известно самая частая фраза об Agile: «у вас не настоящий эджайл!», но существуют общие методы, “церемонии” и термины, которые тестировщик обязан знать. Это: story definition, acceptance criteria definition, story estimation techniques, а также общие церемонии типа stand-up, retro, и demo. Также будет цениться знание стандартных средств управления эджайл-проектами. Это конечно Jira, но Rally и MS Project также активно применяются. Ценность тестировщика возрастет, если он знает и энтерпрайз-решения типа Scaled Agile (SAFe), LeSS, or Nexus.
Теперь мы знаем, как эджайл-команда работает, и тоже умеем определить работает ли она «правильно по эджайлу». Несоблюдение Agile приводит к фейлу, в том числе тестировщика.
Роль тестировщика
Что конкретно делает тестировщик? Где его роль заканчивается, и где начинается разработчик? Как и когда тестировщик сотрудничает с другими ролями в Agile-команде? Важно получать четкие ответы.
К сожалению, ответы всегда разные, в разных компаниях и командах. Навыки, сферы компетенции, ожидания от тестировщика, временные рамки, и рабочая культура каждой команды и компании будет влиять на роли, так что здесь нужен качественный теоретический подход. Понимание своей роли очень ценное в достижении успеха.
Какова бы ни была команда, надо иметь ясное понимание моделей, как компании решают проблемы. Вот немного материала по теме на английском: How Google Tests Software, Microsoft’s Combined Engineering Approach, Atlassian Quality Assistance, Spotify Model, и Slalom Build’s Quality Engineering Core Principles.
Юнит-тестирование
Хотя юнит-тестирование (иногда называемое модульным) часто выполняется самими разработчиками, тестировщик должен иметь представление о том, как его проводить (а в идеале и уметь это делать самостоятельно). Тестировщики должны знать инструменты и фреймворки, подводные камни разных языков и решений, и как покрытие юнит-тестами улучшает и поддерживает высокий уровень автоматизации. Тестировщики не должны испытывать проблем с исправлением кода юнит-тестов, в идеале должны писать их сами.
Уровень компетенций, требуемый от тестировщиков, в случае работы с тестами от разработчиков, может неприятно удивить новичка-тестировщика. Однако эти компетенции являются необходимыми, принимая во внимание роль и ожидания от роли, описанные в предыдущих разделах. QA-инженеры это не «просто тестировщики» или «автоматизаторы тестов», они должны мыслить целостно о качестве приложения, и “схватывать” все что может влиять на качество. Юнит-тесты представляют собой большой и важный фидбек для разработчиков, и тестировщики должны уметь общаться с разработчиками и devop’ами насчет написания и исправления тестов.
В процессе юнит-тестирования нужно иметь понимание, и даже привычку, пользоваться TDD для создания юнит-тестов. Нужно понимать разницу между юнит-тестами в функциональном и объектно-ориентированном языке, а также знать паттерны упрощающие тестирование. Хотя многие фреймворки юнит-тестирования обладают схожей функциональностью, бывает много нюансов усложняющих тестирование, в рамках какого-то языка.
Хотя эта сфера касается юнит-тестирования, профессионал-автоматизатор должен понимать, что автоматизация тестирования не обязательно проводится “точно по слоям приложения”: автоматизация должна восприниматься как целостная деятельность, состоящая из совокупности тестов, от небольших и атомарных до больших и длительных. Знание всех их типов критически важно для разработки непротиворечивой стратегии автоматизации, и является другой причиной, почему тестировщики должны обладать знаниями и пониманием всех типов тестов, даже если они их не разрабатывают и не утверждают.
Автоматизация тестирования API
Автоматизация API это еще один тип фидбека, важный для любой нестандартной системы, и в этой сфере все тестировщики должны иметь глубокое понимание. Хотя автоматизация тестирования API является немного расплывчатым понятием, обычно имеют ввиду тестирование REST-сервисов, веб-сервисов, SOAP-сервисов, запросов в рамках стриминговых архитектур, тестирование файловых интерфейсов, и возможно даже низкоуровневых бинарных протоколов.
API создаются для других программ (как следует из названия этой технологии), так что API обладают хорошими возможностями для автоматизации их тестирования. Из-за ограничений юнит-тестов и end-to-end тестов, тестировщики должны уметь билдить, выполнять, отлаживать, и обслуживать вручную такие тесты.
Для автоматизированного тестирования API могут понадобиться средства типа PostMan, поддерживающие специальные API-тесты. Распространенные методы API-автоматизации поддерживают взаимодействие со средствами типа PostMan при написании тестов.
Чаще всего применяются два API-фреймворка, RestAssured и Karate, также тестирование API можно выполнить просто в тест-раннере типа JUnit, при помощи библиотеки взаимодействия с сервисом (типа HttpClient) и так называемой библиотеки “матчеров”, проверяющей “ассерты» (подробнее здесь: Hamcrest). Для каждого языка программирование есть нечто подобное.
В зависимости от команды, выполнение API-тестов, включая юнит-тесты, может лежать на разработчиках, а не на тестировщиках. Но все равно, тестировщик обязан уметь билдить, расширять, отлаживать и запускать API-автоматизацию.
Автоматизация тестирования веб-интерфейсов
Автоматизация тестирования веб-интерфейсов многими считается «основной задачей автоматизации». Хотя это лишь один из слоев «пирамиды автоматизации», причем самый тонкий из слоев, но он все еще играет большую роль в стратегиях автоматизации. Если приложение имеет веб-UI-интерфейс (а большинство имеет), его автоматизация это единственный способ создать реально сквозное, end-to-end тестирование. Ведь только сквозное тестирование полностью отражает то что называется “пользовательским опытом”.
Это один из самых сложных типов автоматизации. API, например, пишутся для взаимодействия с приложениями, а интерфейсы пишутся для взаимодействия с пользователями. Требование от автоматизации тестов запускать что-то, предназначенное для пользователей, подобно направлению круглого предмета в квадратную дырку. К счастью, для решения этой проблемы создано множество инструментов, фреймворков и средств автоматизации.
Самый применяемый инструмент это конечно Selenium и его оболочки и производные (WebDriver.io, Protractor, Appium и прочие). Тема Selenuim’а практически неисчерпаема, так что на первом этапе надо просто понять, что такое Selenium, что он делает, и как в нем тестируют. Освоив Selenium, и владея хотя бы одним языком программирования, перейти к следующему хайповому фреймворку на основе Selenium, например для автоматизации интерфейса, будет достаточно просто.
Кроме Selenuim, есть фреймворки автоматизации браузеров, которые успешно пытаются автоматизировать без применения специфического Selenium-протокола WebDriver. Они в основном взаимодействуют с API браузера, типа DevTools, делая автоматизацию интерфейса ощутимо проще и мощнее, но бывают и проблемы. Сюда относятся Puppeteer и Playwright. Есть хайповая штука, Cypress.io, довольно перспективная с виду, не связанная с Selenium, стоит на нее поглядеть. Вообще же, конкретные инструменты сами по себе не так важны, как понимание как работает веб-автоматизация, а также основы архитектуры интернета, и язык программирования. Зная эти вещи досконально, можно легко освоить любой новый инструмент за несколько дней.
Кроме “селениумных” и “неселениумных” инструментов, есть другие, платные. Они часто продвигаются как “менее сложные”, и да, могут быть полезны своей упрощенностью. Надо знать их подводные камни, не слишком верить рекламе (“наш искусственный интеллект все автоматизирует почти бесплатно”) и помнить, что хорошее средство автоматизации “ориентируется больше на код”, как и говорилось в предыдущих разделах.
О популярных open-source инструментах для автоматизированного тестирования можно узнать в нашей статье.
Непрерывная интеграция, доставка и развертывание (CI/CD)
Автоматизация полезна, а некоторые говорят, только тогда и полезна, когда она обеспечивает автоматический и прямой фидбек на все изменения. Это значит, что автоматизация тестирования должна сочетаться с постоянной интеграцией и постоянной доставкой и развертыванием (этот процесс обозначается как CI/CD pipelines). Тесты, прозябающие в репозитории и вызываемые лишь когда о них вспомнят, быстро «портятся», закономерно теряют актуальность. Толковый тестировщик должен понимать концепцию CI/CD, владеть инструментами в этой области, и уметь работать с DevOps-инженерами и программистами, внедряя стратегию автоматизации.
Как это происходит на практике, отличается в каждой компании, но в целом, тестировщики прямо привлекаются к процессу CI/CD. Чаще всего они пишут пайплайны в Jenkins (система непрерывной интеграции), работают со скриптами в Cloud Formation, или других подобных инструментах. Тестировщик должен быть готов освоить любой подобный инструмент, чтобы помогать разработчикам на любых этапах CI/CD.
Стратегия CI/CD включает в себя стратегию тестирования, поэтому тестировщик должен уметь выполнять «проверку на входе», участвовать в выборе тестового окружения, понимать связь между тестовым окружением и системой управления тестовыми данными.
Тестирование производительности
Если приложение тормозит или крайне медленно загружается, можно говорить о том, что оно не работает. Производительность критически важна в наше время. Тестирование производительности гарантирует, что производительность отвечает ожиданиям клиента, и это одна из важнейших компетенций тестировщика.
Тестирование производительности это очень широкая тема, и существуют даже тестировщики, которые специализируются исключительно на тестировании производительности. Но всем тестировщикам нужно знать типы и номенклатуру таких тестов, рабочие инструменты, и как такие тесты интегрируются в пайплайны CI/CD.
Вне конкуренции среди инструментов измерения производительности — Apache JMeter. Существуют также плагины, и инструменты с GUI. Как и в других сферах автоматизации, рекомендуется изучать инструменты, связанные со стеком технологий, применяемых в проекте.
Мобильное тестирование
Количество мобильных интернет-пользователей уже давно превзошло количество «десктопных», поэтому тестирование мобильных интерфейсов для многих проектов становится важнее, чем тестирование веб-интерфейсов. Здесь нужно понимать нюансы тестирования нативных приложений, гибридных приложений, и мобильных интерфейсов. В сфере нативных приложений нужно знать, как тестируется приложение на обеих наиболее распространенных платформах Android и iOS, поскольку там есть существенные различия. Подробнее об инструментах тестировании мобильных приложений на iOS можно почитать в нашей статье.
Автоматизация тестирования мобильных приложений это очень специфическая сфера, здесь существует огромное количество инструментов и фреймворков. Есть отличные инструменты типа Espresso для Android и XCUTest для iOS, а также кроссплатформенный Appium. Рекомендуется изучать инструменты, которые больше ориентированы на код, а не на GUI-интерфейс.
Кроме автоматизации мобильного тестирования, надо понимать, как стандартные и облачные приложения тестируются на огромном количестве девайсов, особое внимание обращая на разнообразие версий операционной системы. Нужно понимать, как эмуляторы и симуляторы применяются для получения фидбека, без тестирования на физических устройствах. Как распространяются мобильные приложения, как обновляются релизы и чем они могут отличаться, и другие важные сферы, специфические для мобильных приложений, для которых неприменимы правила стандартных приложений.
Тестирование доступности
Как всякая коммерческая вещь, программное обеспечение должно быть доступно людям со слабым зрением или слухом, или другим людям с ограниченными возможностями. Тестировщик должен знать требования в этой сфере, методы и инструменты, применяемые для проверки на доступность.
В Соединенных Штатах доступность услуг для людей с ограниченными возможностями находится на высочайшем уровне, кроме того существенная часть клиентов софта, написанного в России или Украине, проживают именно в США, поэтому нужно знать американские стандарты 508 Accessibility Standards и Web Content Accessibility Guidelines (WCAG), созданные Консорциумом W3. Если идёт разработка веб-интерфейсов или мобильных интерфейсов, знание этих стандартов, и инструментов их проверки, незаменимо для обеспечения доступности.
Тестирование безопасности
Безопасность программного обеспечения, разумеется, крайне важна для общего качества, и может возникнуть вопрос, почему эта тема освещена так поздно в нашей карте? Важность безопасности, и большая техническая сложность тестирования безопасности заставила индустрию создать специализированные роли в этой сфере. Это: сетевая безопасность, безопасность протоколов, безопасность компании и др. Если вы новичок, скорее всего вас не будут привлекать в какие-то из этих ролей. Вместе с тем необходимо знать основы безопасности, например как обезопасить билд приложения.
Сюда относятся концепции аутентификации и авторизации, то есть ограничения доступа; Принцип наименьших привилегий; как работает криптография (особенно открытые ключи); общее понятие об OWASP Top 10. Надо знать специальную терминологию: вектор атаки и поверхность атаки; как уязвимости идентифицируются сканерами; основы тестирования на проникновение. Если есть цель специализироваться в этой сфере, постижения этих вещей будет достаточно для начала карьеры.
Как же без этого: Тестирование искусственного интеллекта и машинного обучения, тестирование BigData
Самая хайповая вещь в ИТ, ее нельзя не упомянуть, но мы решили все-таки не включать в карту, потому что:
1. Это будет очень большая тема.
2. Роли и обязанности тестировщиков значительно отличаются в разных компаниях.
Можно просто сказать, что уже описанных выше фундаментальных вещей, если они усвоены нормально (особенно это касается основ энтерпрайз-архитектуры и основ автоматизации), должно хватить для успешной работы в качестве дата-инженера или тестировщика AI/ML.
Итого
У нас должно было получиться более 100 тем в 18 разделах. Некоторые из этих тем весьма обширны по своей природе. Масштаб карты должен послужить знаком, что карьера тестировщика будет успешной, если вы любите учиться, находите прелесть в современных технологиях, и любите решать сложные задачи. Обладая крепким пониманием упомянутых тем, можно принести огромную пользу своей компании, да и себе.
Если уже работаете тестировщиком, и «слушайте, все не так», оставляйте ваши комментарии под этой статьей.
