Го тестити virtuoso.qa на стрім https://youtube.com/live/UqiuIw9AsL0 !!!

Ми автоматизуємо тести не для тестувальників ✋🏻, а для розробників 🦾. Ціль не у тому щоб допомогти з мануальною рутиною тестувальникам на стадії тестування, а у тому щоб помогти розробникам не пропустити дефекти, які вони «тільки що наробили» і от от хочуть уже перевести таску в done чи ready for test... ну а далі «класичний пінг-понг» між тестерами і девами 🏓... Тут можна довго придиратись до формулювань, адже з якого це дива взагалі ділити на «це тестування» а це «ще не тестування». Так і є... Але тут трюк в акценті. Якщо трошки змінити кут зору, то можна почати бачити оптимізації там, де раніше вони були не очевидні. Якщо ми починаємо більше думати про розробників, максимально «ближче до них» впроваджувати автоматизацію і інтегрувати її саме у «життя девів», то починає виявлятись що навіть меншою кількістю покриття ми досягаємо більшого в плані якості. Деви тупо починають «менше робити багів».

І в цю ж тему відповідно до розгляду куча практик від розподілу покриття по піраміді до банального включання навіть end-to-end тестів у репу самої апки. Ясно що виключення є скрізь, але, можливо... і враховуючи принцип YAGNI - це «енд ту енд тести окремо від коду проекту є виключенням ніж навпаки». Раз уже наш клієнт - це деви, то чому б і тести не «тримати поближче до них»... Про от це «ближче до того де воно використовується» – ось ця гарна стаття https://kentcdodds.com/blog/colocation 😉 Цікавий термін co-location... Вперше почув) Зазвичай це cohesion-ом обзиваю, та й оригінально з появою React-у саме цей термін і використовули як селлінг поїнт його підходу «вью та логіка вью разом», але щось є у ко-локації - якось більш прямо говорить про що воно 😎

Kentcdodds

Colocation

Maintainability through colocation

Який потрібен софт, щоб допомогти громаді самоорганізуватися та почати вирішувати свої проблеми?

Один з проектів, які можна обрати на Міському таборі для підлітків від школи Майбутні на весняних канікулах — це розробка таск-менеджера для громад.

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

Як громада може визначити свої проблеми і потреби? Хто в громаді може взятися за пошук рішення? До вирішення яких задач треба залучати державу, а з якими проблемами можна впоратися своїми силами? Який сервіс і софт потрібні, щоб громада самоорганізувалася? А що потрібно окрім софту? — це питання, над якими працюватимемо.

Проєкт будемо створювати за ментороством політологів, правників та власне мене, Яші Крамаренко 😇

🗓️ Міський табір триватиме на весняних канікулах з 25-29 березня в приміщенні школи на Подолі.
Опис інших проєктів і реєстрація на табір на сайті🕹️

На стрімі промайнуло – як набиратись досвіду щоб знайти першу роботу, але здається там я не резюмував мій основний лайф хак: «шукати цікаві оупенсорс проекти чи альфа/бета-версій цікавих апок і гайда тестить, заводить баги». Можна самотужки, навіть в незалежностів від команди таких апок - пройти весь цикл, від декомпозиції функціоналу і побудови функціональної карти + чеклістів, написанню простого власного тест плану (що я буду тестить (скоуп)? як (принципи)? чим (інструменти)? коли?), і аж до автоматизації відповідних сценаріїв, власного прослідковування покриття, заведенню багів і спілкуванню з командою, перепровіркою фіксів, регресії на релізах... І ось вчора список таких апок для першого досвіду поповнився https://github.com/diia-open-source 😉

GitHub

Diia

Diia is an app with access to citizen’s digital documents and government services - Diia

Нагадую що сьогодні о 19:00 тестимо virtuoso.qa 😉 Посилання на стрім прилетить сюди ж перед початком.

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

От не один раз я вже чув таке від тестувальників в контексті вибору нового проекту для роботи. Чомусь багатьох умовно молодих по досвіду інженерів – лякає «повна организація процесу QA з нуля, та ще й коли ти один»... Мені це завжди було важко зрозуміти, бо у самого завжди слина текла на такі проекти – це ж скільки простору для само-розвитку і головне «зробити все саме так як хочеться, і щоб ніхто зверху палки в колеса не вставляв» 😇 А ще – не пам'ятаю щоб коли потрапляв у такі ситуації (а на відсотків 90 лиш в такі я і потрапляв) – то я використовував для власне налаштування процесу щось інше окрім здорового глузду та відкритої структурної комунікації з розробниками для спільного вирішення ключових питань. Раптом дивним чином виявляється, що достатньо взяти відповідальність, проаналізувати проблеми, щиро поділитись ними з іншими членами, сформувати потреби, набрейнстормити по ним варіанти вирішення і дуже швидко звичайна логіка допомагає знайти оптимальне рішення... Не читаючи 100500 книжок по QA, не залучаючи супер-мега консультантів, і так далі 🤡

нЄ?

Давайте от сходимо на TechMeetup від QArea і послухаємо що Артем Григоренко розкаже з цього приводу? Навіть так, саме ви (поки я навіть пости тут постити не встигаю) сходите послухаєте Артема, а тут у коментарях поділитесь зі мною інсайтами, і можливо подискутуєте зі мною по темі:) 🙏🏻

Всі виручені кошти від даного заходу будуть передані на підтримку ЗСУ або інші благодійні цілі. 7 березня о 18:00 👉
https://tech-meetups.qarea.org/more-details-organization-of-the-quality-assurance-process

Ще 14го листопада мій хороший товариш та продакт менеджер (довоєнний бо з початку доброволець) оголошував збір з ціллю в 250к. За десяток днів, хлопцям ще не вистачає біля 70к на очі в небі. Давайте допоможемо чим зможемо 🎯

🔗Посилання на банку
https://send.monobank.ua/jar/7xUq6azYSD
💳Номер картки банки
5375411210427436

Чи прям так playwright 🎭 швидше за SElenium ⚛️? 🤔

Ми 🎭 використовуємо на деяких проектах вже давно, але я так ніразу і недобігав реально зрівняти швидкість. І от – припекло🤡 А то Рома от останнім часом «кричить» що «селеніум тепер тільки для бабуїнів» (це моя дуууже вільно-перекручена інтерпретація сенсу, ги) а я якось для себе ще крапок над і не розставив... ну бо 🎭 тільки під web, бо API все ще формувався, до сих пір доволі не консистентний місцями, часом радикально стрибав у інший бік (слава богу що правильний – це я про page.locator замість усього іншого). І от я вже почав переживати що я зовсім не в тренді... Не солідно 🙂

Так от, ми тут поки дуже простенький End-to-End на TodoMVC апку запустили, типу всі види операцій по черзі проробити у сценарії. На 10тьох ранах (так, так, знаю що мало, але грець з ним) – Мінімальна різниця в часі – 11% відсотків усього! Опа опа, такий вже прям і швидший? 🙂 ... Це я так інтригу тримаю... Ну ок, таки є стрибки і аж до 64%. І середня різниця виходить – 35%, що вже не так і мало...

Але тут є ще один цікавий нюанс...

Зрівнювали ми не з чистим SElenium а саме з SelenideJS, тобто селенідоподібним врапером обмазаним зсередини розумними неявними очікуваннями а ззовні лінивими елементами – що самі по собі давлять на гальма поверх чистого селеніуму (все заради добра, стабільності тестів, і все таке, але зараз не про це), і якраз от ця різниця десь приблизно і лежить в залежності від ситуації між 25 і 75 відсотками (це я знаю бо тестив не раз всі свої селени/селеніди в порівнянні з селеніумом). Виходить цікавий висновок – саме в порівнянні з чистим селеніумом ймовірно не на так багато плейврайт і швидше 🤡 Але якщо порівнювати його з чимось типу селенідів що = селеніум + окрім усього + вбудовані очікування на кожен чих, то отримуємо вже щось типу 35% на користь плейврайту... І дуже може бути що якраз ці 35 відсотків і пов'язані з тим що плейрвайт більш ефективно саме "неявно чекає", адже саме в цьому вся фішка його движку, який побудований на набагато ефективніших з точки зору "комунікації" вебсокетах а не http як селеніум...

Тепер питання – чи дійсно того як чекає плейврайт – достатньо? чи настільки ж він стабільний з коробки як селеніди? І якщо так, чи можемо ми на боці селенідів таки зменшити відставання від 35% до чогось хоча б близького до спостереженого мінімуму в 11% у наших тестах...?

P.S.
Далі буде ще серія постів про плейврайт та його порівнянь з селенідами, включно по нюансам синтаксису, тому stay tuned 😉 Для тих хто любить спойлери – по нашим останнім зрівнянням – 🎭 хоч і не так красиво і консистентно але по суті дублює синтаксис селенідів, що означає що навіть врапер довкола плейврайту не особливо то вже зараз і потрібен... Хоча у мене руки все ще чухаються його доробити 🙂

Йо! Поки я дописую статтю по Optional вже більше місяця 🙈, давайте допоможемо Миколі зібрати на бандаж для 71-шої окремої єгерської бригади 🦾

🎯Ціль: 25 000.00 ₴

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

💳Номер картки банки
5375 4112 0936 1141

Linkedin

Mykola Nikiforov PMP on LinkedIn: #supportukraine #helpukraine #standwithukraine #stoprussianaggression…

Dear Colleagues, I have an immediate request from our defenders (the 71st Jaeger Brigade). They require bandages intended for the treatment of penetrating…

Висновок 1: Optional.empty() не те ж саме що Optional

... в той час як null один і той самий що в User | null що в Address | null. А раз той самий, то потенційно, чисто випадково, навіть при «Null Safety» можна передати отриманий null від функції що повертає нулабл адресу до функції що очікує нулабл юзера o_O

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

У #java от – доволі жорстка система типів і вона буде страхувати нас у таких випадках...

Наприклад, якщо у нас є метод @Nullable String getStreetFrom(@Nullable User user), що витягує з юзера адресу (якщо вона не null) а потім витягує з адреси вулицю, то #java хоч і дозволить скомпілювати

```
//java
System.out.println(getStreetFrom(null));

```

Але у більш реалістичній ситуації – не пропустить, якщо ми переплутаємо таки юзера з адресою:

```
//java
Address adressToBeInitLater = null;

// ... і якщо ми забудемо ініціалізувати змінну, залишивши там null,
// то все одно отримаємо

System.out.println(getStreet(adressToBeInitLater)); // COMPILE ERROR!

```

Тобто на практиці #java все таки вміє розрізняти null-и для змінних різного типу.

Але не всі такі розумні... – #typescript от не завжди вміє:) У тій же ситуації код в #typescript скомпілюється без помилок:

```
//typescript
function getStreetFrom(user?: User): string | undefined {/.../}

// ...

let adressToBeInitLater: Address | null = null

// ... і якщо ми забудемо ініціалізувати змінну, залишивши там null,
// то ніхто нас не попередить про це...

getStreetFrom(adressToBeInitLater) // <- COMPILED OK o_O

```

а от з Optional такого б точно не було:

```
//typescript
import { Option } from 'prelude-ts';

// ...

function getStreetFrom(user: Option): Optional {/.../}

//...

let adressToBeInitLater: Option

// ... і якщо ми забудемо ініціалізувати змінну,

getStreetFrom(adressToBeInitLater) // <- COMPILE ERROR 🙂

```

І це були тільки квіточки... Далі буде найцікавіший раунд, де Optional таки надає «Null Safety» тумаків, який все ще пропускатиме потенційні баги з нуллами.

to be continued...