Ділимось історіями про баги до Дня тестувальника! І даруємо мерч від DOU 🐞💚

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

Шановна QA-спільнота, як щодо активності до всесвітнього Дня тестувальника? 😈

За легендою, 9 вересня 1947 — це день, коли вперше було виявлено фактичний випадок помилки в комп’ютері. Тоді при виникненні проблем з машиною, виявилося, що в електромагнітне реле залетіла міль. Оператори видалили метелика і причепили його до журналу. записавши: «First actual case of bug being found» (Перший випадок в практиці, коли був виявлений жук).

Тож розкажіть нам про ваші баги: складні, прості, смішні, цікаві (або ні), улюблені й не дуже.
Автору найкрутішої історії 9 вересня ми подаруємо набір мерчу від команди DOU. Тож коментуйте, не баріться 😉

👍ПодобаєтьсяСподобалось2
До обраногоВ обраному1
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Колись працював над спрощеним варіантом соціальної мережі. На Drupal.

І якось виявив, що іноді сесія користувача замінялася на іншого.
Тобто залогінився під Yarik, щось зробив, і тут бум! — ти вже Oleksandr.
Багато годин шукав чіткий алгоритм відтворення але воно ніяк. Виглядало повним рандомом.
Іноді все ок. Аж потім раптом знову змінювався на іншого користувача. У схемі заміни користувачів також не було закономірності.

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

Виявляється, що на деяких сторінках був віджет, який показував список недавніх друзів, з якими були якісь взаємодії.
Сайт був на Drupal, тобто PHP.
У тому віджеті у циклі показу користувачів-друзів використав назву змінної $user.
А в інших місцях системи поточний користувач також був $user.

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

у нас у апці є кнопка, яка завжди ввімкнена і яку не можна вимкнути, вона відповідає за зміну (гіпотетичну) типу контракту

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

У меня в одном интерфейсе тоже были кнопки на штатах, куда нельзя звонить. И так же отвечали, нельзя убрать, клиенты будут недовольны(хоть оно и красное и не меняется). Типа так у них есть илюзия, что если сильно надо — они договорятся и им разрешат.

Бага яку я запам’ятала найбільше зі своєї практики: у вимогах кнопка для юзерів без певної ролі мала б бути недоступна. І вона виглядала disabled на UI, але я чомусь таки клікнула на неї і вона виявилася enabled) Ржали всією командою)

Далекий, доковідний 2019 рік, часи коли люди ще більш-менш стабільно ходили до офісів)
Новий клієнт, свіжо-зібрана нова команда, тільки 2 місяці як стартували.
В рамках таски ми перевіряли, скажемо так, процес відшкодування грошей клієнтам по програмі лояльності. В нас була частина мігнованих на тестовий енв данних з прода, котрі ми гоняли в рамках тестів. Проблему помітили коли я запустив процес відшкодування суммою в 2.1-2.5 млн євро (не пам’ятаю точну цифру, але точно більше 2х лямів). Тоді наші фінансисти побачили якісь «незвичні суми» в процесі на обробку та створення інвойсів. Була така завелика сумма, що звістно це відшкодування зупинили та почали перевіряти. Перше шо виявилось, це що щось не так було з формулою розрахунків в випадку з цим клієнтом. А вот інше це те що на енві забули вказати тестовий бекенд та він вів на прод. А все це почалось за 2 дні до початку створювання інвойсів та проведення виплат. Як наслідок, все тестування що йшло впродовж 3х днів, все це лилось на прод. Якщо деви були більш скромніщі, та процесили контракти на 1-2тис євро, то я не дуже церемонився і ганяв більш круглі суми. Завдяки цьому це одразу помітили. За підсумком мої «діяння» знайшли дуже швидко та повідміняли. То шо встигли запроцессити деви, ще пару днів виловлювали такі «контракти» та наче все завершилось добре, грощі ми не втратили. Отака коротка історія про те як я майже не коштував клієнту 2.5млн євро. Я вже давно не працюю з цим клієнтом(але треба визначити, що ще 2 роки пропрацював з ним після цього інциденту), але як розповідали друзі звідти, пройшло вже майже 3 роки як я пішов, а на внутрішніх презентаціях ця історія все ще іноді згадується)

Тут цікава не так бага, як рішення

Колись давно в одній платіжці отримали фідбек від клієнта, що при редагуванні тарифної сітки для збору оплат через мобілки, неотримували очікуваний fee. З цікавого, відтворити кейс одразу немогли, бо частина функціоналю працювала при певній комбінації feature-toggle які з міркувань безпеки компанія з проду не надавала. Коли ж все таки бажину відтворили і підтвердили (ухх скільки комбінацій feature-toggle було перебрано...) то вияснилося, що проблема лежала глибоко в ядрі системи, яку писали з декілька років назад і в коді котрої теж безліч feature-toggle, тож хотфікс зробити і щось не поламати було неможливо а проблема серйозна. Що цікаво, що дана проблема була в коді закладена з самого початку написання, але оскільки практики написання бодай юнітів не було, та і в той час коли писалося то було всього навсього mvp (яке звісно ж «переписали як тільки перевірили, що продукт є доцільним для подальшого інвестування та розвитку»). Зібралась нарада з інженерів компанії різних рівнів та різних відділів якби те вирішити — чи якось хитро притулити фікс впихнувши для саме цього кейсу якийсь «if\then» чи все ж настав час пітчити проект рефакторингу ядра чи взагалі спробувати новомодну думку і винести те в мікросервіс (на той час справді новаторська течія) з «грамотно побудованою архітектурою».
Побачивши декілька годинний двіж до нас долучився СТО компанії, якому теж стало цікаво, що ж то за збори такі. Вислухавши проблематику,він погодився з наведеними доводами, задумався, випив кави і спитав:
— Скільки $$$ процесить цей мерчант?
— Близько 1.5к євро на місяць
— Cкажіть йому, хай так не конфіжить, а якщо потрібно — то нехай міняє нас на іншого провайдера

Ось так СТО зберіг бюджет та ресурс компанії, ніхто ніколи і не пофіксав баги, а як воно в них там зараз мені невідомо)

Був один такий цікавий баг, який, на щастя, відловили до того як він потрапив на прод.
В нас на проекті є така опція коли користувачі отримують автоматизовані СМС-повідомлення при певних умовах. Ну наприклад потрібно актуалізувати данні клієнта для того щоб продовжувати отримувати розсилку чи товари. Всі користувачі знаходяться в США і в базі їх кілька тисяч. На день такий івент зазвичай відпрацьовує для пари десятків клієнтів.
І от після невеличкого фікса з боку девів в цьому функціоналі я взяв його на перевірку на тест енві. Це був мікрофікс і звичайна рутинна перевірка. Але натомість почало відбуватися щось дуууже дивне. Як тільки клієнт потрапляв під умови для надсилання йому СМС-ки то система починала спамити його меседжами по 5-6 смс на секунду. Поки за допомогою запитів в БД, постмені та на Юай нашого Веб-додатку я помітив та зміг відслідкувати траблу та поки за допомогою дева вдалось цей процесс зупинити — пройшло трохи часу. За цей час трьом тестовим клаєнтам що попали під умови «надіслалось» більше 20тис. смс-ок. Добре що тест база — це тест база і насправді нічого не відправлялось.
Якби цей баг потрапив на прод то навіть при вартості СМС-ки = 1 Цент Замовник міг влетіти на добрячу сумму. Та й ми як команда теж би добряче «влетіли».
Цей кейс лишній раз підтвердив моє переконання що не буває рутинних задач чи мікрофіксів. І просто заборонено нехтувати будь-якими перевірками, навіть якщо це перевірка якогось хепіфлоу вдесяте за спринт:)

В мене був, мабуть, самий популярний фейл-баг.
Я джун, початок моєі кар’єри, перша робота, пару тижнів тільки працюю, продуктова компанія. В нас у продукту була адмінка, де одним із функціоналів можливість настроїти розсилку листів на пошту клієнтам про апдейти/новини компанії. Проводжу такий собі смоук-ресёрч, пишу текст листа щось типу «Всім пяні» (дійсно було щось дуже невинне) та картинку шоколадного торту у вигляді г*мна (або навпаки), ставлю у розсилку якусь групу клієнтів та свій імейл. Лист мені прийшов, картинка найз, тест пройден.
Десь через пару годин заглядає до нас СОО і трішки вже втомившимся голосом (до нас він вже накричався у маркетологів та відділі саппорту клієнтів) питає «Хтось може з вас послав на проді лист із г*мном?».
Виявилось, що дамп тестової бази даних колись зробили з проду, і на тестове середовище потрапили імейли справжніх клієнтів, причому які наче не з початку заснування компанії. Добре, що їх було не багато, да і відносини із топ-менеджментом дружні були, проще було пояснити ситуацію. Але все одно девелопери трішки прочуханів получили. А мені подякували за виявлення багу тестових даних) А ще тріал-період закрили на півтора місяця раніше, але дуже сподіваюсь що не за це г*мно.

Це як? Тобто листа відсилали Ви, а по сраці отримали девелопери?

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

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

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

Все правильно) відповідальність за якість продукту має бути колективна, в даному випадку бага явно тих, хто конфігурував тестову базу, а не куа який в тестовому режимі відправив листа в «тестову базу»)

В апці для фуд делівері була дебаг панель яка дозволяла перемикати серваки з дев — тест і прод
Якийсь новий девопс вирішив що тест треба розділити на 2 , для автоматизаторів та для мануал
Я вибрав свій звичайний тест і почав там тестувати нову фічу по додаванню нових позиції в меню ресторанів , нових списків ресторанів і додавання власне самих ресторанів
Як виявилось , замість того щоб тест 1 був тестовим , девопс невірно наконфігурив тест 1 і під капотом по факту був і тест1 і продакшн сервер
Ми нічого не підозрювали, бо тестувалось все на адмін панелі яка відображалась відповідно для тест 1
Як же здивувались американські замовники , коли вони почали прокидатись , а це за нашим часом була 4 вечора , тобто пів дня висіли наші нові зміни на проді , і їм почали розривати корпоративну пошту бо ніхто не може зрозуміти звідки взялись всякі «Пузаті хати» , «Фан бар банки» , «Ресторація бачевських» , «Пʼяна вишня» і тд
І курʼєри які розривали супорт бо вони не знали як доставити продукти з Медісона у Львів )

Ще був випадок з додатком на окуляри доповненої реальності. Для входу в програму користувачу треба було залогінитись, а саме вікно логіну зʼявлялось перед очима користувача у фіксованому положенні відносно підлоги — тобто при нахилі голови положення вікна не змінювалось. Потім вирішили трохи цю поведінку адаптувати для зручності, щоб якщо людина дивиться вниз (як виявилось більш частий випадок користування додатком), то вікно логіну зʼявлялось навпроти користувача по висоті також. Розробник, який працював над цією задачею, перевіряв функціонал в Unity а не на самому девайсі, і коли мені в руки потрапив той білд, то вийшло як у відео з продавцями морозива, які своїми спритними руками не давали кульці морозива опинитись у стаканчику — намагаючись ввести свої данні у вікно логіну, це віконечко завжди «тікало» і не виходило клацнути на кнопку входу, бо кут зору на девайсі і у Unity трохи відрізнявся.

Десь 4 роки тому довелось мені тестувати девайс, який вимірює ЕКГ серця в реальному часі, підключається по блютуз до телефону і виводить на мобільний додаток дані, які були опрацьовані сервером, щоб показати пульс, власне ЕКГ і ще ряд інших параметрів.
На головному екрані додатку був невеличкий дашборд який через 3 хвилини мав показати загальний стан активності серця після вимірювання (як тільки сервер опрацює датасет і поверне результат на клієнт). Одним з важливих показників для формули, по якій інформація обчислювалась — був вік людини, з якої девайс вимірював дані. Відповідно: число, місяць, рік народження. Що важливо — по грегоріанському календарю. Тобто по календарю, до якого ми всі з вами звикли. Також важливо уточнити, що на клієнті було обмеження і дата народження не могла бути меншою ніж 13 років від поточного часу і більшою (давнішою), ніж 1900 рік народження.
На одній з виставок наш девайс дістався чоловіку з Тайланда, який благополучно купив його і повернувся на свою батьківщину, в Тай. Звідки почав репортити нам, що у нього додаток не працює, не виводить його дані про здоров’я після обчислень сервера. Коли ми почали досліджувати в чому причина, то трошки здивувалися, бо сервер намагався обчислити його дані, на основі дати народження, яка значилася як — 2522 рік. Звісно, сервер божеволів і не міг порахувати такі дані.
В чому виявилася суть? В Тайланді інший календар — будистський, де наш 2023 рік дорівнює їх 2566 року. Користувач не міг ввести такі невалідні дані, але його айфон зміг, запропонувавши йому заповнити дані з його профілю телефону просто вставивши їх на потрібні місця.
Баг було пофікшено, сервер перестав божеволіти і почав обчислювати коректно, клієнт залишився задоволеним і отримав свої дані про роботу серця.
А вся наша дев і куа команда наповнилася повагою до Будди та нових набутих знань стосовно того, які календарні літописи бувають у різних народів і як цей кейс допоміг врахувати схожі помилки у майбутньому.

Є в мене пару смішних багів (одруківок) з одного проекту — ні на що не впливали і можна би було і взагалі не помітити (якщо не дивитись логи і пул-реквести девелоперів).
Одруківка 1 — один з мікросервісів відповідав за трансформацію файлів з одного типу в інший і під час всіх маніпуляцій файли поміщались в певні сховища і видалялись після обробки, і кожна дія логувалась. Щось мені хотілось знайти в тому процесі чи краще розібратись — не важливо, що я почала дивитись логи. І от читаю «File was added to a di*k storage», «File was removed from a di*k storage» як власне і всюди у слові disk була одна маленька одруківочка (а одне зі значень того слова непристойне, тому замаскувала зірочкою). Посміялись з командою, виправили логи а через якийсь час настає
Одруківка 2 — вже на іншому мікросервісі реалізувалась якась логіка, чи то на унікальні значення, чи то на лічильник якийсь, і захотіла я подивитись на сам пул-реквест, щоб краще продумати тестові сценарії. І заглядаючи в код побачила, що в слові count пропущена літера о, що також взяте зі словника нецензурної лексики.
На якийсь момент подумала, що так девелопери вирішили пожартувати з новенької тестувальниці =)

Все що відбувається у логах, залишається у логах. І тільки девопси знають брудні фантазії девелоперів :-)

в мохнаті роки двічі на рік деякі файли імпортувалися в облікову систему двічі. Бо перехід на літній-зимовий час викликав неочікувану поведінку на нетваревих шарах — для файлів, створених до «переводу стрєлок», час створення файлу змінювався на годину. о першій ночі це було «файл створено о 17.00 вчора», а о третій цей же файл «створено о 16.00 учора»
Файли детектилися як оновлені і іпортувалися в систему вдруге.

Був у нас одна бага в айос апці, коли в юзера була зустріч в календарі на годину часу наприклад, а він змінював формат з 12-годинного на 24-годинний, то та зустріч розтягувалася на цілий день. До демо ми не встигли пофіксити все і зробили окремий білд, де це було залочено на 12-годинний формат, але той білд зовсім не тестований був. То я спочатку показую ввесь функціонал на білді, який я протестував, далі відключаюся від демо, ставлю новий білд, підключаюся. Там починаю придумувати, типу трабли зі звʼязком.) І показую календар, де все гуд.) Загалом клієнт був задоволений, але пару таких демо і посивіти можна)

Мабуть про таке не варто розповідати, бо це баг був з боку нашої команди, але я обожнюю цю історію) звичайний сайт-блог доволі великої жіночої спілки. Для зручності ми собі на тестовий закинули бд з проди. Я як раз перевіряла crud новин, і трошки захопилась. В якості фото використовувала картинку з таракашками, а в текст пхала рандомні цитати з Кафки. Типу: " Ти належиш мені, я зробив тебе своєю, і в жодній казці немає жінки, за яку билися б довше і відчайдушніше, ніж я бився за тебе із самим собою. Так було з самого початку, так повторювалося знову і знову, і так, мабуть, завжди буде...«.
І в якийсь момент нам в істериці пише завжди спокійний (до цього) замовник: «PLEASE STOP IT».
Виявилось що при перенесенні профайлів юзерів на тестовий, ми забули вимкнути нотіфікації...І це все летіло бідолашним жінкам на пошту( Досі соромно

Працюючи з e-commerce проектами, знаходив цікаві баги і я б виділив декілька:
1. Неможливість оплати за допомогою «Apple Pay» тому що після натискання на кнопку, вікно оплати на пів секунди, секунду відкривалося і одразу ж закривалося.
2. Після застосування фільтру і вибору категорії замість відображення списку, користувач переходив на детальну сторінку товару.

Стало цікаво спитати про історію про найкрутішу багу чат GPT:

Привіт! Звісно, ось історія:

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

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

Команда розробників розпочала епічну битву з цим багом, і виявилося, що причина проблеми була в одній строчці коду, де вони недавно додали «свіжий» апгрейд, але забули закрити одну дужку. Це призвело до невірного розпізнавання команди і викликало цю масштабну помилку.

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

Обожнюю вигадки чату
Вони на стільки абсурдні що аж смішно.

Колись, у далекому 2019 році, я брав участь у тестуванні великого онлайн-ігрового проекту. В цій грі гравці відправлялися в епічні пригоди, борючись з монстрами і збираючи скарби. Моя роль полягала в пошуку багів та їхньому документуванні.
Одного дня я вирішив перевірити, як гра веде себе при великому навантаженні на сервери. Для цього я створив декілька десятків ботів, які намагалися зайти в гру одночасно. Спочатку все здавалося добре, але після деякого часу я помітив дуже дивний баг.
Головним персонажем гри був могутній воїн по імені Артур. І ось, коли всі ці боти спробували увійти одночасно, Артур виявився в дуже смішній ситуації. Він став рости як гігант, і його меч виріс разом з ним, але він не міг рухатися і залишався в одному місці. Графіка вибухала і розтягувалася навколо нього, немовби створюючи дивну червону дірку у всесвіті гри. Гравці, які були поруч, почали вигукувати, і це було неймовірно смішно.
Я зразу ж зробив знімок екрана і відправив розробникам гри разом із звітом про баг. Після цього вони не тільки виправили цей баг, але також використали його як основу для створення кумедного івента в грі, де Артур може стати гігантом на певний час, але це було цілком контрольовано і не спричиняло незручностей для гравців.

Свого часу Sony презентувала свою консоль PS5, але в українському ретейлі її було нереально купити. Висіла завжди в статусі «очікується» чи шось типу того. Але була інфа що консолі завозяться невеличкими партіями і таки продають чи то своїм чи то баригам. Так от виявилося, що в одному великому і відомому інтернет магазині немає на беку перевірки корзини(тобто все що присилає фронт — все хаває). Нехитрими маніпуляціями відкриваємо якийсь лівий товар і на фронті міняємо йому айдішник на айдішник консолі. Далі тиснемо «купити», і вуаля...консоль в корзині! Але от бідося....оплатити не дає, бо товара немає в наявності. І тут не біда, моніторимо корзину і вуаля, як тільки товар зʼявляється на складах — кнопка оплати стає активна. Замовляємо! І оплачуємо! Дзвонить консультант і розповідає що консолей немає і то якийсь збій на сайті і т.д. Кажемо що нічого не знаємо, гроші заплачені, давайте товар. Через тиждень консоль на руках. Знаю як мінімум півтора десятки людей які купили консоль таким чином)

Це ніщо порівняно із багом офлайн магазину, який дозволив свого часу одному малому пробити PS4 по ціні печіва (чи що там було) :-)

Це ніщо порівняно із українцем який обікрав майкрософт на 10 лямів генеруючі подарункові карти. 9 років правда дали)

Найсмішніший баг на моїй пам’яті. Тестувала функціональність реєстрації юзерів на сайті. При реєстрації юзер змушений був вказувати свою стать. Перевіряю e-mail повідомлення, що надходить юзерам після реєстрації. А там, як кажуть, чорним по білому:

Hello female Maria Ivanova,
.........................

або

Hello male Ivan Petrov,
.........................

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

оо, так, спеціально вмикаю слоу інтернет і тоді бувають цікаві несподіванки)))

Там би це не допомогло. Аплікуха десктопна із локальною базою. Хіба що проц чимось навантажити. Але такого у тест планах не було.

Підписатись на коментарі