Як можна отримати штраф за чатбота

#ai #bugsinthewild

Знайшов цікаву історію про те, AI (а саме чатбот) привів компанію Air Canada до суду та штрафу.

Головному герою цієї історії, Джейку Моффату, потрібно було терміново летіти в інше місто в зв'язку зі смертю родича. Він купив квитки на літак в Air Canada - з Ванкуверу до Торонто.

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

Коли авіакомпанія відмовилася надавати знижки, Моффат пішов до суду. Бо Джейк вважав, що чатбот йому збрехав. Й надав скріншоти розмови.

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

Висновок: відмазка "це все чатбот, а не ми" - в канадському суді не проходить.

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

Поки ви дивитесь новий випуск DOU QA подкасту, рекомендую створити чергу із випусків в Українських подкастів та в нього додати сьогоднішній епізод подкасту Testing Minutes.
Є ще одна тема, яка стрімко росте й розвивається останні роки. Це - Internet of Things. Що це таке та як його тестувати (та автоматизувати) розбираємось у цьому епізоді разом із гостем - Богданом Савчуком.

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

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

#testingminutes | @a_grygorenko | Test Engineering Notes

Усім привіт!

У черговому випуску до нас прийде в гості Олександр Романов із подкасту Testing Minutes, і ми будемо говорити про тестування та якість програмного забезпечення.

Приєднуйтесь до нас як завжди в суботу о 19:00 за Києвом. Будемо раді побачити ваші питання та коментарі під час прямого етеру!

https://www.youtube.com/watch?v=mvbLkNWfocg

Does expectations for QA skills got super crazy?

#testing

Тестувальники на реддіті жаліються, що вимоги до вакансій за останні декілька років піднялись "до небес".
Шо тепер треба не просто тестувальника, а фулстек девелопера + девопса.

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

А ви як думаєте - чи підвищились вимоги, чи ні?

Про апдейти та розумні девайси

#testing #bugsinthewild

Коротка повчальна історія про те, чому тестування апдейтів - то важливо.

Є відома компанія - виробник електроніки Electrolux. А в них є дочірня компанія AEG, що займається розробкою софту.
Так як IoT - то стильно, модно й молодіжно, то новітні електронні прилади почали робити "розумними". Наприклад - додавати модуль WiFi.
По WiFi зокрема прилітали оновлення софту.

Одного разу інженери з AEG щось недотестували. Або ж поспішили зарелізитись в продакшн.
Як результат, одного холодного зимнього ранку клієнти прокинулись, запустили свої микрохвильові печі та були трохи спантеличені. Микрохвильовка вночі отримала нову прошивку та вважала себе тепер ... - ПАРОВАРКОЮ. З усіма доступними пароварці функціями.

Виглядає як бага, але ж можна "швидко викатити хотфікс, у кого не бува такого!". Але є маленьке але.
Після оновлення прошивки ... на усіх девайсах з багою відвалився модуль WiFi. Тож полагодити швидко - не вийшло.

Висновок: тестування оновлення - вкрай важливе (для розумних девайсів також).
Плюс треба подумати, що робити, коли немає підключення до інтернету.

SSH Port
#engineering

Невеличка, але вкрай захоплююча історія про те, як створювався SSH та чому він запускається саме на порту 22.

⚡️ Епізод 27: Де тестувальник будує ком'юніті разом з Саймоном Томсом (Ministry of Testing) (англійською 🤯)

Наш подкаст продовжує розвиватись та запрошувати різноманітних гостей. В цей раз пробуємо англійською 🤗

Іноді добре зосередитися і працювати самостійно. Але іноді вам потрібно відчути себе частиною чогось більшого: отримати більше точок зору, отримати зворотний зв’язок. Це час, коли спільнота може допомогти.
У цьому епізоді ведучі Артем та Олександр разом із гостем Саймоном Томсом намагаються зрозуміти більше про побудову спільноти!

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

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

#testingminutes | @a_grygorenko | Test Engineering Notes

List of 2024 Leap Day Bugs

#testing #bugsinthewild

Тестувальники не потрібні!

Ми пишемо код без багів!

В нас серйозний продукт та покриття коду майже 100%

А баги з високосним роком все ще актуальні, як ніколи. Навіть в 2024 році!
Приніс вам цілу підбірку таких випадків.

Test Engineering Notes — Vol. 11. Про ШІ в тестуванні, поради для інтерв’ю та UI-тести в Netflix

#testing #engineering #digest

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

- тренди тестування та автоматизації у 2024 році;
- чому не треба панікувати через ШІ та які інструменти можна застосовувати прямо зараз;
- тестування GraphQL, gRPC та circuit breaker-ів;
- новий фреймворк для UI-тестів від Netflix;
- внутрішня магія Git;
- покроковий реверс інжиніринг девайсу для розумного дому;
- поради для проходження інтерв’ю.

⚡️ Епізод 28: Де тестувальник шукає першу роботу разом з Аміною Олійник

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

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

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

Окрім того, за різні підписки ви зможете отримати доступ до закритого чату подкасту, отримувати нові епізоди до самого виходу, а також є можливість присутності під час запису 😏

#testingminutes | @a_grygorenko | Test Engineering Notes

Баг чи фіча? Заводимо таску на тестування цін квитків DOU Day 😏

Зараз там один квиток за повну ціну, а другий видає за 50%. Пропозиція діє до 11.03, відповідно тестувати треба якнайшвидше 👉🏻 https://dou.ua/goto/Tb7A

Test Like Google & Facebook: Simon Stewart

#testing #automation #video

Трошки інсайтів користування Selenium в Google / Facebook від Саймона Стюарта.

Настав час стати QA Leader 💡

Приєднуйся до менторської програми "Шлях до QA Leader", яка створена моїм колегою по подкасту - Артемом Григоренко (QA Coach з десятирічним стажем роботи в різних компаніях від аутсорсу до продуктових).

Що тебе чекає, окрім якісного навчання?

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

всі деталі тут

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

Якщо б архітекторам прийшлося працювати так, як розробникам

#engineering #fun

Переклав оригінальний пост (аж 1997 року!) українською, для того, щоб показати як насправді виглядає розробка софту.

Шановний пане Архітектор!

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

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

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

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

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

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

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

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

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

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

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

P.P.S.
Можливо, мені потрібен зовсім не будинок - а трейлер. Будь-ласка повідомте мене якомога швидше, якщо це так.

Автентифікація у Web - невеличкий посібник

#security

Час від часу читаю та слухаю матеріали з кібербезу (бо цікаво).
Ось натрапив недавно на гарний посібник з багатьох аспектів автентифікації у Web.
Плюс - є навіть підбірка гайдів від OWASP (там просто купа корисного!)

Чому не треба зловживати ChatGPT та іншими AI інструментами для резюме

#interview

Вчора прочитав цікаву статтю від Ben Hoyt з Cannonical. І хочу поділитись головними тезами з неї.

Не зловживайте ChatGPT

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

Не користуйтеся "квітчастою" прозою

Резюме - це не роман чи оповідання.
То ж не треба застосовувати тут усю свою літературну майстерність (залиште це для IELTS / TOEFL чи власного блогу).

Автор наводить приклад:

- had a profound mastery of Java (they’re not James Gosling)
- their journey commenced (they’re not Bilbo Baggins)
- they skillfully constructed programs (they’re not Stradivarius)
- they extended their expertise (not only an expert, but an extended one)
- they crafted Lambda functions (I prefer artisanal Lambdas)
- they leveraged Spring Boot (or did they just use it?)
- they swiftly adapted (this is getting old)
- they meticulously read documentation (good, I will hire them as a proof-reader)
- they embraced object-oriented programming (like everyone in the 90’s)
- and they brought forth robust experience (but do they bring robust Forth experience?)

Тому концентруйтеся саме на суті та пишіть простіше.

- I’m experienced with Java
- I started
- I built
- I learned
- I wrote Lambda functions
- I used Spring Boot
- I adapted
- I read the docs
- I use object-oriented programming (or drop that entirely)
- I gained experience

Не узагальнюйте

Наприклад, на питання "Як би ви описали процес додавання нових фічей на продакшн", кандидати часто пишуть так, наче скопіювали з книги:

Designing and implementing new software starts with gathering requirements, writing a specification, seeking feedback from stakeholders, and then a quality implementation. After it’s implemented, automated testing and manual QA are important. Then we deploy the software and make sure to monitor it properly.

Своїми словами можна описати це так:

I really like succinct specs and some up-front planning. When I was designing the new auth service, for example, I wrote a 3-page spec that included an architecture diagram and a brief denoscription of the API endpoints. Before deploying to production, I think it’s important to load test a real server, so I set up a similar staging environment and measured how many concurrent requests it could serve. Once in production, monitoring is crucial: I’ve used Datadog as well as open-source tools like Prometheus to detect and diagnose issues.

Висновок

Cannonical навіть додали застереження від застосування AI інструментів для резюме в свою форму подачі.
Користуйтеся інструментами обережно.

Тест план за п'ять хвилин, або техніка RCRCRC

#testing

Чи бувало у вас так, що забігає менеджер та каже - "Треба швидко релізитись, у вас є 5 (10, 30, 60) хвилин - тому швиденько перевірте цей білд та йдемо на прод!"

Що при цьому тестувати? Як обрати найважливіше з тієї великої кількості тест кейсів, яка у вас є?
Звичайно, можна подивитись на пріоритет тестів, на ризики.

А можна - застосувати техніку RCRCRC, яку придумала Karen N. Johnson. Та створити тест план за 5 хвилин.

Що таке RCRCRC?

Це техніка, що допоможе вирішити, які фічі включити в тестування в першу чергу - та сформувати швидкий тест план для конкретного білду (релізу).

- Recent. Нові фічі та частини продукту, що були змінені в останньому релізі. Можна подивитись також git diff
- Core. Головні та найбільш використовувані фічі. Можна визначити за допомогою статистики та моніторінгу юзерів на продакшені.
- Risk. Найбільш ризиковані частини продукту. Там, де більше багів, або ж там, де cyclomatic complexity коду - найбільша.
- Configuration-sensitive. Фічі, які найскладніше налаштовувати.
- Repaired. Частини функціональності, де були останні баг фікси.
- Chronic. Частини продукту, які найчастіше ламаються.

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

Оракули в тестуванні

#testing

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

Що таке оракул?
Оракул в тестуванні - це будь-яке джерело, яке ми можемо використати, щоб зрозуміти що поточний результат є очікуваним.

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

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

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

А якими оракулами користуєтеся ви?

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

Хайп мікросервісів вже пройшов. Наразі це лише один з багатьох підходів до проектування бекенду. Але є велика ймовірність, що ваш поточний чи майбутній проєкт буде мати під капотом десятки й сотні маленьких сервісів. Як правильно підходити до тестування та автоматизації таких систем ми (Артем та Олександр) й будемо розбиратись в цьому епізоді.

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

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

Окрім того, за різні підписки ви зможете отримати доступ до закритого чату подкасту, отримувати нові епізоди до самого виходу, а також є можливість присутності під час запису 😏

#testingminutes | @a_grygorenko | Test Engineering Notes