Розбираємо оновлення ISTQB: дві сертифікації, нові розділи та багато конкретики

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

Привіт, з вами Артур!

Нещодавно у світі ISTQB вийшло оновлення сертифікацій з автоматизації. І змін там не просто багато, а ДУЖЕ БАГАТО. По-перше, сертифікацій тепер аж дві — Test Automation Engineer та Test Automation Strategy! По-друге, чимало додали й прибрали.

Тож поглянемо детальніше, що змінилося.

Передусім кому взагалі може бути цікава ця сертифікація? ISTQB надає доволі великий список:

• Test Engineers,
• General Test Engineers,
• Test Analysts,
• Test Automation Engineers,
• Test Consultants,
• Test Architects,
• Test Managers / Test Leads,

а також:

• Project Managers,
• Quality Managers,
• IT Directors,
• Management Consultants,
• Engineering Managers,
• Business Analysts,
• Software Developers,
• Tech Leads.

А ще — рекомендує мінімум шість місяців досвіду в тестуванні або розробці й наявність ISTQB^® Foundation Level сертифіката. Я ж думаю, що для цього треба хоча б рік попрацювати автоматизатором.

Коротко опишу, про що ці сертифікації.

Test Automation Engineer

1. Плюси та мінуси автоматизації.
2. Що треба від системи, де ми збираємося розгорнути автоматизацію.
3. Як проаналізувати інструмент автоматизації.
4. Що таке архітектура автоматизації.
5. Які бувають підходи до автоматизації.
6. Як розгорнути та підтримувати рішення з автоматизації.
7. Як аналізувати результати тестового запуску та як дебажити.
8. На що можна звернути увагу для покращення автоматизації.

Test Automation Strategy

1. Які проєкти підходять під автоматизацію.
2. Купити чи розробляти своїми силами.
3. Знову про піраміди.
4. Трошки про shift-left та shift-right.
5. Що складно автоматизувати.
6. Стратегія розробки та розгортання автоматизації в загальному вигляді.
7. Як порахувати ROI.
8. Які метрики обрати.
9. Загальні рекомендації, як мігрувати мануальну роботу в автоматизовану.

Якщо ви не хочете складати Test Automation Engineer сертифікацію, може бути корисно дізнатися:

• 2.1.2 Про різні типи оточень та для чого вони.
• 2.2.2. Про те, на що звертати увагу під час аналізу інструментаріїв.
• 3.1.3. Про багатошаровий пиріг архітектури.
• 3.1.4. Просто для загального розвитку про підходи.
• 4.3.1. На що звертати увагу, щоб тести було легко підтримувати.
• 5.1.1. Які тести коли запускати.
• 5.1.2. Що не забути параметризувати.
• 8.1.2. На що звернути увагу під час аудиту або рефакторингу.

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

1. Introduction and Objectives for Test Automation

1.1. Purpose of Test Automation

Це розділ про плюси та мінуси автоматизації загалом та її цілі. Думаю, тут не буде жодних відкриттів. Серед плюсів — більше тестів раняться швидше, відсутній людський фактор, швидший фідбек. З мінусів — додаткові кошти й час, а також додаткові дефекти, повʼязані з автоматизацією(як у самому TAS так і у SUT, Наприклад, різного роду false-positive дефекти або дефекти які є результатами trade-offʼів архітектурних рішеннь). Ну і, звісно, що не все можна автоматизувати й що автоматизація перевіряє тільки те, що здатен інтерпретувати комп’ютер.

У нових версіях цей розділ розбили на дві сертифікації. У Test Automation Engineer залишили інформацію про плюси та мінуси автоматизації, а в Test Automation Strategy Specialist перенесли блок про її цілі.

1.2. Success Factors in Test Automation

Тут ішлося про фактори, які треба враховувати для успішності автоматизації в тестованій системі, в архітектурі автоматизації та у фреймворку. Поради на кшталт: подбайте про тестованість системи, установіть стратегію автоматизації, визначте, як задизайнити архітектуру для автоматизації (і відразу відсилання до Test Automation Engineer силабусу), та зробіть ваш фреймворк підтримуваним, розширюваним, з репортерами, логами, легким дебагінгом, чітким планом деплойменту та виконанням тестів.

Поради доволі загальні і, як на мене, у старому силабусі розписані трошки краще. А в новому — це просто булет-поїнти, лише ключові моменти.

У Test Automation Engineer прибрали цей розділ повністю та перенесли в Test Automation Strategy Specialist 1.1.2.

Натомість додали розділ 1.2. Test Automation in the Software Development Lifecycle — тут розказано, як автоматизація вписується у Waterfall, V-model та Agile методології.

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

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

Test Automation Resources

Цей розділ додали тільки в Test Automation Strategy Specialist; у Test Automation Engineer його немає і раніше теж не було.

Тут нас ознайомлюють з рішеннями in-house (у себе в організації) та рішеннями vendor-based (залежні від інших вендорів). Є і третій варіант — це віддати все на аутсорс.

Окрім того, розповідають про типи ліцензій:

• опенсорс (безплатно та є підтримка);
• ліцензія на юзера або комп’ютер (привʼязка до юзерів або комп’ютерів);
• плавуча ліцензія (кількість рахується за кількістю паралельних юзерів);
• ліцензія на час запуску (плати, тільки коли юзаєш).

У розділі також наголошують: автоматизатор має бути як гарним розробником, так і гарним тестувальником. А іноді потрібен ще й Subject Matter Expert — профільний експерт, який допомагатиме автоматизатору. Утім, нерідко всі ці ролі зливаються в одній людині.

2. Preparing for Test Automation

Цей розділ доволі цікавий — його, знов-таки, сильно перекроїли.

2.1. SUT Factors Influencing Test Automation

Такий розділ прибрали. У ньому йшлося про те, що може вплинути на автоматизацію. Це, наприклад, SUT interfaces, Third-party software, Levels of intrusion, different SUT architectures, size and complexity of the SUT.

2.2. Tool Evaluation and Selection

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

Ті поради були вкрай розмитими й недієвими, з розряду «прочитай документацію та спитай на форумі».

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

2.3. Design for Testability and Automation

У новому силабусі цей розділ про проєктування тестованої системи перейшов у пункт 2.1, який називається Configuration Needs of an Infrastructure that Enable Implementation of Test Automation.

Він про те, як покращити testability (тестованість) системи, щоб автоматизація тестування краще вписувалась у нашу систему — раніше це був розділ 2.3. Design for Testability and Automation.

Наприклад, подумати про Accessibility identifiers, System environment variables, Deployment variables.

Також нам нагадують, що testability складається з:

• Observability
• Controllability
• Architecture transparency

Окрім того, додали пункт How Test Automation is Leveraged within Different Environments — про те, як автоматизація взаємодіє з різними середовищами. І це доволі важлива інформація, якої досі не подавали.

Тут описано, які можуть бути середовища для запуску тестів:

• Локальне
• Білд
• Інтеграційне
• Препродакшн
• Продакшн

У старій версії цього розділу подавали деякі приклади, як можна підвищити тестованість системи. Наприклад: моки та стаби, створення інтерфейсів, які імітують поведінку (скажімо, повільного HDD або якогось його збою), інтерфейси для заміни взаємодії з зовнішнім світом (як-от для ембедед-софта — зміни температури).

3. The Generic Test Automation Architecture

У Test Automation Strategy Specialist цей розділ узагалі інший. Спочатку нам розказують про різні піраміди тестування.

А потім — що робити, щоб досягти Shift Left та Shift Right тестування й оптимізувати розподілення тестів, якщо піраміда незбалансована (спойлер — починати аналіз «знизу вгору»).

Щодо Shift Left — це класичні поради з використання тестових двійників (моків, стабів) та контрактного тестування. Щодо Shift Right — порад особливо нема :D

Також нам нагадують, як автоматизація вписується у Waterfall, V-model та Agile. І розказують про те, коли автоматизація доречна, коли ні, а коли й узагалі неможлива.

У новій версії The Generic Test Automation Architecture перейменували просто на Test Automation Architecture. Цей розділ розповідає про архітектуру вашого фреймворку — дуже абстрактно, а проте важливо.

Його теж доволі сильно перекроїли.

По-перше, змінили головну картинку (у старій версії вона була детальнішою та відразу виконувала роль шпаргалки).

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

3.2 TAA Design

3.2.1. Introduction to TAA Design

Тепер цей розділ називається 3.1.2 Explain How to Design a Test Automation Solution. І описаний він дуже поверхнево.

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

Серед нового — розділ 3.1.3. Apply Layering of Test Automation Frameworks. У ньому вводять новий термін TAF Layers, а також виділяють такі шари, як Test scripts, Business logic та Core libraries. Ще трошки — і до чистої архітектури дійдемо :D

3.2.2. Approaches for Automating Test Cases

У новому силабусі це 3.1.4. Apply Different Approaches for Automating Test Cases. Його трошки скоротили, але принципово нічого не змінилось.

Додали Test-driven development — про TDD, думаю, вже кожен чув та може навіть імплементив.

Прибрали Process-driven scripting та Model-based testing, натомість додали ще Behavior-driven development.

3.2.3. Technical Considerations of the SUT

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

3.2.4. Considerations for Development / QA Processes

Прибрали повністю. Тут ішлося про акценти з боку розробки та забезпечення якості: про звітність, про безпеку та ролі, які мають доступ до ТАА, а також важливість, щоб ТАА підтримувала наявний набір інструментів у вашій організації.

3.3. TAS Development

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

У новому силабусі додався розділ 3.1.5. Apply Design Principles and Design Patterns in Test Automation

Тут дуже поверхнево сказано: використовуйте ООП, використовуйте SOLID, використовуйте дизайн-патерни — все. Якщо чесно, поради без контексту звучать так собі :D І, до речі, приклад зі старого силабусу в пункті 3.1 про принципи SOLID мені сподобався більше.

4. Deployment Risks and Contingencies

Із сертифікації Test Automation Engineer цю частину прибрали повністю та частково перенесли в четвертий розділ Test Automation Strategy Specialist.

Тут ішлося про фази ролауту автоматизації, такі як пілот та розгортання.

Цей розділ був про те, як обирати метрики та які види метрик бувають узагалі. А ще — про можливі ризики під час розгортання автоматизації. І також про те, як підтримувати автоматизацію, які є типи мейнтенансу (preventive — більше типів тестів, версій тощо, perfective — кращий перфоманс та adaptive — підтримка нових браузерів систем, регуляцій).

Зараз я б розглядав цей розділ як переосмислений та новий.

У новому силабусі Test Automation Engineer з нього стало два розділи: 4. Implementing Test Automation та 5. Implementation and Deployment Strategies for Test.

4. Implementing Test Automation

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

У розділі описано, які можуть виникнути ризики, повʼязані з деплойментом, — фаєрволи та утилізація ресурсів (CPU, RAM), а також технічні ризики: версіонування, логування, структурування тестів — фікстури та пост- і прекондішени — й оновлення. Це теж нова інформація, якої не було в старому силабусі.

Вона частково перетинається з Test Automation Strategy Specialist: 4.2.2. Identify Test Automation Risks in Deployment, але там ідеться про проєктні ризики: стафінг, затримки в постачанні та впровадженні автоматизації, нестандартні UI-елементи, неприбирання неактуальних тестів тощо.

Також у Test Automation Strategy Specialist додали 4.2.3. Define Approaches to Mitigate Deployment Risks — про можливі ризики з розгортанням, коли ти вперше деплоїш (тести будуть бігти повільніше, конфігураційні проблеми з енвом тощо) або коли підтримуєш уже розгорнутий фреймворк (перед деплоєм у продакшені треба протестувати TAS, перевірити, що звіти відправляються, нема деградації в перфомансі тощо).

Окремим пунктом іде розділ про підтримуваність фреймворку. Також є відсилання до книги Роберта Мартіна «Чистий код», дизайн-патернів, використання статичних аналізаторів коду та стратегії ведення гілок у гіті.

5. Implementation and Deployment Strategies for Test Automation

Розділ фокусується саме на прикладній частині інтеграції автоматизації в CI/CD-пайплайни. Таким чином нам розповідають тут про те, що тести є конфігураційні, компонентні, компонентно-інтеграційні (continuous integration), системні (continuous deployment) та системно-інтеграційні (continuous delivery).

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

Також у цей розділ додали інформацію про конфігураційний менеджмент. Нам треба памʼятати про налаштування тестового оточення (urls, креди) та тестових даних (залежно від оточення тестові дані можуть мати специфіки), а також про тестові набори (нагадують нам, що треба мати різни види тестів, як регресійні та smoke, плюс розділяти тести за фічами та релізними версіями).

І наостанок у цьому розділі нам розповідають про як контрактні тести.

Цей розділ дуже перетинається з Test Automation Strategy Specialist: 4.2. Test Automation Deployment Strategies, де нам спочатку роз’яснюють, як автоматизація допомагає швидше доставляти продукт та верифікувати дефекти.

Потім розказують, як автоматизація може допомогти на етапі приймального тестування — тут і статичний аналіз, і е2е-тести, і тести на відмову системи, на бекап та на перфоманс.

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

У Test Automation Strategy Specialist насипають нових термінів у розділ 4.3. Dependencies within the Test Environment. Серед них, зокрема, SUT (уже знайомий нам — система, яку тестуємо), Platform (де живуть компоненти автоматизації тестування), Test cases and test suites, Tools (тут, думаю, не треба пояснювати), TAF (фреймворк), а також інфраструктурні компоненти — Host machines (де тестові скрипти виконуються), Network (через мережеві запити ми з автоматизації достукуємось до системи), Platform (клауд чи контейнери), Software dependencies (залежності у фреймворку), SUT в інфраструктурному розумінні (версії браузерів, мобілок тощо).

5. Test Automation Reporting and Metrics

У новому силабусі це 6. Test Automation Reporting and Metrics.

5.1. Selection of TAS Metrics

Прибрали повністю. Перенесли у Test Automation Strategy Specialist: 5.2. Test Automation Metrics і суттєво врізали.

Залишили Pass-fail ratio, Ratio of failures to defects, Test automation execution time, Number of automated test cases, Functional coverage of test automation, Code coverage.

Натомість прибрали Automation benefits (кількість заощаджених годин), Effort to build automated tests, Effort to analyze SUT failures, Effort to maintain automated tests — по суті, перенесли в ROI-розділ, Number of false-fail and false-pass results, Tool scripting metrics (наприклад, цикломатичні складності) Automation code defect density (баги у фреймворку), Speed and efficiency of TAS components, Trend metrics.

5.2. Implementation of Measurement та 5.3. Logging of the TAS and the SUT

Цей розділ у новому силабусі включає 6.1.1. Apply Data Collection Methods from the Test Automation Solution and the System Under Test. У цій версії трошки більше інформації стосовно того, як отримувати логи: наприклад, із SUT (з UI, з АРІ, з вебсервера та бази даних), з фреймворку, з білда, з деплойменту, а також продакшн-логи й скриншоти та відеозаписи.

Також додали поняття Test logging — щоб зрозуміти: це дефект системи чи тесту. TAS- та SUT-логи залишилися без змін.

Додали ще один розділ — 6.1.2. Analyze Data from the Test Automation Solution and the System Under Test to Better Understand Test Results. У ньому йдеться про те, як аналізувати логи. Спочатку треба проаналізувати TAS-логи, а потім SUT. А також перевірити, чи подібна помилка уже траплялась і чи є подібний дефект; зрозуміти, який тест-кейс покриває цей дефект і на якому кроці зафейлився тест; проаналізувати SUT-логи, і якщо стан SUT не той, що очікували, то завести дефект. А також враховувати, що інколи оточення для тестів може бути або частково, або повністю недоступним під час прогону тестів.

5.4. Test Automation Reporting — розділ про звітність

У новому силабусі це 6.1.3. Explain How a Test Progress Report is Constructed and Published.

Додався блок Stakeholders to report to include — кого саме включати в репорт (менеджмент — архітект, проєктний або делівері-менеджер, тест-менеджери, тест-директор, операційні — продакт-менеджер / овнер, бізнес-аналітики, технічні — тимлід, скраммайстр, розробник БД, тест-лід, розробник).

А також додали, що різні ролі хочуть бачити різні результати: технічні — низькорівневі деталі, менеджмент — високорівневі та тренди.

Нам пропонують розглянути, зокрема, і створення дашбордів та AI/ML-аналіз на логах тестів.

А в Test Automation Strategy Specialist додали розділ, що робити з цими репортами, — 5.4. Decisions Made from Test Automation Reports. Написали, що ці дані допомагають визначати тренди й робити аналізи першопричин, збільшувати Shift Left та Shift Right тестування, фокусуватися на кластеризації дефектів, допомагати розробникам покращувати код і т. ін. На мій погляд — «водичка».

6. Transitioning Manual Testing to an Automated Environment

Прибрали повністю. Перенесли в шостий розділ Test Automation Strategy Specialist.

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

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

7. Verifying the TAS

7.1. Verifying Automated Test Environment Components

Коли ти все розробив, треба перевірити, чи працює воно. Як це зробити, описано в цьому розділі. Тут є певний чекліст перевірок. Наприклад, установити все, законфіжити, закастомізувати, перевірити повторюваність методів setup та teardown, а також доступність усіх інтерфейсів та зовнішніх систем.

Прибрали тільки перевірку, що Test scripts with known passes and failures (цілком очевидний пункт: тести, що падають, мають падати — і навпаки) та Configuration of the test environment and components (про те, що треба документувати компоненти TAS).

А також видалили пункт Intrusiveness of automated test tools — про те, що тісна інтеграція фреймворку та тестованої системи може призвести до негативних результатів, а високий рівень втручання — до дефектів, які в реальному житті не будуть траплятися.

Коли ви юзаєте тестові інтерфейси, бекдори, рівень вторгнення досить високий. Це може призвести до помилкових дефектів, оскільки тести можуть використовувати інтерфейси, які кінцевий користувач не бачить або взагалі з іншого контексту. Для UI-тестів система адаптується, але її поведінка не змінюється. Проте може змінитись час, що, ймовірно, вплине на поведінку. Ну, і найнижчий рівень втручання — це коли ми взаємодіємо з системою через зовнішні інтерфейси, як-от електронні сигнали чи сигнали USB для клавіатур. Цей підхід більш поширений для ембедед-розробки.

7.2. Verifying the Automated Test Suite було перейменовано на 7.1.2. Explain the Correct Behavior for a Given Automated Test Script and/or Test Suite

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

Так само як і Executing test scripts with known passes and failures, прибрали також Checking that there are enough verification points in the automated test suite and/or test cases. Це був цілком очевидний пункт про те, що логи мають бути, що результати очікування відповідають тому, що нам треба було, а також є докази тестового прогону).

З нового — зʼявився пункт Consider the intrusiveness of automated test tools (який краще був розписаний у старій версії, див. вище).

Також додали два нові розділи.

7.1.3. Identify Where Test Automation Produces Unexpected Results

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

7.1.4. Explain How Static Analysis Can Aid Test Automation Code Quality

Про те, як статичні аналізатори допомагають нам у пошуку вразливостей та дефектів.

8. Continuous Improvement

У старому все називали опціями для покращення автоматизації. В новому — розділили на можливості покращення за допомогою збору й аналізу даних та аналізу технічних аспектів. А ще додали прикладів.

Тепер нам пропонують розглянути як варіант покращення для аналізу даних:

• Test histogram
• Artificial Intelligence
• Schema validation.

З технічних пунктів у розділі Scripting прибрали:

• Treat the testware as software
• Evaluate existing scripts for revision / elimination.

У пункті Test execution краще перефразували, а також додали, що гарною практикою є паралельне виконання пакетних завдань (batch jobs).

Pre- and Post-processing замінили на Setup and Teardown.

Окрім того, додали пункт TAF (Test Automation Framework). У ньому йдеться, що коли апдейтите кор-бібліотеки або компоненти, спочатку зробіть імпакт-аналіз та пілотний проєкт, а після того плануйте вже адаптацію. Потім або всі команди одночасно оновлюють, або кожна команда вирішує це самостійно. Коли всі будуть готові, то оновлюємо на рівні основних бібліотек.

8.2. Planning the Implementation of Test Automation Improvement перейменували на 8.1.3. Restructure the Automated Testware to Align with System Under Test Updates

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

А також додали новий розділ — 8.1.4. Summarize Opportunities for Use of Test Automation Tools

Тут пропонують розглянути такі тестові активності, де допомагає автоматизація:

• Environment setup and control — коли вам треба створювати певні тестові дані (наприклад, юзери з різними профілями), це можна робити за допомогою тестових скриптів.
• Data aging — для маніпуляції тестових даних у тестовому оточенні (оновлюючи рік, наприклад, для тестів у базі даних).
• Screenshot and video generation — можна юзати відео чи скриншоти, які генерує інструмент для документації чи маркетингових цілей.

Ось і все. Напишіть в коментарях, яке з оновлень вважаєте найбільш важливим!

P. S. Щоб завжди бути в курсі оновлень, підписуйтеся на мій Telegram-канал або YouTube.