Test Engineering Notes

Мікромагістратура зі створення архітектури програмного забезпечення

5 грудня SET University запускає мікромагістерську програму Solution Architecture.

За 6 тижнів можна дізнатись про ключові концепції в архітектурі: від бізнес-аспектів та вимог — до структур, різновидів архитектур та підходів до їх дизайну. Програма актуальна для таких позицій: DevOps, Data Engineers, Software Architects, Middle+ Software Engineers.

Подати заявку на програму: тут

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

Вчимося англійській або Поема про відповідальність

How to Speak - лекція в MIT від Patrick Winston

#video #speaking

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

Тому почати цей тиждень пропоную з дуже цікавої лекції від досвідченого лектора з MIT - Патріка Вінстона.

Нащо це дивитись?
- взнаєте як краще почати виступ
- дізнаєтесь різні підходи до побудови лекцій
- побачите чому приклади важливі, а текст на слайді - часто тільки відволікає
- вивчите структуру хорошої лекції (або ж будь-якої письмової роботи)
- відкриєте для себе - що мати слайд "Thank you. Questions" - то не дуже хороша ідея

Кому буде цікаво? Спікерам, лідам, менеджерам та будь-кому, хто щось презентує час від часу.

Найголовніша теза:
Якість спілкування Q = f(K,P,t), де K - це знання (knowledge), P - це практика (practice), t - талант (talent).
Тобто якість залежить більше від знань та практики, ніж від таланту.

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

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


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

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

#testingminutes | @a_grygorenko | Test Engineering Notes

Про силу запитань

#testing

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

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

Але в пулл реквесті мене чекав сюрприз...
Більша частина коду написана на Haskell. А інша частина на PureScript. А це такі мови програмування, які не можна "просто так взяти та почитати".

Тому я пішов та почав задавати питання девелоперам. І чим більше питань я задавав, тим більше "Хм, треба перевірити" я отримував.

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

Підбірки матеріалів з тестування

#testing

Серед купи статей та відео я знайшов декілька цікавих підбірок з тестування:

- Збірна "солянка" різних інструментів тестування та автоматизації
- Блоги про те, як різні компанії автоматизують мобільні додатки
- "Кращі" практики та підходи до UI автоматизації

Корисні книжки з тестування (за мотивами подкасту)

#testing #books

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

Це якщо вам цікаво або ви вважаєте, що "нічого складного та нового в тому тестуванні немає"

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

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

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

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

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

#testingminutes | @a_grygorenko | Test Engineering Notes

Олександр Романов повертається з новим контентом для тестувальників! 🐞

Він підготував дайджест статей з тестування, автоматизації та інших інженерних цікавинок, аби у вас завжди було що почитати між релізами 👉
https://dou.ua/goto/IDLP

AI в тестуванні - підбірка від MoT

#testing #ai

Сьогодні я приніс вам підбірку матеріалів з "гарячої" теми AI (статей, відео й книжок) дбайливо зібраних на форумі Ministry of Testing.
Тут не просто AI, а його тестування або застосування в тестуванні.
Може комусь стане в нагоді.

Як читати дослідницькі роботи

#reading #engineering

Мій короткий конспект з того, як ефективно та правильно читати дослідницькі роботи. Та найголовніше - навіщо?

Головні вороги тестувальників - відсутність доступу до пристрою та незрозуміле ТЗ.
На жаль, AppSpector поки не може покращувати ТЗ, але надає доступ до логів мережі, Core Data, файлової системи, даних локації та ще багато чого, що допомагає розробникам таких компаній як BuzzFeed, Waves та Mirror виявляти причини багів миттєво.
Згідно з репортами, команди, що користуються AppSpector заощаджують на дебагінгу до 38 годин на місяць на одного розробника!

AppSpector – українська платформа для віддаленого дебагінгу мобільних застосунків у реальному часі.
Революційний інструмент за лічені хвилини інтегрується в ваш застосунок та дозволить і розробникам і клієнтам, обмінюватися даними щодо застосунку в режимі online.
Стартуйте free trial.

Для “своїх” маємо приємний бонус: за промокодом “GloryToUkraine” ви отримаєте безкоштовний місяць після тріалу для всієї команди!
Переходьте на лендінг та повертайте втрачений час!

Для тих, хто забув - гарна візуалізація популярних мережевих протоколів

🍿 #partyHard і так, це нове нагадування про те, що в Україні нема краще конфи для тестувальників і автоматизаторів!

https://secure.wayforpay.com/payment/qa_party_hard_3

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

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

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

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

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

#testingminutes | @a_grygorenko| Test Engineering Notes

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."

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

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

"Як працює інтернет" - коротке пояснення від 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 щасливішими, а ваші шанси знайти нову роботу - вищими

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.

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

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

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

ℹ️ На YouTube, в описі епізоду є посилання на всі корисні матеріали із випуску.

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

Підтримати наш подкаст для подальшого розвитку ви можете на Buy Me a Coffee ☕️

#testingminutes | @a_grygorenko | Test Engineering Notes

My Hardest Bug Ever

#testing #bug

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