Test Engineering Notes – Telegram
Test Engineering Notes
3.8K subscribers
177 photos
2 videos
641 links
Україномовний канал про технічні аспекти тестування, розподілені системи, блокчейн та кібербезпеку.

Консультації з автоматизації, менторинг, проведення співбесід - @al8xr
Download Telegram
Простий репорт для Python та не тільки

#automation

Вчора я дізнався, що є такий цікавий проєкт як ctrf.io або ж Common Test Report Format.
Його творці пропонують легкий вид тестового репорту в форматі JSON, який потім можна відображати як частину сторінки тест рану на Github.

Oleksii Ostapov з QAMania вже навіть створив плагін pytest-common-test-report-json, що працює з CTRF.
Собі на проєкт я це інтегрував.
Все дуже швидко й просто - зайняло десь до години часу.

Почитати та подивитись, що це таке - можна в статті на DOU.
11👍5❤‍🔥1👏1
⚡️ 1 червня стартує практичний тренінг, на який я б 100% пішов (як-би було трішки більше вільного часу). Сподіваюсь все-таки доєднатись до наступних груп.

Це тренінг від Олександри Ковальової — Test Design Techniques: Black Box Testing.

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

Формат: прямі трансляції з можливістю переглянути відео.

Розклад: 1.06, 8.06 та 15.06 (10:00-15:00) — 3 заняття щосуботи протягом 3 тижнів.

🦄 Деталі та реєстрація отут => https://bit.ly/4e0xJDQ
5👏3👎1
Playwright interview questions ...

#automation #testing

Серія з двох статей, де Adrian Maciuc ділиться поганими та хорошими питаннями з Playwright.

Допоможе краще зрозуміти інструмент та бути готовим до подібних питань на співбесіді.
- Playwright Interview Questions that you are going to hate
- Playwright interview questions that you are going to love

А для СІНЬЙОРІВ автоматизаторів, чи тих, хто дуже хоче ними стати - маю ще більш цікаву новину.

Олександр Хотемський з каналу Hot Testing наступного місяця буде проводити майстерклас з Playwright. Тільки практика, ніякої теорії.
Деталі можна почитати тут! Доєднуйтесь. Це хороша можливість розібратись з фреймворком та наступного дня вже йти робити на ньому проєкти)))
10👍8❤‍🔥2
Forwarded from DOU | QA
Test Engineering Notes — Vol. 14: Про тестування сервісів в Meta, 10Х-інженерів та інтро в перфоманс-інженерію

Пустий S3-бакет може завдати збитків на тисячі доларів, як писати коміт-меседжи та свій форматер коду, метрики перфомансу фронтенду, розбір різних структур даних в Python — це та багато іншого читайте у новому QA-дайджесті 👉 https://dou.ua/goto/Nr2V
🔥122
Корисне з GitHub - 6

#github #selection

Доброго ранку! Сьогодні пропоную поглянути на декілька корисних підбірок з GitHub.

🛠 project-based-learning - для тих, хто вивчає мову програмування та не вистачає реальних задач для практики.
📚 The Algorithms - набір найвідоміших алгоритмів, що написані на різних мовах програмування.
🐧 The Art of Command Line - одна сторінка, що розповідає як працювати з командним рядком.
🆓 free-for.dev - величезний лист різних інструментів та сервісів, що допоможуть в розробці (усе безкоштовно).
🐍 30 Days of Python - покроковий туторіал з мови Python для тих, хто віддає перевагу самостійному навчанню. А тут - можна подивитись на купу корисних утиліт та невеличких програм (для натхнення).
🔥196
Знайти співробітників з найбільшою зарплатнею

#python #interview #coding

Всім привіт.
Сьогодні я прийшов до вас із задачею. Цю задачу можна вирішити для тренування, а можна навіть дати на співбесіді. Бо задача вкрай нескладна та можна швидко отримати рішення. Відповідь покаже рівень знання мови програмування.

Задача


"Уявімо, що ви працюєте в HR департаменті великої компанії. Вам прилетіла задача написати новий ендпоінт, який буде повертати всіх співробітників, що мають ЗП більше, ніж $100,000 на рік. Поверніть результат у вигляді набору з двох елементів - імені працівника та його зарплати".

Вхідні дані - це map такого вигляду:

employees = {'Alice': 100000, 'Bob': 99817, 'Carol': 122908, 'Frank': 88123, 'Eve': 93121}


Рішення буде наприклад таким:

top_earners = []  
for key, val in employees.items():
    if val >= 100000:
        top_earners.append((key,val))
print(top_earners)


Але існує трохи більш елегантне рішення, що показує можливості мови Python:

top_earners = [(k, v) for k, v in employees.items() if v >= 100000]
print(top_earners)


Або навіть:

top_earners = list(filter(lambda x: x[1] >= 100000, employees.items()))
print(top_earners)


Як бачите, на кожну проблему може бути декілька варіантів рішень. Але не забувайте PEP20 - "There should be one-- and preferably only one --obvious way to do it."

А як буде виглядати рішення на вашій улюбленій мові програмування?
👍193🔥2
Queueing - An interactive study of queueing strategies

#engineering

Сьогодні хочу поділитись, мабуть, найкращим візуальним поясненням навіщо нам черги в computer science та в Web технологіях.
🔥18👍2
Коротко про базові типи даних в Python

#python

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

Цілочисленні - int. Подивитись, який же найбільший integer можна з sys.maxsize
import sys

a = 100500
print(f"a = {a} та має тип {type(a)}")
print(f"максимальний розмір типу int: {sys.maxsize}")


Замість окремих float / double - Python має тільки float.
b = 123.456
print(f"b = {b} та має тип {type(b)}")


Крім float, є можливість працювати комплексними числами, а також з decimal / fraction.
c = 100 + 5j
print(f"c = {c} та має тип {type(c)}")

from decimal import Decimal
from fractions import Fraction

dec = Decimal("0.1")
print(f"dec = {dec} та має тип {type(dec)}")

frac = Fraction(1, 3)
print(f"frac = {frac} та має тип {type(frac)}")

Float дозволяє отримати трохи більш цікаві дані - такі як NaN чи нескінченність.
nan = float("nan")
print(f"nan = {nan} та має тип {type(nan)}")
inf = float("inf")
neg_inf = float("-inf")
print(f"inf = {inf} та має тип {type(inf)}")
print(f"neg_inf = {neg_inf} та має тип {type(neg_inf)}")


Якщо не подобається float, можна застосувати math. Результат той же.
import math
print(f"Те ж саме з math.inf - {math.inf == inf}")


Строки в Python бувають трьох типів - звичайні, сирі (raw) та форматовані.
single_quote_string = 'Hello, World!'
double_quote_string = "Hello, World!"
print(f"Python дозволяє строки з будь-якими лапками: {single_quote_string == double_quote_string}")

raw_string = r"\tRaw \n string"
well_done_string = "\tWell-done \n string"
print(f"raw_string = {raw_string}")
print(f"well_done_string = {well_done_string}")

formatted = f"{a} + {b} = {a + b}"
print(f"formatted = {formatted}")
print(f"formatted з фігурними дужками = {{{formatted}}}")


Результат в консолі:
a = 100500 та має тип <class 'int'>
максимальний розмір типу int: 9223372036854775807
b = 123.456 та має тип <class 'float'>
c = (100+5j) та має тип <class 'complex'>
dec = 0.1 та має тип <class 'decimal.Decimal'>
frac = 1/3 та має тип <class 'fractions.Fraction'>
nan = nan та має тип <class 'float'>
inf = inf та має тип <class 'float'>
neg_inf = -inf та має тип <class 'float'>
Те ж саме з math.inf - True
Python дозволяє строки з будь-якими лапками: True
raw_string = \tRaw \n string
well_done_string = Well-done
string
formatted = 100500 + 123.456 = 100623.456
formatted з фігурними дужками = {100500 + 123.456 = 100623.456}
13👍6
The curious case of the missing period

#engineering #bug

В цю пʼятницю пропоную до вашої уваги історію про те, які проблеми може спричинити відсутність однієї коми в листі (та при чому тут SMTP протокол).

Тим, хто тестує різного роду розсилки - це must-read!
👍15
Що таке system of systems?

#testing

Система систем відрізняється від складної системи.

Складна (complex) система, наприклад операційна система, може бути розроблена в одній організації.

Система систем (system of systems) - це набір різних систем та компонентів, що працюють разом, але розробляються різними командами (компаніями). Кожна з команд чи компаній має свої технічні, економічні та фінансові цілі.

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

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

Фактично, ми зустрічаємося з такими системами в роботі кожного дня. Бо сумніваюся, що у вас в компанії розробляють свої власні бази даних, брокери повідомлень та інші складні підсистеми.
23👍3
Магія пакування в 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


Весь код - тут.
11👍4🔥3
Про динамічність типізації

#python #engineering

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

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

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. Але найбільша свобода може бути причиною найбільшої "головної болі" та багів.
18👍5
Про пошук роботи

#interview

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

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

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

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

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

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

#engineering

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

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

#testing #automation

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

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

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

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

Приходьте. Впевнений, що буде цікаво.
👍19❤‍🔥22
📖 Про читабельність коду (автотестів)

#engineering #coding

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

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

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

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

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

💊Що ж робити?

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

Як зробити код більш читабельним?
- називайте змінні та методи максимально зрозуміло
- структуруйте код відповідно до його функцій
- дотримуйтесь принципів KISS / DRY там, де це доречно
- пишіть коментарі, якщо це потрібно (коментуйте "чому", а не "як")
- постійно покращуйте читабельність коду над яким ви працюєте.
13👍5
Test Engineering Notes — Vol. 15. Про flaky-тести в Uber, “хаос” в serverless та інтернет в Антарктиці

#testing #engineering #digest

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

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

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

#testing #coding

Знайшов тут пояснення чому розпіарене TDD (test-driven development) зазвичай не працює в реальному житті.
Я поки не зустрічав ще розробників, які б успішно практикували такий підхід. А ви?
💯16
Forwarded from Нотатки суворого QA 💛💙 (Artem Grygorenko)
🎉 Інтенсив - "Естімація задач по тестуванню"

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

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

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

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

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

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

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

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