Avi Rubin: All your devices can be hacked

#security #video

Натрапив на невелике цікаве відео про те, як різні сучасні технології можна зламати.

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

Як? Відповіді у відео.

Advanced Python Mastery

#python #engineering

Для тих, хто вивчає Python - знайшов непоганий посібник з задачами та рішеннями.

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

Ласкаво просимо у другий сезон подкасту Testing Minutes.

Дев'ятого вересня тестувальники відзначали своє професійне свято. В цей день, аж 76 років тому, знайшли та задокументували перший баг.
Саме тому Артем та Олександр в цьому епізоді вирішили трошки зануритись у історію та знайти цікаві баги. Баги, які є доказом того, що помилки бувають усюди - навіть у великих компаніях та космічних апаратах.
🔸 YouTube
🔹 Spotify Podcast
🔸 Apple Podcast
🔹 Google Podcast

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

#testingminutes | @a_grygorenko | Test Engineering Notes

Про "ненадійність" MFA та нові технології зламу систем

#security #testing

Колись, треба було мати хоча б один пароль (який-небудь) для усіх сервісів. Потім рекомендували мати складний пароль з цифрами, спеціальними символами та літерами. Бажано - різний для кожного Вашого сервісу.
Далі настала потреба мати ще більше захисту - ввели OTP або інший варіант мульти-факторної аутентифікації. Один з розповсюджених варіантів - користуватись сервісом для генерації паролів типу Google Authenticator.

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

Але як?
Зловмисники спочатку надіслали фішингові SMS співробітникам. Більшість людей проігнорувала такі SMS, але одна людина таки клікнула.
Далі, ця людина зайшла по посиланню на фейковий "робочий" портал та ввела свій логін та пароль. А для того, щоб отримати згенерований пароль з Google Authenticator - зловмисники подзвонили цій людині, змінили свій голос за допомогою deepfake!!! на голос системного адміністратора та попросили співробітника сказати цей OTP пароль. Причому, хакери мали достатньо інформації про компанію, щоб звучати переконливо.

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

Висновки:
- скільки не будуй систему безпеки - найбільш ненадійними все ще залишаються люди
- треба вивчати та перевіряти усі функції систем (навіть ті, що йдуть за замовчуванням та "покращують" usability)

Більше про цей інцидент - в блозі компанії.

Запрошую послухати про тестування в блокчейні

#event

Всім привіт!

Для тих, хто не мав можливості доєднатись до теплої та кулуарної конференції QA Party Hard від QA Club Lviv - маю ще одну можливість послухати про тестування в світі блокчейну.

28 вересня (четвер) о 18:30 в Discord-спільноті SET University я зроблю доповідь на тему "Що таке блокчейн та як його тестувати". Реєстрація не потрібна, достатньо перейти за посиланням. Раджу зайти вже зараз, натиснути "Цікаво" (щоб прийшло сповіщення в Discord) та у налаштуваннях додати івент собі в Google Календар.

Буду радий усіх бачити на івенті.

Легке покращення командної стрічки вже сьогодні

#testing #cmd #linux

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

Що хотілося б?
Мати можливість викликати інструменти короткими командами та не паритись, де конкретно ці інструменти лежать.

Рішення
Я скористався старими добрими alias'ами (псевдонімами) в Linux. Це можливість створити нові команди на основі старих, або навіть комбінації декількох команд.
Наприклад, для Git це може бути

git st

замість

git status -sb

. Або ж

some-cli 

замість

 docker exec container-name some-cli

Як зробити?
1. Створити файл ~/.bash_aliases та покласти усі псевдоніми туди. Щось типу:

alias ls='ls --color=auto'

2. Додати інформацію про новий файл до ~/.bashrc

if [ -f ~/.bash_aliases ]; then
    . ~/.bash_aliases
fi

P.S. Потрібно слідкувати за версіями інструментів та своєчасно оновлювати їх.
P.P.S. Можна робити псевдоніми для Git команд прямо в його конфігурації

git config --global alias.co checkout

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

Цього разу, Артем та Олександр вирішили -побачити сон всередині сна- поговорити вдвох про зустрічі 1 на 1.
Виявляється, що правильні зустрічі можуть принести багато користі як інженеру, так і менеджеру. Але, які зустрічі правильні? Що потрібно робити обом сторонам?

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

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

#testingminutes | @a_grygorenko | Test Engineering Notes

Test Engineering Notes: Vol.6. Про QA в Microsoft, дублікати багів в Google, злам Retool та розробку аналогів Twitter

#testing #engineering #digest

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

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

- як Microsoft позбавилася усіх SDET`ів та що з цього вийшло
- коли контрактні тести дійсно потрібно
- чи можна автоматизувати перевірку платежів в IOS
- як інженери в Google боролись з дублікатами багів за допомогою machine learning
- математичний доказ того, чому гучність розмов у великій компанії зростає із часом
- як “легко” побудувати “вбивць” Twitter - на прикладах Threads та Mastodon
- чому застосування MFA - це не панацея для вашої кібербезпеки
- як правильно ставити питання - щоб отримати корисні відповіді
- багато багато іншого

How Games Typically Get Built

#engineering

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

Доречі, а ви граєте в комп'ютерні ігри? В які?

Тестування комп'ютерних ігор - як це?

#testing #games

Багато хто з нас звик до тестування та автоматизації звичних застосунків - web або mobile.
А от цікаве питання - як тестують ігри на кшталт Call Of Duty чи Sea of Thieves?

Знайшов декілька доволі цікавих доповідей на цю тему:
- Automated Testing of Gameplay Features in 'Sea of Thieves'
- Automated Testing and Profiling for Call of Duty
- Appium 2.0 for Game Testing: Automating Unity Games from the Inside
- Automating game testing in Unreal Engine
- Automated testing for a multiplayer game in Unreal Engine 4

А взагалі автоматизація в таких проектів - це дуже цікаво та складно.

У продовження теми ігор.
Чи знали ви, що в ISTQB є окремий сертифікат з тестування ігор? Я ось не знав. Треба буде почитати syllabus для нього, як буде час.
Може хтось його здавав та має досвід?

⚡️Епізод 13: Тестування у Game Dev

Чи граєте ви в комп'ютерні ігри? А чи знаєте, як їх тестувати та автоматизувати? Якщо ні - цей епізод обіцяє бути вельми цікавим! А розібратись з питанням тестування ігор ведучим допоможе гість - Олександр Дончук. Олександр працював над декількома частинами гри Metro, а зараз працює над не менш крутою мультиплеєрною грою Off The Grid.

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

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

#testingminutes | @a_grygorenko | Test Engineering Notes

QA Wiki

#testing

Дивись, що знайшов! Це QA Wiki з багатьох різних аспектів тестування. Із купою посилань на джерела.
Для новачків точно буде цікаво.

Ten Mental Models to learn anything

#learning

Основні тези зі статті Scott H. Young - Ten Mental Models to learn anything

- Вирішення проблем - це наче пошук виходу з лабіринту

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

- Знання ростуть експоненціально. Те, як швидко та скільки ви можете вивчити залежить від того, що ви вже знаєте. База (або фундамент) - важливі.
- Саме тому вчити щось нове спочатку складніше.

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

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

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

- Знання стають "невидимими" з досвідом
- Чим більше ми опановуємо нову навичку, тим більш "автоматично" ми користуємося нею.
- Наприклад - управління авто (поворотники)
- "Автоматичні" знання складніше викладати.
- "Автоматичні" знання складніше контролювати. А з тим - складніше покращувати.

- Вивчати щось, що ми вивчали в минулому - набагато легше та швидше, ніж навчатись чомусь з нуля.

My Hardest Bug Ever

#testing #bug

Сьогодні пропоную до вашою уваги майже детективну історію. Історію про те, як розробник гри Crash Bandicoot намагався "упіймати" баг, що стирав усі сейви з гри при завантаженні. Девелопер витратив майже 6 тижнів на дебаг. Але бага все ще з'являлася - причому досить рандомно.
А в результаті виявилося - що проблема дещо в іншому ...

How it works: The novel HTTP/2 ‘Rapid Reset’ DDoS attack

#security

В серпні місяці багато великих компаній, у тому числі Google, зіткнулися із новим видом DDoS атак - HTTP/2 ‘Rapid Reset’.
Деякі наймасштабніші атаки досягали (тільки уявіть!) майже 400 мільйонів запитів за секунду.

Коротко
Як завжди, зловмисники знайшли недосконалість у тому, як працює HTTP/2 протокол.
А саме - відкривали багато конекшенів одразу, а потім надсилали RST_STREAM фрейм для того, щоб цей конекшн розірвати завчасно.
Сервер не міг досить швидко зупинити обробку конекшену - тому деякий час продовжував працювати (та займати свої ресурси).

Вже навіть завели окрему вразливість під це - CVE-2023-44487.

Висновки
- Вразливості можуть бути де завгодно. Навіть у загально досліджених та "стандартних" протоколах.
- Треба думати не тільки про "позитивні" сценарії, а й взагалі про весь флоу обробки запитів. Та розраховувати, що обірвати зв'язок клієнт може у будь-який момент.

"Як працює інтернет" - коротке пояснення від Mozilla

#engineering #web

Випадково натрапив на дуже гарне та лаконічне пояснення базових концепцій Web технологій.

Усім новачкам (та й не тільки) - must read!
- How does the Internet work?
- What is a URL?
- What is a Domain Name?

P.S. там на сайті є ще й інші статті - варто тільки пошукати...
P.P.S. Вчіть базу (навіть якщо ви "сіньйор"). Так ви зробите деяких head of qa щасливішими, а ваші шанси знайти нову роботу - вищими

Bad Blood

#testing

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

Цього разу Алан розкриває дві тези, які найчастіше наводять коли говорять, що девелопери не можуть тестувати.

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

2. "У девелопера немає часу на тестування". Тут Алан наводить як свій досвід, так і досвід інших інженерів: "I’ve had the opportunities to work with a lot of great developers who took testing seriously. Every single one of them has told me that writing comprehensive tests for their code has sped up their delivery. They had MORE TIME and got more done when they owned the vast majority of testing because they spent substantially less time doing re-work or fixing bugs."

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

А ви що думаєте? Чи згодні ви з тим, що девелопери можуть тестувати та тестувальники взагалі не потрібні?

⚡️ Епізод 15: Де тестувальник менеджить тести

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

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

Для тих, хто полюбляє слухати:
🔹 Spotify Podcast
🔸 Apple Podcast
🔹 Google Podcast

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

#testingminutes | @a_grygorenko| Test Engineering Notes