Го тестити 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 ? Посилання на стрім прилетить сюди ж перед початком.

AI-Powered Test Automation, це вам не півники смоктунці полизувать) У цю середу, 13го березня о 19:00, обскакаємо virtuoso.qa, і подивимось де він на шкалі між мустангом ? і ... поні ? (нехай всі поні мене пробачать... ?)

Посилання на live stream скину уже в середу десь там за годинку до старту... або підпишіться на канал у ютубі щоб не пропустити, канал зветься так само як цей, шукайте autotestyak ?

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

От не один раз я вже чув таке від тестувальників в контексті вибору нового проекту для роботи. Чомусь багатьох умовно молодих по досвіду інженерів – лякає «повна организація процесу 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 ? Для тих хто любить спойлери – по нашим останнім зрівнянням – ? хоч і не так красиво і консистентно але по суті дублює синтаксис селенідів, що означає що навіть врапер довкола плейврайту не особливо то вже зараз і потрібен... Хоча у мене руки все ще чухаються його доробити ?