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

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

🎧 Слухати подкаст тут
📺 Дивитися подкаст тут

PS. Ми дуже вдячні за ваш фідбек, і його активно використовуємо для того, щоб підвищити якість подкасту. Тому так само будемо вдячні вам за зворотній зв'язок в майбутньому. Не зупиняйтесь ;)

#testingminutes #podcast

Про ще один вид ручної праці та засоби його покращення

#ai #curious

Всім доброго ранку понеділка. За вікном в мене дощ, але це ніяк не привід зменшувати допитливість до світу технологій та тестування.

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

Але деякі аутсорсери пішли далі та застосували "автоматизацію" ...

Коли навчання варте зусиль?

#learning #skills

У бізнесі має місце дилема: чи розробляти якийсь інструмент всередині компанії чи купити вже готовий на ринку?

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

Тобто, з навчанням новому у Вас є варіанти:
- Можна опанувати навичку самому
- Можна найняти когось іншого (делегувати)
- Можна НЕ навчатись взагалі

Які ж питання можна собі задати, коли Ви вагаєтесь чи вчити щось нове чи ні?
1. Як швидко я очікую, що практика навички буде легшою із часом? Є навички, де прийнятний результат можна отримати доволі швидко. А є такі, де треба витратити місяці та роки на опанування.
2. Як часто я буду користуватися цією навичкою? Все залежить від контексту. Якщо ця навичка допоможе зрости у кар’єрі - вона варта. Якщо ж ви не будете практикувати цю навичку - то вона швидко забудеться.
3. Чи буду я отримувати задоволення від практики навички (чи захоплює ця навичка мене)? Не треба вчитись чомусь, якщо ви не отримуєте хоча б найменшого задоволення від практики цієї навички. Навчання через “не можу” рідко буває ефективним.

Більше про те, чи варто навчатись можна почитати в оригінальній статті - When is Learning Worth the Effort?

Test Engineering Notes: Vol. 3

#testing #engineering #digest

Зізнавайтеся, ви вже прочитали усі статті з минулих підбірок?
Якщо так, я приніс вам нову порцію цікавинок зі світу тестування та розробки.

У цьому випуску:
- AI у тестуванні - від теоретичних роздумів до практичного тестування
- "шифтуємо" вліво перевірки безпеки та знайомимось з accessibility
- розширюємо набір інструментів для мобілок та розбираємось з web перфомансом з Lighthouse
- вивчаємо дизайн паттерни для автотестів та дивимось на приклади контрактних тестів
- розкриваємо тему культури тестування на прикладі Google та Apple
- повторюємо базові (та не дуже) концепції з системного дизайну, мереж та баз даних
- дивимось доповіді про performance benchmarking та поглиблені підходи в тестуванні розподілених систем
- багато багато іншого ...

А які найцікавіші статті ви прочитали за червень?

⚡️Епізод 4: Де тестувальник спростовує міфи про тестування

У цьому епізоді, я з Олександром у ролі руйнівників міфів - та спростовували найвідоміші міфи зі світу тестування та автоматизації.

🔸 YouTube
🔹 Spotify Podcast
🔸 Apple Podcast
🔹 Google Podcast

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

Також, ми будемо вдячні за фідбек, бо ми постійно розвиваємось і покращуємо якість (як на мене :D)
Пропонуйте ваші теми в коментарях ;)

#testingminutes #podcast

Про економію, аутсорсинг та надмірну довіру - кейс Boeing 737 MAX

#testing #bugsinthewild
Всім доброго ранку понеділка. Сьогодні я хотів би поговорити про найвідоміші баги та чому вони виникають.

У дописі ми розберемо кейс з літаком Boeing 737 MAX, що стався не так давно - у 2018 році.
Чи то тестувальники пропустили баги, чи то інженери неправильно задизайнили та створили систему, чи то процес був зламаний.

А ви як думаєте? Де тут root cause?

What Makes Israel So Good at Hacking?

#security

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

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

А ви як думаєте?

⚡️Епізод 5: як тестують в Амазон.

Цей епізод незвичний. Бо до ведучих подкасту, Артема та Олександра, доєднався гість - Анатолій Ганзюк. Він поділився купою досвіду та інсайтів про те, як тестують в Amazon.

🔸 YouTube
🔹 Spotify Podcast
🔸 Apple Podcast
🔹 Google Podcast

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

Пропонуйте ваші теми в коментарях ;)
#testingminutes #podcast

Про причинно-наслідкові помилки

#testing #curious #fallacies #thinking

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

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

Але щоб такої помилки уникнути - треба лишень глибше досліджувати проблеми та докопуватись до суті проблеми (а причини може бути в недостатньо оптимізованому коді із купою sleep() або копіпасти)

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

Security Certification Roadmap

#curious #security

В світі тестування люди постійно холіварять - чи потрібно отримувати якісь сертифікати (на кшталт ISTQB) чи можна обійтись без них? А який сертифікат найкращий? А що він дає? А чи обов'язково мати такий?

Для порівняння - подивіться на роадмап сертифікатів в світі security та оцініть масштаби та кількість.
Багато компаній вимагають наявність декількох сертифікатів одразу.
А ще - там для кожного курсу наведена вартість ... Та порівняйте з 100-200$ за тестувальницькі сертифікати.

Про помилку незворотніх витрат a.k.a Sunk-Cost Fallacy

#testing #curious #fallacies #thinking

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

У цьому циклі дописів, я спробую коротко розповісти про такі помилки із прикладами з тестування та автоматизації. Декілька днів тому я вже розповідав про causal fallacy. 

Що таке sunk-cost fallacy?
Сьогодні настав час для наступної помилки - sunk-cost fallacy або помилки незворотніх витрат. 
Уявімо ситуацію. Хтось у минулому прийняв рішення. Через деякий час виявилося, що рішення було неправильним. Але оскільки на це рішення було витрачено вже багато часу, зусиль та грошей - людина (або команда чи компанія) продовжують працювати над цим хибним рішенням. Та ще й відмовляються його переглядати. 

Приклади:
- менеджмент вважав, що автоматизація - то "легко" та купив усім ліцензії на відому та рекламовану low-code / no-code тулзу. Через деякий час виявилося, що тести дуже важко підтримувати та вони швидко ламаються після кожної зміни на фронтенді. Але гроші на річну ліцензію вже були витрачені, тому тестувальникам треба працювати з цими інструментами "через силу"
- те ж саме стосується будь-яких нових інструментів чи підходів (BDD, shift-left and right, etc) Особливо, коли інструменти "спускають зверху". Рішення вже "прийняті" або "нічого не знаю, клієнт так хоче!" або "це модний фреймворк, на ньому усі круті інженери пишуть - це майбутнє!"

Як запобігти цій помилці?
- Приймайте зважені рішення з порівнянням наявних альтернатив
- Розробляйте proof of concept будь-яких нових інструментів
- Думайте не тільки про плюси, а й про час на підтримку, переписування, інтеграцію нового у інфраструктуру
- Постійно оцінюйте прийняті рішення та не бійтеся відмовлятися від хибних та неефективних (навіть якщо сил та грошей було витрачено багато)

Вокршоп про QA Roadmap з OKR

#workshop

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

📅 Коли: 20.07.2023, 18:00
📍 Де: Zoom
💵 Вартість: 50$ / 1850 UAH
🧑‍🎓 Для кого: Senior QA, Test Manager, QA Lead
🧾 Деталі від Артема: На цьому воркшопі я поділюся власними напрацюваннями щодо створення roadmap для команди тестувальників. Розберемось із OKR: що це таке, як його можна використати при плануванні розвитку своєї команди. На самому воркшопі учасники будуть складати таку roadmap для певної команди. А також, всі учасники воркшопу отримають додаткові матеріали після його завершення.

❗️30% коштів отриманих з воркшопу піде на ЗСУ.

🗒 Зареєструватись

Всім привіт!
Звернулась по допомогу 56-та ОМПБр, яка зараз тримає східний напрямок. В ході штурмових дій багато техніки та засобів втрачаються нажаль безповоротно. І це сумно, але ця техніка допомагає зберігати їм життя!
Хлопці просять допомогти трохи відновити арсенал розвідувальних дронів, а саме запит на два DJI Mavic 3 Enterprise. Думаю, не треба пояснювати, яку важливу роль відіграють дрони в зоні бойових дій.

🎯Ціль: 212 000.00 ₴

🔗Посилання на банку
https://send.monobank.ua/jar/5DU4A4xvW3

💳Номер картки банки

5375 4112 0717 6681

Заздалегідь дякую усім💛💙

⚡️Епізод 6: Де тестувальник розбирається з BDD

У цьому епізоді, Артем та Олександр розбирають предмет довгих спорів та холіварів - BDD, він же Behavior Driven Development, він же "огірок".

🔸 YouTube
🔹 Spotify Podcast
🔸 Apple Podcast
🔹 Google Podcast

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

#testingminutes #podcast

Інженерні блоги, за якими варто слідкувати

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

Лист:

Engineering at Meta - https://engineering.fb.com/
Google Research - https://ai.googleblog.com/
Google Cloud Blog - https://cloud.google.com/blog/
AWS Architecture Blog - https://aws.amazon.com/blogs/architecture/
All Things Distributed - https://www.allthingsdistributed.com/
The Nextflix Tech Blog - https://netflixtechblog.com/
LinkedIn Engineering Blog - https://engineering.linkedin.com/blog
Uber Engineering Blog - https://eng.uber.com/
Engineering at Quora - https://quoraengineering.quora.com/
Pinterest Engineering - https://medium.com/pinterest-engineering
Lyft Engineering Blog - https://eng.lyft.com/
Twitter Engineering Blog - https://blog.twitter.com/engineering/en_us
Dropbox Engineering Blog - https://dropbox.tech/
Spotify Engineering - https://engineering.atspotify.com/
Github Engineering - https://github.blog/category/engineering/
Instagram Engineering - https://instagram-engineering.com/
Databricks - https://www.databricks.com/blog/category/engineering
Canva Engineering Blog - https://canvatechblog.com/
Etsy Engineering - https://www.etsy.com/codeascraft
Booking Tech Blog - https://blog.booking.com/
Expedia Technology -https://medium.com/expedia-group-tech
The Airbnb Tech Blog - https://medium.com/airbnb-engineering
Stripe Engineering Blog - https://stripe.com/blog/engineering
Ebay Tech Blog - https://tech.ebayinc.com/
Flickr's Tech Blog - https://code.flickr.net/
Hubspot Product and Engineering Blog - https://product.hubspot.com/blog/topic/engineering
Zynga Engineering - https://www.zynga.com/blogs/engineering
Yelp Engineering Blog - https://engineeringblog.yelp.com/
Heroku Engineering Blog - https://blog.heroku.com/engineering
Discord Engineering and Design - https://discord.com/blog
Zomato -https://www.zomato.com/blog/category/technology
Hotstar - https://blog.hotstar.com/
Swiggy - https://bytes.swiggy.com/
Acast Tech - https://medium.com/acast-tech
ASOS Tech Blog - https://medium.com/asos-techblog
Shopify Engineering - https://shopify.engineering/
Microsoft Tech Blogs -https://devblogs.microsoft.com/
Engineering at Microsoft - https://devblogs.microsoft.com/engineering-at-microsoft/
MongoDB Engineering Blog - https://www.mongodb.com/blog/channel/engineering-blog
Slack Engineering - https://slack.engineering/
Engineering at Depop -https://engineering.depop.com/?gi=c1f06491720c
SourceDiving (Cookpad's Engineering Blog - https://sourcediving.com/
Indeed Engineering Blog - https://engineering.indeedblog.com/blog/
Gusto Engineering Blog -https://engineering.gusto.com/
Engineering at Birdie - https://medium.com/engineering-at-birdie
Forethough Engineering - https://engineering.forethought.ai/
Capital One -https://www.capitalone.com/tech/blog/
Disney Streaming - https://medium.com/disney-streaming

А які технічні блоги читаєте ви? Пишіть у коментарях?

Помилка більшості a.k.a. Bandwagon Fallacy

#testing #curious #fallacies #thinking

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

Що таке bandwagon fallacy?
Суть цієї помилки полягає в тому, що ми приймаємо рішення базуючись тільки на факті, що так робить більшість людей в індустрії. При цьому, ми не думаємо, а чи підходить це рішення для нашої конкретної ситуації.

Приклади
- AI та ChatGPT зараз на хайпі - саме тому треба його не просто вивчати, але й пхати усюди де тільки можна!
- Багато хто застосовує low-code або no-code інструменти - тому й вам потрібно почати!
- Усі пишуть автотести (шифтують вліво чи право, вивчають JS чи якийсь конкретний фреймворк) - тому й вам потрібно вивчати та застосовувати саме ці мови та підходи!
- Усі навкруги пишуть пишуть чек-лісти замість тест кейсів, тому й вам потрібно робити те саме!
- Усі міряють тестове покриття та ставлять не нижче 75-80-90% - тому й у вас на проєкті потрібно впроваджувати таке!

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

Корисне з Github - 2

#github #selection

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

- Для тих, хто готується до system design інтерв’ю, одним із важливих моментів буде швидко рахувати цифри перфомансу вашого майбутнього рішення. Цей репозиторій (а також супутня доповідь) допоможе трохи більше розібратись з latency, throughput та вартістю системи. https://github.com/sirupsen/napkin-math
- Andrejs Doronins має багато корисних курсів на Pluralsight. Крім того, він викладає приклади коду на Github. Для новачків буде цікаво.
- Rest Assured Fundamentals https://github.com/andrejs-ps/REST-Assured-Fundamentals
- Web Testing with Java and Playwright https://github.com/andrejs-ps/automated-web-testing-in-java-with-playwright
- Selenium Fundamentals https://github.com/andrejs-ps/Selenium-Fundamentals-completed
- А для тих, хто цікавиться Cypress - Mohammand Monfared виклав приклад цілого солюшену https://github.com/mmonfared/CyFramework (Але незнаю чи варто починати працювати з цим, бо схоже цей фреймворк потроху “загибається”)

Портфоліо для тест інженера

#testing #career

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

Незалежно від того, чи трейні чи джуніор ви зараз, чи матьорий сіньйор - вам потрібно завжди думати про те, як тримати себе “в тонусі” та мати портфоліо.

Для розробника питання портфоліо визначається доволі просто - або викладай свої open-source роботи на Github, або бери участь в таких проєктах (чи пиши свої бібліотеки).

А от що робити тестувальнику щоб підвищити шанси хоча б опинитись на співбесіді?
- Оновіть своє резюме та оптимізуйте його під конкретну вакансію. Відмічайте саме той досвіду, який буде важливим на конкретній позиції. Не забувайте оновлювати свій Linkedin профіль також.
- Тестуйте! Оберіть відомі або невідомі веб сайти чи мобільні застосунки - та тестуйте їх. Напишіть тест план, чек ліст, стратегію. Спробуйте автоматизувати їх. Усі ваші роботи викладайте у вільний доступ на Github або у ваш блог.
- Викладайте цікаві баги, які ви знайшли в процесі тестування публічних веб-сайтів.
- Не зациклюйтесь тільки на одному інструменті чи фреймворку. Спробуйте будувати ваші рішення з автоматизації навіть на тій мові, яку знаєте менше.
- Можна підготувати план вашого навчання - наприклад у вигляді дошки в Trello та викласти її в загальний доступ. Таким чином ви зможете показати, яким був ваш прогрес та чого нового ви навчились - а також - як ви застосували ваші знання на практиці. Робіть публічні комітменти вивчити нове та звітуйте (наприклад в Твіттері)
- Аналізуйте та рефлексуйте кожну виконану задачу на роботі - чого ви навчились. Робіть нотатки та формуйте свою базу знань. Це також допоможе вам згодом підготувати багато історій для співбесід - коли вас запитають, чого саме ви досягли чи навчились окрім “писав тести чи проходили регресію)
- Навчайтесь новому та практикуйте отримані знання. А ще краще - діліться тим, чого навчились з іншими. Це може бути стаття на DOU наприклад чи відео на Youtube. Одна справа прочитати про щось в Інтернеті - зовсім інша - спробувати розповісти своїми словами.

А що ви робите для свого портфоліо?

⚡️Testing Minutes - Епізод 7: Quality Coaching в Unity

Новий тиждень - черговий епізод подкасту!
Цього разу до нас з Артемом у випуск завітав Oleg Virovkin з компанії Unity.
Ми обговорили багато цікавих питань: від теми коучінгу якості до тестування та автоматизації графічних ефектів.

🔸 YouTube
🔹 Spotify Podcast
🔸 Apple Podcast
🔹 Google Podcast

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

#testingminutes #podcast