Ші в тестуванні API

Цей день настав - ось і ми торкаємося AI-шок😇
Підготували вам пару класних інструментів а також коротенько їх плюси/мінуси. Го!

🤖Postbot by Postman 🤖

Вже пів року як Postman - найтоповіша тулза для розробки і тестування API має вбудованого асистента Postbot, що реалізований на генеративній моделі ШI. Важливою перевагою є те, що він доступний і в безкоштовній версії також.

Чим може бути корисним нам?
👉 Генерація автоматичних тестів для отриманої відповіді від сервера. Це доволі непоганий тул для того, щоб вчитися саме синтаксису і написання тестів. Як на мене, генерує непогано і багато! Проте, це не має нічого спільного з тест дизайном, тому як і у випадку з ChatGPT для тривіальних випадків годиться, але мозок людини-тире-QA Postbot не замінить.

👉 Генерація документації для запитів. Оце для мене прямо ґеймченжер). Тільки подивіться на цей скарб:

This API endpoint allows you to create a new customer in the BigCommerce system. It is an HTTP POST request that should be sent to the following URL: https://www.blabla.com/api/bigcommerce/createCustomer.
Request Parameters
The request does not require any specific parameters. However, you need to include the necessary customer information in the request body. This information should be sent in JSON format and should include details such as the customer's name, email, address, and any other relevant information.

Response
The response for this request will have a status code of 409, which indicates a conflict. The response body will be in JSON format and will include the following properties:
* status: This property indicates the status of the request. In this case, the value is 0, which suggests that the request was not successful.
* noscript: This property provides a noscript or denoscription for the error. In the last execution, it was empty.
* type: This property specifies the type of error encountered. In the last execution, it was empty.
* errors: This property contains a nested object that provides more details about the error. In the last execution, the message property within the errors object was empty.

Please note that the specific error message or reason for the conflict is not provided in the response. You may need to refer to the API documentation or contact the API provider for more information on resolving the conflict.

Не ідеально, але команда вам скаже дякую!😊

🤖Генерація синтетичних даних 🤖

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

Два способи:

👉 GPT - або чат або API OpenAi. Ви можете по API звертатися з промптами для отримання певного тіла запиту, цілого або часткового (значень параметрів) і вже їх використовувати в тестуванні ваших APIшок).

👉 Використання глибоких генеративних моделей. GANs - це тип нейронних мереж, які складаються з генератора і дискримінатора. Генератор створює нові дані, а дискримінатор намагається визначити, чи це реальні дані чи штучно згенеровані. Процес тренування GANs дозволяє генераторові створювати дедалі більш реалістичні дані. Приклад: https://gretel.ai/ Пограйтесь - це доволі цікаво😼

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

Сподіваюсь було цікаво!
Діліться тулзами якими користуєтесь ви, в коментарях!
До зустрічі👽

🦄 Хочу поділитися із вами цікавою пропозицією від наших друзів Certified Unicorns, адептів ISTQB, які навчають не лише теорії, а й впровадженню міжнародних стандартів в реаліях українських компаній.

Рання реєстрація на курс підготовки до сертифікації ISTQB FOUNDATION LEVEL (Syllabus 4.0) від Олександри Ковальової доступна за найвигіднішою ціною до 1-го грудня.

Важливі деталі:
👉 старт 24 січня 2024 року;
👉 5 тижнів навчання (15 занять, прямі трансляції та доступ до записів);
👉 заняття в понеділок, середу та п’ятницю, 9:15-11:00am (по Києву);
👉 навчання побудовано на оновленій версії силлабусу - 4.0, що вийшла у 2023 році;
👉 курс включає всі матеріали, відео, тести, книги і спеціальні інструменти, які допомагають учасникам якісно підготуватися і відчувати себе на іспиті спокійно і впевнено;
👉 підтримка куратора і тренера в чаті між заняттями 24/7;
👉 допомога з реєстрацією на іспит та всіма оргдеталями;
👉 мова курсу: всі матеріали та тести — англійською, пояснення тренера на заняттях — українською.
🟡 Для броні місця на курсі необхідно внести мінімум 50% вартості курсу (другу половину можна оплатити до 24 січня включно).

🔷Деталі та реєстрація: https://bit.ly/3QXTKIA

🔰Більше новин, корисних матеріалів та інсайтів про ISTQB на каналі Certified Unicorns: https://news.1rj.ru/str/istqb_certified_unicorns

Якщо хочете, щоб у вас було менше роботи, пишіть менше тестів, але запамʼятайте саме головне, тести повинні бути такими, які перевіряють основну логіку системи!

Тестами можна розписати всю систему, покривши її в довжину і впоперек, але чи варта ця гра свічок?

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

Тут вам допоможуть у пригоді:
1. Аналіз, опрацювання та розуміння вхідних даних, це можна добитися завдяки вивченню документації, спілкуванню з BA, PO, DEV, Designers ну і користувачами врешті решт
2. Використання технік тест дизайну, за цим на курс до Alexandra Kovalova або ж до мене на тест марафон
3. Оптимізація тестових сценаріїв використовуючи техніки комбінаторики.

Є багато інструментів та підходів, але головний інструмент це ваш мозок, тому підходьте до роботи з розумом 😉

Та памʼятайте, в нашій справі головне не кількість, а якість! © кеп

Ваш покірний слуга, Роман Якимчук

Друзі привіт 👋

У цю неділю ввечері хочу провести для вас практичний воркшоп на тему лідерства в команді

Розглянемо такі речі як:
- комунікація в команді та за її межами
- створення стратегії та планування
- збір метрик та підготовка звітів

Це займе у нас з години з 18:00 по 21:00 у цю неділю 3 грудня

Кому цікаво, вхід за донат на банку 💰

Збираємо на дитяче свято 🎁🥳🙏🏻

Давайте подаруємо свято діткам з дитячого будинку

🎯Ціль: 50 000.00 ₴

🔗Посилання на банку
https://send.monobank.ua/jar/9rGhVn8qUV

💳Номер картки банки
5375 4112 1262 1416

Гайз привіт🫡

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

Початок о 19:00

Хто бажає доєднатися і подарувати діткам трохи новорічного свята, кидайте 🔥 в коментарях

Тест менеджмент і побудова процесів тестування, на QA Magic MeetUp 4.0

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

На вас чекають:

▪️Виступи - Романа Якимчука, Олександра Хотемського, Олександри Ковальової,
Романа Марінського та Олексія Остапова
▪️Топова локація в центрі Києва
▪️Нетворкінг з колегами та спікерами якого не вистачає: сидячи за ноутом
▪️Драйвова атмосфера та смачна їжа
▪️Афтепаті з новорічною тематикою🔥


Локація - Hall A, Володимирська 79, Київ (у центрі столиці). Тривалість - 1 день

Вартість: 2800 грн

Хто бажає доєднатися до топової офлайн тусовки тестувальників - WELCOME🙌

Деталі на сайті https://conference.ry-consulting.online/

Як зменшити кількість багів на проекті?

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

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

Спочатку члени команди не спілкуються один з одним і їм не вдається повідомити про проблеми на ранній стадії.

Це не обов'язково має бути помилка, інколи виникає якась проблема з налаштуванням програми, немає середовища тестування, доступу до певних ресурсів (наприклад, певних інструментів або зовнішніх API сервісів), опис завдання розпливчастий або команда налаштована неправильно.

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

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

Як же ви як тестувальники можете використовувати Shift Left підхід на своєму проекті?
Перш за все ви можете займатися детальним аналізом вимог та брейнштормінгом, ще на стадії проектування системи. Всі комунікації з девелоперами та архітекторами, будуть для проекту корисними та дадуть свій вплив на покращення якості програмного продукту.
Ви навіть можете піти ще лівіше, та обговорити з замовником, які користувацькі сценарії найчастіше використовуються їх цільовою аудиторією. Або навіть самим зробити Lab Usability тестування, про що я вам розповідав вже кучу разів на своїх вебінарах.

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

Тому рекомендую ознайомитись з цим підходом та впровадити його на ваших проектах, якомога раніше. Тому що Shift Left - справжній підхід QA інженера.

А які ви підходи використовуєте на своїх проектах, для покращення якості?
Діліться в коментарях 🙌

Гайз, нагадую що завтра ми збираємося на практичний ворк-шоп, на якому поговоримо про

- комунікацію в команді та за її межами
- створення стратегії та планування
- збір метрик та підготовка звітів

Це займе у вас 3 години з 18:00 по 21:00 тому, хто бажає доєднатися і отримати корисний досвід - welcome

Спікери: Роман Якимчук та Ріна Ужевко 😎

Друзі, пан Хотемський просить доєднатися нас до збору, давайте допоможемо хто чим може і закриємо збір разом 💪

NLAW, РПГ 18 Муха та безкоштовне заняття з вогневої підготовки за донат!
Друзі, відкрито збір на пікап Nissan Navara🚙 для окремого взводу розвідки спеціального призначення бригади наступу «РУБІЖ»!

Використаємо авто як евакмобіль 🚑 або встановимо станок під АГС / МК19

Козаки! Задонатьте, будь ласка, вартість кави. Ваша гривня має вагу в зборі! Це дуже допоможе✊🏻

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

Місця:
1 - тубус NLAW
2 - тубус РПГ 18 Муха
3 - вогнева підготовка

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

Будь ласка, долучайтесь!

На пікапчик 🇺🇦💪

🎯Ціль: 247 000 ₴

🔗Посилання на банку
https://send.monobank.ua/jar/6XPy76HssN

💳Номер картки банки
5375 4112 0941 0948

Гайз, давайте знайомитись з першими спікерами, які чекають вас на QA Magic MeetUp 4.0

Олександр Хотемський
Quality Practice Lead at Doxy.me

Основні напрямки моєї роботи – це розробка тестів, підходів, архітектури та інструментарію для автоматизації тестування. За більш ніж 11 років досвіду, попрацював на багатьох проектах з використанням JavaScript, TypeScript, Java та Python. Проводжу курси по тестуванню (Web, API, Test Infrastructure), та веду власний канал на YouTube. Розвиваю telegram спільноту @js_for_testing. Переможець та суддя Ukrainian Dev Challenge. Доповідач на різноманітних IT конференціях.

На конфефенрції ми з вами:

Подивимось на один з експериментів над яким я зараз працюю: це зберігання ручних тест кейсів в коді, та виконання і репортинг через фреймворк playwright. Часто для ручних тестів використовуються спеціальні test case management системи, які є доволі дорогими, негнучкими, а також відірвані від користування командою розробників (економлять на аккаунтах, нікому не цікаво і т. д.). В своєму підході я експериментую щодо використання playwright, як фреймворку для зберігання і виконання і репортингу ручних тестів прямо в коді. Це приносить купу цікавих та перспективних варіантів використання про які я розповім в цій доповіді.
----------------

Та Олексій Остапов
QA Test Lead at Infopulse

Маю 15 років досвіду в QA. Основний напрямок моєї роботи – тест менеджмент, але, не обмежуючись ним, цікавлюсь програмуванням та автоматизацією тестування на Python та JS, тестуванням навантаження і TestOps. Один з авторів каналу про тестування QA Mania. Ведучий подкасту Питання Якості на DOU. Автор курсів з тестування та численних публікацій, доповідач на конференціях. Вимогливий, але справедливий суддя Dev Challenge.

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



Це тільки невеличка частина з того досвіду який ви зможете почути зі сцени. Хто ще планує доєднатися та дізнатися більше, що саме на вас чекає, welcome на сайт https://conference.ry-consulting.online/

Друзі хто на мене підписаний в інстаграм, мене взломали, нікому не скидати гроші