| Mother of QA |

Хелоу хелоу!
Минулого вівторка, як завжди у нас був вебінар у комʼюніті і я несу Вам вижимку!
Цього разу я заміняла Артема і допомагала у проведені і це доволі цікавий experience😁спробую ще, скажу чи сподобалось…
А поки йдемо до вижимки)

👩🏼‍💻Оксана Лодигіна, «GraphQL under test»

💡GraphQL займає 3 місце в світі серед найбільш популярних АРІ архітектур (це нам каже офіційний ресурс Postman).

☠️ «Beautify» під час роботи з GraphQL краще не натискати😅

‼️ У GraphQL важливі пробіли та переноси.

📁 GraphQL не працює з файлами та їх завантаженням.
P.S. це можливо, але потребує часу, роботи та зусиль!

📌 Ця АРІ розрахована на вибірку потрібних даних.

🌲 Важко копатись всередину цих гілок і розуміти куди воно все йде.

🔎 Коротка історія GraphQL:
• Восени 2012 року Facebook випустив свій новий додаток для iOS на базі GraphQL.
• У 2015 році команда GraphQL вирішила перейти на відкритий код.

💻 GraphQL - це зручна для розробників мова запитів. Дозволяє маніпулювання даними для API.

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

🥲 У GraphQL є проблеми з обробкою помилок:

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

❤️Хороші практики обробки помилок GraphQL

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

Отакий був вебінарчик!
Готую для вас відгук по QA Day і біжу відпочивати❤️
Всім гарного вечора!

Вечір добрий!
Як і обіцяла даю Вам другу частину вижимки🔥
А загальний відгук надам завтра/післязавтра🥰

💻Online QA Day 2024. PART 2.💻

👩🏼‍💻 Свят Логін, «Що можна витягнути з мобільних додатків»

📁 Успішність взломів у відсотках:
• Веб - 96%
• АРІ - 50%
• Андроїд - 19%
• IOS - 18%
• Оперативні системи - 13%
• IoT - 11%
• Computer hardware - 7%
• Blockchain - 5%

📌Необхідно налаштовувати моніторинг, щоб знати чи були якісь атаки на ресурс.

📌Чим старіший софт на додатках - тим швидше їх можна ламати.

☠️ Для початку зловмисники роблять reverse engineering.
Якщо розробник не забрав вразливі дані, то цим може скористатись зловмисник.

‼️MobSF - сканує додаток і шукає вразливості‼️

🔥Hopper - IOS
🔥JaDX - Android
Можна розшифрувати наш додаток.
Після розшифрування будемо мати декілька папочок.

🥲Найбільшою проблемою може бути неправильне використання платформи та коду.

‼️Необхідно хешувати ендпоінти, натискання кнопок, буфер копі, проміжні дані, функції логування, дані аналітики на відправку третім сторонам.

🙏🏼НЕ ХАРДКОДИМО.


👩🏼‍💻 Андрій Заблоцький, «Досвід побудови сильної та ефективної QA команди»

📌Лідерство це не про те, що «я зробив», а «ми зробили».

‼️Основні обовʼязки ліда:
• Визначити стандарти, яких будуть дотримуватись.
• Розбудова тестової команди.
• Слідкування за якістю проєкту.
• Вміння справлятись з викликами самостійно.

🏛️Будуємо корпоративну культуру:
• Бути радикально чесним.
• Пояснювати цілі проєкту і виклики для команди.
• Зменшувати число правил та погоджень.
• Не очікувати, що сьогоднішня команда досягне успіху завтра.
• Будувати команду а не сімʼю.
• Розуміння потреб.
• Встановлення прозорих процесів.

📕Книга Патті Маккорд, Powerful.

🫰🏼Lessons learned:
• Впевненість у якості - це не лише відповідальність тестувальників.
• Visibility роботи QA команди недостатньо.
• Звертати увагу на дефекти, які перевідкриті.


👩🏼‍💻 Ріна Ужевко, «Тестування локалізації та терміни у GameDev»

📌Основна мета локалізації, зробити так, щоб склалось враження, що гра зроблена у тій країні тим громадянином.

• Глобалізація - масштабування світового продукту.
• Інтернаціоналізація - технічна підготовка.
• Локалізація - регіональна адаптація.
• Культуризація - культурна чутливість.

‼️На 1 ID - 1 баг-репорт.

❔Що робити якщо переклад не готовий?
• Додаємо неіснуючу локаль.
• Перевіряємо наявність перекладу, відображення символів, збереження розмітки.

‼️Необхідно перевіряти особливості різних мов. Наприклад і, ї, ґ в українській мові.

💰Тестування сторів та валюти є дуже важливим у іграх! Обовʼязково тестувати такі сценарії:
• коли у користувача немає грошей;
• користувач зробив 103468393 кліпів по кнопці «Купити»;
• користувач звернувся для відшкодування грошей.

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

📌GDPR «стандарт ЄС» - згода на обробку, доступ та видалення персональних даних.

📌Оновлення після деплою відкривається не для всіх одразу (2-3 дні).

‼️Закінчити тестування і фікси необхідно за +15 днів до дати події.


👩🏼‍💻 Катерина Абзятова, «Від барʼєрів до мостів: Важливість Accessibility Testing»

📌Ці три речі ідуть разом:
• Usability - наскільки зручно взаємодіяти.
• User experience - досвід використання в цілому (від моменту роз пакування і до кінця)
• Accessibility - взаємодія з продуктом людей з обмеженнями і різними потребами.

‼️10-20% людей в різних країнах мають стабільні обмеження (по всіх вікових категоріях).

📒Це можуть бути прогресуючі обмеження, тимчасові, ситуативні, перманентні.

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

📄Стандарт ISO 9241-171.


Попереду мене очікує ще 7 доповідей у записі💻
Тому вижимки ще будуть!

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

💻Online QA Day 2024. PART 1.💻

👩🏼‍💻Олег Заревич «Взаємодії між DevOps та QA»

❔Мета цієї доповіді?
• Для ефективної роботи - потрібна ефективна співпраця.

❔Що таке DevOps?
• Концепція яка виникла у 2007-2009 році.
• Ідея співпраці між командою розробки та тих хто робить інфраструктуру.
• Основний фокус - робочий продукт зі сторони інфраструктури.

‼️Тестування залежить від того як ми робимо деплой.
Не знаючи інфраструктури/ архітектури, ми не можемо робити детальне тестування‼️

❔Чого QA може навчити DevOps?
• Побудова спільного словника.
• Як працює додаток з точки зору енд юзера.
• Запропонувати додаткові тести та аналізатори коду.
• Донести розуміння, що додаток - це трохи більше, ніж запущений контейнер.

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

❔Чого DevOps може навчити QA?
• Ввести його в деплоймент пайплайн процес. Які стадії, що за що відповідає і тд.
• Розповісти про обмеження безпеки.
• Розповісти про Disaster Recovery Plan.
• Продемонструвати Observability (дає максимальну інформацію для роботи над дефектом; золоті сигнали - метрики, логи, трейси).

📌Synthetic checks (наприклад у Postman monitors) дають нам розуміння того, наскільки наша система є доступною.

📌Chaos Engineering - це підхід до аналізу роботи нашої системи під час неочікуваних збоїв.



👩🏼‍💻Алла Пенальба, «QA Automation, the secret weapon that need manual»

📌Перед тим як запровадити автоматизоване тестування - ми повинні розуміти для чого нам це і які причини.
«Чому, що хочемо досягнути, як вимірювати успіх?»

📌Нам потрібно слідкувати за стабільністю наших тестів, вони повинні бути зеленими.

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

⚖️Автоматизація та мануальне тестування має бути в балансі.
Автотести повинні закривати питання рутинного тестування, а мануальне тестування має аналізувати, креативити і тд.

❔Як не зафейлити автоматизацію?
1️⃣ Визначіть чіткі цілі та виміри успіху.
2️⃣ Оцінити скіли команди.
3️⃣ Обрати тулу для автоматизації.
4️⃣ Поревʼювати тест кавередж і визначити роадмап для автоматизації.
5️⃣ Визначити підхід до масштабування та підтримки тестів.
6️⃣ Потрібно побудувати гарний колаборейшн зі всіма залученими тімками.

❔Що має робити автоматизація?
• Зберігати час.
• Зменшувати cost.
• Підвищувати якість релізів.



👩🏼‍💻Олена Нікітіна, «Глибинне занурення в процеси тестування: від документації до успішних case-studies».

📄 Документація:
• Має бути канал для комунікації для прояснення вимог щодо нового функціоналу.
• Документацію потрібно постійно створювати та оновлювати.
• Всі процеси на проєкті необхідно описувати.

🧮 Оцінка та планування:
• Відокремлення QA оцінювання від Dev.
• Critical Path планування.

🎨 Тест дизайн та ревʼю:
• Якісне ревʼю тест дизайну.
• Створення мануальних чеклистів.

‼️Важливо проводити peer-review Dev for QA‼️

🔥 Test Execution:
• за тест кейсами.
• за вимогами сторі (happy path).

💻 Оптимізація регресійного тестування:
• пріоритезація тест кейсів.
• impact analysis таблиція.
• smoke загального тестування.

That’s all на сьогодні!
Якщо Ви хочете почути також мій фідбек щодо того, які доповіді сподобались, а які не дуже - ставте 🙏🏼

Раночку доброго⛅️

Тільки прокинулась і вже на QA Day😁

Всім хто теж там - бажаю продуктивної конференції❤️
А хто ні - скоро буде вижимка!!!

Хелоу гайзи!
Заключна частина відгуку та розбір 3 завдання з DEV Challenge!

Там ще є четверте завдання (для Hard level), але оскільки я його не виконувала, то репостити не буду)
Кому цікаво, почитаєте в Олексія в каналі)

#devchallenge
⭐️ Завдання №3 - автоматизація

Завдання - соціальний експеримент. Ніяких легенд - потібно будь-яким безкоштовним інструментом, будь-якою мовою автоматизувати 3 простих тест кейса на сторінці https://devchallenge.it В самому завданні сказано, що можна користуватись ШІ і всім, що допоможе вирішити задачу.
По-перше, я та інші судді важаємо, що в 2024 році всі тестери мають хоч трішки розбиратись в автоматизації
По-друге, чергова лякалка, що от тепер, зі штучним інтелектом, розробники автотестери не потрібні. Цікаво подивитись, чи дійсно некодери зможуть успішно вирішити досить тривіальну задачу.

✅ Expected results
🟢Судді мають отримати файли тестів та інструкцію, як їх запустити
🟢Якщо всі кроки інструкції виконані і ми бачимо браузер, що виконує сценарії - це успіх. Ніяких хитрощів і підводних каменів
🟢Особисто я очікував, що більшість піде найпростішим шляхом, і візьме Playwright + TS, і запише тести рекордером


⚠️ Actual results
🟠Люди розучились писати інструкції. Для QA інженера це неприпустимо! 50% інструкцій не містять важливих кроків. Я б мав ставити 0 за такі роботи, але маю навички і досвід, тож запустив майже весь отриманий код. Але серед нас є і судді не автоматизатори. Якщо ваші тести на джаві/JS/Python, а ви не вказали, що цю мову потрібно встановити - тести вже не пройдуть. Якщо ви написали їх на Mac, вони можуть не запуститись на Linux чи Windows. І як мінімум, читайте 1 раз самі, що ви написали 😡
🟠Було декілька грунтовних робіт - не просто файл тесту, а проєкт, з фабрикою браузерів, окремими класами на кроки, а зверху ще й тести написані на Cucumber. На написання такого треба витратити не години, а дні роботи. Як на мене це зайве ускладнення. А ще, не зважаючи на всю помпезність, використані дуже погані локатори типу div/div/div/div/span/div/a. Я б рекомендував витрачати час ефективніше
🟠Були роботи, автори яких пропонували встановити IDE для запуску тестів. Народ, так ніхто не робить - це має бути 1 команда для CLI чи навіть скрипт - запустив - і все працює
🟠Були роботи, які імітували виконання тестів, але по факту, код нічого не робив. Але ми вміємо читати 😀
🟠1 людина написала в інструкції, що тести їй написав ШІ, а надиво - тести гарно працювали!
🟠Загальна статистика:
➡️ Я зміг запустити 50% всіх тестових проєктів
➡️ Топ мов програмування: Python, TS, Java, Kotlin, JS. Я приємно здивований, що Python обрало найбільше
➡️ Топ фреймворків: Playwright, Selenium, Selenide, Cucumber, Cypress, Selenium IDE. Я дуже радів побачити тести на Selenium IDE - щось тепле і лампове з далекого минулого. А головне - це працює і вирішує задачу!

💡 Загальне враження - Автоматизатори - видихайте, ШІ нас не замінить. Не автоматизатори - починайте цікавитись автоматизацією, щоб випадкова задача не поставила вас в незручне становище. А ще мене турбує загальна якість більшості побаченого коду. Я розумію, що це Challenge, і можна не так старатись, але якщо вам за це гроші платять - вчіться робити якісніше!

Вечора доброго!
Ловіть розбір другого завдання з DEV Challenge🔥

#devchallenge
⭐️ Завдання №2 - нефункціональне тестування

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

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

Проблеми почались з розповсюдження застосунку. Я написав його на Python і за допомогою PyInstaller зкомпілював в виконавчий файл, який можна запустити де завгодно. Але поточна ситуація на ринку ОС і заліза викликає в мене занепокоєння. Разом з колегами, ми зробили білди для:
🟢Windows x64
🟢Linux x64 Ubuntu
🟢Linux x64 OpenSuse
🟢Mac OS x64
🟢Mac OS arm
Я радію, що в учасників не було Windows та Linux на arm, бо не уявляю, де б я це збирав 😅
І більшість учасників, хоч і не з першої спроби - але запустили застосунок і протестили!

✅ Expected results
🟠Performance: програма працює тим повільніше, чи більше символів вводиш для шифрування. Я використав квадратичну прогресію для наглядного ефекту
🟠Performance: програма на старті “з’їдає” 1 Гб RAM. Я хотів, щоб хоч хтось глянув у монітор ресурсів
🟠Compatibility: програма каже, що несумісна з вашою версією ОС. Я це захардкодив, але з точки зору black box тестування я б про це повідомив
🟠Usability: Я використав найдивніші консольні аргументи, які тільки зміг придумати. Типові ключі: -h - для допомоги, -f для файлу. Я використав випадковим чином взяті букви, деякі капсом, щоб було не зручно
🟠Maintainability: програма створює конфіг, який нічого не робить. Наповнив рандомними значеннями, які ні на що не впливають
🟠Reliability: а ні, впливають. В конфізі є лічильник версій, які збільшуються при кожному використанні програми. Як тільки він доходить до 7, програма ламається і каже почистити конфіг
🟠Usability: вже писав вище, що програма пише про версію ОС, але я це пишу стильно: You ÕS veršioÑ Ïs depræ¢åted. Pleasê update y¤ur 0S to the ¬§µðÂЇØçÞ vè®S1Öñ
🟠Usability: коли програма шифрує, вона виводить купу інформації на екран, яка робить користування менш зручним. Баг - відсутність акуратності і єдиного стилю в інтерфейсі
🟣О, а ще я додав дідівський мем - rickroll. Якщо попросити програму зробити rroll, вона за 5 секунд видасть посилання на відео. І це не баг, це фіча. За цей звіт ми віднімали бали


⚠️ Actual results
🟠Мало багів! Я перелічив 9, всього їх заклав ~14, але в звітах читав в середньому лише 5
🟠Багато багів не містили конкретних прикладів. Народ, якщо ви вводите команду caesar.exe --file, і у вас помилка - напишіть цю команду для копіпасти, а не описуйте словами, що ви там вводили
🟠Також я бачив багато описів багів без конкретних цифр: “програма працює повільно” - дуже поганий опис. “Програма споживає пам’ять” - мені приємно, що хоч хтось подивився, але всі програми її споживають, тут замало конкретики
🟠Лише кілька людей написали, що конфіг зайвий
🟠Багато хто писав функціональні баги, що було не правильно, функціональні вимоги невідомі, і те, що в моїй програмі після букв йдуть цифри, а потім спецсимволи - так і задумано. Час витрачено даремно
🟠Мій топ діамантів з баг репортів:
➡️Non-functional quality characteristic: Functionality
➡️Displayed description in another alphabet language (це про символи в версії ОС)


💡 Загальне враження - Я люблю теорію тестування, а саме стандарт якості ПЗ, і постійно до неї звертаюсь при дослідницькому тестуванні. Я очікував побачити більшу винахідливість в тестуванні застосунку локально, але в тих роботах, що я перевіряв, не було навіть жодної спроби декомпіляції, щоб написати мені за поганий код та купу sleep’ів 🥲

Мабуть Ви вже чули про цю подію, проте хто я така, аби не поділитись нею з Вами?😍

🚀Embedded QA skill set: Are you all set? 👀

Крутезна подія для QA-спеціалістів, які цікавляться напрямом Embedded, де команда SQUAD поділиться дослідженнями та аналізом актуальних навичок для Embedded QA.

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

Ну а хто цікавиться чи працює у напрямі, приєднуйтесь, щоб оцінити себе або команду відносно потреб ринку ✨

❔ЩО У ПРОГРАМІ?

▪️Статистика по топ навичкам для Embedded QA в Україні та США.
▪️Опис скілів та їхнє оцінювання.
▪️Які навички Embedded QA не втратять актуальності у майбутньому.
▪️Визначення пріоритетних скілів кандидатів при наймі в команду.
▪️Обґрунтоване формування цілей та трекінг прогресу розвитку колег.
▪️Чому skill set матриця є одним з найзручніших інструментів візуалізації вмінь команди?

🗓️ КОЛИ?
• 23 жовтня | 19:00-21:00.
📍 ДЕ?
• Київ, облаштований та безпечний простір SQUAD
• Онлайн-трансляція для тих, хто не може долучитися фізично.
💰СКІЛЬКИ?
• Участь безкоштовна.

Деталі та реєстрація тут

P.S. Ви знаєте, що я поганого не пораджу, тому на цій зустрічі звісно ж буду! Приєднуйтесь❤️

Олексій поділився своїми враженнями від робіт учасників по Task 1, а також тим, що включала в себе таска та що очікувалось від учасників!
Дуже інформативний допис🔥

#devchallenge
Привіт друзі! Завершився онлайн раунд DevChallange 21, вітаю всіх причетних і поспішаю поділитись своїми думками і спостереженнями цього року.

Матеріалу багато, тож буде декілька постів.

Загалом було придумано 4 задачі, які учасники мали виконати за 20 днів. Традиційно, номінація тестування містила 2 категорії: легше і важче, але цього року ми не стали пропонувати різні завдання учасникам (бо перевіряти їх потім важко), а запропонували тим, хто хоче легше виконати всього перші 3 завдання. До оцінювання робіт ми ретельно готуємось, тож у нас буквально написані expected results з кількістю балів за кожен пункт. Тож давайте, як справжні QA, подивимось на типові actual results і виміряємо якість відповідей учасників.

⭐️ Завдання №1 - вибір інструмента

За легендою учасник має обрати найкращий інструмент для тестування API складної системи, що містить цілий зоопарк інтерфейсів:
➡️ TCP sockets (data serialized as XML)
➡️ UDP sockets (byte stream)
↪️ SOAP (via HTTP and FTP)
➡️ REST API (JSON and byte stream via HTTP)
➡️ Web Sockets
↪️ GraphQL (via HTTP)
➡️ FTP and SFTP
➡️ + бази даних, різна автентифікація для HTTP та SHH tunneling

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

Це досить типова задача для інженера - знайти щось, що за однакових обставин простіше, дешевше, корисніше. Незнання API не рахується як виправдання. Коли ви обираєте холодильники, телевізори чи телефони, теж не обов’язково розумієте всі фічі. Коли мав необхідність обрати і замовити РЕБ для підрозділу морпіхів - теж не дуже розумів список фіч, тож довелось швидко збирати інформацію 🤷‍♂️


✅ Expected results
- Ми очікували побачити порівняльну таблицю - в колонках інструменти, в рядках - фічі, які порівнюються.
- Ми очікували - що кожен протокол буде окремою фічою (рядком)
- Ми очікували, що учасники переглянуть документацію та проставлять реалістичні оцінки
- Ми не очікували, що учасники знайдуть один супер-інструмент, бо це майже неможливо (хоча цікаво було почитати про незнайомі), тож головна хитрість - зрозуміти, що ідеального інструмента немає і треба запропонувати наайкращу комбінацію, що задовільнить всі вимоги. І в висновку це і треба було написати

⚠️ Actual results
- більшість учасників чомусь вирішила, що дійсно може існувати лише 1 інструмент. Але біда навіть не в цьому, а в тому, що цей інструмент - Postman, який ні з TCP, ні з базами не працює. Типу - нема інструмента, значить ті АПІ хай хтось інший тестує
- Частина учасників, при цьому, в порівняльній таблиці без вагань ставила Postman`у 3 бали з 3 за повну підтримку протоколу TCP - таке враження, що скопіювали відповідь з ШІ не сильно вчитуючись, що саме він написав
- Багато, мінімум 50% учасників чомусь об’єднали всі протоколи в 1 рядок, який назвали “протоколи”. В інших були ціна, зручність користування та ін. Це однозначно поганий підхід, тому що важко порівнювати інструменти, якщо умовно Postman має оцінку протоколів 2/3, а JMeter - 3/3. Як зрозуміти з цього, який що вміє?
- Майже ніхто не згадав бази даних в можливостях інструментів - про них ніби забули, тому що вони описані не пунктом списку, а реченням нижче. Треба бути уважнішими!
- Деякі учасники зробили горизонтальні таблиці, які буквально треба скролити не вниз, а вправо. За що?
- Хочу відмітити декілька сильних робіт, які отримали майже максимальні бали і навіть запропонували цікаві рішення ❤️


💡 Загальне враження - суб’єктивно мені здається, що більшість учасників не шукала інструменти в Інтернеті, як в старі добрі часи, а попросила написати порівняння в Chat-GPT, і навіть не перевірили результати. Не треба так 🥲

I’m a finalist 🚀

Я потрапила у фінал DEV Challenge!

Беру участь вперше і я дуже задоволена тим, що пройшла у фінал!

DEV Challenge став для мене справжнім викликом, адже в період неймовірної завантаженості, наклалось ще й змагання.

Але бажання прийняти участь було сильнішим і я зібрала всі останні сили та зробила завдання в останній день.

Зусилля були не марними і я у фіналі🥳

Звісно у мене не без приколів…можливо пізніше розповім))

А поки, зустрінемось у Києві🥰

P.S. я радію і приймаю вітання! Це для мене невеличке досягнення🤩

Гайз, понеділочка продуктивного всім!
Як завжди принесла Вам щось цікаве!

Кожному з нас хочеться для себе кращого…
«А як знати де те краще?»

Звісно ж за допомогою голосувань DOU💌

Сьогодні DOU запустило голосування для Рейтингу ІТ-роботодавців 2024 ⭐️

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

Тому запрошую всіх ІТ-спеціалістів взяти участь та оцінити свою компанію 🔥

📄 Приклад, як це було попередьного разу можете знайти тут.

Це дуже важливо, тому приділіть декілька хвилин свого часу!

Почитати такі статистики ми всі любимо, еге ж?)
То гайда голосувати 🙏

Суботнього деньочка!

Цього тижня, як Ви вже знаєте була у Сані Хотемського на воркшопі з Playwright.
Я вже маю деякий досвід з автоматизацією, а також з record & play у Playwright, і хочу дати свій фідбек.

ЦЕ БУЛО ДУЖЕ ЦІКАВО!
Я нахапалась від Сашка дуже багато крутих інсайтів!

І думаю Сашко не проти якщо я поділюсь деякими з Вами🥰

Ловіть:

💎Автоматизовані тести потрібно викристалізовувати на мінімальну кількість кроків аби досягнути найкращого результату.

🪛Менше деталей - менше ламається.

💻Завжди фокусуйтесь на тому, що хочете потестити.

‼️Тести потрібно запускати регулярно (по розкладу, вручну, на кожен коміт, PR, etc.).

🧟‍♀️Якщо тести не запускаються - вони мертві.

⚠️Автотест підтверджує, що все досі нормально і нічого не зламалось.
Автотести погано знаходять баги, вони не мають падати.

📖Читаємо доку Playwright - у ній можна знайти відповіді на більшість запитань.

Не потрібно боятись писати код - краще зайвий раз переписати!

💌Для тестових акаунтів - робимо пароль такий же як емейл.

🫡Неймінги мають бути consistency.

📌Команда pressSequentially- коли треба вести текст, але повільно.

‼️Коли оновляється Playwright - треба оновлювати браузери.

😁Ніколи не довіряйте компʼютеру який ви не можете викинути з вікна.

Отакі круті поради для себе виокремила протягом 3-х днів навчання!
(P.S. особливо остання😁).
Насправді їх більше, але деякі з них залишу при собі😅

У підсумку скажу - дуже раджу цей воркшоп!
Саша розповідає все дуже цікаво, від його розповіді не хочеться заснути, а головне що він розповідає дуже багато класних та практичних штук зі своєї рутини.
Однозначно топ!
Якщо Саша буде проводити ще якісь вебінари чи воркшопи - ІДІТЬ І НЕ ДУМАЙТЕ🔥
Воно того варте!

❔Як «зловити» pop-up чи tooltip для автоматизації?

Всім привіт!
Як Ви вже знаєте, у Саші Хотемського проводиться воршоп «Перші кроки з Playwright».
P.S. думаю при бажанні можете ще доєднатись, хто не встиг)))

❔І на одному з занять, хтось задав питання: «А як ловити поп-апи?».

Насправді способів є багато і ми ділились один з одним різними.
Якось мене це надихнуло і хочу залишити Вам маленькі хінти щодо цього питання🥰

1️⃣спосіб:
• Відкрити DevTools
(Mac: Cmd + Option + I;
Win: Ctrl + Shift + I).
• Перейти у вкладку «Sources».
• Натиснути на іконку паузи.

2️⃣спосіб:
• Відкрити DevTools
(Mac: Cmd + Option + I;
Win: Ctrl + Shift + I).
• Перейти у вкладку «Sources».
• Натиснути комбінацію клавіш (Mac: Cmd + \;
Win: на жаль не знаю, але мабуть замість Cmd -> Ctrl).

3️⃣спосіб:
• Відкрити DevTools
(Mac: Cmd + Option + I;
Win: Ctrl + Shift + I).
• Перейти у вкладку «Sources».
• Натиснути F8.

⚠️P.S. Останній метод у мене персонально не працює, тому тут вже відштовхуйтесь від того, який метод працює найкраще у Вас!

📖Ці комбінації допомагають зупинити все що відбувається на сторінці, аби подивитись на ті елементи, які зникають!

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

То ж, сподіваюсь це комусь допоможе!
Користуйтесь❤️

Хелоуік🙃

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

👩‍💻Віктор Домбовецький, «Нетворкінг для QA. Як побудувати сильне оточення».

📌Якщо у вас є певні цілі, яких ви хочете досягнути: 50% впливу на ці цілі робить нетворк.

❔40% на нетворк має наше мислення.

‼️Нетворк будується під цілі.
Без розуміння цілей на 1-3 роки - неможливо будувати нетворк.

💭Є дві речі які впливають на побудову глибоких стосунків:
• просити про допомогу.
• запропонувати допомогу.

Це мабуть найкорисніші думки, які я для себе виокремила під час доповіді.
Далі пішли якісь розмови про кола спілкування, вправи- розподілення свого оточення…

🤔 Це трохи не складалось мені в картину тієї теми, яка була заявлена спікером.
Так я і не зрозуміла як побудувати те «сильне оточення» саме для QA… чи то я така туга, чи то просто мені формат розповіді не зайшов… не знаю.

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

⚠️ Не буду сперечатись, коучі - це окей.
Я була у коучів, які консультують саме у сфері QA і такий коучінг мені сподобався.
Я навіть змінила про нього думку)))

А от саме формат і подача коучінгу представленого на вебінарі - трохи не моє…

Таке щось вийшло у мене😅
Хто був на вебінарі - поділіться своїми думками… цікаво почути Вас💭
А хто не був, то як Ви вважаєте, чи є користь від нетворкінгу?
❤️ - звісно, що так.
🗿 - нашо воно?

Хелоу гайз!

Цього тижня так багато подій і справ, що я не встигаю в моменті Вам про все написати!
Тому йду до Вас поступово😁

Вчора відвідала вебінар Саші Ковальової на тему «ISTQB Test Manager 3.0: управління тестуванням в умовах невизначеності».

І хочу поділитись деякою інформацією та інсайтами з цього вебінару🥰

📌Якщо ви хочете:
• Розуміти чому менеджмент не дозволяє щось зробити;
• Внести зміни;
• Отримати більше часу на тестування.

То знання, які дає ця сертифікація - для Вас!

💭Часто кожен з нас думає: «Я не можу змінити це зі свого місця», і так думає кожен в команді.
Тому такі актуальні теми, як чендж менеджмент та переговори зачіпаються всередині сертифікації.

📌Якщо ви хочете більше знати що тестувати, як тестувати, за допомогою яких апроучів, з якого глибиною і тд. - з цим допоможе сертифікація «Test Analyst».

💡«ISTQB це набір body of knowledge»

❓Чому змінили сертифікацію Test Manager аж через 12 років?
• Тому, що FL 4.0 перевернув повністю все.

‼️Питань стало менше - складнощів більше.

🙃З силабусу видалили всі приклади, адже потрібно було його скоротити. А обґрунтували це тим, що тренінг провайдери мають надавати ці приклади🙃

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

📚По змінах в структурі екзамену:
• З 65 питань стало 50.
• З 225 хвилин стало 150.
• Тотал скор складає 88 балів.

📌Також тут нас зустріне різна кількість поінтів залежно від складності.
Розподілення поінтів:
• К2 - розуміти (26 питань).
• К3 - застосовувати (10 питань).
• К4 - аналізувати (14 питань).

📌Структура тепер важка, і стало важче розуміти звідки і яка кількість питань нас очікує.

‼️Офіційний тест лише один.
Також ще є один додатковий у американської борди.

ПРОХОДИТИ РАНДОМНІ ТЕСТИ З ІНТЕРНЕТУ ЦЕ ТАБУ.

💪🏼Тепер по важливих змінах:

📖 Change 1: FL 4.0 & Agile.
Потрібно прочитати принаймні книгу для 4.0, щоб розуміти підґрунтя сертифікації менеджера.

📖 Change 2: Hybrid.
Акцент йде не на класичні та agile моделі, а саме на гібридні.
До одних activities застосовуємо підходи класики, до інших agile.

📖 Change 3: Point of view focus.
В першу чергу ми повинні враховувати стейкхолдерів і їхні типи.

📖 Change 4: Management context over techniques.

📖 Change 5: Removed topics.
Reviews and audits видалили.

📖 Change 6: Tools introduction homecoming.

Чую мені буде весело здавати цю сертифікацію😁адже коли я дійду до неї, то це вже точно буде версія 3.0)
Щось мені щастить на оновлення😅

А Ви вже здавали чи можливо плануєте здавати Тест Менеджера?
😎 - вже здав (-ла).
🦄 - планую здавати.
🗿 - а нашо воно мені?
❤️ - подяка за допис.

💡 Бажання знати все…
Воно зʼїдає…

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

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

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

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

То ж, пишу цей допис з нагадуванням і до Вас - дайте собі відпочити, дайте собі прокрастинувати, дайте собі байдикувати….
Це лише допоможе Вам більш якісно відпочити та продовжувати фігачити далі)))

Такий от вечірній #інсайт😌

Всім добра❤️

Що не день - то новини😁

Довгоочікуваний анонс QA Coffee Time у Team Challenge!

Ми разом із платформою для початківців Team Challenge організовуємо Coffee Time для QA інженерів.

📖Team Challenge - це платформа для початківців, які тільки прийшли у сферу та хочуть по практикувати свої знання!
На цій платформі Ви можете долучитись до pet проєкту і почати набувати навички роботи в команді, розробляти цікавий проєкт з 0 та до релізу.

P.S. Також подейкують, що існує ймовірність знайти замовника, який зацікавиться вашим проєктом.

❓Що це за Coffee Time?
Це зустріч для QA- початківців, хто тільки починає свій шлях у сфері та хоче отримати та перейняти досвід старших колег!
Зустріч, де будь-хто зможе поставити будь-яке питання, яке давно цікавить та отримати довгоочікувані відповіді!

🗓️Коли: 14 жовтня, 19:00
🏢Де: Google Meet

‼️Важливо! Щоб долучитись перейдіть за посиланням та натисніть "Так", щоб додати подію до свого календаря і не пропустити її.
Посилання тут

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

Всім гарної пʼятниці!❤️