| Mother of QA |

Так так так, а тепер відгук на QA Party Hard🔥

Мій перший QA Party Hard був десь рік тому… ще 3-тій по рахунку…
Саме на цій конфі я зустріла класних людей, деякі з них встигли стати для мене близькими друзями🫶🏼
Тому враження від цієї конфи можуть бути лише позитивні🔥

Але ця… 7-ма конфа стала просто чимось надзвичайним….

Чому? По порядку👍🏼

1️⃣ Дуже класний, новий та цікавий формат, де всього 30 хвилин для спікерів та все решту - кулуари.

2️⃣ Дуже крута ярмарка для людей, на якій ми зібрали багато коштів та яка подарувала людям нові емоції.

P.S. ідея ярмарки виникла дуже цікаво😅 після девчеленджу ми сиділи у закладі, просто собі про щось спілкувались і тут я сказала, що мої батьки виготовляють вʼялені томати і я принесу їх за донат, Таня сказала що спече чізкейк… і так ми з нею придумали, що треба зробити благодійну ярмарку😁
І не прогадали😉

3️⃣ Офігезні партнери та подарунки за активність та донати.
То напевне одна з небагатьох конференцій на якій подарунки льються звідусіль.
І від спікерів і від організатора і від партнерів.

4️⃣ Дуже класна та легка атмосфера, яка сприяє розвитку та комфорту для висловлення своїх думок.

5️⃣ Багато препаті, афтерпаті і тд. І це мега круто, бо саме на таких зустрічах люди більше розслабляються і діляться своїми думками, емоціями та іншим.

Взагалі обожнюю цю конференцію саме за її атмосферу!

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

Люблю цю конфу і люблю цих людей!❤️
Хто сумнівався чи йти на неї чи ні - ОДНОЗНАЧНО йдіть!

Хелоуік!

Вчора у нас була QA терапія! Це новий формат в межах спільноти, де ми можемо обговорити свої проблеми та запити)

Цю терапію проводив Євген Пасєка і ми говорили про зростання в умовах невизначеності 💫

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

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

📌 Умови невизначеності:
• Економічні кризи.
• Пандемії.
• Велика кількість інформації.
• Військові конфлікти.

💪🏼 Челенджі:
• Нестабільність (швидкі зміни).
• Невизначеність (складність контролю).
• Складність (непередбачуваність результатів).
• Неоднозначність (руйнування зрозумілих патернів).

❔Як врятуватись у такому світі?
❗️Адаптація та зміни.
• Погляд у майбутнє.
• Робота з контекстом та середовищем.
• Виділення ключових факторів та аналіз проблеми.
• Адаптація до змін, експерименти.


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

❔А як Ви ставитесь до невизначеності?

Привітик гайз!

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

Але перш за все - про QA Party Hard💫

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


👩🏼‍💻Аміна Олійник, «Естімація тестування: наука чи інтуїція».

Наводила кейс з практики, коли оцінка тестування вкладалась у вигляді 30% у оцінку девелоперів.

📚 Основні проблеми цієї оцінки:
• Underestimate розробників.
• Нерелевантна оцінка на тестування.
• Зсування розкладу тестування на спринт.

🔐 Типові проблеми естімування:
• Недооцінка.
• Переоцінка.
• Нестабілість вимог.
• Відсутність кваліфікації.
• Ігнорування залежностей.
• Ігнорування нефункціональних вимог.

📌 Типи естімації:
• Estimation based on ratios - оцінка, яка базується на історичних даних всередині організації.
• Wideband Delphi - оцінка, яка базується на попередньому досвіді.
• Three point estimation - оцінка, яка складається з найбільш оптимістичної, реалістичної та песимістичної, та вираховується за формулою.


🧑🏼‍💻Артур Белак, «Як працює Cypress та чому він помре»

• Немає можливості використовувати async та await;
• Проміси незручні у використанні;
• Ускладнюється читабельність коду;
• Важко поєднувати асинхронність сайпресу та JS;
• Жере багато перформансу;
• Немає можливості паралельного запуску тестів з коробки;
• Є залежність від сайту який покривається тестами.


🧑🏼‍💻 Євген Толчинський, «Співбесіди QA — як не померти від них»

3️⃣ найважливіших фактори при підборі персоналу:
• Хард скіли;
• Софт скіли;
• Тім метч.

💪Хард скіли:
• Прочитати CV.
• Прочитати вакансію.
• Підготуватись до співбесіди.
• Повторити тули або технології.
• Повторити теорію.

🫶Софт скіли:
• Відповідати на питання.
• Не треба «води».

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


🧑🏼‍💻 Юрій Малий, «ROI автоматизації на конкретному прикладі»

Під час доповіді ми розглядали приклад того, як було розраховано ROI автоматизації, там було доволі багато прикладів різних таблиць та метрик, тому і важко Вам це розповісти і вижати цю інфу)
Це просто треба бачити!)
Тому тут Вам спойлерів не буде😅


👩🏼‍💻 Ріна Ужевко, «Автоматизація ніколи не окупиться й ось чому»

❔Коли зазвичай використовується автоматизація?
• Коли треба шось оптимізувати;
• Коли тіма не вивозить регресію;

❔Що є показником для автоматизації?
• Архітектура;
• Інфраструктура;
• Інструменти;
• Процеси.

💰ROI - це фінансовий показник і ми перш за все рахуємо в ньому гроші.

❗️Часто, якщо ROI відʼємне то ми стараємось його підкорегувати щоб влізти в нього, через те, що ми хочемо (або хтось хоче) автоматизацію.

📌 У ROI немає термінів, типів команд, порівняння зарплат, оновлення тестів, аналіз впавших, те що можна оптимізувати і те, що не автоматизовано і тд.

📚 ROI - це не статичний показник.

❗️Структура команди дуже впливає на вартість автоматизації❗️

📌ROI є допоміжним, а не вирішальним.

💲Автоматизація не окуповується ніколи💲

💫Якщо ми будемо автоматизовувати в збиток, то будуть економити на іншому.


🧑🏼‍💻 Павло Берлінець, «Чому без автоматизації ми помрем»

📖 Після 2020 року продуктова культура почала розвиватись стрімкіше.

❔ «Яку проблему вирішує AQA?» - це питання потрібно собі задавати постійно.

💰Автоматизація не окупається. Це про процеси.
Часто автоматизаторів наймають пізно.

❗️Автоматизатори це не тільки про код. Це про забезпечення якості з застосуванням коду.


Це був дуже цікавий досвід, оскільки на виступ у нас було 20 хвилин + 10 хвилин на запитання.
В цілому виступ кожного спікера - 30 хвилин.

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

❔А поки поділіться, хто слухав мою доповідь, як Вам? Як враження?)
Мені дуже цікавий Ваш фідбек🫶🏼

Хелоу гайзи!

Цих вихідних я спікала на QA Party Hard і тема моя була «Test Estimation: science or intuition», де я ділилась своїм кейсом імплементації оцінки на тестування.

P.S. коротка вижимка та враження після конфи будуть тут завтра🔥 а поки подивіться на ці прекрасні подаруночки, які я отримала як спікер❤️

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

Тому вирішила себе підстрахувати та піти на інтенсив по «Естімації задач по тестуванню» до Артема Григоренка!

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

Доречі, відгук по інтенсиву можете прочитати тут.

І тут у мене для Вас круті новини…

🚨LAST CALL🚨

Саме цього тижня стартує даний інтенсив!
І у Вас все ще є можливість до нього доєднатися! Що я доречі дуже рекомендую зробити!

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

Адже порахувати години то таке, а от ключовим челенджем є донести необхідну оцінку до стейкхолдерів)))

Деталі тут

А я поки піду відпочивати свій вечір🫶

Хелоуік гайз!
В середу у мене знову була можливість помодерувати вебінар і цього разу ми говорили на дуже актуальну тему для всіх!
А саме - про навчання! То ж, традиційно вижимка біжить до Вас💫

👩🏼‍💻 Олександр Романов, «Stop Studying, Start Learning - або як вчитись краще»

❔Коли ми вчимось?
• Читаємо книги.
• Проходимо курси.
• Читаємо блоги.
• Дивимось відео.
• Працюємо з менторами.
• Працюємо з колегами.

📌 Основна проблема: знання без практики забуваються з часом.

❔Що з цим робити?
• Нам потрібно навчитись вчитись.

❔Нащо нам навчатись вчитись?
• Тому що навчання - це метта навичка, за допомогою якої ми можемо опановувати інші навички.

❔Як ми звикли вчитись?
З самого малку ми вчимо те, що нам дають і головне у цьому навчанні «правильно відповісти» в кінці, ми завчаємо без розуміння, зазвичай «вивчили і забули», вчимося в невмотивованих викладачів та по застарілих програмах.

❔Як ми вчимось на роботі: «це модне, це для промоушину, це прикольне треба вчити і тд.»

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

🧠 У нас є робоча памʼять та довготривала пам’ять.

І наша задача під час навчання - формувати нейронні звʼязки у нашій голові.

📊 Навчання схематично:
• Mapping (prepare).
• Encoding (learn it - робоча памʼять).
• Consilidation.
• Retrieval (link it - довготривала памʼять).

📋 Mapping :
• Що ми хочемо вчити: факти, концепції, процедури.
• Що підходить саме нам: пробуємо, рефлексуємо.
• Як це вивчати? Питаємо в експертів, шукаємо роадмапи і тд.

📚 Encoding:
• Можемо робити нотатки, робити майнд мапи, хайлайтити і тд.
🚨Перечитувати чи завчати - теж техніки, але вони неефективні🚨

🔗 Consolidation:
• Interleaved practice - чередуємо навички чи теми при навчанні.
• Varied practice - змінюємо умови того, як ми практикуємось.
• Directed drill - практикуємо окремі частини в ізоляції.

🔐 Retrieval:
• Техніка Феймана - потрібно розповісти тему яку ви вчите людині, яка цієї теми не знає. Чим простіше - тим краще.
• Active recall - переказуємо своїми словами.
• Spaced repetition - робимо самоперевірку через деякий час.
• Flashcards - якщо є купа термінів.
• Mock exams - якщо необхідно підготуватись до чогось.
• Study with others - перевіряти один одного.
• Mnemonics - запамʼятовування за допомогою асоціацій.

❗️Хороший сон допомагає краще запамʼятовувати інформацію❗️


🚨 Доречі, у березні, коли я дебютувала як спікер на конференції, я розповідала про майстерність самонавчання, дуже схожа тема до тієї, що розповідав вчора Олександр!
Шарити це відео вже можна, тому, кому цікаво послухати - велкам 🫶🏼

Всім цьом 💋

Скажіть мені хтось…..
Нащо ви страждаєте роками з старими, повільними та заскурублими тестрейлами, ікс-реями та кютестами???!!!

❗️Переходьте на новітню testomat.io!


Зараз діє дуже класна пропозиція, адже команда Testomat.io може допомогти Вам переїхати!!! А для того, щоб отримати допомогу Вам всього необхідно звернутись у саппорт та використати кодове слово FUCKOFFTESTRAIL.

P.S. А тим хто готовий переїхати протягом наступного тижня - буде супер знижка 😎
Акція доступна тільки для українців!

Пропоную Вам не страждати та переходити на українську TMS💫

❔Що з твоїм курсом?

Таке питання отримала я і думаю, буде чесно розповісти Вам всю історію щодо цього…

📖 Як Ви знаєте, у мене в «колаборації» з Романом Якимчуком був базовий курс по тестуванню.
Де я організовувала курс, розробляла програму, наповнювала матеріалом, проводила, перевіряла ДЗ, давала фідбек і тд., а Роман відповідав за піар.

Програму курсу, наповнення, всі організаційні штуки я взяла на себе… оскільки належної допомоги не отримала…

📌 На перший потік прийшла одна людина і хоч ця людина дуже задоволена і я тішусь що змогла допомогти…
…та сенсу проводити курс далі я не бачила….
Бо маркетинг Романа складався з вебінарів у його спільноті та не залучав нових людей… і ще й в додаток до всього я отримала порцію хейту на «ebanoeIT» від аудиторії Романа.

⏳ Ще на початку жовтня я звернулась з проханням припинити курс, оскільки хотіла його покращити, а також не бачила сенсу проводити його для 2-3 людей.

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

❗️Проте з ситуацією, яка випливла - відновлення співпраці вже неможливе.

Я прийняла рішення створювати свій продукт сама.
Дякую комʼюніті за те, що відгукнулись і погодилась допомогти❤️
Зараз я вже бачу те, який продукт я хочу зробити. Бачу як він має виглядати.

☝🏼 Але мені потрібна Ваша підтримка і допомога.
Оскільки я хочу зробити свій продукт максимально якісним та корисним для Вас!

🚨Мені необхідно декілька добровольців для інтерв’ю)
Інтервʼю буде на 15-30 хв, я задам Вам питання, Ви дасте відповідь і за це отримаєте знижку на мій майбутній продукт або безкоштовну сесію зі мною🚨

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

Якщо Ви в одній з тих категорій, або просто знаєте, чого не хватало Вам, коли Ви були в тій категорії - пишіть «+» під цим дописом і я напишу Вам💫
Цим Ви дуже допоможете мені! Тому дуже сподіваюсь на Вашу допомогу!
Дякую!


❗️UPD: БІЛЬШЕ НЕ АКТУАЛЬНО! ВИБІРКА ОПИТАНА - ДЯКУЮ ВСІМ ХТО ВІДГУКНУВСЯ💋

Хто хоче додати свої ідеї та поділитись потребами - можете відгукнутись смайлом «⚡️» і я Вам напишу🫶🏼

Понеділкового вечора всім!
Я до Вас із вижимкою, оскільки минулого тижня у нас було дві події у спільноті! Так співпало)))

Послухала про мобільне тестування, насправді там було нереально багато інформації, моя вижимка - це лише «крапля в морі»😅 і скажу, що це було цікаво!
Тому ловіть трішки інфи🥰

👩🏼‍💻 Катерина Абзятова, «Challenges and Techniques in Mobile Testing»

💰Монетизація завжди дуже важлива у мобільних додатках.

📌Є такі типи монетизації:
• Freemium - додаток безкоштовний, але якийсь функціонал платний.
• Advertisement- based - купа реклами, якщо заплатити то її не побачимо.
• Transaction- based - криптогаманці і тд., які заробляють за рахунок транзакцій.
• Fee based - не можна скачати, доки не заплатимо.
• Enterprise applications - банківські додатки, де ми не платимо, але організація заробляє.

❗️Дуже важливо розуміти, де замовник заробляє гроші. Адже цей функціонал має працювати найкраще❗️

📌Mobile device type:
• Basic phone.
• Feature phone.
• Smartphone.
• Tablets.
• Companion devices including wearables and some IoT devices.

👩🏼‍💻Типи додатків:
• Нативні - скачування додатка.
• Браузерні - аплікація в браузері, адаптований варіант.
☝🏼Варіанти:
- m(dot) site.
- Responsive.
- Adaptive.
- Progressive.
• Гібридні - веб- аплікація в оболонці нативної апки.

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

💡Додатки можуть бути pre- installed - людина купує телефон і він вже має цей додаток.

Тестування кожного з цих типів додатків може вимагати різного підходу. Параметри, які слід враховувати, включають:
• Різні типи пристроїв для підтримки.
• Функції датчика та пристрою, які будуть використовуватися.
• Доступність за різних мережевих умов.
• Можливість встановлення, сумісність, ефективність роботи та зручність використання.

📎Connection methods наших аппок:
• Never connected.
• Always connected.
• Partially connected.

⚡️ При тестуванні необхідно вимірювати температуру девайсів, різне положення екрану, використання батареї, куди ведуть нотіфікейшини, локація, hard & soft кнопки звуку, різні варіанти інпута, клавіатура, один або більше дотиків до екрану, жести, камера, QR коди, орієнтації екрану і тд.

❗️Режим «Не турбувати» - у ньому можуть бути великі проблеми. Ми не маємо відправляти повідомлення коли він ввімкнений, а коли ми вимкнули цей режим - повідомлення не мають сипатись спамом.

☝🏼Звертаємо увагу на пермішини (локація, камера, мікрофон і тд.).
Запити на доступ мають бути обґрунтовані, в залежності від того, який функціонал ми маємо і для чого використовуюємо.

🚨І памʼятаємо: тестуємо в реальних умовах, не тільки в офісі з гарним інтернетом.

А тепер поділіться, хто у нас тут тестує мобільні апки?)
😍 - я;
🤯 - не я;
❤️ - дяка за допис.

Про DEV Challenge⚡️

Що ж, я обіцяла розказати Вам всю правду і от вона!

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

❔Що по балах?
• Онлайн раунд - 125 балів.
• Фінал - 206 балів.

⚡️Загалом мій результат склав - 331 бал.

Я приймала участь у Lite категорії, оскільки на Hard не встигла зробити завдання.
То ж, у моїй категорії було 15 учасників, у рейтингу я посіла 11 місце.

❔Чи соромно мені за низький результат?
Абсолютно ні. Я ніколи не приховую правди, бо вона така як є. Мені не соромно казати свої бали і показувати Вам реальну картину. Я за чесність.

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

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

❔Чи буду я брати участь ще?
Так.
Доти - доки не отримаю перше місце.
У мене є ціль і я буду робити стільки спроб, скільки буде потрібно аби її досягнути.

Наразі я пишаюсь, що потрапила у фінал та спробувала свої сили.
Я зрозуміла, що я маю покращити і повернусь за нагородою наступного року⚡️

❗️Ще одне нагадування для Вас та для мене.
Запамʼятайте: змагання ДУЖЕ субʼєктивне. Адже кожен із суддів оцінює це завдання зі своєї перспективи, і на оцінку завдань впливає маса зовнішніх факторів.
Правильної відповіді немає - є та, ідеальна, яку очікують побачити.

То ж, хто приймав участь - не засмучуйтесь.
Просто зробіть висновки і рухайтесь далі🦾

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

А поки, повертаюсь у життя і даю Вам вижимку вчорашнього вебінару, який відвідала✍🏼


👩🏼‍💻 Аня Красильник, «Конфлікт — це можливість»

✍🏼 Конфлікт - це не завжди погано.

☝🏼Варто ознайомитись з «Моделю Такмана» про формування команд.
Адже часто буває так, що команди застрягають у стадії формування і не можуть вийти на стадію дійсно гарного перформансу.

📖 Конфлікт - це різниця в думках або перетин інтересів, яке призводить до необхідності домовлятись.

💫 Конфлікт буває:
• Конструктивним - переговори.
• Неконструктивним - активна/пасивна агресія.

🦾 Чиї потреби задовольняються - фундамент для стратегій вирішення конфліктів.

📌 Томас Кілман, 5 стратегій вирішення конфлікту:
• Суперництво
• Співпраця
• Компроміс
• Пристосування
• Уникання

❗️Найкращої стратегії немає - є та, яка доречна.

1️⃣ правило:
Обираємо стратегію, а не стратегія нас.

❔Чому ми несвідомо йдемо в уникненя або пристосування?
• Страх осуду
• Страх зіпсувати стосунки
• Сила звички

❔Чому ми несвідомо йдемо в суперництво?
• Страх невдачі, зради
• Сила звички

❔Коли доречно уникання?
• Якщо не несе цінності ні проблема ні стосунки
• Коли треба охолонути
• Коли обоє погоджуються що проблема не варта зусиль

❔Коли доречно пристосування?
• Інвестиція у відносини
• Заохочення людей бути ініціативними
• Довіра думці партнера більше ніж власній
• Дотримання субординації
• Адаптація до нових умов

❔Коли доречно суперництво?
• Коли немає часу на дискусії
• Коли потрібно впроваджувати непопулярні рішення

❔Коли доречний компроміс?
• Немає часу, але стосунки важливі

❔Коли доречна співпраця?
• Інтереси дуже важливі
• Шукаємо альтернативу
• Є багато часу на дослідження та пошук

📖 Типи поведінки у конфлікті:
• Пасивна - уникання пристосування
• Пасивно - агресивна - уникання пристосування, суперництво
• Агресивна - суперництво
• Асертивна - все

❗️Знайти асертивність це мистецтво.

🏋🏼Техніки асертивної поведінки:
• Я - висловлювання
• Техніка зламаного запису
• Техніка негативного підтвердження
• Техніка позитивного ствердження

2️⃣ правило:
Ми не можемо змінити співрозмовника, ми можемо впливати на власну поведінку.


3️⃣ правило:
Якщо ми залишаємось асертивними - співрозмовнику не залишається вибору, як врахувати нашу позицію.

❔Хто керує конфліктом?
• Той хто усвідомлює мету та стратегію.
• Розуміє ситуацію на різних рівнях.
• Може створити атмосферу довіри.

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


Вебінар був дуже цікавий і подача інформації у Анни мені дуже імпонувала💫

А як Ви вважаєте, конфлікти корисні для нас?
👍🏼 - так.
👎🏼 - ні.
❤️ - дяка за допис.

Що ж, результати відомі, переможці нагороджені…
На жаль, цього року я не взяла жодного призового місця…

Проте це ще один крок на моєму шляху і можливо наступного разу пощастить🍀

Як тільки отримаю інформацію щодо того яке місце у рейтингу я маю - одразу напишу і розкажу свої бали та розшифровку)))

Тому чекайте⚡️

🌠 Ніч без сну, через й***ну русню…
⏳ 8 годин роботи….
🏋🏼 Багато викликів під час виконання завдання.
💫 Втомлені очі, болить голова і просто хочеться спати…

Проте я рада, що прийняла цей виклик! Завтра дізнаємось результати… а потім розповім Вам трішки детальніше про фінал, про свої результати та мої враження⚡️

P.S. одразу скажу, що це було дуже важко…під кінець мої мозги просто «поплавились»)))

ВИ НЕ ШАРИТЕ В ПАТЕРНАХ ПРОЄКТУВАННЯ.

❔Відчуваєте постійну складність як називати класи, методи, змінні, папки, допоміжні файли, селектори і тд.?

❔Все кладете в базові класи, юзаєте лише бідний Page Object для всього у своєму житті?


🚨Тоді цей воркшоп для Вас!🚨

12 листопада Ромка Марінський проводитиме ОНЛАЙН воркшоп, де послідовно розкриє, як з розумом будувати гідний проєкт з автотестами:
• принципи KISS, DRY, YAGNI;
• патерни проєктування;
• code smells;
• селектори;
• можливості тест ранерів.

⚡️Буде корисно для джунів, мідлів та сіньйорів автоматизаторів.

💰ЦІНА?
• Донат у розмірі 2000 грн.
Всі кошти підуть на певний підрозділ, деталі згодом.

🦾 Інструкція:
1. Клікаєте на баночку.
2. Потім тицьніть на кнопку "Отримати нагороду".

Finger crossed 🤞🏼

Побажайте удачі⚡️

Привітик гайз! 🌞
Поки я знову в дорозі до Києва, пишу Вам допис!

Памʼятаєте я Вам розповідала про програму ENGin?

P.S. Хто не читав, я реплайнула цей допис - можете піднятись та ознайомитись!

Так ось, я мала вже 3 заняття зі своїм бадді і хочу розповісти Вам свої враження!💫

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

🤔 Дуже цікаво, що в Україні та США наше покоління має купу спільних проблем. Наприклад, як от купівля житла. Я завжди думала, що це лише в Україні наше покоління не може купити собі житло через надзвичайно високу вартість. Проте як виявилось, у США це також розкіш.
І це так цікаво пізнавати іншу культуру від імені громадян.

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


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

Якщо Ви спитаєте мене, чи рекомендую я цю програму - моя відповідь «однозначно так»!
Адже Ви не лише імпрувите мову, а й пізнаєте іншу культуру, звикаєте до різних акцентів та просто гарно проводите час!

⬇️ продовження вижимок з QA Day ⬇️

👩🏼‍💻 Анастасія Чудовська, «Переїзд з моноліту на мікросервіси з точки зору QA»

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

➕Плюси моноліту: легке оновлення, цілісність коду, просте тестування.
➖Мінуси моноліту: довге розгортання, пошук проблем, довга регресія.

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

➕Плюси мікросервісів: розпаралелювання, передбачуваність, швидкі релізи.
➖Мінуси мікросервісів: інтеграції, контроль даних, АРІ та автоматизація.

‼️Shift left не просто рекомендація, а скоріше обовʼязкова практика у світі мікросервісів.

📄Документація - наш найкращий друг.
• Документуємо все.
• Верифікуємо.
• Оновлюємо текст кейси.
• Залучення до мітингів.

💡Правила деплою:
• Жоден тікет не потрапляє на середовище без згоди QA.
• Регулярні зустрічі для обговорення очікуваних змін.
• Вчимось працювати з логами.

🦾Міграція даних - виклики:
• Зміни у зберіганні даних.
• Цілісність точність на повнота даних.
• Консистентність даних між системами.

✍🏼Міграція даних - тестування:
• Документувати структуру даних.
• Логи для відстеження помилок.
• Контроль доступу до чутливих даних.
• Синхронізація та відновлення.
• Час міграції на тестових середовищах.



👩🏼‍💻 Євген Гайдай, «Виділена команда автоматизації тестування»

❔В чому перевага структури коли AQA всередині команди?
• AQA завжди доступний для ліда, ПМ чи інших.
• AQA дуже добре знайомий з функціоналом.
• Зрозуміла ясна та керована структура команди.

❔В чому недоліки структури коли AQA всередині команди?
• Важко уніфікувати підхід до автоматизації та стек технологій в рамках компанії.
• Проблема перерозподілу ресурсів.
• 1 AQA - 1 команда.

❔В чому переваги структури відділеної AQA команди?
• Відсутність прямої привʼязки AQA до команди.
• Можливість залучити ресурси на критичні напрями.
• Уніфікація підходів та стеку технологій.

❔В чому недоліки структури відділеної AQA команди?
• Важко одночасно бути в контексті всього.
• Велика кількість швидких перемикань уваги.
• Можливість недостатку ресурсу у потрібний момент.

❔Як витримувати навантаження декількох команд?
• CI/CD рішення має бути простим, зручним та надійним.
• AQA не тестують, а надають інструмент для тестування.
• Скоуп автоматизації формують продуктові QA.

❌Можливі помилки:
• Бажання, щоб AQA були додатковими тестерами в командах.
• Відсутність залучення мануального QA в роботу з автоматизацією.
• Відсутність контролю за процесом автоматизації та тестування.

Отакий виходить нотатник Аміни😂 вибачте! Я зупинюсь)))

❔Як Вам інфа? Знайшли щось собі корисне?
⚡️ - так;
🥱 - ні;
❤️ - сердечко за старання.

Привітульки!
Тиждень ще не встиг початись, а вже майже його кінець… то ж завершуємо справи і готуємось до вихідних!
Поки Ви завершуєте, я вже повністю додивилась доповіді з QA Day і несу Вам останні вижимки🥳
Насолоджуйтесь!


👩🏼‍💻 Ганна Каплун, «Тестування на основі персон: ідея, інструменти, приклади»

💡Техніка прийшла до нас від UX дизайнерів.

📖 Ідея цієї техніки полягає у тому, щоб спробувати поставити себе на місце користувача.

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

👤 Персона - це конкретний користувач якого ми вигадали, але для кого ми маємо певну інформацію.
Цей користувач є частиною нашої цільової аудиторії.

✍🏼 Наприклад: імʼя, позиція, скільки років, з якими проблемами стикається і тд.

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

⬛️ Чорний ящик побудований на даних, а технік на основі поведінки мало.

📄 Сценарії будуть відрізнятись між собою не тільки даними, а й кроками.

❔Які питання собі задавати?
• Хто це користувач нашого продукту?
• Яка у нього проблема?
• Як вони його використовують?

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

📜 Характеристики:
• Вік
• Робота , роль
• Доступність
• Геолокація
• Патерни поведінки
• Цілі
• Болючі поінти
• Все що завгодно, що може повпливати на використання продукту

✅Хороші практики:
• Фокусуємось на тому, що важливо.
• Дізнаємось нашого юзера.

❌Погані практика:
• Забути про техніки тест дизайну.
• Фокусуватись тільки на едж кейсах.



👩🏼‍💻 Юрій Малий, «QA метрики в процесі SDLC»

✔️ QA бере участь у всіх етапах SDLC.

«• Що у нас там із проектом?
• Як виміряти?
• Що означають ці цифирки?
• Як було раніше? І т.д. І т.п....»
Можна привентивно задати ці питання собі, вчасно їх задавши у нас буде більше часу на аналіз, підготовку і гарний результат.

❔Менеджмент задає ці питання бо вони не розуміють, що там відбувається - їм недостатньо прозорості.

💫 Забезпечити прозорість - ми можемо вибором правильних метрик.

📜 Приклад метрик:
• Defect quantity
• Fault density
• Test cases
• Pass rate
• Quality coverage rate
• Logged time metrics
• Scrum metrics

⬇️ внизу будуть дві останні ⬇️

Як і обіцяла - одразу даю Вам частину другу! Аби не затримувати…

👩🏼‍💻 Євген Толчинський, «QA метрики і як їх хакнути»

📌Метрики потрібні щоб оцінити якісь тестування.
Потрібні вони менеджерам, лідам, та команді.

💫Для менеджерів:
• Репортінг.
• КРІ.
• Оцінка ситуації.

💫Для лідів:
• Репортінг.
• Оцінка ситуації.
• Менеджмент команди.

💫Для команди:
• Репортінг.
• Розуміння, що я роблю.
• Оцінка ситуації.

Далі ми розглядали метрики, які збирають для того, щоб відстежувати якість продукту! Там були скріни, тому їх «вижати» не можу😅



👩🏼‍💻 Артем Овчаренко, «Promises від А до Я: Асинхронність, колбеки та пастки масивів»

🙏🏼Більше знаєш, легше працюєш, отримуєш більше грошей.

📌Promises - виникли для того, шоб працювати з асинхронністю.

📖Асинхронність - це архітектурне рішення, яке не блокує виконання коду.
Паралельно може виконуватись декілька дій.

📌 Це взаємодія з іншими елементами на сторінці при тому, що всі інші доступні.

💡Неблокуюча комунікація.

📌Await і async - це проміси.

В браузері у нас асинхроний код, він працює паралельно.

💡Call back - функція, яка передана як аргумент в іншу функцію.
Наприклад:
Йдемо в магазин, в магазині дзвонимо і питаємо що купити.



👩🏼‍💻 Юрій Малий, «Впровадження системного процесу QA в великій компанії для забезпечення якості IT-продуктів на кожному етапі»

📌 Переваги тестування для бізнесу та цінність для компанії:
• Зменшення витрат на підтримку та оновлення.
• QA допомагає виявити дефекти на ранніх етапах розробки.
• Підвищення продуктивності.
• Покращення якості обслуговування клієнтів.

💫 Основний бізнес будь-якої компанії - створювати додаткову цінність.

📌Для нас - це гроші
📌Для клієнта - якісний продукт

❔З якими питаннями звертаються до IT:
• Інструмент не працює.
• ІТ-рішення працює погано.
• Клієнти/користувачі чимось не задоволені.
• Інструмента взагалі немає.

📌Основні причини:
• Неправильно зробили вимоги.
• Неправильно зафіксували вимоги.
• Перед впровадженням продукту не перевірили чи все працює.

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

❔Як Вам інформація? Яка з вижимок сподобалась найбільше?
Діліться!❤️

Раночок!
Конфа - конфою, а вижимку ніхто не відміняв!
То ж, ловіть першу частину🔥


👩🏼‍💻Олексій Остапов, «Персональна ефективність»

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

❔Задавайте собі питання:
«Чи вважаєте Ви себе хорошим спеціалістом?»

❌Аргументи по типу:
• Я довго працюю…
• Мені платять гроші…
• Я вмію тестувати…
• Я знаю технології…
• Я маю сертифікацію…
… І тд. - не підходять, оскільки для менеджменту це не аргументи.

Якщо менеджеру казати «я хочу» для менеджера це не аргумент, аргументом є досягнення.

📌У нас є два шляхи:
• Особиста точка зору.
• Точка зору менеджменту.

💫Люди самі себе оцінюють краще, ніж інших.

‼️Завжди необхідно записувати всі свої досягнення.

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

🎤 Якщо Ви займаєтесь медійною активністю - то це автоматично репутаційна активність для компанії.
Компанія стає більш впізнаваною і це розвиває бренд роботодавця.



👩🏼‍💻Ріна Ужевко, «Впровадження процесу адаптації на прикладі великого проєкту»

❔З чого почанати розбиратись з адаптацією?
• Опитування людей.
• Занурення у процес.
• Спілкування з іншими (HR, бухгалтери і тд.).
• Стаємо в «капці» інших і думаємо, що потрібно було б нам.

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

💫 50% людей йдуть з проєкту після прийняття на роботу через неякісний онбординг.

❔Що потрібно людям на онбордингу щоб залишитись в компанії?
• Комфортне знайомство з командою.
• Чітко виставлені очікування.
• План онбордингу.
• Структурність.
• Розуміння де, що взяти.
• Розуміння що за проєкт і для чого.
• Які будуть завдання.
• Хто відповість на питання.
• Що треба для росту та які способи навчання.

📌 Адаптація це не тільки знайомство з продуктом, вона складається з:
• Onboarding - знайомство.
• Induction - посада.
• Adaptation - звичка.
• Offboarding - усвідомлення припинення співпраці.

📄 Для гарної адаптації необхідно скласти стратегію:
• Які люди потрібні?
• Що ми від них очікуємо?
• Які цілі закриваємо?
• Хто допоможе?
• Кому що делегувати?
• Як реалізувати?

📜 Формуємо план адаптації який містить в собі дії, терміни, етапи, документи та відповідальних на кожному етапі адаптації.

💡Можна дати реальну задачу новенькому, аби глянути які очікування можна виставити до нього і чи готова людина вже виконувати справжні задачі.

🦾Індивідуальний чеклист або цілі по SMART чи PDP у якому мають бути і посилання на документи, і загальні речі і тд.

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

📌 Підсумки по адаптації:
• Адаптація повинна закривати всі етапи.
• Враховуйте особливі кейси людей.
• Випробувальний термін може бути окремо.
• Рішення про закінчення адаптації за вами.
• Збирайте відгуки і опрацьовуйте.
• Постійно вдосконалюйте процес.
• Зробіть цей процес прозорим для всіх.



👩🏼‍💻 Антон Синявський, «Як побудувати процес тестування на проєкті з нуля?»

1️⃣ Зрозуміти проблему, яка є на проєкті.
• Про що продукт і як він приносить гроші.
• З чим ми взаємодіємо, як ми взаємодіємо.
• Говоримо з командою девів.

❔Які аутками ми маємо мати?
• Бізнес модель.
• Депенденсі системи.
• Девелопмент процес.
• Документи з issues.

2️⃣ Створення процесу відносно проблем, які ми побачили.
• Створюємо стратегію.
• Обговорення цієї стратегії.
• Будуємо процес відповідно до документації.

❔Які аутками ми маємо мати?
• План заапрувлений тімкою.

3️⃣ Імплементація і практична верифікація процесу.
• Працюємо над процесом.

‼️ При побудові процесу з 0 звертаємо увагу на:
• Обираємо концепцію.
• Створюємо процес (чіткий, підтримуваний, візібл).
• Додаємо автоматизацію.


Довго затягувати не буду, увечері буде друга частина, то ж очікуйте🥰