Июль 26

Помилка ціною в десятки тисяч і баг, що з’являється двічі на рік. Українські QA — про нестандартні проблеми, з якими стикалися в роботі

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

DOU поспілкувався із чотирма QA про визначні баги в їхньому житті, а також про те, чи вдалося їх успішно виправити, а головне — як.

«Помилка фази місяця»

Анна Лазебна, General QA в Livebeam, SKELAR

Раніше я працювала в компанії, де значна частка функціонала була зав’язана на призначенні зустрічей між різними користувачами у календарі. Люди були з різних куточків світу, тож одним з викликів стали часові пояси. Однак, як виявилося, вони — не найстрашніше.

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

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

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

Тоді мені стали в пригоді сервіси з визначення часу в різних країнах на кшталт Time and Date, а також VPN для зміни локації користувачів. Я віддавала всю інформацію розробникам — вони щось виправляли. Правдиво відтворити ситуацію, яка склалася в наших користувачів, майже неможливо. Через це було важко зрозуміти, де ховається проблема та як її усунути. Доводилося чекати пів року до наступного переведення годинників, щоби дізнатися, чи все спрацювало.

На жаль, тоді я ще не була досвідченою QA, тож повноцінно зануритися в роботу розробників не могла. Нині я б спробувала отримати від них більше інформації: як саме вони виправляли помилки, які бібліотеки використовували для часових зон, і просто ставила б більше запитань, а не вірила на слово, що «все має працювати».

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

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

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

У компанії, де я зараз працюю, культивується думка, що відповідальність за продукт несе не лише QA. Саме тому розробники проводять власні тестування та інколи доставляють на продакшн свій код без залучення тестувальників. Якщо раніше комунікація з розробниками могла бути складною, адже «на їхніх машинах все працює як слід», то за останні півтора року це змінилося. Уся команда розуміє свою відповідальність за продукт, тож і розробники, і QA разом тестують.

Тож я раджу всім QA-початківцям розвивати своє критичне мислення та не боятися ставити запитання. Перше правило QA: нікому не довіряйте, іноді навіть власним очам. Усе потрібно ставити під сумнів, експериментувати та змінювати умови, звертати увагу на найменші дрібниці та не боятися бути гнучкими, не боятися «крешнути» систему, щоби дізнатися, яка відповідь помилки надійде. Кожен баг — це корисна інформація, з якою потрібно працювати.

Як кілька байтів призвели до перевантаження пам’яті

Олексій Остапов, QA Test Lead, Infopulse

Я працюю в IT вже 15 років, весь час — у компанії Infopulse. Хотів починати з розробки, але на початку навичок бракувало, тож мені запропонували QA. Зараз я QA Test Lead, маю низку сертифікатів ISTQB різних рівнів, веду блог QA Mania і подкаст «Питання якості» на DOU. За час роботи, звісно, стикнувся з низкою цікавих багів, але про всі не розповісти.

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

Одного дня отримав звіт від замовника, що деякі системи «падають» з незрозумілих причин, хоча все нібито працює стабільно й на стендах тести проходять. Скільки ми не моніторили логи та метрики, нічого не знаходили, аж поки зовсім випадково не дійшли до маленьких піктограм, у яких насправді й полягала проблема. Коли камера спостереження знаходить певний об’єкт, знизу на моніторі може з’явитися маленький значок, наприклад червоний кружечок, — таким чином система показує, що виявила рух. Картинка займала буквально 10×10 пікселів, кілька байтів пам’яті, але не видалялась, тож коли фіксувався новий рух, виникала нова картинка, яка теж займала комірку пам’яті.

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

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

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

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

По суті, треба було забивати цвяхи мікроскопом. Та я погодився на тестування навантаження і почав запускати свої тести. Кілька тижнів я робив MVP (Minimum viable product), а згодом виявив, що тестування навантаження ігнорувало саме навантаження.

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

Я не дарма згадав про цвяхи і мікроскоп. Рішення, яке я розробив, просто не підходило — воно виконувало свою функцію, але максимально неоптимальним шляхом, і мало свої ліміти. Щоб змусити його працювати на повну, довелося масштабувати його на 5-6 потужних серверів, які згенерували б потрібне навантаження.

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

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

Крім того, ставши лідом, я припинив звинувачувати інших за помилки. Люди помиляються, і це нормально. Якби вони цього не робили, професії тестувальника не існувало б. Навіть коли розробник проведе юніт-тести і протестує власний код кілька разів, можуть виникнути баги на поверхні. Ми їх вловимо та виправимо. Ідеальний код теж може працювати не так, як це було задумано. Наше завдання — виявити ці помилки й усунути до того, як вони дійдуть до користувачів.

Як зламати платіжну систему на Objective-C

Ярослав Міндолін, Senior Automation QA Engineer / SDET, WiX

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

Я мав автоматизувати статуси оплати: Success, Not Enough Funds, Card Declined тощо. Для цього використовували мокапи [прототипи, моделі для тестування — ред.], які відтворювали той чи інший статус. Розробник написав мок-систему та покрив два найбільш критичних статуси. Інші я викликався написати власноруч.

Застосунок писали на Objective-C, що має певні особливості, до яких треба бути готовими, якщо звикли писати на Java, Python тощо. Декларування рядкового типу має починатися з літералу @, і якщо цього не зробити — компілятор вважатиме, що цей тип рядка взятий з мови С. Під час «склеювання» рядків з мов C і Objective-C станеться помилка компіляції, але середовище розробки Xcode вважатиме, що все добре.

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

Сповнений праведним гнівом, я підійшов до розробника: «Сашо, хто це накодив? Як це могли пропустити моки? Я ж казав, що покривати потрібно було в реальному середовищі».

Розробник задумався, а я з почуттям переможця пішов на своє робоче місце. За 10 хвилин колега покликав мене: «Ярику, дивись на цей рядок для Network Error. Тут ти поставив літерал. А ось ти робиш „склеювання“, а другий рядок без літерала».

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

Друга невдача сталась під час моїх перших місяців роботи у WiX. Я працював на проєкті ADI — це сайт-білдер для користувачів, які не вміють програмувати й не хочуть використовувати метод drag and drop. Він створює сайт на основі введеної інформації під час проходження інтро.

Фіча полягала в тому, що в інтро додавалась нова consent-сторінка, яка під час імпорту зображення із сайтів пропонувала підтвердити права на контент.

Уточню три моменти:

Інтро є і на мобільних пристроях, де імпорт був відсутній.
На проєкті діє принцип A/B-тестування, кожна фіча відкривається під експериментом.
Покриття автотестами мобільної версії — високе.

Я протестував вебверсію, покрив її автотестами, а на мобільній версії просто прогнав білд з експериментом. Однак я не врахував одну механічну помилку. Тести я запустив з прапорцем фічі в полі experimentsOff, а не experimentsOn. І, звичайно ж, вони пройшли.

Я дав добро на відкриття фічі, зробив реліз, а впродовж пів години метрики створення нових сайтів на мобільних пристроях знизилися до 40 %. Виявилося, що consent-сторінка все ж була на мобільній версії у вигляді порожньої сторінки, яку не можна обійти, і вона блокувала наступні кроки.

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

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

Тестування, що обійшлося в десятки тисяч доларів

Поліна, Automation QA, GlobalLogic

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

Цікава історія сталася не безпосередньо в моїй команді, а в тій, що готувала інфраструктуру для наших тестів. У певний момент і вони, і ми почали мігрувати в «хмару». Зупинилися на сервісі Amazon. Міграцією займалася команда крутих спеціалістів, які легко могли створити надскладну систему.

Але згодом ми стикнулися з проблемою. Створена колегами система працювала так, що, коли ми запускали, скажімо, 500 тестів у 20 потоків, кожен з цих потоків розгортав окрему віртуальну машину, що стартувала в «хмарі» й окремо звітувала про результати.

Тут ми зібрали 250+ запитань, що ставлять на співбесідах з QAЗдавалося б, усе добре: тобі потрібна машина — чекаєш 10 секунд, вона створюється, обсяг «хмари» регулюється автоматично. А потім нам надійшов рахунок. Виявилося, що ми платили не лише за машинний час, а й за створення інстансу! Набігло кілька десятків тисяч доларів за місяць!

Це було для нас уроком — завжди дивитися на вартість, коли користуєшся «хмарою», і мінімізувати витрати.

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

Згодом на тому ж проєкті ми дивилися, які є типи машин, і могли обирати між ними. Якщо йдеться про API-тести, які швидко «біжать», можна брати дешевшу і слабшу машину. Якщо UI-тести, які запускають кілька браузерів одночасно, обирайте потужніші машини. Так ми навчилися оптимізувати і потужності, і витрати, а клієнт витрачав менше грошей.