Test Engineering Notes

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

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 розробників. Тести не входять у кінцевий продукт - тому вони не будуть дуже переживати через те, що їх код зламає якусь важливу фічу на продакшені. """ Ось такі тези були в книзі, написаній у далекому 2012 році. А що ми маємо зараз? Чи вмерло тестування у вигляді окремих SET інженерів? Чи є вони у вас на проєкті?

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

📅 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

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.

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

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

Автоматизація за межами UI та API #testing #automation Писати автотести на рівні UI та API не є чимось новим для тест інженерів. В інтернетах написані вже сотні чи не тисячі туторіалів на ці теми. Крім того, є курси (наприклад Test Automation University) та інструменти для полегшення життя. Але як щодо чогось менш розповсюдженого? Як тестувати бібліотеки (наприклад Java бібліотеки)? Які інструменти є для автоматизації тестування утиліт командної стрічки? Як автоматизовувати ААА ігри? Може хтось знає? Діліться інструментами та статтями у коментарях.

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 - тестувальник допомагає перевірити софт з функціональної сторони, а також - на основі свого досвіду. Бесперечно тільки справжні користувачі зможуть сказати (можливо непрямим методом, а метриками) чи подобається їм фіча та як їм зручно нею користуватися.

Playwright vs Selenium Speed Comparison #testing #automation Натрапив тут на статтю, у якій порівнюються модний Playwright та старий добрий Selenium Webdriver. І виявляється, Webdriver швидший за Playwright! І це все після відео від Ярослава на цю тему. Там результати діаметрально протилежні. То ж де правда? Хто помиляється? :) Думаю, що треба буде й самому зробити такий бенчмарк коли буде час). Чи може хтось з вас, мої читачі, вже має такі результати?

2022. Підсумки. Всім привіт. Олександр на зв’язку. Новий рік вже зовсім скоро. Але 2022й назавжди залишиться в нашій пам’яті. В нас самих. Трішки підсумків: 1. Канал Test Engineering Notes виріс до 1100 учасників. 2. Я почав більш-менш постійно приймати участь у подкасті “Не баг, а фіча”. 3. Доволі активно я писав як в канал, так і в блог. А також на DOU :) Мій топ технічних книжок у 2022 році: - Team Guide to Software Testability - Effective Software Testing - Software Testing: A Craftsman's Approach - The Coding Career Handbook - Staff Engineer: Leadership Beyond the Management Track З нетехнічних книжок хотів би виділити “Брама Європи” Сергія Плохія. Треба мати хист, щоб описувати історію України так цікаво та захоплююче. Про деякі книги я писав окремі огляди. Їх можна знайти у каналі за тегом #books Для тих, у кого буде трохи вільного часу у ці святкові дні - та не буде чим зайнятися - я підготував черговий дайджест цікавих статей зі світу тестування та інженерних практик. З Новим Роком, друзі! Бажаю нам в новому році тільки перемоги! Перемоги кожному - окрему та всім нам - разом! Дякую, що читаєте! Побачимось вже у наступному році! Слава Україні! Та величезне дякую ЗСУ!

Всіх вітаю 🥳 Вийшов 5й новорічний випуск нашого подкасту “Не баг, а фіча” де ми обговорили як це працювати у блекаути та підвели деякі підсумки року https://youtu.be/bGhIJqmzN4M

Платна підписка на medium #testing Перше враження: круто, можна фільтрувати статті по темам. Підписуватись на окремі теми. Багато статей, купа цікавих людей. Читати - не перечитати! Пройшло 3-5 днів: більшість статей з тестування для рівня trainee, junior. Максимум middle. Щоб дістатися до хоча б трохи цікавих статей - треба перерити дуже багато посереднього контенту. Але є дійсно хороші пости. Небагато нового з QA, але по блокчейну та розподіленим системам є що почитати. Продовжую дослідження.

Systems @Scale 2019 - Continuous Deployment at Facebook Scale #automation #deployment Для тих, кому цікаво побачити реліз процес та інструменти у Facebook - маю дуже цікаву та невеличку доповідь.

Augmenting QA processes with OpenAI #testing Мануальні тестувальники скоро стануть не потрібні))) Бо штучний інтелект може писати acceptance критерії, тести та навіть автотести. Здається неймовірним, але це вже працює. Більше - у статті про OpenAI у тестуванні.

[Test Engineering Weekly] Практика автоматизації, приклади фреймворку, mutation testing та рекомендовані книжки на зимові канікули #testing #engineering #weekly #digest Привіт! На зв'язку Олександр. А це значить, настав час почитати про тестування та інші цікаві штуки. Сьогодні у випуску: - як правильно відповідати на питання "чому ти не знайшов цей баг?" - де практикувати знання з автоматизації? - з чого складається типовий фреймворк? - що таке mutation testing? - як змінити погане відношення до тестування в команді? - що почитати довгими зимовими вечорами (рекомандації Gergely Orosz) - у чому різниця між GraphQL та gRPC? - та інше...

Гарна візуалізація - варта Вашої уваги. Для тих, хто тільки вивчає Git. Та й для тих, хто хоче розібратися із ним трохи більше, ніж пара кліків на UI.