Performance Testing Webinar Record
#linkz

Привіт друзі! Вчора відбувся запланований вебінар. Хто хотів послухати, але пропустив - ось посилання - Performance Testing with Locust

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

​​(Не)упередженість в тестуванні
#truestory

Кому доводилось розраховувати ROI, наприклад для впровадження автоматизації тестування, той знає, що результатами підрахунків можна в певній мірі маніпулювати. Наприклад аргументовано з графіками продемонструвати що інвестовані в автоматизацію тестування кошти почнуть окупатися вже за 3 місяці, хоча в реальному житті це може бути 7-8. Або навпаки: зрозуміти в результаті підрахунків, що інвестиція окупиться приблизно ніколи, й тому ці результати нікому не показувати :) Як це робиться? - Коефіцієнт там, коефіцієнт сям.. й вуаля, "потрібний" результат готовий ;)
Ще один приклад упередженості в тестуванні, або швидше навіть зловмисної недбалості: іноді, нажаль, доводиться зустрічатись з "passed" тестами, яких насправді ніхто не торкався :(

Я от точно пам'ятаю що так ROI колись, років 12 тому рахував :) А ви так робили? Зізнайтесь кнопочці внизу поста ;)

Тепер, власне історія.
Хочу замінити собі смартфон. Старенький 5-річний Huawei P9 все ще класно фотографує, але йому вже зле. Одним з основних критеріїв для мене є якість фото. За цим критерієм взяв би топовий актуальний Huawei, якби вони не були під санкціями з недоступними google apps. Тому придивляюсь до найновіших Samsung. Зокрема Samsung Galaxy S21 Ultra. В ньому на папері все дуже круто (крім ціни :( ) Але ми всі достатньо дорослі щоб безоглядно довіряти маркетинговим матеріалам. Потрібні об'єктивні тести.
До суті. Якщо хто не знає, то одним з найвпливовіших ресурсів, що визначають фото рейтинги смартфонів, є dxomark. Тож я чекав на результати тестів нового Ultra смартфону від Samsung саме від лабораторії DXO. Вони їх досить довго не надавали. Samsung презентував нову модель в середині січня, а результати тестів з'явились лише на початку березня. В такій затримці є певний сенс, оскільки патчі прошивки в перші місяці після релізу благотворно впливають на функціональність смартфону в цілому й камери зокрема. Й ось, нарешті, дочекались, є результати тестів! .. але стривайте но, що це... 17-те місце?! Гірше минулорічного S20 Ultra? WTF?! Really?!
Перша реакція: розчарування (й полегшення, від того що зекономлю купу грошей :) ) Але потім з'явилися сумніви, підкріплені численними сумнівами коментаторів під результатами тестів.
Причини для сумнівів:
❓ хоч і пройшло 1,5 місяця після релізу, й Samsung за цей час випустив як мінімум два серйозних патчі прошивки з "фіксами" для камер - DXO всі свої тести робили на preview версії прошивки.
Це як ретестити фікси багів не на тому білді...
❓ DXO для частини оцінюваних знімків має контрольовані "лабораторні" умови, для частини - вулиця. Але, так чи інакше, всі знімки доступні в оригіналі, з повним набором EXIF метаданих. ... Всі крім Samsung Galaxy S21 Ultra! Майже на всіх знімках, зроблених для перевірки теле-фото режимів камер цього смартфона - навмисне затерті метадані!
Це як репортити баг, не вказуючи ані версію білда, ані версію браузера, ані енвайрмент, на якому його було знайдено...

І це тільки найкричущі відхилення від того, що можна було б назвати неупередженим підходом до тестування. Є ще й інші. Кому цікаво, ось тут стаття із доволі детальним розбором цих та інших невідповідностей: Deep Review - DxOMark проти Samsung.

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

PS а у вас там як, доводилось свідомо маніпулювати результатами на свою користь?

Навіщо я QA?
#truestory

Привіт друзі. Не пам'ятаю вже, писав чи ні - але сам час від часу повертаюсь до роздумів, навіщо я QA? То читаю черговий пост про "вайті в ІТ", то хтось в черговий раз питає, з чого почати кар'єру чи черговий раз десь починається холівар - тестування - придаток до програмування чи самостійна наука?

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

І ось на співбесіді на програміста мені кажуть: "в тебе знань малувато, але тестером можеш бути, якщо хочеш." Я в той час навіть не знав, хто це такий 🤷‍♂️ Але подумав, що попрацюю трішки та перекваліфікуюсь.

І ось пройшло вже 13 років, а я так і не змінив професію 🦒 Бо, як виявилось

👍 мені подобається тестувати. Робота приносить задоволення. Тестування робить світ кращим а користувачів ПЗ щасливішими. Як то кажуть - зменшуємо рівень ентропії.

👍 нормальних програмістів багато - а хороших та досвідчених тестерів треба ще пошукати

👍 тестування дає багато простору для роботи з різними технологіями - я за свою кар'єру працював і з "залізом" (різними контроллерами, датчиками, камерами), і з софтом в сферах безпеки, телеком, банку, офісу. І для великих корпорацій, і для малого бізнесу. Написаного на древньому коболі, всемогутньому С++ чи новітньому Java/JS/C#

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

А що вас найбільше мотивує бути QA?

MQTT performance test
#tools

Привіт друзі! Знов пропав на деякий час. Цього разу проти своєї волі протестував на собі корону 🦠 - такий собі досвід, не рекомендую, носіть маски 🦹‍♀️, будьте здорові!

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

На щастя, варіанти є! Знайшов плагін для JMeter і клієнт на python, на той випадок, якщо з JMeter щось не запрацює і доведеться реалізовувати підтримку mqtt в locust.

Для зручної роботи з сервером (щоб перевіряти, що повідомлення приходять), я рекомендую скачати MQTT-Explorer
Для тестування там навіть кілька тестових серверів є.

Щодо процесу тестування - все досить просто і описано в документації до плагіну - додаєте семплери для коннекту, відправлення/отримання повідомлення та дисконекту, вказуєте налаштування і вперед! Я лишень хвилювався за версію протоколу - пишуть, що плагін працює з mqtt 3.1.1, а сервер підтримував 5, але помилок з цим я не отримав (на щастя)

Оскільки це не http, то як повідомлення відправлено - семплер вважає успішною операцією.

Лише 1 момент мене збентежив і я ще хочу з ним розібратись. Пишуть, що mqtt сервер Mosquitto може тримати 1000 одночасно відкритих з'єднань. Але скільки б користувачів я не створював в Jmeter, при навантаженні більше 300 повідомлень/сек нові з'єднання не створюються. Щоб перевірити, це баг серверу чи клієнту, хочу зробити розподілений (distributed) тест, та ще руки не дійшли.

А ви колись мали справу з mqtt?

Годнота
#offtopic

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

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

А ще прочитав гарну книжку - Python Tricks: A Buffet of Awesome Python Features. Це вже трохи про IT, але все ще більше про годноту. Десь безкоштовно роздавали (не на торенті, все по чесному) - я й узяв. Не сказати, що книга відкрила багато секретів, але дала глибше розуміння тих буденних речей, що я використовую кожного дня. І просто весело написана. Використовую її зараз як джерело хитрих питань на співбесідах 😎

Напишіть, яку музику/книги ви відкрили для себе протягом карантину?

Citrix Performance Test - незакритий гештальт
#tools #performance

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

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

Почав шукати щось більш технологічне. Знайшов плагін для JMeter (здається, для всього на світі є плагін для JMeter), але він виявився дуже сирим і працювати не став 🤷‍♂️

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

А ви колись тестували citrix додатки?

Невідомий бог
#offtopic

Привіт друзі! Сьогодні ще один пост не зовсім про IT. Знаєте, як то часто буває - гортаєш ці ваші Інтернети і знаходиш статтю, якою дуже кортить поділитись. Я одразу подумав, що це буде гарна аналогія 😁

Отже, люди завжди намагались пояснити явища природи - до того, як все розклали по поличках науковці, їм в цьому допомагала релігія. Зійшло сонце - то бог сонця ☀️ зробив; подув вітер - то точно бог вітру 🌬 В Египетській міфології сумарно нараховують близько 700 різних богів на всі відомі явища.

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

І давні греки придумали дуже крутий "костиль" для своєї релігії - невідомого бога! Назвали його Агостос Теос, і відповідав він невідомо за що. І молились йому про всяк випадок, щоб не образився 😎

Набагато зручніше, ніж придумувати 700+ різних

Я як прочитав, подумав - це ж просто ідеальний покровитель граничних кейсів, рандому та костилів!

Як вам історія? Знали про такого раніше?

tech/uklon QA Hiring Weeks
#ads

Привіт друзі! Нам написали про подію, і ми вирішили, чому б нею не поділитись, може комусь стане цікаво.

Завітай на tech/uklon QA Hiring Weeks та прокачуй продукти Uklon, які юзають мільйони людей по всій країні!

⏰ Коли: 31 березня - 14 квітня
🚖 Відкриті вакансії:
✅ Middle Manual QA Engineer;
✅ Senior Manual QA Engineer;
✅ Senior Automation QA Engineer.

Реєструйся до 14 квітня та отримай шанс всього за тиждень стати частиною команди tech/uklon! Якщо в тебе з компанією буде метч, новісінький квадрокоптер або гіроскутер - твій! 🛰
Працюй з останніми технологіями з будь-якого куточка України або світу та отримай винагороду вище ринку. 💪🏼

⚙️Новітні технології та фреймворки:
➡️ Testing Tools: Charles, Postman, Fiddler, Android Studio Emulator, Sentry, GrayLog, Wireshark.
➡️ Automation testing: C#, Nunit, RestSharp, WireMock.
➡️ Monitoring: Grafana.
➡️ Containers: Kubernetes.
➡️ Mobile App: Kotlin, Xcode.
➡️ Web: Angular, C#, Node.js, Web-socket, REST API, Kafka, Python, Rebbit MQ.
➡️ DB: Redis, MongoDB, MsSQL, Postgre, EventStore, Elasticsearch.
➡️ Management Tools: JiRA, Confluence, TestRail.
➡️ CI/CD: GitLab, ArgoCD.

Більше про Hiring Weeks можеш дізнатися на сайті: https://bit.ly/3foYe9T

Full-page screenshot
#tools

В тестувальників іноді виникає потреба зробити не просто скріншот, а "сфотографувати" сторінку в браузері повністю, зверху й до самого низу (наприклад рецептом борща з кулінарного сайту поділитись ;) )
Як це зробити в різних браузерах без встановлення сторонніх плагінів?

🌐 Chrome
1. Відкрити консоль (Ctrl+Shift+I)
2. Відкрити меню команд (Ctrl+Shift+P)
3. Виконати команду "Capture full size screenshot"
➡️ png файл буде збережено в папку Downloads

🌐 Microsoft Edge (Chromium)
Оскільки під капотом Chromium, то можна зробити через консоль так само як в Chrome. Але Microsoft додає в Edge багато своїх фіч, серед яких є й можливість робити screenshot, та ще й потім його редагувати:
1. Меню -> Web Capture (або Ctrl+Shift+S)
2. Опція "Full Page"
➡️ Відкриється вікно редагування з можливістю малювати олівцем, зберігати у файл, копіювати в буфер

🌐 Firefox
1. Відкрити консоль (Ctrl+Shift+I)
2. В консолі відкрити опції (F1)
3. Ввімкнути опцію "Take a screenshot of the entire page"
4. Натиснути кнопочку з камерою "Take a screenshot of the entire page", що з'явилась на панелі інструментів консолі
➡️ png файл буде збережено в папку Downloads

🌐 Safari
1. Відкрити консоль на вкладці з інспектором елементів (CMD+OPT+I)
2. Ctrl+Click на елементі <body>
3. В контекстному меню обрати "Capture Screenshot"
➡️ Відкриється діалог збереження png файлу

А вам часто доводиться "фоткати" рецепт борщу повну сторінку?

Мій Excel кращий за твій: Spreadsheet Compare
#tools

"Excel - фундамент сучасної цивілізації" ;)
Ну тобто не стільки сам Excel зокрема, скільки електроні таблиці взагалі.
Й не те щоб "фундамент" - доводилось іноді зустрічати людей, які й без нього обходяться ;)
Але в цілому, погодьтесь, всім нам рідше або частіше доводиться працювати або з Excel, або з Google Sheets.

Один з сценаріїв використання Excel, який зазвичай не дуже часто зустрічається в повсякденній роботі - порівняння двох Excel файлів. Наприклад - щоб дізнатись про відмінності між новою та старою версіями.
✅ І якщо Вам таке за примхою долі доведеться робити, знайте: потрібний інструмент є, називається він Spreadsheet Compare й постачається разом з іншими Microsoft Office Tools в рамках пакету Plus.
➕ Там все гарно: можна вибрати яку саме різницю помічати (значення, стилі, формули, й інше), неспівпадіння підсвічуються.
➖ Чого не вистачає: синхронізації скролу й механізму merge.

Сподіваюсь Вам не дуже часто доводиться таким займатись ;)
Але все одно цікаво: доводилось?

Шок сенсація! Літак погладшав у польоті, а жінки помолодшали!
#bugseverywhere #friday

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

21 липня 2020-го року Boeing 737 о 5-й годині ранку вилетів з британського Бірмінгему в напрямку іспанської Пальма-де-Майорка з 187 пасажирами на борту.
Пілоти перевірили лист завантаження перед зльотом й відзначили, що заплановане завантаження суттєво менше ніж зазначено в іншому важливому документі - плані польоту. Також пілоти звернули увагу на неочікувано високу кількість дітей в листі завантаження - 65, порівняно з 29 зазначеними в польотному плані. Командир літака вже мав досвід із змінами завантаження безпосередньо перед вилітом через відмову деяких пасажирів від квитків, тому зважаючи й на інші передпольотні умови вирішив що ситуація знаходиться в межах норми. Але про цю розбіжність повідомив.

Як виявилось потім після детального дослідження - літак де-факто летів на 1244 кг важчим за розрахункову вагу. Й сталося це через те, що софт для чекіну пасажирів реєстрував дорослих жінок де-факто як дітей в тому випадку, коли перед їх ім'ям стояв префікс Miss. Усереднена вага дитини в системі - 34кг, жінки - 69кг. Помилково зареєстровано в якості дітей було 38 жінок. Відповідно, софт згенерував "лист навантаження" із помилково розрахованою вагою, суттєво нижчою за фактичну.
Й це трясця небезпечно! Їм могло не вистачити палива! Індустрія знає випадки, коли літак не долітав через невірно розраховану вагу :( Добре що в цьому випадку все скінчилось добре, всі долетіли куди треба.
Оператор запровадив тимчасову процедуру "ручної" перевірки титулів - працівники на чек-іні мали впевнитись що дорослі жінкі мають префікс Ms, а не Miss. А згодом за декілька днів й хотфікс для програми доїхав.

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

Замість висновку:
Тепер ви знаєте, що навіть Miss може підкинути проблем ;)

ПС А ще, дуже раджу ознайомитись з офіційним incident-report даної проблеми. Наприклад я, до ознайомлення з ним, вважав що з приводу баг-репортингу вже давно познав дзен, й про баг-репорти знаю все... як я помилявся.. ;)

Софт, що ним соколи й дракони скеровані
#truestory #longread

Мабуть з теми ви вже здогадались що мова про SpaceX та їх ракети Falcon й корабель Dragon.
Компанію, що повернула людству цікавість до космосу.
Мені ж, як інженеру з забезпечення якості, завжди цікаво було що там в них з софтом, й власне якістю :)
Натрапив на вихідних на одне відео на ютубі, поділюся з вами тими моментами, що окрім звичайної зацікавленості викликають ще й професійну.

🚀 Залізо
В космосі електронні системи мають бути надійно захищені від радіації. Якщо спростити, то є два шляхи досягнути потрібного рівню надійності: 1) використовувати дійсно захищене від радіації залізо 2) використовувати "звичайне" залізо, але надлишково його дублювати.
Перший підхід надає високий рівень відмовостійкості, але він не для SpaceX, тому що по перше: спеціальні радіаційно захищені процесори не тільки доволі повільні, але й дуже багато коштують (наприклад 200-300.000$ за 1 IBM RAD6000 CPU - такий встановлений на марсіанських роверах Spirit та Opportunity), по друге, що навіть важливіше: такі процесори мають свою власну архітектуру й дуже обмежену кількість інструментів й відповідно інженерів, які знаються на них.
Тому SpaceX обрала другий підхід: надмірне дублювання систем. Якщо бути точним - потрійне.
Dragon має три двоядерні x86 CPU, які постійно виконують одні й ті самі задачі, перевіряючи чи не схибив бува один з них із обчисленнями. Якщо один схибив - він одразу ж перезавантажується й синхронізується з двома іншими для продовження роботи. Окрім CPU в кораблі є ще 18 систем, що мають процесори - всі вони також трикратно дубльовані.
Falcon9 так само має по 3 процесори на кожну систему: CPU - 3 процесори + на кожен з 9 двигунів по 3 процесори.

🚀 Софт
Оскільки SpaceX обрала "звичайні наземні" процесори для своїх ракет та корабля, то й в якості ОС - очікувано Linux. Як на комп'ютерах розробників, так й в кораблях, й ракетах. Мова програмування - C++.
Цікаво (й логічно), що SpaceX намагається перевикористовувати якомога більше коду між Falcon9, Falcon Heavy та Dragon - це дозволяє фіксити один баг відразу в трьох девайсах :)
Було б дивно, якби в SpaceX не практикувався Continuous Integration - код збирається та тестується юніт-тестами.
Щодо тестів - велика їх частина (нажаль достеменно невідомо яка саме) робиться на актуальному апаратному забезпеченні, але про це нижче.

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

🚀 Тестування
Кому доводилось тестувати системи, які безпосередньо взаємодіють із "залізом", тому напевно знайомий такий термін як "тестовий стенд". В моєму досвіді "тестовим стендом" були як дошки ДСП з прикрученим контролером дверних замків, так і повноцінна ізольована кімната-лабораторія з купою різних пристроїв для системи відеоспостереження.
SpaceX звісно також має купу різноманітних тестових стендів. Й варіюються вони так само - від десятків процесорів на чиємусь робочому столі (ще пам'ятаєте про вартість процесорів як один з чинників обраного підходу?) до повністю зібраних до купи електронних компонентів ракети Falcon9, з якими можна провести повноцінну симуляцію польоту для знаходження потенційних проблем.

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

Про правила та їх однозначне розуміння 🤓
#fun

Привіт друзі! Читав ту різні цікаві статті в Інтернеті, і на кількох різних ресурсах зустрів дуже схожі за описом проблеми. Вони не мають прямого відношення до тестування, швидше до математики, правил та вимог (тобто про задротство 🤓, не можу таке пропустити).

Власне проблеми були опубліковані вище, як вирішити наступні вирази:
1️⃣ 2x : 2x = ❓
2️⃣ 5 : 1/5 = ❓

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

А тепер до суті.
✅ В математиці є пріоритет операцій. Множення та ділення виконуються до додавання та віднімання, тобто 2 + 2 * 2 = 6.
✅ Дужки можуть змінювати пріоритет операцій, наприклад (2 + 2) * 2 = 8.
✅ Знак множення у виразах з невідомими та дужками можна не писати, тобто 2х == 2 * х

А тепер повернемось до наших виразів
1️⃣ Якщо рахувати буквально, то 2x : 2x = 2 * х : 2 * х = x^2, але багато хто в Інтернеті та навіть в деяких навчальних посібниках сприймають вираз 2x : 2x = (2x) : (2x) = 1. Ось вам і однозначність 🤷‍♂️ Не можу навіть звинуватити, що хтось неправий (мозком розумію, що варіант 1 більш правильний, але сам спочатку порахував за варіантом 2). Сам же, щоб запобігти такій неоднозначності, в програмуванні та математиці користуюсь дужками. В моєму коді в математичних вираз дійсно багато дужок. Хто бачив про приколи з приведенням типів в тому ж JS, певне, теж так роблять

2️⃣ Другий вираз здається простішим, але в твітері розгорнувся цілий срач про результат 5 : 1/5 =❓. Я цей вираз рахую як 5 : 1 : 5 = 1, оскільки це все операції ділення. Інший "табір" стверджує, що його треба сприймати тільки як 5 : 0,2 = 25, тобто сприймати 1/5 не як операцію ділення двох чисел, а як число! Операція ділення / має пріоритет над : ? Щоб запобігти двозначності в таких випадках, я завжди рекомендую користуватись єдиним способом позначати операції.

Як бачите, навіть в таких фундаментальних речах, як запис математичних виразів можуть бути баги (чудова відмазка, чому не знайшов той баг з прода 😁). Тому не втрачайте пильності!

MQTT Testing
#performance

Привіт друзі. Кілька тижнів тому я вже писав, що трохи розбирався з тестуванням навантаження з протоколом MQTT. Історія на тому не закінчилась, і мені так чи інакше довелось писати генератор MQTT повідомлень на python, бо JMeter щось з метриками прибрехав. Вирішив про це невеликий пост на ДОУ написати - поділитись спостереженнями та може дізнатись у спільноти про їх рішення в подібному тестування.

Приємного читання

Just for Fun
#friday #fun

Гарної п'ятниці, друзі! Кілька років тому, до пандемії, чи не на кожній конференції можна було зустріти доповідь про мікросервіси: як це круто, ново та зручно. А на кожному IT ресурсі можна було "похоліварити" про плюси та мінуси мікросервісів у порівнянні з монолітної архітектурою додатків.
Так вийшло, що я став більше скептиком мікросервісів, навіть статтю написав на DOU, де, звісно, читачі одразу ж написали, що то в нас неправильні мікросервіси і я все роблю не правильно 😁

Але мова сьогодні не про це. Читаю зараз гарну книгу, і вам також її рекомендую - Just for Fun, біографія Лінуса Торвальдса (чувак створив Linux, хто не в курсі). Дуже гарно написана і читається на одному подиху. І в першій частині книги є історія про суперечку з Ендрю Таненбаумом, автором книги про розробку операційних систем (що надихнула Лінуса) і Unix сумісної ОС Minix. Суперечка, напевне, настільки знакова, що має навіть власну сторінку на вікі

Перекажу коротко суть, щоб ви зрозуміли іронію і до чого тут мікросервіси.
На дворі 1992 рік, Ендрю пише Лінусу:
Е: Linux застарів одразу після створення, монолітні ядра ОС, це концепція 70-х років.Майбутнє ОС - за мікроядерною архітектурою, де кожне мікроядро відповідає за свою невелику частину роботи, що забезпечує простоту розробки, підтримки і т.д. Як от система Amoeba, над якою я зараз працюю...
Л: Так, мікроядерна архітектура з теоретичної точки зору виглядає дуже гарно, але має ряд суттєвих недоліків, ключовий з яких - спрощення функцій в мікроядрах невідмінно збільшить складність інтерфейсів, через які мікроядра взаємодіють, тому виграш виходить сумнівний...

Там іще аргументи були, але не хочу далі спойлерити, рекомендую читати самим. Але історія показала, чий підхід виявився продуктивнішим 😺

Як бачите, сучасна концепція мікросервісів зовсім не нова 🤷‍♂️

Яка відстань до "горизонту" в багах?
#bugseverywhere #longread

Ще одна історія про дефекти в ПЗ, які мали значний вплив на життя людей.
У 1999 році Пошта Великобританії впровадила в мережі своїх відділень нову систему "Horizon", розроблену японською компанією Fujitsu. Ця система поєднувала в собі як софт, так і "залізо". Приблизно 40,000 терміналів підключених до Horizon, було встановлено в поштових відділеннях по всій країні. Впровадження Horizon обійшлося бюджету в 1 млрд фунтів. Ця система й досі забезпечує бухгалтерський облік, інвентаризацію та проведення транзакцій між ~11,500 відділень та головним офісом пошти.
В період з 2000-го по 2014-й Пошта звинуватила 736 співробітників своїх відділень у шахрайстві, відмовляючись визнавати те, що справжньою причиною невідповідностей у фінансових показниках числених відділень були дефекти системи "Horizon".
Частина звинувачених поштарів збанкрутували через п'ятизнакові штрафи від пошти (приклад для розуміння: 38,000 фунтів), частину було ув'язнено, дехто перезакладав свої домівку щоб сплатити суми штрафів виконавчим службам, дехто не зміг влаштуватися потім на іншу роботу через "кримінальну" справу в історії праці. Іншими словами - суттєвій кількості людей спаскудили життя.

Як це виглядало для працівників поштових відділень (доречі, в них поштові відділення працюють ніби як за франшизою, тому кажу "працівник" - маю на увазі "власник"):
😱 Прокинувся зранку у 2000-му році й побачив що баланс не сходиться на 6000 фунтів не на твою користь. Почав розбиратися й завдяки IT бекграунду побачив що через нічний апдейт софта - продублювався один з видів пенсійного депозиту на 5000. Відправив корегуючу транзакцію, чим пофіксив цю частину нестачі. Про залишок нестачі у 1000 фунтів ти повідомив службу підтримки, де тобі збрехали що серед десятків тисяч працівників ти єдиний маєш таку проблему. Пізніше тебе почали пресувати виконавчі служби головного офісу на тему повернення "боргу". Ти сперечався, прохав показати логи, тобі не показували. За два роки цю 1000 списали, нічого не пояснюючи тобі, але сказали що маєш сплатити 1400 фунтів іншої нестачі, про яку ти взагалі ні сном ні духом. Ти не погоджувався нічого платити, поки не покажуть логи - знову не показали. Ще за рік контракт з тобою розірвали.

Лише рік тому, у 2020-му році об'єднання колишніх поштарів, яке займається колективними позивами до Пошти досягло певного успіху в визнанні Поштою своєї неправоти. Цей "певний" успіх на даний момент вимірюється 58 мільйонами фунтів, які Пошта погодилась виплатити постраждалим.
Звідки ж брались всі ці кримінальні справи проти співробітників поштових відділень?

Згідно досліджень сторонньої компанії Second Sight, якій довірили аудит системи - найпроблемнішими місцями Horizon були: комунікація між компонентами системи непродуманість якої призводила до числених випадків розсинхронізації (яку важко було виправити в автоматичному або напівавтоматичному режимі), застаріле обладнання, упереджене ставлення менеджменту, погане навчання та підтримка, відсутність traceability щодо транзакцій та деякі інші.
Більш повний перелік з поясненнями є в повній версії статті на нашому сайті.

Мораль така: якщо ваш менеджмент дуже хоче вірити в те, що багів немає, та в тестування до виходу продукту в прод - не інвестував, то вам кранти.

Сподіваюсь вам сподобалась ця історія, й ви так само праведно гнівались через скалічені багами людські долі як і я, поки шукав та перечитував силу силенну статей та документів на цю тему. Більше того - мені тепер стало страшенно цікаво: а як поставлені процеси тестування у наших поштових операторів, особливо в найбільших з них: УкрПошті, Новій Пошті. А вам цікаво? Може маєте інсайди?

Воркшоп з Playwright
#event

Привіт друзі! Якось вийшло, що підписався провести подію і зовсім забув про неї розказати.

Я з кінця минулого року вивчаю інструмент для автоматизованого тестування playwright і маю час на натхнення трохи про нього розказати. Я вже писав кілька постів на каналі та DOU, а зараз разом з коллегою створюю за його допомогою автотести в комерційному проєкті.

Якщо дуже коротко описати мої враження - я просто в захваті! Саме цим і хочу поділитись - які фічі вийшли дійсно корисними та як ними користуватись.

Воркшоп з Playwright - промокод
#event

Привіт друзі! Для анонсованої вчора події в нас є промокод на знижку 100 грн

PTAP270521

Доступний всім підписникам каналу 😺