Playwright vs Selenium Speed Comparison

#testing #automation

Натрапив тут на статтю, у якій порівнюються модний Playwright та старий добрий Selenium Webdriver.
І виявляється, Webdriver швидший за Playwright!

І це все після відео від Ярослава на цю тему. Там результати діаметрально протилежні.
То ж де правда? Хто помиляється? :)

Думаю, що треба буде й самому зробити такий бенчмарк коли буде час).
Чи може хтось з вас, мої читачі, вже має такі результати?

The Last Time

#testing

У продовження "гарячої" статті про непотрібність тестувальників, Алан Пейдж також розповів свої думки про feedback loops.

А точніше:
- як швидко отримували зворотній зв'язок та баги у епоху Windows 95
- у чому схожі автори та редактори на розробників та тестувальників
- наскільки успішні нові фічі в різних компаніях "в середньому". Та чому важливо все таки тестувати в продакшені.

В аналогії з авторами та редакторами мені сподобався цей уривок:
"I’m sure other editors are better, but editors have two purposes. The first is to help with functional correctness (grammar, structure, clarity, etc.). The second is (often) to act as a proxy and give feedback on the experience of the writing. Here too, I think static analysis tools (e.g. grammarly) can provide feedback on the “correctness” of my writing, but I think the experience is probably better evaluated by my readers."

Тобто, якщо повернутися до світу IT - тестувальник допомагає перевірити софт з функціональної сторони, а також - на основі свого досвіду.

Бесперечно тільки справжні користувачі зможуть сказати (можливо непрямим методом, а метриками) чи подобається їм фіча та як їм зручно нею користуватися.

Автоматизація за межами UI та API

#testing #automation

Писати автотести на рівні UI та API не є чимось новим для тест інженерів. В інтернетах написані вже сотні чи не тисячі туторіалів на ці теми. Крім того, є курси (наприклад Test Automation University) та інструменти для полегшення життя.

Але як щодо чогось менш розповсюдженого?

Як тестувати бібліотеки (наприклад Java бібліотеки)?
Які інструменти є для автоматизації тестування утиліт командної стрічки?
Як автоматизовувати ААА ігри?

Може хтось знає? Діліться інструментами та статтями у коментарях.

Software Engineering at Google

#engineering #book

Багато хто знає, або читав, книгу "How Google Tests Software". Книга вона вже доволі стара. Хоча підходи, описані у ній - універсальні та поза часом.

Для тих же, хто бажає дізнатися більше, ніж про тестування, у 2020 році вийшла книга "Software Engineering At Google".
Я прочитав її практично одразу після її виходу. Та знайшов дуже багато цікавих ідей там. Не надто революційних, але хороших.
Звичайно - частина цих ідей буде працювати тільки у великих компаніях. Більше про книгу я написав у рецензії.

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

Вакансії стають все кращими.

Proven Solutions to Five Test Automation Issues

#testing #automation #microservices

Тестування мікросервісів складається з багатьох рівнів. На кожному з рівнів - свої інструменти.
Одна з найпоширеніших задач - це протестувати мікросервіс в ізоляції. Так - внутрішні залежності можна замінити на testcontainers.
Але що робити, коли є залежності на API іншого сервісу (свого чи third-party)?

Сьогодні я пропоную до Вашої уваги статтю Wojciech Bulaty - Proven Solutions to Five Test Automation Issues.
В ній автор знайомить нас із п’ятьма проблемами, з якими стикалася його команда при тестуванні зовнішніх API - та які інструменти вони використовували для вирішення цих проблем.

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

📅 25 січня, в середу, о 19:00 у телеграм-каналі dou_qa влаштуємо «Книжковий клуб» — обговоримо книгу «How Google Tests Software» та кілька інших.

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

Адже спікери вже прочитали її та готові ділитись враженнями:
💥 Олег Грудко, QA Team Lead в Omilia, співведучий подкасту «Питання якості»
💥 Олександр Романов, SDET в IOHK, автор тижневих дайджестів про тестування
💥 Роман Марінський, Test Engineering Lead and Community Leader QA Club Lviv

Відмічайтесь в івенті: https://dou.ua/goto/9dsv

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

The Future of the SET (SDET, Software Engineer in TEST)

#testing #automation #book

Тези з книги “How Google Tests Software”. 2012 рік.

"""
Простими словами, ми не віримо у майбутнє SET. SET - це розробники. Крапка. Google платить їм так само, як розробникам, оцінює їх продуктивність як розробників, та й навіть називає обидві ролі - software engineer. Тому це одна й та сама роль.
Як би не була приречена ця окрема роль, обов’язки нікуди не подінуться.
Магія формули SET у Google саме в роботі, які вони виконують. SETи створюють такі фічі продукту, як testability, reliability, debugging capability та ін. Якщо ми ставимося до цих функціональностей так само, як і до інших, на кшталт UI, тоді SETи - це ніщо інше, як розробники, які відповідальні за окремі фічі у продукті.
Дійсно, ця частина процесу зламана.
Кожна фіча, що доступна користувачеві - управляється продакт менеджерами та створюється розробниками (Sofware Engineers). Код для цих фічей підтримується та деплоїться за допомогою автоматичних інструментів. Однак тестовий код пишуть SETи та користуються ним тест інженери. Але чому? Це скоріш історичний релікт з часів розвитку ролей. Але еволюція не стоїть на місці: тому час відноситись до тестового коду так само, як і до feature коду. Нехай він управляється PM-ами та створюється розробниками також.
…
Ось наші міркування. Тестовий код, зазвичай, перевіряє увесь продукт на багатьох рівнях. Тому розробники, що пишуть такий код вимушені більше вивчати продукти та API різних взаємопов’язаних частин. Чи може бути швидший спосіб глибше розібратися у продукті, його системному дизайні та архітектурі? Бути відповідальним за тести - це найкращий початковий проєкт для будь-якого розробника новачка у команді. Згодом, ці новачки почнуть писати фічі, а тести перейдуть у власніcть нової “хвилі” новачків.
Теж відноситься також до junior розробників. Тести не входять у кінцевий продукт - тому junior-розробники не будуть дуже переживати через те, що їх код зламає якусь важливу фічу на продакшені.
"""
Ось такі тези були в книзі, написаній у далекому 2012 році. А що ми маємо зараз? Чи вмерло тестування у вигляді окремих SET інженерів? Чи є вони у вас на проєкті?

Як бага в системі приводить до великих рахунків за світло

#testing #bugs #funny

Поки в нас перевантаження електромереж та постійні відключення світла - ось Вам історія про те, як через багу у системі, у школі в Массачусетсі не могли вимкнути світло протягом РОКУ!

[Test Engineering Weekly] Тестування ML та розширень браузера, чи завжди wait є поганим та чому потрібно читати дослідницькі роботи

#testing #engineering #weekly #digest

Це п'ятниця - а значить саме час завершувати усі таски та почитати щось цікаве.
Тому я прийшов до вас із черговим дайджестом статей зі світу тестування та технологій.

🎧💚 Публікуємо запис та таймкоди войсчату з обговоренням книг про тестування! 📚

🗣 Спікери:
👉 Олег Грудко, QA Team Lead в Omilia, співведучий подкасту “Питання якості”
👉 Олександр Романов, SDET в IOHK, автор тижневих дайджестів про тестування
👉 Роман Марінський, Test Engineering Lead and Community Leader QA Club Lviv

На форумі також опублікували запис на Soundcloud.
https://dou.ua/goto/qZEE

Quality Culture Transition Guide

#testing #leadership

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

А я поки пішов поєднувати Java та Scala тести в межах одного проекту)

Рації для 109ї

Всім привіт!
Прошу долучитися до збору на допомогу хлопцям з 109ї бригади, які зараз знаходяться під Бахмутом.
Є дуже велика потреба в засобах комунікації - рації motorola dp4400 VHF!

Дякую кожному з Вас!

🎯 Ціль: 110 000 ₴

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

💳Номер картки банки
5375 4112 0324 6678

Як автоматизувати command-line інструменти?

#testing #automation

Коротка розповідь про те, як замість пошуків інструменти, краще написати десяток строк коду.

Infinum QA Handbook

#testing #junior

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

[Test Engineering Weekly] Метрики якості, архітектори тестів, multiplayer в Age of Empires та проблеми з float числами

#testing #engineering #weekly #digest

Всім привіт! Це Олександр на зв'язку.

Цього разу дайджест цікавого вийшов досить великим. І це ще багато чого не вмістилося (залишив до наступного разу!).
Приємного читання.

ChatGPT вже має сертифікат ISTQB Foundation Level.

Для тих, хто забув або тільки вчить HTTP Codes - є дуже хороший набір картинок до дня усіх закоханих!

Корисні поради для вашого резюме

#testing #interview

Усім нам рано чи пізно потрібно змінювати роботу. А значить - проходити інтерв’ю.

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

На ринку АйТі України домінують аутсорсні компанії. Тому хочете Ви цього чи ні - резюме краще писати англійською мовою та за стандартами “західних” компаній.

Деякі загальні поради та корисні ресурси:
- Для того, щоб красиво та змістовно описати Ваш досвід, потрібно трохи розширити свій словниковий запас. Тут Вам стане у пригоді підбірка синонимів до найбільш розповсюджених слів в резюме
- Резюме краще відсилати у форматі PDF
- Незалежно від кількості років досвіду - краще вмістити все на 1 - 2 сторінки
- Деякі компанії та рекрутери шукають виключно по ключовим словам та технологіям. Тому, якщо хочете пройти цей фільтр - вказуйте технології в окремій секції
- І ще про технології - не треба вказувати усе, що Ви коли-небудь бачили в житті. Будьте готові відповідати на питання по будь-якій з вказаних абревіатур. Навіть, якщо це вже застаріла бібліотека чи фреймворк, який Ви бачили раз у житті у доповіді на локальному мітапі
- Якщо Ви початківець - не пишіть просто “вчив цю бібліотеку чи технологію”. Кращі вкажіть, як ця бібліотека допомогла Вам в поточних задачах чи навчанні
- В описі свого досвіду концентруйтеся на тому ЩО БУЛО ЗРОБЛЕНО, а не на тому ЩО ВИ РОБИЛИ. В ідеальному випадку повинна бути чітка та зрозуміла метрика Вашої роботи. Чи то покриття тестами чи то покращення швидкості запуску тесті на стільки то відсотків
- Для досягнень можна користуватися підходом STAR - Situation, Task, Action, Result. (Цей метод можна також застосовувати на співбесіді - коли Ви розказуєте про минулий досвід)
- Важливо не тільки те, що Ви почали - але й те, що Ви закінчили почату роботу чи ініціативу

Наостанок - шаблон CV, яким користуюся я сам.