QAMania

⚙️ Management -> Engineering - downgrade? part 2

Привіт друзі! Продовжую описувати власний досвід про перехід з менеджерської посади на інженерну.

Взагалі, ми навіть на подкасті з Ромою і Наталкою обговорювали, що часто-густо, менеджмент, це дорога в один кінець - технології так швидко розвиваються, що як тільки перестаєш працювати з ними напряму, одразу втрачаєш навичку. Це дійсно правда. Втягнутись в ритм щоденної розробки мені було надзвичайно складно. Мої перші PR-и містили більше зауважень і коментів, ніж змін, які я зробив 😸

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

Але я й не переставав повністю займатись інженерією - постійно писав пет-проєкти, робив PoC на нові технології, робив невеликі курси по автоматизації та перформансу, пишучи і переписуючи код багато разів. І це гарно спрацювало. За майже пів року роботи AQA інженером, я не тільки почав гарно писати код, та ще й опанував bash і докер на рівні, на якому ніколи й не планував його знати 😅

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

Далі буде!

Management -> Engineering - downgrade?

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

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

Перш за все - нова компанія! Хто мене хоч трохи знає - я працюю в ІТ більше 15 років і весь цей час працював з компанією Infopulse. Люди, з якими я провів вагому частину свого дорослого життя - сформували мене як спеціаліста, передали мені свої цінності, поділились знаннями і досвідом. Багато хто, як от Міша, стали моїми найліпшими друзями ❤️
Тому мені міняти роботу, сталий ритм життя і коло спілкування було ой як не просто. Але я радий, що в нас в Україні дуже багато класних спеціалістів і компаній! Коли я підключився на перше інтерв'ю з рекрутером nCube - після перших же хвилин зрозумів, що ми маємо спільні цінності і мені буде комфортно працювати з ними. "Наша компанія активно допомагає ЗСУ, не працює з руснею і не толерує русню" 🔥 А сама вакансія - робота з ШІ на пайтоні - просто всі зірки зійшлись!

Тож зараз я працюю просто AQA Engineering і задоволений! Уявіть собі - в мене 1 мітинг на день на 5 хв, а далі купа роботи, яку я можу сам вибрати і пріоритезувати. Безперечний плюс!

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

Думки поки що закінчились, але далі буде!

Такееее для вас готую…

В новому році я з двох ніг вриваюсь в ютюби, буду заливати вже відзнятий курс по шарпам, тематичні відосики для QA, і головне…

Мені рівно не сиділось і я придумала собі в канал нову рубрику з кодовою назвою «Обнять і плакать», але з офіційною «Спаси і ctrl+S».
Суть цієї чудесної рубрики в тому, що за 12 місяців МЕНЕ проінтервʼювають 12 поважних і шанованих в світі ІТ спеціалістів.

Питання будуть для мене сюрпризом, хоча я звісно буду готуватись, але позоритись перед вами в прямому ефірі я буду знатно:)

І ось він анонс: 16.01, в четвер, записуйте собі в календарики що о 19:00 Олексій Остапов відкриє цю рубрику і перевірить мене на відповідність сеньйорності на позицію Manual 😉

Всіх запрошую на публічний допит Попелюхи 👾
Посилання скину за день до, і зможете знайти як трансляцію в Ютюбі

🎄 Підсумки 2024 року?
#новорічне

Привіт друзі! Багато разів писав і переписував ці підсумки року. Бо важко підібрати слова, щоб передати всі думки і почуття 😵‍💫

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

На фоні всіх існуючих проблем в буквально у всіх сферах життя дуже легко зневіритись і опустити руки:
⚠️ проблеми на фронті
⚠️ беззаконня в тилу
⚠️ влада, яка за 3 роки вторгнення може забезпечити міністерства потужної єдності та плани переможної потужності, але не може купити і поставити літаючи дрони
⚠️ скорочення в ІТ
⚠️ падіння економіки та інфляція

Говард Лавкрафт з його хтонічним жахом нервово курить в стороні 🚬

Саме тому я вважаю правильним дати нашій спільноті промінчик надії.
✅ По-перше, в нас є ми - спільнота QAMania, DOU, KOLO, IT - ми тут, ми живемо і працюємо! Минулого року я був щасливий спілкуватись із вами на кожній відвіданій офф-лайн події!
✅ По-друге, в кожного є родичі та друзі - хто в складі ЗСУ, незважаючи ні на що продовжує захищати нас! Одна думка про них не дає зневіритись!

Минулого року я проаналізував виписки, щоб зрозуміти об'єм донатів і прямих закупок для своїх друзів. Цього року я зробив так само і нарахував 💸 830 тисяч грн власних коштів. А разом зі зборами, які ми проводили в нашому блозі, ця сума сягає більше мільйона! Пишаюсь вами ❤️

Можна скільки завгодно класти хуями владу за неефективність та бездіяльність, але якщо моєму рідному 18 батальйону морської піхоти треба РЕБ на вчора, то я можу щось з цим робити і я роблю.
Я пишу це не щоб похизуватись, а щоб показати - скільки б в твітері не писали "всьо пропало" - разом ми можемо багато! Ми не одні! Волонтерство і донати все ще важливі! Вони рятують життя і вбивають окупантів!

Будьмо сильними в цьому році!
Слава Україні! 🇺🇦

Tech Meetup
#ad

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

Ви дізнаєтесь про те, як уникнути типових помилок в роботі над проектом, як зробити так, щоб дизайн ефективніше втілювався в код, результативно комунікувати та оптимізувати сам процес. Yehor Sokhan, Head of Design (12+ years of experience) розповість про свій досвід і поділиться практичними інструментами планування та ведення проектів.

Реєстрація за донат на ЗСУ - https://tech-meetups.qarea.org/more-details-common-language-ux-dev-qa

👍 План стійкості тестування

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

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

1. Потужна єдність - всі QA мають єднатись з розробниками. Задушіть їх в своїх обіймах, якщо потрібно
2. Незламний тест кейс менеджмент - потрібні зміни в керуванні тестами. Терміново провести рев'ю всіх написаних тестів і видалити всі, що не потужні
3. Потужні тест тули - нестачу грошей на інструменти компенсуємо неоплачуваними овертаймами. Хто немає ноута для роботи, нехай тестує на листочку
4. Гроші - потужно і незламно просимо у замовника грошів
5. Безпека - Оскільки сама лише присутність QA на проєкті захищає критичні фічі від багів, просіть більше грошів
6. Продам гараж. Тут може бути ваша реклама
7. Стратегія стійкості - обіцяйте обіцяти нові потужні плани назламності щомісяця, і не робіть це із "скучним лицем, бо грошів ніхто не дасть" (с)
10. Я втомився писати. Пунктів ну майже 10, і вазагалі - хто там рахує? Ви шо, самі умні?

Користуйтесь!

#Звіт за дрон

Привіт друзі. Нещодавно публікував пост зі збором на дрон. Необхідну суму вже зібрано, дрон закуплено і передано. Всім дякую за участь! Ось посилання на повний звіт https://www.facebook.com/story.php?story_fbid=3709981755881436&id=100006089448894&_rdr

Разом до перемоги!🇺🇦

💰 ROI та Codeless автоматизація

Привіт друзі! Якщо ви пропустили - на DOU нещодавно було опубліковано гарний пост про розрахунок ROI автоматизації тестування Codeless інструментом. І хоча в коментах більшість людей накинулась обговорювати плюси та здебільшого мінуси Codeless автоматизації, як на мене, сама суть поста - про те, як врахувати всі аспекти мануальногго тестування, автоматизації, порівняти їх і вирахувати, чи взагалі варто займатись автоматизацією у випадку, якщо команда чи бізнес хоче зекономити таким чином грошей.
А як вишенька на торті - реальний, хоч і анонімізований кейс порівняння ROI для класичної та Codeless автоматизації. Ми з Михайлом таке теж іноді рахували, і це дійсно стає опцією - якщо тестований продукт можна покрити автотестами не пишучи код, чи варто переплатити за нього, чи може дешевше використати безкоштовний і найняти більш скілового спеціаліста.

https://dou.ua/forums/topic/51191/

‼️ Льошина 1000

Привіт друзі! Трохи заклопотаний через роботу, мітапи та підготовку до дев челенджу, але я про всіх вас не забув.

Я вирішив підтримати ініціативу нашого незламного президента і потужно допомогти нашій QA спільноті. Щоб запобігти скороченням в ІТ і дати тестувальникам більше роботи, я дав розпорядження міністерству потужної незламності видати кожному QA в Україні по 1000 багів! 🐞 По нашим розрахункам - вони вже мають надходити в ПЗ, яке ви тестуєте. Просто проведіть регрешн чи хоча б smoke - і знайте, всі знайдені вами баги - то від мене.
Оскільки багів у всіх стало більше - сміливо йдіть до керівництва і просіть більше грошів, щоб потужно знайти всі баги 💪

Не забудьте розказати про “Льошину тисячу” колегам - най перевірять застосунки, що тестують!

#Збір на Мавік

Привіт друзі! Мій знайомий колега і волонтер відкрив збір на мавік, нижче його пост. Будемо вдячні за допомогу і поширення (посилання на збір)
➿➿➿➿➿➿
⚡️ Дрон для ППО ⚡️
Друзі, вітаю!
Наш близький друг служить у ППО (643 окремий зенітний батальйон 831 бригади тактичної авіації)
Раніше ми допомагали цьому підрозділу зі старлінком та колесами, але зараз виникла нова потреба - хлопцям потрібен дрон.
Після збиття ворожих БПЛА, їм доводиться шукати ці БПЛА пішки, витрачаючи купу часу.
Щоб пришвидшити і полегшити пошуки, необхідний DJI Mavic 3 (звичайний, без тепловізора).
Це значно підвищить ефективність роботи і зекономить їм сили.
Мета збору: 80,000 грн.
Схема проста як завжди: збір —> закупка —> передача —> звіт.
Реквізити:
💳 Монобанка: https://send.monobank.ua/jar/8fo5KJb1vy
💳 Номер банки: 5375411223863395
💳 Приват: 4731219659848570
Всі реквізити на імʼя: Валелерій Синенко
Давайте допоможемо їм, захистити нас!

Привіт друзі! Хочу похизуватись гарною футболкою, що мені подарували @istqb_certified_unicorns, побажати гарної та спокійної п'ятниці і нагадати, що завтра можемо зустрітись у Роми Якимчука на https://conference.ry-consulting.online/

#devchallenge
⭐️ Завдання №4 - тестова стратегія

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

✅ Expected results
Стратегія має мати
🟢Користь для бізнесу
🟢Цілі тестування
🟢Підхід (Approach)
🟢Метрики
🟢Умови початку і закінчення тестування (Entry/Exit Criteria)
🟢Об’єм робіт (Scope)
🟢Ризики і питання (оскільки опис дуже короткий)
В цій задачі нема правильних та не правильних рішень - все в рамках адекватності

⚠️ Actual results
🟠Таке враження, що більшість знову використала ШІ і навіть не почитала, що вписує в стратегію
🟠Я бачив багато робіт з майже ідентичним змістом. Більш того - це generic відповідь chat-GPT про тестову стратегію - він просто перелічує всі відомі йому підходи, незалежно від того, чи вони тут можуть бути використані.
🟠Багато проблем з визначенням користі для бізнесу - здається, QA інженери не розуміють, навіщо взагалі компанії платять за тестування
🟠Якщо у вас є пів року, у вас фізично не буде часу на автоматизацію, враховуючи, що треба покрити Android, iOS, браузерну версію і стару версію на Delphi (навіщо?)
🟠Багато хто запропонував зробити фокус на Performance та Security тестуванні - я фанат, але ви впевнені, що ви це зробите? І чи треба саме на цьому фокусуватись? Може спочатку функції перевірити?
🟠Метрики - мало виписати список всього, що ви прочитали в інтернеті - метрики служать цілі. Якщо ваша ціль тестування - скорочення часу розробки, то й метрики мають бути спрямовані на визначення, чи ви виконуєте цю ціль, а не просто кількість тестів та багів
🟠Ризики - це складна тема. Саме тому для вас Рома попросив додати слона в кімнату - застосунок на Delphi, який треба підтримувати, і витрачати на нього увагу. Очевидний ризик! Але не всі побачили

💡 Загальне враження -Хоча я й написав багато ай-ай-ай, але в цілому, мені сподобались стратегії. Я спродіваюсь, з ШІ чи без, учасники отримали цінний досвід і зможуть стратегічно поглянути на тестування і зробити світ якіснішим!


Дякую, що дочитали! Чекайте звіт по фіналу❣️

#devchallenge
⭐️ Завдання №3 - автоматизація

Завдання - соціальний експеримент. Ніяких легенд - потібно будь-яким безкоштовним інструментом, будь-якою мовою автоматизувати 3 простих тест кейса на сторінці https://devchallenge.it В самому завданні сказано, що можна користуватись ШІ і всім, що допоможе вирішити задачу.
По-перше, я та інші судді важаємо, що в 2024 році всі тестери мають хоч трішки розбиратись в автоматизації
По-друге, чергова лякалка, що от тепер, зі штучним інтелектом, розробники автотестери не потрібні. Цікаво подивитись, чи дійсно некодери зможуть успішно вирішити досить тривіальну задачу.

✅ Expected results
🟢Судді мають отримати файли тестів та інструкцію, як їх запустити
🟢Якщо всі кроки інструкції виконані і ми бачимо браузер, що виконує сценарії - це успіх. Ніяких хитрощів і підводних каменів
🟢Особисто я очікував, що більшість піде найпростішим шляхом, і візьме Playwright + TS, і запише тести рекордером


⚠️ Actual results
🟠Люди розучились писати інструкції. Для QA інженера це неприпустимо! 50% інструкцій не містять важливих кроків. Я б мав ставити 0 за такі роботи, але маю навички і досвід, тож запустив майже весь отриманий код. Але серед нас є і судді не автоматизатори. Якщо ваші тести на джаві/JS/Python, а ви не вказали, що цю мову потрібно встановити - тести вже не пройдуть. Якщо ви написали їх на Mac, вони можуть не запуститись на Linux чи Windows. І як мінімум, читайте 1 раз самі, що ви написали 😡
🟠Було декілька грунтовних робіт - не просто файл тесту, а проєкт, з фабрикою браузерів, окремими класами на кроки, а зверху ще й тести написані на Cucumber. На написання такого треба витратити не години, а дні роботи. Як на мене це зайве ускладнення. А ще, не зважаючи на всю помпезність, використані дуже погані локатори типу div/div/div/div/span/div/a. Я б рекомендував витрачати час ефективніше
🟠Були роботи, автори яких пропонували встановити IDE для запуску тестів. Народ, так ніхто не робить - це має бути 1 команда для CLI чи навіть скрипт - запустив - і все працює
🟠Були роботи, які імітували виконання тестів, але по факту, код нічого не робив. Але ми вміємо читати 😀
🟠1 людина написала в інструкції, що тести їй написав ШІ, а надиво - тести гарно працювали!
🟠Загальна статистика:
➡️ Я зміг запустити 50% всіх тестових проєктів
➡️ Топ мов програмування: Python, TS, Java, Kotlin, JS. Я приємно здивований, що Python обрало найбільше
➡️ Топ фреймворків: Playwright, Selenium, Selenide, Cucumber, Cypress, Selenium IDE. Я дуже радів побачити тести на Selenium IDE - щось тепле і лампове з далекого минулого. А головне - це працює і вирішує задачу!

💡 Загальне враження - Автоматизатори - видихайте, ШІ нас не замінить. Не автоматизатори - починайте цікавитись автоматизацією, щоб випадкова задача не поставила вас в незручне становище. А ще мене турбує загальна якість більшості побаченого коду. Я розумію, що це Challenge, і можна не так старатись, але якщо вам за це гроші платять - вчіться робити якісніше!

🔥 Ідеальний тест план

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

Отже, по пунктах:
✅ замовники дають багато грошів
✅ замовники одразу дають повні, однозначні, гарно написані вимоги до ПЗ
✅ розробники пишуть ідеальний код. Без багів і вчасно
✅ Тест кейси для вас пише аналітик. Йому це просто, бо вимоги вже ідеально написані
✅ Тестують за вас фінальні користувачі, бо можна їм передати вимоги, які написав аналітик
✅ Після успішного релізу вам дають ще більше грошів за якісно проведене тестування

Такий план. Не дякуйте! 😍

#devchallenge
⭐️ Завдання №2 - нефункціональне тестування

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

Я вже кілька років хотів реалізувати щось подібне, бо чергове тестування web-застосунків набридло і не викликає відчуття challenge’у, незвичного досвіду, за яким всі і приходять.

Проблеми почались з розповсюдження застосунку. Я написав його на Python і за допомогою PyInstaller зкомпілював в виконавчий файл, який можна запустити де завгодно. Але поточна ситуація на ринку ОС і заліза викликає в мене занепокоєння. Разом з колегами, ми зробили білди для:
🟢Windows x64
🟢Linux x64 Ubuntu
🟢Linux x64 OpenSuse
🟢Mac OS x64
🟢Mac OS arm
Я радію, що в учасників не було Windows та Linux на arm, бо не уявляю, де б я це збирав 😅
І більшість учасників, хоч і не з першої спроби - але запустили застосунок і протестили!

✅ Expected results
🟠Performance: програма працює тим повільніше, чи більше символів вводиш для шифрування. Я використав квадратичну прогресію для наглядного ефекту
🟠Performance: програма на старті “з’їдає” 1 Гб RAM. Я хотів, щоб хоч хтось глянув у монітор ресурсів
🟠Compatibility: програма каже, що несумісна з вашою версією ОС. Я це захардкодив, але з точки зору black box тестування я б про це повідомив
🟠Usability: Я використав найдивніші консольні аргументи, які тільки зміг придумати. Типові ключі: -h - для допомоги, -f для файлу. Я використав випадковим чином взяті букви, деякі капсом, щоб було не зручно
🟠Maintainability: програма створює конфіг, який нічого не робить. Наповнив рандомними значеннями, які ні на що не впливають
🟠Reliability: а ні, впливають. В конфізі є лічильник версій, які збільшуються при кожному використанні програми. Як тільки він доходить до 7, програма ламається і каже почистити конфіг
🟠Usability: вже писав вище, що програма пише про версію ОС, але я це пишу стильно: You ÕS veršioÑ Ïs depræ¢åted. Pleasê update y¤ur 0S to the ¬§µðÂЇØçÞ vè®S1Öñ
🟠Usability: коли програма шифрує, вона виводить купу інформації на екран, яка робить користування менш зручним. Баг - відсутність акуратності і єдиного стилю в інтерфейсі
🟣О, а ще я додав дідівський мем - rickroll. Якщо попросити програму зробити rroll, вона за 5 секунд видасть посилання на відео. І це не баг, це фіча. За цей звіт ми віднімали бали


⚠️ Actual results
🟠Мало багів! Я перелічив 9, всього їх заклав ~14, але в звітах читав в середньому лише 5
🟠Багато багів не містили конкретних прикладів. Народ, якщо ви вводите команду caesar.exe --file, і у вас помилка - напишіть цю команду для копіпасти, а не описуйте словами, що ви там вводили
🟠Також я бачив багато описів багів без конкретних цифр: “програма працює повільно” - дуже поганий опис. “Програма споживає пам’ять” - мені приємно, що хоч хтось подивився, але всі програми її споживають, тут замало конкретики
🟠Лише кілька людей написали, що конфіг зайвий
🟠Багато хто писав функціональні баги, що було не правильно, функціональні вимоги невідомі, і те, що в моїй програмі після букв йдуть цифри, а потім спецсимволи - так і задумано. Час витрачено даремно
🟠Мій топ діамантів з баг репортів:
➡️Non-functional quality characteristic: Functionality
➡️Displayed description in another alphabet language (це про символи в версії ОС)


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

#devchallenge
Привіт друзі! Завершився онлайн раунд DevChallange 21, вітаю всіх причетних і поспішаю поділитись своїми думками і спостереженнями цього року.

Матеріалу багато, тож буде декілька постів.

Загалом було придумано 4 задачі, які учасники мали виконати за 20 днів. Традиційно, номінація тестування містила 2 категорії: легше і важче, але цього року ми не стали пропонувати різні завдання учасникам (бо перевіряти їх потім важко), а запропонували тим, хто хоче легше виконати всього перші 3 завдання. До оцінювання робіт ми ретельно готуємось, тож у нас буквально написані expected results з кількістю балів за кожен пункт. Тож давайте, як справжні QA, подивимось на типові actual results і виміряємо якість відповідей учасників.

⭐️ Завдання №1 - вибір інструмента

За легендою учасник має обрати найкращий інструмент для тестування API складної системи, що містить цілий зоопарк інтерфейсів:
➡️ TCP sockets (data serialized as XML)
➡️ UDP sockets (byte stream)
↪️ SOAP (via HTTP and FTP)
➡️ REST API (JSON and byte stream via HTTP)
➡️ Web Sockets
↪️ GraphQL (via HTTP)
➡️ FTP and SFTP
➡️ + бази даних, різна автентифікація для HTTP та SHH tunneling

Учасникам було запропоновано пошукати інструменти, створити порівняльну таблицю і обрати найкращий інструмент для тестування. І написати короткий висновок, чому обрано саме цей інструмент.

Це досить типова задача для інженера - знайти щось, що за однакових обставин простіше, дешевше, корисніше. Незнання API не рахується як виправдання. Коли ви обираєте холодильники, телевізори чи телефони, теж не обов’язково розумієте всі фічі. Коли мав необхідність обрати і замовити РЕБ для підрозділу морпіхів - теж не дуже розумів список фіч, тож довелось швидко збирати інформацію 🤷‍♂️


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

⚠️ Actual results
- більшість учасників чомусь вирішила, що дійсно може існувати лише 1 інструмент. Але біда навіть не в цьому, а в тому, що цей інструмент - Postman, який ні з TCP, ні з базами не працює. Типу - нема інструмента, значить ті АПІ хай хтось інший тестує
- Частина учасників, при цьому, в порівняльній таблиці без вагань ставила Postman`у 3 бали з 3 за повну підтримку протоколу TCP - таке враження, що скопіювали відповідь з ШІ не сильно вчитуючись, що саме він написав
- Багато, мінімум 50% учасників чомусь об’єднали всі протоколи в 1 рядок, який назвали “протоколи”. В інших були ціна, зручність користування та ін. Це однозначно поганий підхід, тому що важко порівнювати інструменти, якщо умовно Postman має оцінку протоколів 2/3, а JMeter - 3/3. Як зрозуміти з цього, який що вміє?
- Майже ніхто не згадав бази даних в можливостях інструментів - про них ніби забули, тому що вони описані не пунктом списку, а реченням нижче. Треба бути уважнішими!
- Деякі учасники зробили горизонтальні таблиці, які буквально треба скролити не вниз, а вправо. За що?
- Хочу відмітити декілька сильних робіт, які отримали майже максимальні бали і навіть запропонували цікаві рішення ❤️


💡 Загальне враження - суб’єктивно мені здається, що більшість учасників не шукала інструменти в Інтернеті, як в старі добрі часи, а попросила написати порівняння в Chat-GPT, і навіть не перевірили результати. Не треба так 🥲

⚡️Приєднуйтеся до події від SQUAD – Embedded QA skill set: Are you all set? 23 жовтня, онлайн + офлайн у Києві

У програмі:

📌 Актуальні скіли для Embedded QA
📌 Статистика по топ навичкам для Embedded QA в Україні та США
📌 Визначення пріоритетних скілів кандидатів при наймі в команду
📌 Обґрунтоване формування цілей та трекінг прогресу розвитку колег
📌 Оптимізація підбору ресурсів на проєкт
📌 Чому skill set матриця є одним з найзручніших інструментів візуалізації вмінь команди?

Участь безкоштовна, деталі та реєстрація — https://bit.ly/4eU7luY 🔥

Фантомні поїзди у Швейцарії 🚂👻
#bugseverywhere

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

Поїздам у Швейцарії не дозволено мати рівно 256 осей. Це може здатися абсурдним обмеженням, але справа не в суворих європейських регуляціях чи дивній бюрократії. Причина набагато цікавіша — і це справжній баг!

Швейцарська залізнична мережа використовує детектори, розташовані вздовж рейок, для відстеження місцезнаходження поїздів. Ці детектори активуються, коли колесо проходить по рейці, і рахують кількість коліс, щоб надати основну інформацію про поїзд, що щойно проїхав. На жаль, кількість коліс відстежується за допомогою 8-розрядного двійкового числа. Коли це число досягає свого максимуму — 255 (або 11111111 в двійковій системі) — воно скидається до нуля. Тобто будь-який поїзд рівно із 256 осями стає "невидимим" для системи, ніби справжній фантомний потяг.

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

Отож, це один із тих рідкісних випадків, коли проблему в програмному забезпеченні вирішили адміністративним шляхом. Як вам такий підхід до багфіксу? 😂

Знаєте ще цікаві приклади "креативних" виправлень багів? Діліться в коментарях!

🤓Ті, хто цікавиться оновленнями у світі тестування, точно помітили, що цьогоріч світ ISTQB був щедрий на оновлення.

Про одне із найпомітніших — вперше за 12 років оновлена версія силабусу до сертифікації ISTQB Advanced Test Manager — вже все знає Олександра Ковальова, ISTQB-тренерка з 8+ річним досвідом.

8 жовтня відбудеться безкоштовний вебінар Олександри “ISTQB Test Manager 3.0: управління тестуванням в умовах невизначеності”, на якому вона розповість:

👉 що покриває нова версія Advanced Test Manager 3.0 і де вона стане у нагоді, а де ні;
👉 чи став іспит легшим в новій версії;
👉 скільки в новій версії agile і до чого тут Foundation Level 4.0;
👉 як впливає модель розробки на проєкті на планування тестування, і де тут невизначеність;
👉 навіщо тестувальникам рівня Middle та Senior розуміти роботу Test Lead;
👉 чи вплинули ці зміни на тестувальників, які складали попередні версії іспиту;
👉 яка різниця в ролях Тест Лід та Тест Менеджер в компаніях, і що про це каже ISTQB.

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

⏰ Початок о 19:00, 8 жовтня
📋 Обов'язкова реєстрація для участі у трансляції та отримання запису.
🎯 Деталі та реєстрація: https://bit.ly/3BBWOWI

📊 Персональна ефективність

Привіт друзі! Цього літа я вперше за довгий час шукав собі нову роботу. До цього я дуже пишався своїм резюме:
✅ в ньому описані мої навички та багатий досвід
✅ воно було концентроване - лише 3 сторінки
✅ воно мало непоганий дизайн

Але я вирішив, що хочу мати щось набагато крутіше. Тож почав з оптимізації контенту. На щастя, зараз є десятки сервісів-аналізаторів, куди можна завантажити резюме і отримати його оцінку. Я був впевнений, що зараз ШІ тільки гляне на моє CV, пустить скупу цифрову сльозу радості і видасть мені оцінку 99/100. Але я отримав лише ~25%. Але чому так?

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

Всі аналізатори зараз дають поради та приклади на кшталт:
- "завдяки моєму менеджменту, зменшив час регресійного тестування в 3 рази"
- "мій тест дизайн допоміг досягти 90% покриття продукту тестами і збільшити якість на 27%"
- "моя стратегія тестування призвела до зменшення кількості критичних багів на 95%"

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

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

А поки бережіть себе
допомагайте ЗСУ
Слава Україні! 🇺🇦

ДрукАрмія

Привіт друзі. Хочу трохи поділитись із вами своїм новим хобі - 3D друком для друк-Армії.

Хоча мені, без сумніву, найбільше подобається ліниве волонтерство - кидати комусь донати чи максимум - купувати і передавати різні штуки (що, по суті, теж впирається в гроші). Я все таки розглядав для себе різні варіанти:
✅ збирати дрони? - не моє. Мій максимум - замовити детальки на Аліку, передати куму, який і спаяє, і облітає, і знає, кому передати.
✅ навчитись літати? 20 годин в Liftoff показали, що це теж не моє 😱

⚡️ І ось на DOU Пікнік я відвідав стенд Друк Армії - подивився, як наживо всі відбувається, попитав про поради новачкам і замовив собі принтер! (нетворкінг, безумовно - найкрутіша сторона офлайн івентів).

Це просто і дуже круто! Вже надрукував і надіслав першу партію виробів. А у години простою ще й надрукував дитині кілька іграшок 😁

На фото - мій принтер із унікальним інженерним рішенням тримача катушки пластику - ракетка для бадмінтону, притиснута двома ящиками тушонки 😅

Привіт, спільното!
Опублікував на DOU короткий звіт по детекторах, на які ми збирали на благодійному вебінарі.

https://dou.ua/forums/topic/50446/

Dev Challenge XXI

Привіт друзі! В черговий раз Я – Суддя номінації Testing найбільшого ІТ-змагання в Європі – DEV Challenge 🏆

Це виклик, що змусить вийти за рамки звичного, знайти нові підходи у своїй роботі й проявити максимум досвіду й таланту.


👉 Реєструйтесь до 22 вересня: https://devchallenge.it/

Обирай свою номінацію:
• macOS
• Backend
• Frontend
➡️➡️ Testing ⬅️⬅️
• Product Design
• UI Design

На вас чекають:
🎮Завдання, більшість з яких – реальні запити із соціальним фокусом, зокрема від UNICEF, БФ «Повернись живим» та ін.
💾Корисні знайомства та обмін досвідом: 2500+ учасників та 40+ суддів.
💿Призи від провідних компаній-партнерів та освітні можливості.

#DEV_Challenge

🍓
#ai

Тут нова штучка-інтелект приїхала.
Тепер вже точно роботу відбере!

Готові стати QA Leader? 💡

Запрошуємо на четвертий потік с̶у̶в̶о̶р̶о̶г̶о̶ групового менторства QA-Lead, де ви дізнаєтеся все про цю посаду та отримаєте інструменти для успішного вирішення завдань після підвищення.

📚Що у програмі?

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

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

📅 Старт: 16 вересня

Реєстрація та програма тут

Сьогодні першому офіційному багу виповнилось 77 рочків! З кожним роком його життя стає тільки насиченішим й цікавішим!

Так само і наше професійне життя. З професійним святом! Будьмо ще допитливішими, вдалих нам полювань за багами, корисних й якісних релізів! 🎉

Смертельний код ☢️
#bugseverywhere #friday

Кожен другий QA тренер (а може й кожний перший - ми з Льошею точно так робили :) ), коли розповідає початківцям про баги - наводить декілька найбільш екстремальних прикладів, що мали не просто негативний, а люто ніщивний вплив на якусь сферу людського життя.
Але не кожний тренер знає про root cause таких багів.

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

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

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

Проблема полягала в тому, що змінна Class3 зберігалась як 8-розрядне двійкове число, значення якого встановлювалось на нуль після досягнення максимального значення 255. Через це кожен 256-й раз, коли запускався конфігураційний цикл, Class3 встановлювалася на нуль, незалежно від фактичної перевірки безпеки. Це призводило до того, що апарат пропускав критичну перевірку коліматора і мішені, що могло спричинити випромінювання небезпечного для життя рівня радіації.

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

Знаю ще декілька прикладів overflow, цікаво було б почути?

33 роки 🇺🇦❤️

З Днем Незалежності, Україно!
В моєму житті, і мабуть для більшості з нас, ці слова ніколи раніше не були такими сповненими сенсу, як останні 3 роки.
Величезна подяка нашим захисникам та захисницям, волонтерам, медикам, рятувальникам, та всім тим, на чиїх плечах зараз тримається ця незалежність, і завдяки кому ми маємо змогу жити, святкувати й також намагатися її підтримувати 💛💙

😄 Я живий, я легітимний

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

Якщо коротко - працюю в компанії nCube просто Test Automation інженером, насолоджуюсь виконанням інженерних задач. Більш детально, напевне, розкажу вже в черговому подкасті, чи при зустрічі всім бажаючим на DOU Пікнік вже за тиждень!

Ну і звісно ж трохи інсайдів:
✅ В новому проєкті основна робоча система - Ubuntu. Тож, незважаючи на мою любов до Windows, довелось ставити другу ОС. Давно не працював з Linux повноцінно - це прикольний досвід. Тепер ціную вінду ще сильніше 😀 І готую пости по використанню лінукс в тестуванні в якості основної ОС

✅ В новому проєкті активно використовується Azure DevOps - продукт чи радше екосистема для розробки, що включає Git, wiki, task tracker, build server. З яким би стеком ви не працювали раніше - досвід майже однаковий. Залетів з ноги і почав працювати. Тож хто нервує, шука.чи роботу, що в вакансії немає вимоги роботи з умовною джирою - не варто.

Гарного, продуктивного і безпечного всім дня!