Дорожня карта навчання Quality Engineer. Посібник для початківців

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на DOU | QA!

Публікуємо переклад матеріалу Блейка Норріша, Quality Engineer, Software Developer, Consultant, Pessimist — Currently Sr Director of Quality Engineering at Slalom Build.

А що ви порадите початківцям, які цікавляться кар’єрою Quality Engineer? Чого потрібно навчитися, щоб стати QE? Які мови слід опанувати, якими інструментами володіти, які навички слід практикувати?

Відповісти на це питання непросто — якість знань QE залежить від усього: від базової інформатики та основ забезпечення якості до найновіших фреймворків автоматизації, стеків додатків та інструментів тестування. У цій публікації ми розглянемо дорожню карту навчання, яка описує всі навички, інструменти та технології, необхідні для успіху QE.

Роль QE

Перш за все, що таке «інженер якості»?

Хоча існує багато способів створення програмного забезпечення, ми (автори оригінальної статті — ред.) вважаємо, що його найкраще створювати невеликими, кросфункціональними командами, що взаємодіють. «Кросфункціональна» характеристика описує, що команда має всі ролі та навички, необхідні для створення рішення, не покладаючись на зовнішні команди чи набори навичок.

Однією з ролей у цих командах є інженер з якості (QE). QE — це більше, ніж просто тестувальники чи автоматизатори, вони надають командам можливості, вносячи «мислення якістю» у кожен аспект створення програмного забезпечення. Вони є експертами із забезпечення якості, автоматизації тестування, аналізу ризиків, гнучких процесів, CI/CD та всього іншого, що може вплинути на якість продукції. Вони співпрацюють з усіма іншими ролями, щоб гарантувати, що якість «вбудована» з першого дня, з першої сторі, до написання першого рядка коду. Деякі компанії називають цю роль SDET (інженер з розробки програмного забезпечення в тестуванні), але кожна компанія визначає ролі по-різному, тому те, що SDET або QE робить в одній компанії, може не зовсім відповідати тому, що аналогічна роль передбачає в іншій.

Хоча ця дорожня карта розроблена спеціально для ролі інженера з якості в конкретній команді, вона буде актуальна для всіх, хто хоче почати кар’єру в сфері якості, незалежно від назви чи ролі.

Дорожня карта навчання QE

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

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

Як бачите, є чому повчитися. Роль інженера з якості широка, і вивчення всіх відповідних навичок є значними інвестиціями!

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

Отже, без додаткового введення, переходимо до дорожньої карти!

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

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

Для початку нам потрібно зрозуміти, що ми маємо на увазі під «якістю» щодо програмного забезпечення. Знаючи це, ми можемо перейти до визначення, що таке тест-кейсі як розробити тест-сьюти і тест-плани за допомогою методів тест-дискавері. У методах є такі поняття, як граничні випадки, класи еквівалентності, граничний аналіз, комбінаторний аналіз та тестування на основі ризику. Для опису тестів використовується спеціальна термінологія, тому знання, як описувати, категоризувати та групувати тест-кейси або типи тестів, використовуючи такі відмінності, як black-box / white-box / grey-box тестування, функціональне та нефункціональне тестування, негативне та позитивне тестування, або статичне чи динамічне тестування. Треба розуміти відмінності.

Існують також види діяльності, які описуються нефункціональним тестуванням — такі речі, як продуктивність, безпека, доступність, сумісність, локалізація тощо. Хоча вам НЕ потрібно бути експертом у жодному з них, Ви повинні знати терміни та тип тестування, який вони описують.

Крім усього цього, є інструменти для управління проектами, відстеження дефектів, керування тестовими прикладами та звітності, з якими потрібно ознайомитися. Jira є найпоширенішим для загального управління проектами, а такі інструменти, як Zephyr, TestLink і TestRail, є звичними для керування задачами.

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

Розробка програмного забезпечення більше не є окремим заняттям, і, за рідкісним винятком, все сучасне програмне забезпечення створюється командами. Щоб бути ефективним інженером з якості, важливо розуміти, як багато співробітників команди програмного забезпечення працюють разом, щоб розробити та відправити продукт. Це широка категорія — ми не будемо заглиблюватися в якусь конкретну методологію чи філософію розробки (це буде пізніше), але нам потрібно зрозуміти, що є, що використовувалося раніше, а що використовується сьогодні.

Тут ви повинні дізнатися, що люди мають на увазі, коли говорять про Waterfall-модель, V-модель, спіральну модель або Agile. Ви повинні вивчити основи сучасних підходів, таких як Scrum і Kanban, а також аргументи як за, так і проти використання цих типів методологій у сучасній розробці програмного забезпечення.

Хоча ця категорія може здатися занадто теоретичною, наявність міцної основи в SDLC Fundamentals принесе дивіденди, коли ви почнете свій шлях до QE.

Основи Інтернету

У 1995 році Білл Гейтс написав меморандум для керівників Microsoft, в якому говорилося, що Інтернет зараз має «найвищий рівень важливості» для компанії. Він не помилився, і сьогодні майже все програмне забезпечення, так чи інакше, є програмним забезпеченням для Інтернету. Щоб зрозуміти, як працює програмне забезпечення та як воно ламається, вам потрібно знати, як працює Інтернет.

Хоча це може здатися складним, не опускайте рук. Вам не потрібне глибоке розуміння якоїсь окремої технології, а скоріше розуміння того, як вся ця річ поєднується. Наприклад, вам не потрібно знати, що пріоритет пакетів встановлюється в другому 8-бітовому слові заголовка пакета IPv4, але ви повинні знати, що IP («протокол Інтернету») відноситься до пакетів і є тим, що складає IP у TCP/IP.

Інші важливі інтернет-технології, з якими ви повинні бути знайомі, включають такі речі, як DNS, HTTP та модель OSI. Майте на увазі, що «Основи веб-додатків» — це категорія «на потім», тому такі речі, як HTML/JS/CSS, можна поки що відкласти.

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

Комп’ютерні науки та основи техніки

Ви зараз кричите щось тиу: «Комп’ютерна наука! Комп’ютерна інженерія! Це чотирирічні університетські дипломи, як ви можете очікувати, що я навчусь всього цього сам?» Не хвилюйтеся.

1. Є багато аспектів академічної інформатики та техніки, які просто не мають відношення до QE. Наприклад, знання того, які класи обчислювальних задач можна віднести до категорії NP, NP-complete, NP-hard, є важливою темою в академічній інформатиці, але не дуже допоможе вам як інженеру з якості.
2. Хоча офіційна освіта в галузі комп’ютерних наук/інженерії є хорошою основою для QE, вона не є обов’язковою. Ви можете навчитися цьому безкоштовно десь в Інтернеті.

Тож які теми інформатики та інженерії є актуальними для починаючого інженера з якості? Такі предмети, як комп’ютерне обладнання та те, як ним керують операційні системи та користувацькі програми. Як написані ці програми та як розвивалися різні типи мов програмування для цього? Ви повинні розуміти загальні характеристики мов програмування та те, як їх можна класифікувати, наприклад, високий або низький рівень, компільований чи інтерпретований, функціональний чи об’єктно-орієнтований, а також різні підходи до систем типів.

На додаток до цих основоположних концепцій, ви повинні дізнатися про алгоритми і складність алгоритмів, аналіз, паралельність і потоки, а також інші загальні поняття про програмування. Майте на увазі, що саме програмування (наприклад, вивчення мови) є категорією «на потім».

Деякі люди можуть заперечити проти цього занадто теоретичного вивчення інформатики. Чому потрібно вивчати системи типів для автоматизації сценаріїв?

По-перше, є припущення, що автоматизація тестування є менш складною, ніж «справжнє» програмування. Це не так, і ми загалом не любимо називати розробку автоматизації тестування «скриптингом». По-друге, є припущення, що ви можете вивчити мову, просто проглядаючи «верхівку», а не розуміючи фундаментальні концепції, на яких побудовані всі мови. З нашого досвіду, люди з таким глибоким розумінням можуть опанувати нові мови швидше, ніж ті, яким цього не вистачає.

Інженер з якості — це спеціалізований тип інженера-програміста. Міцна основа в галузі інформатики та інженерії прискорить ваше подальше навчання; це дозволить вам розуміти, а не просто знати.

Основи вебдодатків

Тепер, коли у нас є фундамент з інформатики та основ Інтернету, ми готові вивчати вебдодатки. Хоча не всяке програмне забезпечення, з яким ви будете працювати, обов’язково матиме вебінтерфейс, поширені вебтехнології, тож особливу увагу слід приділяти розумінню того, як вони працюють.

Прийнятний рівень розуміння включатиме знання про те, як вебсайти розробляються за допомогою таких технологій, як HTML, CSS та JavaScript. Вам потрібно зрозуміти, як працюють браузери, щоб сприймати ці мови та відображати їх як інтерфейс. Коли ви зрозумієте основи вебдодатків, ви можете переходити до таких речей, як AJAX, односторінкові програми (SPA) і прогресивні веб-додатки (PWA), а потім шифрування, системи керування вмістом і розширені теми, як-от клієнт/сервер, адаптивні та реактивні вебдодатки.

Вам потрібно знати, як створити вебдодаток з нуля? Ні, не дуже. Але це не зашкодить. І якщо зробити це кілька разів у кількох різних фреймворках (Angular, React тощо), це демістифікує процес та дасть більш глибоке уявлення про тестування. Створення кількох простих вебдодатків дасть вам уявлення про те, як можна використовувати різні типи тестів, і надасть інформацію про загальну стратегію тестування та автоматизації.

Програмування

Раніше ми говорили про інформатику, але насправді не включали туди програмування. Ми знаємо про системи типів, пам’ять та операційні системи тощо, але тепер нам потрібно зробити ці знання практичними, навчившись працювати з мовою програмування.

Щоб бути ефективним програмістом, ви повинні відчувати себе комфортно в середовищі, в якому ви будете розвиватися. Це означає розуміння вашого інтегрованого середовища розробки (IDE) та оболонки. Коли ви програмуєте, ви повинні думати про код, а не про те, як знайти певну кнопку чи налаштування.

На додаток до мови, ви повинні вивчати конструкції вищого рівня, які організовують код і інформують про передові практики програмування: шаблони проектування, концепції, такі як DRY і SOLID тощо. Ці концепції — і те, як вони реалізуються в коді — залежать від природи мови, яку ви вибираєте для вивчення, тобто SOLID застосовується до об’єктно-орієнтованої мови, тоді як шаблони, як-от чисті функції, застосовуються до функціональних мов.

Мови програмування, на яких ми б зосередилися, це JavaScript/TypeScript, Java або C# і Python.

JavaScript є чудовою початковою мовою, оскільки на ній лежить вся веброзробка. Крім того, він неухильно посягає на інші сфери через такі фреймворки як Node.js. Через його використання у веброзробці JavaScript також активно використовується в вебавтоматизації за допомогою таких інструментів як 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 тощо — і інженери з якості повинні мати досвід у кожному з них. Однак, перш ніж ми зможемо глибоко розглянути будь-який тип, нам потрібно розглянути автоматизацію тестування як теоретичну концепцію.

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

Нам також потрібне розуміння того, наскільки автоматизація no-code/low-code вписується в картину, переваги та недоліки record-and-playback інструментів, і як використовуються мови BDD, такі як Gherkin.

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

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

Сучасне Agile Delivery

Перш ніж ми глибоко зануримося в різні типи автоматизації тестування, нам потрібно розглянути деякі менш технічні, але все ж дуже важливі області. Хоча раніше ми розглядали SDLC Fundamentals, тепер нам потрібно конкретно зануритися в Agile Delivery.

Для того, щоб ефективно діяти в команді Agile розробників, вам потрібно знати більше, ніж просто теорію Agile, ви також повинні бути знайомі з тактичними та практичними аспектами. І хоча найкращий спосіб дізнатися багато чого з цього — випробувати це на власному досвіді, не завадить мати деяке розуміння заздалегідь.

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

Знання того, як працює ваша команда, і вміння визначити, коли вона працює добре, а коли ні, має вирішальне значення для ролі інженера з якості — часто саме ці проблеми є першопричиною проблем із якістю програмного забезпечення.

Роль QE

Що саме робить інженер з якості? Де закінчується ця роль і починається роль інженера-програміста? Як і коли інженер з якості співпрацює з усіма іншими ролями в команді гнучкої розробки? Важливо мати чіткі відповіді на ці запитання, перш ніж почати.

На жаль, відповіді на ці питання відрізняються не тільки від компанії до компанії, але й від команди до команди. Набір навичок, сфера діяльності, очікування, часові рамки та культура кожної команди та компанії впливатимуть на те, що робить інженер з якості. Незважаючи на це, знання своєї ролі буде надзвичайно цінним для досягнення успіху.

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

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

Хоча модульне тестування зазвичай виконується інженерами з програмного забезпечення, інженери з якості також повинні мати досвід. Інженери з якості повинні знати інструменти та фоеймворки, знати недоліки та підводні камені в їхній конкретній мові, та точно знати, як охоплення модульним тестуванням доповнює та підтримує інші рівні автоматизації вищого рівня. Інженери з якості не повинні мати проблем із кодом, переглядаючи модульні тести або навіть реалізуючи самі тести.

Рівень досвіду, який нам потрібен від інженерів з якості для типу тестування, який переважно здійснюють інженери програмного забезпечення, може вас здивувати. Однак це розуміння є критичним з огляду на роль і очікування, викладені в попередніх розділах.

Інженери з якості — це не просто тестувальники чи автоматизатори тестів, вони повинні комплексно думати про якість додатків і розуміти все, що може вплинути на цю якість. Модульне тестування створює великий і важливий цикл зворотного зв’язку для команд розробників, і інженери з якості повинні мати можливість співпрацювати з інженерами програмним забезпеченням.

У рамках модульного тестування ви повинні розуміти TDD для розробки модульних тестів. Ви повинні розуміти відмінності між модульним тестуванням функції та об’єктно-орієнтованою мовою, а також шаблонами, які полегшують модульне тестування.

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

Автоматизація 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 існують фреймворки для автоматизації браузера, які намагаються стимулювати вебавтоматизацію без використання базового протоколу WebDriver Selenium. Ці інструменти зазвичай взаємодіють зі спеціальними API для вебпереглядача, такими як DevTools у Chrome, і можуть значно полегшити й покращити автоматизацію інтерфейсу користувача для цих браузерів, хоча й з деякими недоліками. До цієї категорії належать такі інструменти, як Puppeteer і Playwright. Cypress.io — це ще один новий і перспективний інструмент у категорії «без Selenium», який вартий вивчення.

Знову ж таки, самі інструменти менш важливі, ніж знання того, як працює вебавтоматизація, у поєднанні з основами вебархітектури та програмування, що дозволить вам швидко підібрати будь-який новий інструмент.

На додаток до «селенової» та «не селенової» автоматизації інтерфейсу користувача, існує багато комерційних запатентованих інструментів автоматизації. Зазвичай вони продаються для менш технічно підкованих і можуть бути корисними для виконання простих речей. Знати, коли вони доречні, а коли ні, і мати можливість проглядати велику кількість маркетингових матеріалів (ми використовуємо ШІ, щоб автоматизувати все безкоштовно!) важливо для розуміння їхньої ролі порівняно з більш орієнтованими на код підходами.

Постійна інтеграція, доставка та розгортання

Автоматизація тестування є найбільш цінною, коли вона автоматично забезпечує прямий і негайний зворотний зв’язок щодо всіх системних змін, що означає інтеграцію автоматизації тестування з безперервною інтеграцією та безперервними конвеєрами доставки/розгортання. Тести, які знаходяться в репозиторії і запускаються лише тоді, коли хтось натискає їх, швидко і неминуче викидаються в смітник. Як інженер з якості, вам потрібно буде розуміти концепції CI/CD, добре володіти інструментами та вміти співпрацювати з DevOps та інженерами з програмного забезпечення для реалізації загального підходу автоматизації тестування, який є цінним для всіх.

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

Ваша стратегія CI/CD обов’язково збігається зі стратегією тестового середовища, і це ще одна область, з якою інженери з якості повинні бути знайомі. Що таке контрольні перевірки, коли слід використовувати спільні середовища, яка залежність між тестовими середовищами та керуванням тестовими даними? Інженери з якості повинні бути готові відповісти на все це та багато іншого.

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

Не має значення, чи працюють програми, якщо вони занадто повільні для використання або зазнають час очікування під навантаженням. Тестування продуктивності гарантує, що програмне забезпечення відповідає очікуванням продуктивності, і є важливою сферою знань для інженерів з якості.

Хоча тестування продуктивності само по собі є глибокою та широкою темою, і є професіонали з тестування, які не спеціалізуються ні на чому, окрім тестування продуктивності, ви повинні розуміти типи та номенклатуру цих тестів, інструменти, які їх підтримують, і як ці тести можна інтегрувати в CI/CD і agile-процеси.

Чинним чемпіоном серед автономних інструментів для тестування продуктивності є Apache JMeter, але існує широкий вибір інструментів як для створення коду, так і для GUI. Як і в інших областях автоматизації тестування, ми рекомендуємо використовувати інструменти для навчання відповідно до технологічного стека, який вас найбільше цікавить.

Мобільне тестування

Використання мобільного Інтернету перевищило використання комп’ютерів, тому тестування мобільних інтерфейсів не менш важливе, ніж тестування вебінтерфейсів. У категорії «мобільні» ви повинні розуміти нюанси тестування нативних додатків, гібридних програм і мобільних вебінтерфейсів. У категорії додатків вам потрібно знати, як тестувати платформи Android і iOS, оскільки, звичайно, є відмінності.

Автоматизація мобільних додатків ставить перед собою власний набір проблем, а також безліч інструментів і фреймворків, які використовуються для їх подолання. Існують спеціальні інструменти, такі як Espresso для Android і XCUITest для iOS, а також міжплатформні інструменти, такі як Appium. Так само, як і вебавтоматизація, ми рекомендуємо вивчати інструменти, які використовують філософію коду, а не інструменти, орієнтовані на графічний інтерфейс.

На додаток до мобільної автоматизації, ви повинні розуміти, як пристрої (як локальні, так і хмарні) можна використовувати для прискорення тестування на величезній кількості типів пристроїв і версій ОС. Ми повинні розуміти, як емулятори та симулятори можна використовувати для отримання зворотного зв’язку з тестуванням без фізичних пристроїв, чим делівері та реліз мобільних додатків відрізняється від інших типів програмного забезпечення та інші тестові області, характерні для мобільних додатків, які не можна знайти при тестуванні звичайного вебпрограмного забезпечення.

Тестування доступності

Як і всі комерційні послуги, програмне забезпечення має бути доступним для людей із вадами зору, слуху чи інших порушень. Як інженери з якості, ми повинні розуміти ці вимоги, а також методи та інструменти, які використовуються для їх перевірки.

У Сполучених Штатах доступність визначається урядовими стандартами доступності 508 і Інструкціями щодо доступності веб-контенту (WCAG), визначеними консорціумом W3. Якщо ви збираєтеся працювати над вебінтерфейсами або мобільними інтерфейсами, важливо розуміти ці стандарти та безліч інструментів сканування, які використовуються для оцінки відповідності.

Тестування безпеки

Безпека програмного забезпечення надзвичайно важлива для загальної якості програмних систем, то чому ця тема з’являється відносно пізно в нашій дорожній карті навчання? Важливість безпеки та високотехнічний характер більшості тестів безпеки підштовхнули галузь до прийняття спеціалізованих ролей безпеки; наприклад: мережева безпека, безпека протоколів, безпека підприємства тощо. Як новий інженер з якості, ви, ймовірно, не будете брати участі в жодному з них. Однак ви все одно повинні знати основи безпеки, зокрема, як захистити сам процес створення програмного забезпечення.

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

Додатковий кредит: тестування AI/ML та інженерія даних

AI/ML та інженерія даних є гарячими темами в розробці програмного забезпечення, але ми вирішили виключити їх з основної дорожньої карти, тому що 1) це вже досить довго, і 2) це спеціалізації, які можуть бути непридатними залежно від ролі та компанії. Однак, якщо ви хочете піти цим шляхом, основа, яку ви отримали в попередніх розділах, як-от архітектура підприємства та основи автоматизації, добре послужить вам, і не буде проблем додати AI/ML або тестування інженерії даних до вашого інструментарію тестування.

Резюме

Такий розмір і масштаби цієї навчальної дорожньої карти можуть залякати — 144 теми в 18 розділах, деякі з них досить глибокі! Прийміть широту дорожньої карти як вказівку на те, що кар’єра якісного інженера може бути корисною, якщо ви любите вчитися, насолоджуватися технологіями та вирішувати складні проблеми. З володінням цими темами цінність, яку ви можете принести організації, є величезною.