Test Engineering Notes

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.

Запис доповіді - "What does it mean to test a blockchain?" #video #blockchain #testing Минулого місяці я брав участь у Quality Management Week від Soft Serve. На цій конференції я коротко розповів про те, що ж таке блокчейн, що там можна тестувати та що почитати, щоб почати розбиратися у цій сфері. Слайди доповіді (з купою корисних посилань) можна подивитися тут.

НЕТЕХНІЧНА робота у команді Можливо у когось з вас було таке на проєкті: ви приходите, починаєте працювати (писати тести чи автотести). З часом ви помічаєте, що робите багато додаткової організаційної роботи для команди: розмовляєте із сапортом та іншими командами, уточнюєте вимоги, проводите онбордінг, влаштовуєте різні сесії з knowledge sharing. Ця робота важлива, але ви самі не розвиваєтеся технічно. У статті від Tanya Reilly такий тип роботи називається - "Glue Work". Постає питання - чи потрібно взагалі робити таку роботу? Хто її повинен робити: ви чи лід команди? Та найголовніше - що робити, коли на performance review Вам кажуть "то що ви робили, це, звичайно класно - але підвищення не буде, бо вся ця робота не надто ТЕХНІЧНА". P.S. Після статті також постають питання - так куди ж рости тестувальнику? Які є варіанти? Швидко змінювати професію, чи розвиватися в тестуванні? Тестування - технічна професія чи ні? )

An End To End Playwright Testing Tutorial | Playwright With TypeScript #video #automation Знайшов досить непогане інтро відео з Playwright на Typescript. Воно довге (5 годин, Карл!) - можна багато чого перемотувати та дивитися на 2х швидкості. Але основні моменти вказані.

[Test Engineering Weekly] Bug-bounties, мікросервіси в 1998 році, property-based тестування UI та видалення prod бази #testing #engineering #weekly #digest Всім привіт! Це знову Олександр із підбіркою цікавих статей зі світу тестування та інженерії. Сьогодні у випуску: - якими бачили мікросервіси у 1998 році? - що буде, якщо видалити продакшн базу даних? - які проєкти створити для свого портфоліо? - як заробляти на пошуку взразливостей? - як localstack допомагає тестувати хмарну нфраструктуру локально? - що таке generative AI та Precision Time Protocol?