[Test Engineering Weekly] Bug-bounties, мікросервіси в 1998 році, property-based тестування UI та видалення prod бази

#testing #engineering #weekly #digest

Всім привіт!

Це знову Олександр із підбіркою цікавих статей зі світу тестування та інженерії.

Сьогодні у випуску:
- якими бачили мікросервіси у 1998 році?
- що буде, якщо видалити продакшн базу даних?
- які проєкти створити для свого портфоліо?
- як заробляти на пошуку вразливостей?
- як localstack допомагає тестувати хмарну нфраструктуру локально?
- що таке generative AI та Precision Time Protocol?

An End To End Playwright Testing Tutorial | Playwright With TypeScript

#video #automation

Знайшов досить непогане інтро відео з Playwright на Typenoscript. Воно довге (5 годин, Карл!) - можна багато чого перемотувати та дивитися на 2х швидкості. Але основні моменти вказані.

Далі вже - вивчати документацію та поглиблювати знання.

P.S. Typenoscript мені навіть сподобався (на перший погляд). Такий собі JS здорової людини.

НЕТЕХНІЧНА робота у команді

#management #career

Можливо у когось з вас було таке на проєкті: ви приходите, починаєте працювати (писати тести чи автотести).

З часом ви помічаєте, що робите багато додаткової організаційної роботи для команди: розмовляєте із сапортом та іншими командами, уточнюєте вимоги, проводите онбордінг, влаштовуєте різні сесії з knowledge sharing.

Ця робота важлива, але ви самі не розвиваєтеся технічно. У статті від Tanya Reilly такий тип роботи називається - "Glue Work".

Постає питання - чи потрібно взагалі робити таку роботу? Хто її повинен робити: ви чи лід команди?

Та найголовніше - що робити, коли на performance review Вам кажуть "то що ви робили, це, звичайно класно - але підвищення не буде, бо вся ця робота не надто ТЕХНІЧНА".

P.S. Після статті також постають питання - так куди ж рости тестувальнику? Які є варіанти? Швидко змінювати професію, чи розвиватися в тестуванні?

Тестування - технічна професія чи ні? )

Запис доповіді - "What does it mean to test a blockchain?"

#video #blockchain #testing

Минулого місяця, я брав участь у Quality Management Week від Soft Serve.

На цій конференції я коротко розповів про те, що ж таке блокчейн, що там можна тестувати та що почитати, щоб почати розбиратися у цій сфері.

Слайди доповіді (з купою корисних посилань) можна подивитися тут.

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

[Test Engineering Weekly] Практика автоматизації, приклади фреймворку, mutation testing та рекомендовані книжки на зимові канікули

#testing #engineering #weekly #digest

Привіт! На зв'язку Олександр. А це значить, настав час почитати про тестування та інші цікаві штуки.

Сьогодні у випуску:
- як правильно відповідати на питання "чому ти не знайшов цей баг?"
- де практикувати знання з автоматизації?
- з чого складається типовий фреймворк?
- що таке mutation testing?
- як змінити погане відношення до тестування в команді?
- що почитати довгими зимовими вечорами (рекомандації Gergely Orosz)
- у чому різниця між GraphQL та gRPC?
- та інше...

What's the career path of a tester?

#testing

Чому, коли ми говоримо про кар'єрний ріст тестувальника - у багатьох випадках ми маємо на увазі перехід в інші професії: в розробники, менеджери, бізнес аналітики, девопси, та ін.
Які реальні перспективи розвитку та росту (а також можливі шляхи) є саме в тестуванні?

Цими питаннями я задався після прочитання статті What's the career path of a tester?. В ній автор розмірковує про різні шляхи розвитку у IT.
Але найголовніше - він пропонує своє бачення майбутнього тестувальника після 5-10 років роботи в індустрії.

Додатково - опис компетенцій можна знайти тут. Автор пропонує разом подумати та створити повний опис шляхів розвитку.

Рекомендація книжок для тих, хто вивчає DevOps практики (від Alex Yates)

Augmenting QA processes with OpenAI

#testing

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

Більше - у статті про OpenAI у тестуванні.

Systems at Scale 2019 - Continuous Deployment at Facebook Scale

#automation #deployment #video

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

Платна підписка на medium

#testing

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

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

Продовжую дослідження.

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

https://youtu.be/bGhIJqmzN4M

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

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

З Новим Роком, друзі! Бажаю нам в новому році тільки перемоги! Перемоги кожному - окрему та всім нам - разом!

Дякую, що читаєте! Побачимось вже у наступному році!
Слава Україні! Та величезне дякую ЗСУ!

Перша цього року добірка цікавих новин для фахівців з тестування.

Окрім прогнозів на новий рік, маємо поради для професійного розвитку і кар'єрних змін, особливості різних видів тестів, роботи зі StackOverflow та інше.

https://dou.ua/goto/DU1S

#Digest

Читаємо електронні книжки з Amazon (якщо немає Kindle читалки)

#books

На Новий Рік (та навіть дещо раніше) я отримав у подарунок декілька цікавих книжок в електронному форматі (для Kindle).
Kindle читалка є тільки у дружини. Але кожного разу брати читати книгу в неї - не зовсім зручно.

Пошукавши трохи, я знайшов Kindle Reader для Android та його Web версію.

Плюси:
- Можна читати книгу як на телефоні, так і у веб-браузері.
- Прогрес автоматично сінхронізується між девайсами. (Між читалкою також).
- Є вбудований словник, вікіпедія, перекладач та нотатник. Це не є чимось екстраордінарним. Але воно працює дуже приємно та зручно.
- В самій аплікації можна легко подитивитися книжки, дуже схожі на ту, що ти читаєш зараз.
- Зручно переглядати обрані фрагменти з книг у веб версії.
- Куплені книги автоматично додаються у вашу бібліотеку на девайсі. До того ж - можна ділитися бібліотекою з членами сім’ї.

Мінуси:
- Читати технічну літературу з конспектом (роблю так практично завжди) мені не сподобалося. Копіювати текст та картинки одразу з книги неможливо. Можна вносити в обране - а потім копіювати (тільки текст).

Отже Kindle Reader - це для тих, хто хоче купувати книги на Amazon. І тільки для нетехнічної літератури.
Для всього іншого - є багато інших читалок та програм.

P.S. Amazon не платив мені за огляд 🙂

Most software teams do not need dedicated testers anymore.

#testing

В тестувальницьких колах західного світу зараз горить від статті Алана Пейджа.

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

У статті Алан наводить дуже багато пояснень своєму твердженню.

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

Та найголовніше:
Take a moment and answer this: If the developers on your team wrote the vast majority of test automation and if you had a way to know if your software was solving customer problems, would your team need dedicated testers?

А що думаєте з цього приводу ви?

A History of Automated Testing

#history

Сьогодні я пропоную до Вашої уваги дуже велику та змістовну статтю від одного з моїх найулюбленіших технічних блогерів - Jeff Nyman.

Цей пост немов з підручника історії чи енциклопедії!

У пості автор розповідає про історію розвитку того, що зараз ми можемо назвати automated testing.
В залежності від розвитку технологій та людства під автоматизацією тестування люди розуміли зовсім різні (а у чомусь незвичні для сучасних інженерів) речі.

До того, у статті ви знайдете відповіді на такі питання:

- Якими були перші комп’ютери та для чого вони вели обчислення?
- Коли з’явилися перші автотестери?
- Як автоматизація пов’язана з освітою?
- Скільки разів за майже століття люди чули фразу “автоматизація замінить усіх (особливо тестувальників)”?
- У чому схожі вчителі та тестувальники?
- Та чому тестувальникам потрібно доводити та роз’ясняти свою важливість?

Стаття дійсно варта Вашого часу - як мінімум вона дуже цікава.

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

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