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 метрик. Але буде багато роздумів про те, чому метрики важливі та які вони бувають.

Moving towards a Future of Testing in the Metaverse

#testing

Натрапив на цікаву статтю про тестування в майбутньому від Tariq King.
З неї ви дізнаєтеся:
- які потенційні складності принесе Metaverse та супутні із цим технології - VR, AR, XR.
- як тестувати AI ботів за допомогою AI та computer vision
- чи можна взагалі автоматизувати тестування геймплею в FPS іграх

Як завжди на InfoQ - мінімальна кількість води, максимально багато прикладів та користі.
Цей ресурс мені подобається більше, ніж Medium (який переповнили однакові статті на однакові поверхневі теми з тестування).

Blockchain 101 - A Visual Demo

#blockchain #engineering

Доброго ранку, тест інженери

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

А точніше:
- що таке хеш на прикладі SHA256
- що таке блок та як з блоків формується блокчейн
- як це виглядає в розподіленому середовищі

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

You’ve “Built Quality In”. Are You Sure About That?

#testing

Всім доброго ранку. Сьогодні понеділок, шосте березня 2023 року.
Сьогодні хочу поділитися короткою статтею від Michael Bolton.

В ній він в черговий раз підіймає питання, чому в команді повіння бути або окремо взяті тест інженери або хоча б люди, що виконують таку роль. Бо більшість учасників процесу розробки (дизайнери, розробники, менеджери) зазвичай зосереджені на тільки на тому, щоб продукт працював. Працював успішно.
Але тестування працює з ризиками. Ризиками того, чому продукт чи проєкт може бути не успішний. Тому для тестування (за думкою автора) потрібен інший "тип мислення".

А що думаєте Ви? Чи тестування потребує іншого, деструктивного типу мислення, чи ні?

Цікава цитата:
"Quality is not a property of a product; it’s a set of many-to-many-to-many relationships between elements of the product, a variety of customers, and their different needs, desires, and preferences. Deciding that we have a well-checked product doesn’t mean that we’ve got a problem-free product, and doesn’t mark the end of testing. A well-checked product does provide a foundation for faster, more efficient, deeper testing that can happen in parallel with ongoing development.

To find hidden, subtle, intermittent, emergent problems in a product, you’ll want help from people who are estranged to some degree from builders’ focus. Finding the deep problems takes determination, time, effort, preparation, and a degree of disruption to the builders’ mindset.

To find problems without disrupting the developers’ focus, you’ll want someone attending full-time to trouble, problems and risk; someone who interacts with the product and gets experience with it before you inflict problems on your customers. You’ll want someone committed to learning and studying many things: the technology in and around the product; the problems that the product is intended to solve; the worlds of the users of the product who are outside the process of building it.

You’ll want testers. Or at least, a tester"

Postgres Architecture Explained

#engineering #databases #howitworks
Завжди цікаво як працюють різні системи "під капотом". Натрапив на таке цікаве відео про базу даних Postgres.