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

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

Автоматизація за межами UI та API

#testing #automation

Писати автотести на рівні UI та API не є чимось новим для тест інженерів. В інтернетах написані вже сотні чи не тисячі туторіалів на ці теми. Крім того, є курси (наприклад Test Automation University) та інструменти для полегшення життя.

Але як щодо чогось менш розповсюдженого?

Як тестувати бібліотеки (наприклад Java бібліотеки)?
Які інструменти є для автоматизації тестування утиліт командної стрічки?
Як автоматизовувати ААА ігри?

Може хтось знає? Діліться інструментами та статтями у коментарях.

Software Engineering at Google

#engineering #book

Багато хто знає, або читав, книгу "How Google Tests Software". Книга вона вже доволі стара. Хоча підходи, описані у ній - універсальні та поза часом.

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

Але мій допис трохи не про це.
Зараз є можливість зекономити 30 - 40 доларів та прочитати цю книгу безкоштовно - ось тут.

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

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 роком.