ШІ — загроза чи помічник? Як штучний інтелект змінює професію тестувальника
Дуже довго спеціалізацію тестувальника позиціювали як найлегший і найшвидший вхід в IT. І досі деякі курси та школи періодично спекулюють на цьому питанні. Проте багатьом вже стало зрозуміло, що все не так просто й однозначно. Крім того, стрімко розвивається штучний інтелект, завдяки інструментам якого також спостерігаються певні трансформації в роботі тестувальників і підходах до відбору кандидатів.
Сергій Романов — тестувальник із досвідом роботи понад 15 років, який наразі працює на українську компанію Brightgrove, що співпрацює зі стримінговим гігантом Pluto TV, власником якого є Paramount Global. Він поділився з dev.ua своїми спостереженнями щодо змін у напрямі QA, а також порадами щодо ШІ-інструментів і прикладами використання штучного інтелекту в роботі тестувальників, які можуть як допомогти, так і становити загрозу.
Дуже довго спеціалізацію тестувальника позиціювали як найлегший і найшвидший вхід в IT. І досі деякі курси та школи періодично спекулюють на цьому питанні. Проте багатьом вже стало зрозуміло, що все не так просто й однозначно. Крім того, стрімко розвивається штучний інтелект, завдяки інструментам якого також спостерігаються певні трансформації в роботі тестувальників і підходах до відбору кандидатів.
Сергій Романов — тестувальник із досвідом роботи понад 15 років, який наразі працює на українську компанію Brightgrove, що співпрацює зі стримінговим гігантом Pluto TV, власником якого є Paramount Global. Він поділився з dev.ua своїми спостереженнями щодо змін у напрямі QA, а також порадами щодо ШІ-інструментів і прикладами використання штучного інтелекту в роботі тестувальників, які можуть як допомогти, так і становити загрозу.
Довідка про Сергія Романова
36-річний Сергій Романов народився й вчився в Харкові. Там же отримав перший значний досвід на посаді PM та Automation QA Engineer у компанії Videal, яка створює інноваційні рішення для аналізу, обробки та використання великих даних. Надалі він працював як Software Development Engineer in Test у компанії з розробки програмного забезпечення SoftServe й американській компанії з розробки програмного забезпечення Red Hat.
Останні пʼять років Сергій Романов працює менеджером у стримінговому сервісі з підтримкою реклами Pluto TV, що належить і яким керує підрозділ Paramount Streaming компанії Paramount Global. Наразі фахівець управляє трьома командами тестувальників: фахівцями в Європі, де працюють його колеги з Харкова, Києва та Польщі, командою у США й фахівцями в Північній Америці.
Про тестувальника — ролі, завдання, інструменти
Саме тестувальники — ті фахівці, які відповідають за якість програмного забезпечення. Зокрема, вони перевіряють, наскільки добре софт відповідає вимогам, і насамперед — як програма, яку створюють, поводиться в різних умовах. А також зʼясовують, які критичні помилки можуть бути виявлені під час використання цієї програми або цього продукту. І хоча насправді тестувальники виконують ролі кінцевого користувача, їхній вплив, на думку Сергія Романова, на цей час недооцінений.
Сергій Романов, тестувальник із досвідом роботи понад 15 років (Фото з особистого архіву)
Основними завданнями тестувальників, що виконують ручне або автоматизоване тестування, є:
аналіз вимог;
розробка тестових сценаріїв;
ідентифікація дефектів;
перевірка виправлення виявлених раніше помилок.
Отже, тестувальник насамперед постійно комунікує з командою, зокрема з розробниками, аналітиками, менеджерам продукту, щоб разом рухатися в одному напрямку для створення стабільного та якісного продукту.
Серед основних інструментів, які фахівці використовують для ручного тестування, зокрема:
TestRail— система управління тестуванням, яка допомагає структурувати процес, вести облік тест-кейсів, відстежувати результати та звітувати про них.
Jira— комерційна система від компанії Atlassian, яка допомагає в управлінні проєктами й у створенні та відстежуванні помилок.
Postman — інструмент для тестування й аналізу API, за допомогою якого можна надсилати запити до сервера, отримувати відповіді й аналізувати їхню поведінку, щоб перевіряти роботу бекенд-застосунків.
Charles Proxy— інструмент для перехоплення й аналізу мережевого трафіку, що дає змогу переглядати HTTP запити й відповіді між клієнтом і сервером у реальному часі, щоб тестувати, досліджувати й налагоджувати роботу застосунків.
Browser DevTools — набір інструментів, вбудованих у сучасні веббраузери (наприклад, Chrome, Firefox, Edge), які допоможуть вивчати HTML, CSS і JavaScript-код сторінки, налагоджувати код і знаходити помилки, аналізувати продуктивність сайту, емулювати різні пристрої та роздільну здатність екрана.
Для автоматизації тестування, зокрема, щоб перевірити функціональність системи, фахівці користуються програмами, які дають змогу писати автоматизовані тести й запускати їх у процесах Continuous Integration і Continuous Deployment (CI-CD):
Selenium — це фреймворк із відкритим кодом для автоматизації вебзастосунків, який підтримує різні мови програмування та спрощує кросбраузерне тестування.
REST Assured — це Java-бібліотека, яка допомагає у створенні й виконанні HTTP-запитів до API, а також перевірки відповідей на відповідність очікуваним результатам.
TestNG і JUnit— це фреймворк для автоматизованого тестування на Java, який дає змогу керувати порядком виконання тестів, об’єднувати їх у групи, запускати тести паралельно й отримувати детальні звіти.
Jenkins — автономна платформа з відкритим кодом для безперервної інтеграції, написана на Java, яка надає сотні плагінів для автоматизації процесів збірки, тестування, розгортання й обслуговування будь-якого проєкту.
На початковому етапі проєкту тестувальники здебільшого спочатку пишуть автотести для перевірки функціональності. На наступному етапі відбувається тестування продуктивності, на якому моделюють реальні сценарії використання, щоб оцінити навантаження на систему в прайм-тайм — час, коли очікується найбільша кількість користувачів. Щоб оцінити продуктивність, тестувальники запускають навантажувальні тести для бекенд-частини за допомогою таких інструментів, як:
JMeter— найпростіший інструмент, за допомогою якого можна виміряти прискорення, який складається з плагінів, що додають у проєкт, і який можна конфігурувати.
Gatling— це зручний інструмент для тестування навантаження, що дає змогу моделювати трафік за допомогою коду, переважно мовою Scala. Він легко конфігурується й інтегрується в автоматизовані пайплайни CI/CD і генерує детальні звіти.
«Особисто для мене тестувальник — це необов’язково той, хто займається пошуком дефектів, але точно той, хто розуміє продукт і допомагає команді створити високоякісний і технологічний софт», — зауважує Сергій Романов.
Як змінилися завдання тестувальника з появою ШІ
Професія тестувальника не стоїть на місці, а штучний інтелект змінив роль цих фахівців, трансформуючи її. Як акцентує Сергій, якщо раніше основну увагу приділяли ручному тестуванню або написанню автоматизованих тестів, то сьогодні штучний інтелект перебирає на себе більшу частину рутинних завдань. Але фахівець упевнений — це не означає, що роль тестувальника зникає.
Навпаки, ШІ допомагає завданням тестувальника трансформуватися на користь технічного мислення, коли спеціалістам потрібно думати у стратегічному напрямку. Зокрема, вирішити, що унікального може зробити команда, й аналізувати, що не може зробити штучний інтелект, щоби знайти дефекти в продукті.
«Ми йдемо з автоматизації в аналітику, коли нам потрібно більше думати про те, як повинен працювати продукт», — підкреслює тестувальник.
ШІ-інструменти для тестувальників
З появою штучного інтелекту змінилися не лише завдання тестувальників, а й інструментарій, яким вони користуються у своїй роботі.
Зокрема, як розповідає Сергій Романов, дуже допомагає ChatGPT— його тестувальники можуть залучати для складання тестової документації. Експерт зауважує, що раніше було дуже мало тестувальників, які готували якісну документацію щодо своїх проєктів. Завдяки чатботу тестова документація стала виглядати значно якісніше, а її структура стала більш логічною та зручною для сприйняття. Проте є нюанси, зокрема між платною й безоплатною версіями програми. Наприклад, за словами фахівця, тестовий план для однієї з фіч, складений платною версією ChatGPT, потребує близько 20% уточнень. Користуючись же безоплатною версією чат-бота, кількість необхідних виправлень збільшується до 30–40%.
«Загалом суть ChatGPT передає правильно десь на 90%, а 10% залишається на інформацію, яка ніким не підтверджується, і яку він, імовірніше, сам вигадав», — зауважує експерт.
Сергій також підкреслює, що для якісного використання інструменту важливо заздалегідь скласти промпт. У промпті потрібно детально розповісти про свої очікування, закцентувати, що чатбот повинен надати лише перевірену й точну інформацію, а в питаннях, де ChatGPT некомпетентний, нічого не вигадувати. Крім того, у платній версії чатбота є можливість залишити запит на ресьорч, наприклад, щодо деяких нових фіч.
Також серед інших ШІ-інструментів Сергій Романов радить використовувати:
MABL — це хмарна платформа для автоматизованого тестування, яка поєднує можливості штучного інтелекту й машинного навчання для створення, виконання та підтримки end-to-end тестів.
Приклад як Mabl генерує тестовий сценарій у реальному часі (Скриншот Сергія Романова)
Платформа підтримує тестування вебзастосунків, мобільних додатків, API, а також надає базові можливості для аналізу продуктивності.
Приклад як Mabl виконує тестовий сценарій (Скриншот Сергія Романова)
Mabl автоматично виявляє зміни в інтерфейсі, адаптує тести до цих змін і зменшує кількість помилкових спрацьовувань. Завдяки інтелектуальній аналітиці Mabl допомагає швидко виявляти проблеми, що впливають на досвід користувача, і забезпечує безперервну якість на всіх етапах розробки.
Скриншот із аналітичного звіту в Mabl (Скриншот Сергія Романова)
TESTIM — це платформа для автоматизації тестування, яка використовує штучний інтелект для прискореного створення, стабілізації та підтримки автотестів, а також надає інструменти TestOps для керування тестовим процесом.
Дашборд Testim з основними показниками проєкту (Скриншот Сергія Романова)
Алгоритми машинного навчання допомагають ідентифікувати зміни в інтерфейсі, зменшувати кількість хибних спрацювань і підтримувати тести актуальними навіть у динамічно змінних застосунках.
Результати виконання тестів у Testim (Скриншот Сергія Романова)
Також додатково з Testim можна використовувати Sealights, який дає змогу визначити, які саме частини коду були покриті під час виконання автотестів. Це допомагає фокусувати тестування лише на змінених або ризикованих ділянках застосування, підвищуючи ефективність перевірок і скорочуючи годину зворотного зв’язку.
Скриншот із Sealights, де видно, що завдяки аналізу зміненого коду система рекомендувала пропустити 99% тестів (Скриншот Сергія Романова)
Functionalize— це хмарна ШІ-платформа для автоматизації функціонального тестування, яка використовує генеративний ШІ для створення, оптимізації та підтримки автотестів. Вона розроблена для мінімізації ручної роботи завдяки автоматичній генерації тестів на основі змін у коді та сценаріїв взаємодії користувачів із застосунком. Платформа автоматично визначає найризикованіші або змінені ділянки коду, які потребують перевірки. Також Functionalize пропонує релевантні тести, що дають змогу скоротити час на написання сценаріїв і зосередитися на найкритичніших модулях застосунку. Платформа також інтегрується із CI/CD, системами контролю версій Git, Jira й іншими інструментами розробки.
Саме ці інструменти використовують машинне навчання для створення так званих self-healing тестів. І завдяки ШІ команда тестувальників витрачає на тестові сценарії, які потребують допрацювання зі зміною продукту, значно менше часу. Так, за словами експерта, завдяки ШІ-інструментам адаптація сценарію замість кількох днів потребує кілька годин.
Серед інших ШІ-інструментів, які значно спрощують роботу тестувальників, експерт називає також GitHub Copilot, який допомагає спеціалістам швидше писати автоматизовані тести. Крім того, цей ШІ-інструмент може робити код-рев’ю та знаходити помилки в написаному коді. Також, як підкреслює Сергій Романов, за допомогою GitHub Copilot можна створювати не тільки автоматизовані тести, а й тестові утиліти, які можна використовувати, щоб виконувати певні дії на стороні автоматизованого фреймворку майже в сто разів більше.
Крім того, тестувальник створив власне рішення, адаптоване під унікальні завдання відеострімінгової індустрії. Це проєкт під назвою HLS AI Analyzer, який використовує ChatGPT API для перевірки цілісності.m3u8 плейлистів і медіасегментів. Це рішення автоматично завантажує HLS-маніфест, витягує .ts сегмент, витягує з медіа сегменти метадату через ffprobe, а потім відправляє всі дані в ChatGPT API для інтелектуального аналізу на відповідність стандарту RFC-8216. Такий підхід дає змогу гнучко виконувати тестування відеостриму в реальному часі й інтегрувати AI у тестову інфраструктуру. Рішення, написане на Java, легко розширюється й може бути вбудоване в пайплайн CI/CD.
У межах проєкту HLS AI Analyzer Сергій використовує ChatGPT API та модель GPT-4o для аналізу відеостриму й відеофайлів, але за бажання це рішення можна адаптувати й для локального використання. Замість звернення до зовнішнього API можна використовувати локальну ML-модель і виконувати аналіз прямо на своїй машині — без залежності від інтернету та хмарних сервісів. Такий підхід дає змогу зберегти контроль над даними, покращити приватність і кастомізувати модель під конкретні завдання у стримінговому пайплайні.
Згадуючи інші інструменти, які допомагають у роботі тестувальників, експерт розповів про:
Хмарну платформу DataDog, яку використовують для моніторингу й аналізу продуктивності та безпеки інфраструктури й додатків. Він пояснює, що DataDog-тестувальники використовують для аналізу логування й метрик програми. ШІ в DataDog дає змогу під час збою в продакшені аналізувати, які сервіси також були схильні до впливу цього збою. Також платформа дає змогу зробити Root Cause Analysis, який згенерує всю необхідну інформацію для того, щоб цю проблему усунути правильнішим шляхом.
Інструмент Applitools — платформу, яка використовує ШІ для тестування інтерфейсу користувача. Applitools не просто порівнює пікселі, а намагається зрозуміти, як змінився інтерфейс і чи є ця зміна критичною для кінцевого користувача.
ШІ — вимоги до тестувальників і помилки у використанні
Попри досить активну роль, яку ШІ вже відіграє в роботі тестувальників, вимоги до фахівців під час прийняття на роботу, як говорить Сергій Романов, не дуже змінилися. Хоча він підкреслює, що на інтервʼю в кандидатів уже запитують про досвід використання ШІ-інструментів, зокрема GitHub Copilot, а саме — чим він допоміг у минулому і як фахівець планує його використовувати в майбутньому.
«Ті тестувальники, які зараз уже приділяють час ШІ-системам та інструментам, у безпеці, тому що вони завжди знайдуть для себе, чим займатися на проєкті», — додає експерт, заспокоюючи QA-фахівців.
Він підкреслює, що на власному досвіді бачить, як тестувальники стали приділяти менше уваги навичкам хорошого написання коду, а віддають цю роботу штучному інтелекту. Надмірне використання ШІ в цьому питанні призводить до більшого код-ревʼю.
«З того, що я бачу, код, який пише Junior-тестувальник за допомогою ШІ, потребує значного аналізу та виправлень», — додає Сергій Романов. Крім того, він додає, що ШІ-інструменти важливо знати й уміти ними користуватись, але розуміючи їхні особливості та підводні камені. «Якісно написаний і добре структурований код може бути незайвим козирем у команді», — зауважує тестувальник.
Говорячи про іншу поширену помилку, Сергій згадує ситуації, коли тестувальники не дають GitHub Copilot усю інформацію необхідну для написання автотестів. Зокрема, не занурюють ШІ в контекст продукту або фічі, для якої пишеться автоматизований тест. Так, якщо ШІ-інструмент не враховує, наприклад, певні aceptance-критерії, які вказані в Jira Stories, то написаний ним тест, за словами експерта, ймовірніше, не дасть повних результатів.
Приклади ШІ в тестуванні
Сергій уже підкреслював, що інструменти ШІ стають гарною підмогою в підготуванні документів від тестувальників. Проте, говорячи про практичні приклади застосування штучного інтелекту в роботі, QA-експерт підкреслює, що жоден інструмент не буде впроваджено, поки для нього не буде розроблять Proof of Concept. Тобто, попередньо з інструментом повинна ознайомитись команда, а керівництво має узгодити, яке value він може принести. Саме розгляд ШІ-інструмента менеджерами, інженерами й техлідами відбувається до етапу впровадження.
Є кілька прикладів процесів, які назвав Сергій Романов, де ШІ себе добре зарекомендував у тестуванні, зокрема:
Тестування інтерфейсу — тут у більшості випадків застосування ШІ допоможе прискорити написання тестових сценаріїв, випуск релізів і багато іншого.
Тестування API — у цьому випадку використання ШІ теж є доречним, тому що є інструменти, які дають змогу на підставі інформації у Swagger розробляти тестові сценарії та виконувати ці тестові сценарії.
Коли ШІ не допоможе тестувальнику
Але штучний інтелект не завжди може стати ефективним помічником для тестувальників. Зокрема, як підкреслив Сергій Романов, коли йдеться про великі проєкти, де використовують унікальні протоколи й технології, ШІ, ймовірніше, не зможе продемонструвати весь свій потенціал.
Як приклад він навів ситуацію у проєкті з відеостримінгом, над яким наразі працює команда Сергія. ШІ не може допомогти їм у написанні автотестів для медіафайлів і відеопротоколів. І тут ідеться ось про що.
Згідно з розповіддю експерта, якщо поставити ШІ базове завдання перевірити HLS-маніфест, попередньо завантаживши його за допомогою автотестів, то штучний інтелект, найімовірніше, упорається з цим завданням. Саме документація, яка є для цього протоколу, допоможе ШІ зрозуміти, що в цьому маніфесті правильно, а що ні.
Інша справа, якщо йдеться про тестування самих медіафайлів, які завантажує плеєр під час відтворення відео. Тут ШІ уже не зможе виконати роботу сам і потребуватиме допомоги людини. Штучному інтелекту буде потрібен фахівець, який напише код, де цей медіафайл насамперед парситься. Після того, як дістанеться метадата, саме вона транслюватиметься в ШІ, і штучний інтелект уже буде визначати, наскільки ця метадата відповідає очікуванням певної фічі або критерію для продукту.
«Є продукти, зокрема, які мають юзер-інтерфейс та API, де інтеграція із ШІ відбудеться дуже швидко, і бенефіти можна буде побачити вже на ранніх етапах. Але у продуктах, які унікальні самі по собі, інтеграція із ШІ, імовірніше, не покаже результатів на ранніх етапах», — резюмував експерт. Крім того, він додав, щоби правильно налаштувати ШІ, потрібно ще багато часу, аби побудувати весь цей ланцюжок інтеграції й адаптувати фреймворк для використання ШІ.
Також Сергій підкреслює, що ШІ не допоможе тестувальнику у визначенні зручності інтерфейсу для кінцевого користувача. У цьому питанні, як і раніше, компетенція залишається за людиною. Крім того, ШІ, імовірніше, не може бути креативним у пошуку складних сценаріїв, тому що в нього не завжди може бути правильний бекграунд. Тестувальник, який має гарні навички тест-дизайну, може знайти більше сценаріїв, які ідентифікують баги у продукті, вважає експерт. На його думку, ШІ також справляється з цим завданням, але в нього, по суті, шаблонне мислення, і він не виявляє таку креативність, як людина.
Але комбінація правильного фахівця з хорошими навичками тест-дизайну, який працює із ШІ, що запропонує кілька сценаріїв, на думку Сергія Романова, може прискорити роботу тестувальника. У такому випадку саме людина буде аналізувати й виявляти, що ще не запропонував штучний інтелект, і що може запропонувати сам фахівець.
«Ми приходимо до варіанту, коли ШІ може прискорити роботу тестувальника, але потрібно буде допрацювати 20% того, що штучний інтелект зробити не в змозі», — підкреслює експерт.
Яке майбутнє чекає тестувальників із появою ШІ
Кількість новин про ШІ-розробки й інструменти, яка множиться майже щоденно в геометричній прогресії, дає підстави вважати, що штучний інтелект має велике майбутнє. Дивлячись на те, як ШІ може допомогти тестувальникам у майбутньому, Сергій Романов вважає, що штучний інтелект забере на себе всю рутинну роботу, залишаючи фахівцям з QA більше простору для креативних ідей.
Наразі вже є інструменти, які розподілені за функціоналом, наприклад, один сфокусований на юзер-інтерфейсі, інший — на написанні коду. У майбутньому, за словами Сергія Романова, ШІ-інструменти також сфокусуються на певній сфері життя й діяльності людини. Наприклад, зʼявиться ШІ, який безпосередньо зможе працювати з моделями для медицини або для агентств нерухомості.
Крім того, Сергій впевнений, що фахівці залишаться в безпеці, а ШІ не замінить їх повністю.
«Це буде зона розвитку для тестувальників — потрібно буде переналаштуватися від рутинних завдань у бік аналізу й перевірки роботи ШІ-систем», — пояснює він.
Зокрема, за словами експерта, у QA-фахівців стане більше обовʼязків, де потрібно буде стежити не лише за якістю продукту та пошуком дефектів. Крім того, тестувальникам потрібно бути готовим до того, щоб брати безпосередню роль в обʼєднанні команд і побудові ефективної взаємодії між відділами.
«Навіть для виробників трун і пам’ятників я писав тексти». Як стати game-тестувальником під час війни: історія колишнього металурга, страховика, копірайтера
34-річний Андрій Зубков під час війни увійшов в IT, докорінно змінивши свою кар'єру і буденне життя. Тепер він QA Engineer у компанії Pingle Game Studio — тестує ігри. А до цього працював на металургійному комбінаті, в страхуванні та навіть копірайтером. Свою історію про вхід в нове життя Андрій розповів dev.ua.
«Я вигоріла настільки, що вже не могла дивитися на комп'ютер». Історія QA-інженерки про великі гроші, безглузді купівлі, вигорання та дауншифтинг
Хмельничанка Олена Шеліна ― айтішниця, яка настільки вигоріла на роботі, що вирішила покинути IT-сферу та докорінно змінити своє життя. За 9 років роботи в IT дівчина пройшла всі ступені кар’єрного зростання, змінила кілька компаній і навіть напрямів. Та прокинувшись одного ранку, вирішила, що більше не зможе виконувати свою роботу якісно. Дівчина переїхала в село, завела господарство та повністю змінила професію. Розповідаємо її історію.
Manual QA з Luxoft Ukraine вже три роки приборкує вітер на воді та кайфує від цього. Ось його історія та поради для тих, хто мріє про море та віндсерфінг
«Навколо IT» — нова рубрика, в якій ми збиратимемо все корисне для життя айтішника, яке не стосується його роботи. Виявляється, у айтішників найрізноманітніші хобі. Ми вже писали про айтішників-бігунів, плавців, художників, музикантів, танцівників, і навіть заводчика собак. Сьогодні розповідаємо про програміста, який навчився приборкувати вітер. 39-річний Сергій Костюченко — Manual QA у Luxoft Ukraine — розповів про своє захоплення віндсерфінгом та можливості займатися цим видом спорту для всіх бажаючих.
Хочете повідомити важливу новину? Пишіть у Telegram-бот
Головні події та корисні посилання в нашому Telegram-каналі
