Test Engineering Notes

⚡️ Епізод 21: Де тестувальник вивчає сучасні "школи" тестування

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

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

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

#testingminutes | @a_grygorenko | Test Engineering Notes

Питання про QA Vision

#testing #leadership

Читаю зараз одну книжку з тестування. (Обрав її досить випадково, але виявилась доволі цікавою).
Коли в книзі розповідають про те, як краще формулювати vision тестування, наводять наступні приклади.

Ось так не рекомендують писати:
"To ensure that our customers and users receive software that meets or exceeds their expectations of quality."

А ось так - набагато краще:
"To help the software development and maintenance teams deliver software that meets or exceeds our customers’ and users’ expectations of quality."

Питання - чому перший варіант гірший, ніж другий?

Де взяти практичні навички з програмування?

#automation #engineering

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

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

Наведу декілька збірок та сервісів, де можна знайти безліч ідей для втілення. Від найпростіших до створення аналогів відомих вебсайтів чи додатків.
- project-based-learning
- build-your-own-x
- projectbook
- codecrafters.io
- devchallenges.io

Про якісне виконання роботи

#testing

Почну з історії.

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

А тепер питання - чи винен лікар, якщо людина проігнорує призначення та не буде лікуватися взагалі?

Буде лікуватись людина чи ні - лікар проконтролювати не може. (За винятком, коли лікування проходить саме в лікарні - стаціонарі).
То ж якщо людина свідомо обирає НЕ лікуватись - то вона сама бере на себе відповідальність за можливі ризики для свого здоров'я.
В такому випадку, людина не може сказати, що лікар "не забезпечив якісне лікування".

Те саме й в розробці софту.

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

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

Навіщо ми тестуємо?

#testing

Головна мета тестування - це дати команді (менеджменту) інформацію про поточний стан продукту (білду) та про можливі ризики при релізі.
Як потім цією інформацію користуються - це вже питання менеджменту.

З автотестами - те ж саме. Ваші тестові репорти повинні "розповідати історію" - тобто подавати інформацію про стан продукту на мові, зрозумілій менеджменту. Якщо це складно - подумайте, як переробити ці репорти або ж додати якийсь зведений окремий репорт тільки для high-level менеджерів.

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

Тож тестування - це не тільки про "проходити тести" чи "писати автотести". Це - про дослідження, виявлення проблем та надання інформації. Саме тої інформації, що потрібна, а також вчасно.

Запис - Що таке блокчейн та як його тестувати?

#testing #blockchain

В цю п'ятницю хочу поділитись записом мого минулорічного виступу на QA Party Hard у Львові.
Про блокчейн, що воно таке, як його тестувати та чи потрібно воно вам взагалі.

Про історію команд в консолі

#cmd #linux

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

1. Подивитись минулі команди стрілочкою вгору (але то буває надто довго)

2. Подивитись історію за допомогою команди history

history
...
 2000  ls
 2001  cat contractlog.json 
 2002  ls
 2003  ll
 2004  history

// виконати команду знову - !N, де N - номер команди зі списку
!2001

// шукати в історії команди також можливо
history | grep search

Важливо. Кільксть збережених команди в історії обмежена. Конфігурувати цю кількість можна за допомогою змінної HISTSIZE=1000.

3. Виконати пошук команди за допомогою reverse search
- Натисніть Ctrl+R в консолі
- Введіть частину команди
- Оберіть те, що потрібно та натисніть Enter для запуску. Або ж стрілку вправо для того, щоб внести правки в команду
- Якщо ж знайшли не те - повторіть пошук знову з Ctrl+R

 2001  cat contractlog.json 
 2002  ls
 2003  ll
 2004  history
(reverse-i-search)`cont': cat contractlog.json
cat contractlog.json

Можна шукати за допомогою інших інструментів, але про них - наступного разу.

Channel photo updated

Нотатки з Docker на кожен день

#testing #tools

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

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

// почистити кеш докера
docker kill $(docker ps -q)
docker rmi $(docker images -a --filter=dangling=true -q)
docker rm $(docker ps --filter=status=exited --filter=status=created -q)
docker rmi $(docker images -a -q)
docker volume rm $(docker volume ls)
docker system prune

// копіювати файл з локальної машини на контейнер
docker cp /path/to/local/file.txt my_container:/path/in/container/file.txt

// копіювати файл (або теку) з контейнеру на вашу локальну машину
docker cp my_container:/path/in/container/file.txt /path/to/local/file.txt

// запустити командну стрічку на контейнері
docker exec -it my_container bash

// подитивитись логи контейнеру
docker logs --follow container_name

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

А які улюблені команди чи лайфхаки з Docker маєте ви?

Про задачі на співбесіді автоматизатора

#testing #automation #interview

В одному з ком'юніті минулого тижня ми обговорювали задачі на співбесіді для автоматизаторів.

Які варіанти задач я зустрічав

1. Задачі на алгоритми та структури даних (на обраній мові програмування). Це можуть бути спеціалізовані платформи типу Codility або HackerRank. Якщо це перший етап інтерв'ю - то дають 1-3 простих невеличких задачі на 30 - 60 хвилин. Якщо це частина технічної співбесіди - можуть бути задачі складніші. Плюс інтерв'юер може додавати нові вимоги.
2. Задачі типу "напиши сервіс та покрий тестами". Перевіряються як загальні скіли розробника, так і знання інструментів тестування конкретного фреймворку.
3. Задачі "ось тобі шматок коду - скажи, що він робить та де можуть бути баги". Перевіряється вміння читати чужий код, знання мови програмування та вміння знаходити баги.
4. Задачі "напиши UI чи API тести прямо зараз з нуля. Ось тобі сайт чи API". Тут перевіряється наявність ваших заготовок, вміння швидко писати тести. Якщо ви давно не працювали з бібліотекою чи фреймворком (або якщо ви займались копіпастингом БДД сценаріїв у готовому солюшені) - ви легко можете завалити співбесіду.

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

Окремо про тестові завдання

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

Які варіанти тестових я бачив

"Покрий автотестами частину функціональності чи API". Додатково може бути завдання написати спочатку тест план для фічі.

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

Головне правило роботи з тестовими завданнями - краще зробити менше тестів, але щоб вони працювали, стабільно, додати автоматичний запуск тестів на Github / Gitlab CI, репорти, інші корисні речі та додати README зі зрозумілим описом.
Бо якщо у вас крутий солюшен з усіма паттернами в світі, але він незрозумілий або навіть не запускається локально - то це величезний мінус.

А які варіанти задач на співбесідах зустрічали ви?

Приховане перетворення даних в grpcui та k6

#testing #api #tools #python

Ситуація
Для одного з наших gRPC сервісів нам потрібно відправити hash у форматі HEX. Але коли я намагався відправити запит за допомогою grpcui або ж у скрипті навантаження k6 - сервер повертав помилку, що такий хеш не знайдений в нашій базі.

Задача
Треба було розібратись, у чому причина перетворення даних - та де криється проблема. Бо сервіс точно працював правильно.
Значить проблема в роботі інтрументів ...

Рішення
Як виявилося - обидва інструменти очікують вхідні дані в base64. Потім вони декодують ці дані та надсилають результат на сервер.
В Python з base64 працювати дуже легко. То ж у нагоді стане наступний скрипт.

import base64


def from_b64_to_hex(input):
    binary_data = base64.b64decode(input)
    return binary_data.hex()


def from_hex_to_b64(input):
    binary_data = bytes.fromhex(input)
    return base64.b64encode(binary_data).decode()


base64_string = "LxTKPCw9jAv1U8Xm6lxjhtGlnoZzNPc6I="
hex_string = "2f14ca3c2c3d880653b15e6ea5c6386d1a59e867334f73a2"

assert hex_string == from_b64_to_hex(base64_string)
assert base64_string == from_hex_to_b64(hex_string)

І ще одне
Крім цього скрипта, можна скористатись також безкоштовним онлайн конвертером.

Про інтеграційні тести в реальному світі

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

То ж, як розповідають деякі поважні тестувальники - єгиптологи 😀, для успішної автоматизації, рекомендується писати наступні види тестів:
- Unit testing involves testing the smallest testable parts of an application, called units, independently and in isolation from other parts.
- Integration testing focuses on testing the interfaces and interaction between integrated units/modules to expose defects in their interactions.
- End-to-End testing is a technique that tests the entire software application from the start to the end along with its integration with external interfaces.

З юніт та е2е тестами все більш-менш зрозуміло (юніти - то більше про класи та функції, а е2е тести - про UI або зрідка API рівень).
Але коли починаєш питати в чатах "що таке інтеграційні" тести - отримуєш тисячу й одну відповідь від експертів. І кожен по-своєму правий.

Пропоную сьогодні поглянути на це питання за допомогою аналогій.

Авто
Юніт тести - це перевірка роботи конкретної окремої деталі. Наприклад батареї (для електро або гібриду).
е2е тест - це перевірка, чи авто взагалі може їздити (тобто як кінцевий користувач).
Інтеграційний тест - це перевірка, як декілька деталей схожої функціональності працюють разом (тестування підсистеми електрики або ж системи гальмування).

Ресторани
Юніт тест - це коли шеф-кухар перевіряє окремі продукти - чи свіжі овочі або м'ясо.
Інтеграційний тест - це коли перевіряються готовність декількох компонентів, які готуються разом. Наприклад, коли ми готуємо зажарку, щоб потім додати її в борщ.
е2е тест - це коли шеф-кухар або клієнт - пробують готову та сервіровану страву. Оцінює як саму страву, так і весь досвід від подачі до обслуговування.

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

Медицина
Юніт тест - це коли вчені експериментують з ліками на рівні окремих клітин.
Інтеграційний тест - це коли ліки перевіряють на рівні окремих органів чи більш складних систем.
е2е тест - це експериментальне тестування готових прототипів ліків на різних групах людей (разом із плацебо)

А які аналогії з інтеграційним тестуванням є у вас?

Запам'ятовування vs Розуміння

#learning

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

Питання в тому, що такий підхід не працює саме для розуміння інформації.

Записи (нотатки) та роздуми про те, як різні ідеї пов'язані між собою - це саме той вид уточнення сенсу, що потрібен для навчання та розуміння.

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

Тож простого читання недостатньо.

"Читання, особливо перечитування, може легко примусити нас повірити в те, що ми розуміємо текст. Це особливо небезпечно через ефект знайомства з текстом - з того моменту, коли ми познайомились з чимось, ми починаємо вірито в те, що вже розуміємо це." (с) Р. Фейнман

Test Engineering Notes: Vol. 9 Про важливість тестування, кар’єрний ріст до Senior та як працює Shazam

#testing #engineering #digest

Новорічні свята вже в минулому. Треба повертатись до робочого настрою.
Сьогодні до вашої уваги пропоную дайджест статей за грудень 2023.

2023. Підсумки.

Всім привіт. Це Олександр на зв'язку. Сьогодні 31 грудня - то ж саме час підводити підсумки року.

2023 рік у світі тестування та IT
- Ще більше застосування та тестування AI / ML. Google та інші компанії випускають "вбивць" ChatGPT майже кожного кварталу
- ChatGPT, Copilot та схожі системи все більше допомагають в повсякденних задачах
- Playwright стає новим "стандартом" в світі автоматизації Web'y
- У світі блокчейну "ненадійні" та "сірі" проєкти помирають. Індустрія стає більш зрілою. Інвестори цінують зараз не стільки "проривні" технології, як реальне застосування в бізнесі та комплексні продукти
- Мікросервіси перестали бути "гарячою темою". А стали лиш черговою опцією в арсеналі інженера
- Багато команд хоче влаштувати собі shift-left тестування, але стикається з купою проблем. Насамперед - відсутність знань та досвіду людей
- Кібербезпека й раніше була важливою, але зараз стає просто критичною. Кейси Київстару (й не тільки) це тільки підтверджують. Тому якщо вам випадково "нудно" в тестуванні - кібербезпека може бути дуже цікавим напрямком розвитку
- Світовий ІТ ринок пережив продовження звільнень. Ринок праці в Україні - остаточно став ринком роботодавця. Тож тепер треба ще більше вчитись, щоб стати кращим за інших кандидатів. (Навіть якщо ви сіньйор або лід)

Щодо мене.
В цьому році ми разом із Артемом Григоренко запустили власний подкаст - Testing Minutes.
А ще, крім роботи, каналу та подкасту - я був ментором - як для починаючих, так і для досвідчених інженерів. У 2024 році буду менторити ще більше.

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

Всім привіт.
Рома Марінський з QA Club Lviv буде сьогодні у 19:00 проводити вечірню неКаву у Varburger в ДНІПРІ!
Тема - мобільна автоматизація.
Формат - просто неформальна зустріч - розмова.
Хто має час - приходьте.

Друзі, доброго ранку!

Нещодавно ми подали з Олександром заявку на першу премію від DOU подкаст Testing Minutes і буду вдячний, якщо ви проголосуєте за нас.

Голосувати тут:
🔻🔻🔻
https://jobs.dou.ua/questionary/dou-award/podcast

Дякую всім 🙏

Хороший скетч про метрики та як з ними працювати

Чому тестувальники все ж таки потрібні - роздуми розробника

#testing #engineering

Натрапив на пост від розробника, присвячений питанням, що непокоять багатьох в індустрії тестування.

Питання такі:
- Чому до тестувальників склалося таке "зверхнє відношення" та
- Чи правильний підхід - "звільнемо тестувальників, бо якістю можуть займатись усі потроху!"

Мої короткі нотатки

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

(Додатково це призвело до великого знецінення користі роботи тестувальника).

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

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

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

А ви користуєтесь достатньо сильними паролями?