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

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

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

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

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

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

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

#reading #engineering

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

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

#testing #ai

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

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

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

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

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

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

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

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

#testingminutes | @a_grygorenko | Test Engineering Notes

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

#testing #books

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

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

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

#testing

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

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

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

#testing

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

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

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

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

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

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

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


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

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

#testingminutes | @a_grygorenko | Test Engineering Notes

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

#video #speaking

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

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

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

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

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

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

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

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

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

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

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

Корисне з GitHub - 4

#github #selection

- inshellisense: автокомпліт для вашої командної стрічки від Microsoft
- Giskard: безкоштовний інструмент для тестування machine learning моделей
- sshx: колаборативна командна стрічка
- Awesome emulators: купу емуляторів різних девайсів та консолей
- OWASP Web Security Testing: чекліст для тестування вразливостей веб додатків
- tech interview handbook: підбірка ресурсів, для тих, хто готується до кодинг інтерв'ю

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

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

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

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

#testingminutes | @a_grygorenko | Test Engineering Notes

Test Engineering Notes - 2 роки!

#anniversary

Дев'ятнадцятого листопада 2021 року я створив канал Test Engineering Notes.
Це неймовірно, але ще один рік пролетів - й дуже швидко.

Результати за рік:
- Test Engineering Notes виріс більше ніж вдвічі
- пишу регулярні дайджести статей з тестування на DOU
- створив з Артемом свій власний подкаст з тестування - Testing Minutes
- виступив на найбільш кулуарній конференції - QA Party Hard у Львові
- ще більше читаю, пишу й говорю про тестування українською (й не тільки про тестування)

Дякую підписникам за те, що продовжуєте читати мене та писати коменти!
Дякую Артему Григоренко за те, що робимо цікавий подкаст разом!
Дякую ЗСУ за те, що маю можливість все це робити!

А я й надалі буду ділитись з вами цікавими, технічними та складними штуками зі світу тестування та інженерії.

Нотатки з Git від Julie Evans

#tools #git

- git reset —hard HEAD~X - відкотитись на X коммітів назад
- git diff HEAD~Y - показати, що було змінено Y коммітів назад
- git rebase -i HEAD~X - "стиснути" X коммітів в один
- git commit —amend - додати зміни до останнього комміту
- git commit —amend-no-edit - додати зміни "без питань"

Коли закомітили не в ту гілку:

- git checkout correct_branch
- git cherry-pick COMMIT_ID
- git checkout wrong-branch
- git reset —head HEAD^

Коли закоммітили зайвий файл:

- git rm —cached FILENAME
- git commit —amend

Коли хочеться прибрати один комміт в минулому:

- знайдіть SHA комміту
- git revert SHA
- введіть нове ім'я та створіть комміт

Коли потрібна "машина часу":

- git reflog
- git reset —hard HEAD{2}

Секрет швидкого кар'єрного росту розкрито

Laws of Test Automation

#testing #automation

Чергова холіварна стаття. ЦЬого разу не від Alan Page, а від Jason Arbon. У ній автор ділиться "законами автоматизації".
Кожен "закон" можна розбирати та дискутувати.

Law of Coverage. Automate frequent or difficult things.
Law of Speed. Speed kills quality and engineer’s time.
Law of ROI. Automation is the most expensive, slowest, and flakiest way to write tests.
Maintenance Principal. Automation exponentially becomes maintenance.
Law of Failures. When a failure occurs, it should be painfully obvious.
Mocking Principal. All tests can run locally.
Dollar Save Club Principal. Money saved on infrastructure costs more in engineering hours.
Boolean Principal. Not all tests are pass/fail.
Law of Automation Quality. Automation quality is inversely proportional to the number of classes, frameworks, and templates used
Law of New Frameworks. New frameworks are only for promotions.
Documentation Paradox. Tests should not need documentation.
Law of logarithms. The best test code is logging.
Law of Difficulty. Test code is the most difficult code to get right.
Law of Flakiness. Tests aren’t flaky, the test code is unreliable.
Law of Testability. Everything is testable with a little creativity.
Law of Frameworks. Frameworks enable bad test code.
Generation principle. Never generate test code.
Law of selection. Test selection adds risk.
Law of Shapes. Ignore pyramids, toroids, and ice cream cones.
Automation paradox. Don’t automate — unless you have to.
Reporting Principle. Other than 100%, percentages aren’t useful.

А ви з усіма законами згодні?

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

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

Розібратись з питаннями навчання себе та інших ведучим подкасту допоможе гостя - Наталія Попелишко. Багато хто її знає як авторку одного з найбільших україномовних YouTube каналів про тестування - Popeliuha!

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

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

P.S. Друзі! Це наш заключний випуск другого сезону!

А поки подкаст буде у відпустці - на каналі Testing Minutes вже є купу випусків, які можна послухати.

#testingminutes | @a_grygorenko | Test Engineering Notes