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

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, яким користуюся я сам.

Книжки з тестування, автоматизації та інженерії

#testing #automation #books

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

Книжки:
- Team Guide to Software Testability: Better software through greater testability (what testability is and how we can work with developers to improve it)
- Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems (must-have read for those who work with distributed systems!)
- How Google Tests Software (old, but still has a lot of insights)
- Software Engineering at Google: Lessons Learned from Programming Over Time (better than previous - contains examples not only for testing but for other aspects of software delivery)
- Leading Quality: How Great Leaders Deliver High-Quality Software and Accelerate Growth (small book on how to drive and lead quality in any organization)
- Effective Software Testing A developer's guide (the way how testing should be explained and taught to the developers)
- Software Testing: A Craftsman’s Approach (true technical sides of testing)
- System Design Interview – An insider's guide (insights on how modern systems are)
- Agile Testing and More Agile Testing (only part about automation worth it)
- The Coding Career Handbook. Guides, Principles, Strategies, and Tactics (general advice on every aspect of day-to-day IT job)
- Staff Engineer: Leadership Beyond the Management Track (for those who see the future not in management/leading but in IC contributing)
- Complete Guide to Test Automation: Techniques, Practices, and Patterns for Building and Maintaining Effective Software Projects
- Experiences of Test Automation: Case Studies of Software Test (bits of advices and stories about old times in test automation)

Звичайно є ще багато інших книжок.
Але я навмисно не включав сюди книжки з якихось окремих технологій чи мов програмування. Це ви вже зможете знайти самі :)

А які книжки Ви вважаєте найкориснішими для Вашої кар'єри?

[Test Engineering Weekly] Про SDETів, аналіз даних автотестів, парне програмування та менторинг

#testing #engineering #weekly #digest

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

Чому потрібно почитати дайджест? З нього ви дізнаєтеся:
- що таке тестування насправді
- хто такі ті SDETи
- як та навіщо аналізувати результати ваших автотестів (та нащо там прикручують machine learning)
- яку нову оупен-сорс тулу для тестування релізнув Microsoft
- чи потрібні знання статистичного аналізу в АйТі
- як правильно менторити людей та парно програмувати
- як одна строчка коду призвела до вибуху ракети
- різні корисні штуки в Playwright
- та багато іншого....

Про Generalizing Specialists та цікавий плагін для VS Code

#testing #tools #career #notes

Всім привіт. Сьогодні я вирішив поділитися моїми нотатками цікавої статті - Generalizing Specialists: Improving Your Effectiveness.

А для тих, хто хоче більше про код - пропоную поглянути на CodeGPT - плагін для VS Code, який згенерує вам потрібний шматок коду з вашого коментаря. Щось на кшталт GitHub Copilot.
Особисто я спробував, погрався, але в роботі поки що не знадобилося.
Але генерує воно доволі непогані шматки коду.

Вакансія для Джона Коннора

Finding Adequate Metrics for Outer, Inner, and Process Quality in Software Development

#testing

Сьогодні пропоную до Вашої уваги хорошу статтю про метрики в тестуванні. Нащо вони потрібні, та що краще вимірювати.
Тут не буде просто "готового" набору must-have метрик. Але буде багато роздумів про те, чому метрики важливі та які вони бувають.