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

#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

Keep a brag list of the wins you achieved, thank me later

#career

Ще одна стаття про те, чому вести brag document дуже важливо.
Особливо, коли навкруги вирують скорочення та велика конкуренція.

Готуйтесь до пекельного поєдинку! 22 лютого в офлайн дискусії зійдуться Роман Марінський та Ярослав Пернеровський 🔥

Почнемо нашу подію з доповідей:
— "Коли АІ вас підводить" - Роман Марінський розкриє ризики та виклики використання AI у тестуванні.
— "Як АІ допомагає в тестуванні" - Ярослав Пернеровський презентує огляд існуючих рішень, які зроблять ваше тестування ефективнішим.

А після виступів вас чекає панельна дискусія, яку модеруватиме Senior .Net Test Automation – Наталія Попелишко.

Чекаємо вас! Кількість місць обмежена, тож не втрачайте шанс зареєструватись вже зараз. Деталі на сайті 👌🏻

Про brace expansion в linux

#linux #cmd

Уявімо, що вам потрібно створити декілька файлів чи тек зі схожими назвами.

Можна робити так

mkdir -p test/data/chrome test/data/firefox test/data/safari

А можна застосувати так штуку, як brace expansion

mkdir -p test/data/{chrome,firefox,safari}

що в результаті буде мати той же самий ефект - створить три теки з різними назвами.

Можна мати декілька expansions

> echo test/{1,2,3}/data/{5,6,7}
> test/1/data/5 test/1/data/6 test/1/data/7 test/2/data/5 test/2/data/6 test/2/data/7 test/3/data/5 test/3/data/6 test/3/data/7

Виглядає прикольно, але є ще більше "магії".

Наприклад вам треба створити 10 тестових файлів зі з порядковими номерами в назвах, але щоб ці номери ще й були з інтервалом в 10

touch file-{0..100..10}.txt

ls file*
file-0.txt  file-100.txt  file-10.txt  file-20.txt  file-30.txt  file-40.txt  file-50.txt  file-60.txt  file-70.txt  file-80.txt  file-90.txt

⚡️ Епізод 25 - Де тестувальник стає помітнішим

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

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

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

#testingminutes | @a_grygorenko | Test Engineering Notes