Test Engineering Notes

⚡️ Episode 33: The one where the test engineer explores holistic testing with Lisa Crispin

Багато хто читав "Agile Testing". Але після цих книг постає питання - чи можливо подивитись на тестування ще ширше? Чи потрібно тестувати лише до виходу в продакшн? Як щодо тестування моніторингу чи навіть ідей? Тут допоможе новий підхід - holistic testing. А що це таке та як реально його застосовувати ми поговорили з Лізою Кріспін, що й придумала цей підхід.

Дивитись та слухати:
🔸 Youtube
🔹 Spotify
🔸 Apple

А ще ви можете підтримати наш подкаст будь - яким донатом на Buy Me a Coffee ☕️

Окрім того, за різні підписки ви зможете отримати доступ до закритого чату подкасту, отримувати нові епізоди до самого виходу, а також є можливість присутності під час запису 😏

#testingminutes | @a_grygorenko | Test Engineering Notes

📚Що б почитати: Agile Testing

#testing #books #whattoread

Час від часу хочу ділитись з вами своїми книжковими рекомендаціями.

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

Це вже свого роду класика - книги за авторством Лізи Кріспін та Джанет Грегорі.
- 📕 Agile Testing
- 📕More Agile Testing

В цих книжках майже немає коду чи точних відповідей на питання. Але вони допоможуть тестувальнику поглянути на процеси тестування більш ширше.

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

Ви можете сказати: "так це старі книжки, діду!" Але то тільки на перший погляд.
Процеси та підходи за ці 10-15 років сильно не змінилися. (Деякі організації тільки-но починають шлях в agile)
Плюс - краще читати ці книжки, ніж починати з Савіна.

Новий погляд на "старий" продукт

#notes

Кожного дня ми вчимося. Ми вчимось, коли читаємо книги, дивимось відео, проходимо курси. Ми вчимося навіть коли читаємо пости в телеграмі.

Крім того, ми вчимося на роботі. Це може бути документація про нові фічі чи інструменти. Але також, ми можемо навчитись чогось нового навіть про ті фічі, які здавалося б вже протестовані.

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

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

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

Найголовніше - спробуйте поглянути на продукт з іншої сторони. Налаштуйте чи задеплойте продукт. Пройдіть якнайбільше сценаріїв користувачів. Дивіться на продукт з різних сторін.

Бо автотести не приносять гроші компанії. А робочий продукт - приносить.

Engineering Principles for Building Financial Systems

#engineering

Хороші поради для тих, хто створює (й тестує) фінансові системи. Базові штуки, та речі, на які варто звернути увагу.

⚡️ Епізод 32: Де тестувальник взаємодіє з SRE (разом з Романом Подолякою з Google)

Якби ви знали слухачі, що роблять SRE вночі ... Хто такі SRE інженери? Чим вони займаються? Як вони забезпечують надійність систем в Google? Та найцікавіше - чи є тестувальники в Google? Про все це сьогодні в епізоді ми поговоримо з Романом Подолякою.

Дивитись та слухати:
🔸 Youtube
🔹 Spotify
🔸 Apple

А ще ви можете підтримати наш подкаст будь - яким донатом на Buy Me a Coffee ☕️

Окрім того, за різні підписки ви зможете отримати доступ до закритого чату подкасту, отримувати нові епізоди до самого виходу, а також є можливість присутності під час запису 😏

#testingminutes | @a_grygorenko | Test Engineering Notes

Щоб добре працювати, треба добре відпочивати. Це мені сказали друзі з DOU і попросили гукнути вас на DOU Day Picnic.

Це офлайн-подія, де найбільша IT-спільнота хоче зібрати найбільшу кількість айтівців. Обіцяють влаштувати круту нетворкінг-паті, зі смачною їжею, майстеркласами, зонами пасивного та активного відпочинку, просторами для дітей, панельними дискусіями, стендапами й концертом.

Ще з важливого: 100% вартості квитків йдуть на збір DOU та “Повернись живим”. Ось так можна і задонатити, і взяти квиток на пікнік.

https://dou.ua/goto/I0PB

Ось що буває, коли образив штучний інтелект ...

Software Testing as a Social Science (Caner) - частина 2

#testing #caner

В першій частині нотаток зі слайдів Кема Канера ми розбирались з тим, що таке тестування та як воно повʼязане із соціальними науками. Сьогодні ми продовжимо переглядати слайди й подивимось на важливість контексту, сценаріїї та складнощі у виявленні помилок.

Про техніки та контекст

Техніка тестування - це рецепт по створенню тестів. Сюди входять тестування домену, ризиків, сценаріїв, та ін. Канер зазначає, що існує близько 150! різних технік. (Варто пошукати той перелік технік. Чи це тільки маркетинговий трюк?)

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

(Тут варто нагадати, що Кем Канер - один з творців "школи" context-driven software testing.)

Про тестування на основі сценаріїв

Ідеальний сценарій базується на історії того, як програма використовується, включаючи мотивацію користувача. Історія повинна мотивувати зацікавлену сторону в тому, щоб виправити помилку в сценарії. Історія має бути реалістичною та використовувати складне середовище чи набір даних. Чим складніше історія, тим легше оцінити результат сценарію.

Звідки брати ідеї створення сценаріїв?
- Згадайте життєвий цикл обʼєктів в системі
- Запишіть та проаналізуйте можливих користувачів та їх мотивацію
- Перелічіть список можливих та неможливих системних подій
- Взнайте в користувача про типові кейси взаємодії з продуктом
- Подивіться на подібні системи в конкурентів (а також звернення користувачів з проблемами)
- Шукайте послідовності: люди (або система) зазвичай виконують завдання X у заданому порядку. Які найпоширеніші послідовності завдань у досягненні X?

(Хтось взагалі користується scenario-based testing усвідомлено?)

Виявляти помилки - не просто.

Хоча розробник зазвичай знаходить більшість багів, тестер шукає помилки в "сліпих зонах" розробників. Щоб тестувати більш ефективно, треба базуватись на теорії того, чому люди роблять помилки.

Існує феномен "ненавмисної сліпоти" - люди (часто) не бачать того, на що не звертають уваги. Програми ж (завжди) не бачать того, чого їм сказали не бачити. Це призводить до появи помилок, що не відтворюються.

Навіть, якщо ми покрили весь функціонал тестами, додаткові побічні ефекти (дані, ресурси та час) стають новими причинами для проявлення принципу Гейзенберга. (Взагалі принцип Гейзенберга - цікава тема. Знайшов декілька дослідницьких робіт. Частково, це повʼязане із flaky тестами).

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

Саме тому важливо ретельно описувати знайдені помилки - тим самим показуючи ефективність тестера. Зверніть увагу на технічну якість опису, імпакт аналіз, переконливість та зрозумілість.

Цікаво, чому Канер вимірює ефективність тестувальника у вмінні описати баг. Чи згодні ви з таким твердженням?

На цьому все. До нових зустрічей!

Software Testing as a Social Science (Caner) - частина 1

#testing

В одній з книжок я знайшов посилання на презентацію Кема Канера з тестування (2006 року). Було дуже цікаво прочитати слайди. Наче й все зрозуміло, але подача інформації зовсім інша - відрізняється від сучасних книжок та стандартів. Наведу декілька нотаток зі слайдів.

Про соціальні науки

Тестування більше схоже мікс психології, економіки, бізнес менеджменту - ніж на програмування.

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

Про програми

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

Програма - це спілкування між декількома людьми та компʼютерами, що розподілені в просторі та часі, що містить інструкції, які можуть бути виконані компʼютером. Мета програми - надати користь зацікавленим сторонам.

Про тестування та помилки

"Quality is value to some person" (c) Jerry Weinberg

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

"Традиційний" погляд визначає тестування лише як функціональне - що фокусується на перевірці програми на відповідність специфікації. Цей концепт легко зрозуміти, легко навчити. Але - за таке тестування мало платять. "Традиційне тестування" - фокусується на пошуку помилок. Але помилка може бути НЕ в коді та може бути НЕ функціональною. Такі підходи працювали при розробці десь в 80-х.

"A bug is something that bugs somebody" (c) James Bach

Помилка в софті - це атрибут програмного продукту, що зменшує його цінність для зацікавленої сторони.

Тестування програмного забезпечення - це технічне розслідування, що проводиться для надання зацікавленій стороні повʼязаної з якістю інформації про продукт. Це наче в серіалі CSI: є багато інструментів, процедур, джерел доказів. Слідчий повинен обрати, які докази вивчати, щоб віднайти якнайбільше корисної інформації за найкоротший проміжок часу.

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

Продовження - у наступному дописі.

⚡️ Епізод 31: Де тестувальник думає, чи можна працювати без нього / неї

Всім привіт! Ми повертаємось з новим, четвертим сезоном!

Чи можна випускати софт без тестування? Чи виживуть команди та продукти, якщо в них не буде тестувальників? Як боротися зі страхом стати непотрібним - коли всі настільки класно тестують без вас? Ці питання Артем та Олександр будуть обговорювати в черговому випуску подкасту.

Для тих, хто полюбляє слухати:
🔸 Youtube
🔹 Spotify Podcast
🔸 Apple Podcast

А ще ви можете підтримати наш подкаст будь - яким донатом на Buy Me a Coffee ☕️

Окрім того, за різні підписки ви зможете отримати доступ до закритого чату подкасту, отримувати нові епізоди до самого виходу, а також є можливість присутності під час запису 😏

#testingminutes | @a_grygorenko | Test Engineering Notes

Joining Strings in Python: A "Huh" Moment

#coding #python

Невелика стаття про те, що краще використовувати для зʼєднання великої кількості строк в Python - генератори чи list comprehensions? Що швидше?

🎉 Інтенсив - "Естімація задач по тестуванню"

Друзі, запрошую вас приєднатися до мого нового інтенсиву, де ми разом опануємо мистецтво оцінювання задач у тестуванні!

📅 Коли?
29 Липня та 5 Серпня о 19:00 (2 заняття по 1.5-2 години)

💡 Про що?
Знання, як точно оцінити час, зусилля, ресурси та бюджет для тестування продукту, є одним із ключових для успіху будь-якого проекту. Це не тільки допоможе вам виграти битву з дедлайнами, але й стане вашою перевагою у світі QA.

🚀 Що ви отримаєте?
- навчимося використовувати різні підходи до оцінювання задач у різних проектах
- розберемо основні терміни та чому оцінювання важливе
- покращимо навички оцінювання задач
- систематизуємо знання щодо оцінювання в різних компаніях і проектах

Під час інтенсиву ви зможете визначати ключові параметри оцінювання та створювати детальні плани задач, що стане основою для подальшого тестування. Також дізнаємося, на чому тестувальник повинен зосередити свою увагу в роботі і як пріоритезувати задачі.

⚠️ Місця обмежено!
Забирайте своє 😉

🔗 Реєстрація тут

До зустрічі на інтенсиві!

TDD CANNOT Work

#testing #coding

Знайшов тут пояснення чому розпіарене TDD (test-driven development) зазвичай не працює в реальному житті.
Я поки не зустрічав ще розробників, які б успішно практикували такий підхід. А ви?

Test Engineering Notes — Vol. 15. Про flaky-тести в Uber, “хаос” в serverless та інтернет в Антарктиці

#testing #engineering #digest

Підбірка статей за червень вже готова.

TLDR, або Що у випуску

- як Uber бореться з flaky-тестами та як в Zalando тестують на мобілках;
- наскільки успішно великі компанії застосовують ШІ в роботі інженерів;
- новий інструмент для тестування мобільних девайсів від Google;
- як зробити chaos engineering для ваших serverless-систем;
- зрозуміле пояснення контрактних тестів;
- як працюють токени, cookie та черги в сучасних системах;
- багато іншого...

📖 Про читабельність коду (автотестів)

#engineering #coding

Юніт тести можуть чітко показати чи правильно працює ваш код. А юніт тестів на читабельність поки що не вигадали.

Тому дуже важливо (особливо для мідлів та сіньйорів) - писати код максимально зрозуміло для себе й інших.
Під кодом я маю на увазі код ваших автотестів та солюшенів.

🌀Про "спіраль незрозумілого коду"

Якщо читабельність коду погана - можна потрапити в "спіраль незрозумілого коду". Що це таке? Розберемося на прикладі.

Уявімо, що інженеру - автоматизатору, треба зробити правки в коді тесту, пейджі чи утилітного методу. Читабельність коду дуже низька. Він чи вона витрачає купу часу щоб хоча б трохи зрозуміти, що той код робить.
Але код до кінця зрозуміти не вдалося. Замість покращення читабельності, цей автоматизатор робить мінімально можливі правки, щоб пофіксити тест. Такі правки призводять до ще менш читабельного коду. Наступна людина, що буде дивитись на "підправлений код" витратить ще більше часу на те, щоб розібратись в ньому. А може - здасться, видалить той незрозумілий шматок та перепише усе заново.

💊Що ж робити?

Як протестувати ваш код на читабельність? Викласти його на код ревʼю!
Якщо інша людина зрозуміє його - це вже дуже класно! Якщо його зрозуміє людина з іншої команди - ще краще!

Як зробити код більш читабельним?
- називайте змінні та методи максимально зрозуміло
- структуруйте код відповідно до його функцій
- дотримуйтесь принципів KISS / DRY там, де це доречно
- пишіть коментарі, якщо це потрібно (коментуйте "чому", а не "як")
- постійно покращуйте читабельність коду над яким ви працюєте.

Про сертифікацію автоматизаторів

#testing #automation

Тут нещодавно Джеймс Бах (той, який разом з Майклом Болтоном робить "Rapid Software Testing") розкритикував вирізки з матеріалів ISTQB для автоматизаторів. "Воно не про тестування, не про стратегію, та все інше" - говорить Бах. Та він ... правий.

Я сертифікат такий не отримував, але читав рекомендовану книжку - "Test Automation Fundamentals".
Книжка мені сподобалася. В ній я побачив перші спроби подачі знань з автоматизації на більш абстрактному рівні. Тобто так, що підійде будь-якому інженеру майже в будь-якому проєкті.

Але питання залишається - що взагалі в тому сілабусі з автоматизації? Чи варто взагалі отримувати той сертифікат?
Та найголовніше - які зміни трапились з цим сертифікатом після останніх нещодавних оновлень.

Відповідь на це питання можна отримати - й доволі швидко. Для цього треба зареєструватись на безкоштовний вебінар.
Хто розкаже? Олександра Ковальова та Артур Шевченко.
А Коли то буде? 3 липня о 19:00

Приходьте. Впевнений, що буде цікаво.

Engineering for Slow Internet

#engineering

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

Пінгвінів тут не буде, але будуть деякі питання до розробників: чому навіть простий сайт тягне за собою десятки мегабайт того джаваскріпту?

Про пошук роботи

#interview

Для багатьох людей пошук роботи = пошук вакансії на DOU/Djinni/Linkedin та подання на неї.
Але чим вище у вас позиція та років досвіду, тим менше ефективності від такого пошуку.

Що ще можна зробити, щоб підвищити свої шанси знайти роботу?

Прокачайте свій Linkedin профіль (допоможіть рекрутерам знайти Вас)

- Встановіть чіткий headline: в чому ви кращі, в чому ви спеціалізуєтесь?
- Додайте опис кожної роботи та що конкретно ви там робили (можна написати навіть більше, ніж у вашому CV)
- Застосовуйте ключові слова в секції summary
- Приберіть нерелевантний досвід роботи

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

А щоб оцінити свій рівень поточної ЗП - можна прийняти участь в літньому опитуванні від DOU.

Про динамічність типізації

#python #engineering

Коли я ще писав на Java, я був в курсі, що існують статично-типізовані та динамічно-типізовані мови програмування.

В динамічно-типізованих мовах, як-от Python чи Javascript, тип перевіряється під час запуску.
Тому ніхто не забороняє писати щось типу такого:

x = 10       # x - integer
x = "Hello"  # x - string

Можна навіть написати функцію, яка буде працювати з різними типами

def add(a, b):
    return a + b

print(add(5, 10))        # Працює з integers
print(add("Hello, ", "Alex!"))  # Працює з strings

В статично-типізованих мовах (C++, Java, C#) компілятор перевіряє правильність типів ще на етапі компіляції (до запуску коду).
Тому компілятор буде скаржитись як на етапі визначення змінної

int x = 10;        // x - integer
x = "Alex";       // Compile-time error: incompatible types

так і при роботі з функціями:

public int add(int a, int b) {
    return a + b;
}

public static void main(String[] args) {
    System.out.println(add(5, 10));       // Works with integers
    System.out.println(add("Hello, ", "Alex!")); // Compile-time error
}

Погляд під іншим кутом

Протягом якогось часу я просто думав, що Python динамічно-типізований так само, як JS та не переймався.
Але в системі координат типізованості є ще одна вісь. Мова можна бути зі слабкою (weak) та сильною (strong) типізацією.

Python - мова з сильною типізацією. Інтерпретатор все-таки слідкує за типами та може генерувати TypeError у випадках жорсткого порушення правил.

a = "Hello"
b = 5
c = a + b  # Спричинить TypeError: бо додавати можемо тільки str (не "int")

d = a + str(b) # Python вимагає явного перетворення даних
print(d) # Hello5

Те ж саме з функціями:

def add_numbers(a: int, b: int) -> int:
    return a + b

result = add_numbers(3, "4")  # Знову буде TypeError: unsupported operand type(s) for +: 'int' and 'str'

JS - це мова зі слабкою типізацією.
Компілятор дозволяє як завгодно працювати з типами та багато чого робить "під капотом" - неявно.
Саме через ці неявні перетворення в JS так багато "магії".

// звичайні динамічні типи
var a = 10;
a = "Now I'm a string";  // Тип a був змінений з number на string
console.log(a);  // Output: Now I'm a string

// JS робить магію
var a = "Hello";
var b = 5;
var c = a + b;  // Помилки не буде. JavaScript спробує сконвертувати b в строку та виконати конкатенацію
console.log(c);  // Hello5

// Інший приклад
var e = 1;
var f = "2";
var g = e - f;  // JavaScript робить число з f та віднімає
console.log(g);  // Output: -1

Висновок

Хоч Python всі називають мовою, де можна як завгодно працювати з типами, це не так. Все-таки є в Python є деякі обмеження (може навіть на краще).
Найбільша свобода все-таки в JS. Але найбільша свобода може бути причиною найбільшої "головної болі" та багів.

Магія пакування в Python

#python

Розпакування - то одна з найцікавіших "фішок" мови Python.

Якщо у вас є tuple - то можна звичайно отримати доступ до елементів через індекс:

p = (4, 5)
first = p[0]
second = p[1]

Але можна - "розпакувати" tuple одразу в дві змінні

unpacked_first, unpacked_second = p

Можна розпаковувати більш складні структури:

data = ['ACME', 50, 91.1, (2024, 06, 18)]
name, shares, price, date = data


* дозволяє вказати - "а все інше запиши сюди 😁". Наприклад тут - в phone_numbers

record = ('Alex', 'alex@example.com', '123-456-7890', '124-456-0000')
name, email, *phone_numbers = record

Подібним чином можна розбирати строки (якщо ви точно впевнені в їх структурі):

line = 'nobody:*:-2:-2:Unprivileged User:/var/empty:/usr/bin/false'
uname, *fields, homedir, sh = line.split(':')


_ дозволяє вказати, що ця частина даних несуттєва. Наприклад, отримати тільки імʼя та рік:

record = ('ACME', 50, 123.45, (12, 18, 2012))
name, *_, (*_, year) = record

З пакуванням звʼязаний відома задачка про те, як поміняти дві змінні місцями

a = 1
b = 2
a, b = b, a

Також, за допомогою рекурсії та розпакування можна писати такі функції

def sum(items):
    head, *tail = items
    return head + sum(tail) if tail else head

Як завжди - результати виконання кожного фрагменту:

first: 4, second: 5
unpacked_first: 4, unpacked_second: 5
name: ACME, shares: 50, price: 91.1, date: (2012, 12, 21)
name: Alex, email: alex@example.com, phone_numbers: ['123-456-7890', '124-456-0000']
uname: nobody, homedir: /var/empty, sh: /usr/bin/false
name: ACME, year: 2012
a: 2, b: 1
sum([1, 2, 3, 4, 5]) = 15

Весь код - тут.