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

#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

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

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

#testing #blockchain

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

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

#testing

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

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

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

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

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

#testing

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

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

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

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

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

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

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

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

#automation #engineering

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

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

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

Питання про 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."

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

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

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

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

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

#testingminutes | @a_grygorenko | Test Engineering Notes

Selenium Vs … blog posts

#testing #automation

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

Про ідеї та простір для обміну

#learning

Продовжую ділитись своїми думками після прочитання книги "How to take smart notes". Сьогодні - про ідеї.

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

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

Приклади:
- Наприклад раніше, нові літературні ідеї виникали в окремих кафе, де збирались поети та письменники та вели дискусії
- В контексті досліджень це може бути лабораторія чи учбовий кампус університету
- На роботі - це можуть бути ті самі community of practice, гільдії та інше.

Саме тому, форуми, конференції та ком'юніті - вкрай важливі. Як для розвитку окремої людини, так і для індустрії в цілому.

А саме:
- Конференції. Доповіді та слайди будуть доступні пізніше в записі. Головне в конференціях - це можливість спілкуватись із купою спеціалістів, розширювати свою мережу контактів. Найкращі ідеї завжди народжувались під час неформальної розмови в кулуарах
- Мітапи, вебінари. Також може стати середовищем "змішування" ідей. Особливо, коли це дискусія декількох спеціалістів на обрану тему
- Ком'юніті. Важливо, щоб ком'юніті було не токсичне. Щоб це було місце - де поважають думки інших та можуть допомогти один одному. Гарне ком'юніті спрямовано на ріст та обмін важливими ідеями. Таких ком'юніті мало. Але їх треба пошукати

І ще одне.
Чим більше у вас досвіду та знань, тим складніше отримати "нові ідеї". Чергові розмови можуть здаватися повторенням одного й того ж.
Щоб такого не сталося - шукайте різні ком'юніті. Спілкуйтесь з різними експертами. Не тільки в тестуванні, а й в інших інженерних (та й не тільки) напрямках.

P.S. Краще спілкуватись менше, але якісніше. Та не забувайте робити нотатки.

Для тих, хто готується до технічної співбесіди

#automation #interview

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

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

⚡️ Епізод 22: Де тестувальник приймає участь в ретроспективах

Не всі можуть дивитися в завтрашній день. А як щодо минулого?

В цьому епізоді подкасту Артем та Олександр розбираються з ретроспективою.

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

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

А ще ви можете підтримати наш подкаст будь - яким донатом на Buy Me a Coffee ☕️
Окрім того, за різні підписки ви зможете отримати доступ до закритого чату подкасту, отримувати нові епізоди до самого виходу, а також є можливість присутності під час запису 😏

#testingminutes | @a_grygorenko| Test Engineering Notes

Як тестувальник створює цінність

#testing

Цінність інженерів

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

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

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

Щоб підвищити свою ефективність та цінність, розробник може працювати над найбільш важливими фічами та зменшувати час, поки фічі стануть доступними користувачеві.

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

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

Цінність зворотнього зв'язку

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

Інформація про стан продукту також повинна надаватися вчасно. Тому багато команд оптимізують процеси тестування таким чином, щоб отримувати зворотній зв'язок не через дні та тижні, а через лічені хвилини.

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

Цінність коду й тестів

Робочий автотест на локальній бранчі має меншу цінність, ніж той, для якого створений PR. Автотест у процесі код рев'ю - має меншу цінність, ніж той, що вже в головній гілці. Але тест, що вже вмерджений в develop гілку та ганяється кожен день - має найбільшу цінність.
Тест кейс, тільки-но доданий в TMS приносить менше користі, ніж той, який вже використовується, як частина чекліста.

Чим швидше ви пройдете код рев'ю або ж зберете потрібну інформацію для тестування - тим швидше тест буде приносити цінність.

Цінність автоматизованих тестів

Автоматизація сама по собі не приносить цінності користувачеві. Це просто один з інструментів, щоб отримати інформацію та прискорити фідбек. Так само, як юніт тести чи автоматизований CI/CD пайплайн. Або ж canary релізи.

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

Як тестувальник може підвищити свою цінність

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

Keeping Tests Valuable: Social Testing at the Heart of Software!

#testing #engineering

Чи знаєте ви, в чому різниця між solitary та sociable модульними тестами?
Якщо ні - маю для вас одну з найкращих нещодавних статей на цю тему. У статті - купа практичних прикладів та пояснень.
Рекомендую.

🎙 «Питання якості». QA Podcast #14. Як тестувальнику приборкати ШІ та фейли, які траплялися з новими ведучими

Друзі, сьогодні рівно 2 роки з моменту створення нашої тестувальницької спільноти 🎉 Дякуємо, що ви з нами!

І сьогодні, у нас для вас прем’єра нового сезону подкасту «Питання якості». Нові ведучі, нові погляди на робочі та не тільки моменти, а також багато чого цікаво зі світу тестування.

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

Випуск подкасту «Питання якості» #14 на нашому YouTube 👉 https://youtu.be/1UzIrUJEkxg

А обговорюємо — на форумі. 
💬 https://dou.ua/goto/mCUc

Test Engineering Notes Vol. 10. Про важливість Unit-тестів, перфоманс вебу та E2E-тестування в Microsoft

#testing #engineering #digest

Хей хей. Знаю, що скучили за цікавими статтями з тестування та технологій. Тож поспішаю до вас із новим дайджестом за січень 2024.

Букайте годину в календарі, вносіть статті у ваш чекліст - та читайте!

⚡️ Епізод 23: Де тестувальник використовує інструменти AI разом з Романом Марінським

Хайп AI інструментів продовжується. Але виникає питання - як AI може допомогти в роботі тестувальнику? В цьому питанні Артему та Олександру допоможе розібратись гість - Роман Марінський. Як завжди - з реальними прикладами та кейсами з досвіду.

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

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

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

#testingminutes | @a_grygorenko| Test Engineering Notes

The Hacker News Top 40 books of 2023

#books #engineering

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

Але я маю для вас результати іншого голосування. А саме - топ IT книжок, що рекомендують користувачі Hacker News у 2023 році.
Є що подивитись та з чого обрати.

Continuous Integration

#engineering #processes

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

Про JSON-RPC та як його тестувати

#testing #api

Коли я прийшов працювати в блокчейн - то побачив, що доволі багато різних продуктів мають інтеграцію через API. Але то було не звичне усім HTTP REST API. Це було - JSON-RPC API.
Тому сьогодні поговоримо про те, що таке JSON-RPC та як його тестувати.

Що таке RPC?
RPC (Remote Procedure Call) - віддалений виклик процедур. Це протокол з далеких 1970х років, що дозволяє викликати процедури на іншому ком'ютері ніби-то процес знаходиться на вашому ком'ютері. Більше - ось тут.

Що таке JSON-RPC?
Якщо коротко, це протокол для віддаленого виклику процедур, побудований за специфікацією. Він розділяє бізнес логіку та від саме передачі даних. Запити йдуть через HTTP POST у форматі JSON.
Формат запиту та відповіді в JSON-RPC - стандартизований, та складається з декількох обов'язкових полів.
Запит (приклад Ethereum API)

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBalance",
"params":["0x407d73d8a49eeb85d32cf465507dd71d507100c1", "latest"],"id":1}'

- "jsonrpc" - індикація, що це саме jsonrpc. Зазвичай використовується версія 2.0
- "method" - ім'я віддаленого методу (аналог ендпоінту в REST)
- "params" - об'єкт або ж массив параметрів для методу
- "id" - унікальний ідентифікатор запита

Відповідь

{
  "id":1,
  "jsonrpc": "2.0",
  "result": "0x0234c8a3397aab58" // 158972490234375000
}

- "jsonrpc" - також "2.0"
- "result" - об'єкт відповіді
- "error" - об'єкт помилки, що складається з полів code, message та data
- "id" - такий же, як і в запиті

Які бувають коди помилок в JSON-RPC
- '-32700' - Parse error (сервер не зміг розпарсити запит)
- '-32600' - Invalid Request (JSON у запиті - невалідний)
- '-32601' - Method not found
- '-32602' - Invalid params
- '-32603' - Internal error (внутрішня помилка JSON-RPC)
- '-32000' to '-32099' - Server error

JSON-RPC - транспортно незалежний протокол. Тобто він може працювати як з HTTP,
так і з TCP чи веб сокетами. HTTP - частіше. Плюс - протокол підтримує як синхронні, так і асинхронні виклики.

Як та чим тестувати JSON-RPC API?
Коротко - так само, як ви тестуєте будь-яке інше звичне API. Робите запит, отримуєте відповідь.
- Якщо відповідь успішна - поле result буде з даними.
- Якщо трапилася проблема - перевіряйте поле error.

Тому тестувати можна будь-яким зручним інструментом, типу: Postman, Insomnia чи cURL.
Для прикладу - API від Ethereum.

Як бачите - нічого страшного.

Про якість, що впливає на долю людей - історія British Post Office

#testing #bugsinthewild

Як зв'язане тестування, розподілені системи та Британська Поштова Служба?

⚡️ Епізод 24 - Де тестувальник стартує автоматизацію на проекті з нуля

До вас прийшов менеджер та попросив "швидко написати пару автотестів". З чого почати? Яку технологію обрати? Як отримати максимум від автоматизації та уникнути проблем як на старті так і згодом? Про це й будуть сьогодні спілкуватись ведучі подкасту - Артем та Олександр.

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

А ще ви можете підтримати наш подкаст будь - яким донатом на Buy Me a Coffee ☕️
Окрім того, за різні підписки ви зможете отримати доступ до закритого чату подкасту, отримувати нові епізоди до самого виходу, а також є можливість присутності під час запису 😏

#testingminutes | @a_grygorenko | Test Engineering Notes