6 історій про фейлі QA: “Компанія могла втратити 50 000 доларів. Усе сталося тому, що у нас не було якісного тестування"

[Fail review — рубрика, в якій ми збираємо історії про робочі провалили: що відбулось, як виправляли і які висновки нікого.]

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

QA-спеціалісти поділилися власними факапами й тім, як вони змінили їхній підхід до роботи.

Ілюстрація Каталіни Маєвської

Під час важливого демо зникли всі дані

Олена, Head of QA в e-commerce компанії

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

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

За 5 хвилин з різницею у кілька секунд мені надходить два повідомлення. Перше від підлеглого: «Там дані в тестового акаунті якісь дивні були, я їх видалив, щоб усе перезапустити» (нагадую, що це хвилин на 40). Одного повідомлення від французького колеги: «У мене зникли дані». Я за хвилину повторно заливаю вчорашні дані в демоакаунт і пишу підлеглому, щоби поки що не чіпав його.

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

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

Коли погане тестування може коштувати 50 000 доларів

Дмитро, Software Developer in Test Engineer

Одна з моїх перших робіт була в продуктовій компанії. Відділ, у якому я працював, складався з 5 людей: двоє менеджерів, один сапорт і ми вдвох із колегою, які збирали дані як бізнес-аналітики та як продакт-оунери вели проєкт і намагалися розвивати його. Ми займалися ресейлингом різних промов на таких платформах, як eBay та Amazon: отримували дані від компаній і фабрик щодо наявності товарів на складах, брали цє в обробку, трохи переформатовували контент, а потім відправляли на eBay та Amazon і продавали їх там.

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

Траплялося багато ситуацій, коли через відсутність тестування ми йшли в мінус. Альо одного разу це була особливо велика сума. Як завжди, винні були не ми, а інтеграція з системою, яка мала надавати дані. Проблема полягала в тому, що дані оброблялися некоректно: система не розуміла, що таке обробка крайніх значень, тому вийшло так, що ми ледь не продали товари для автомобілів вартістю 7000 доларів за 1 долар. Якщо бути ще точнішим, то одним з останніх кроків у перевірянні цін був написаний мною механізм, такий собі rocket science AI framework if -> else conditions.

Оскільки сапорту 24/7 не було, актуальні дані ми завжди отримували із затримкою в часі. Тож коли один чоловік хотів купити 8 бамперів по долару, ми дізналися про це тільки вранці. Мабуть, він сидів десь у Каліфорнії з посмішкою і думав: «Ну-ну, відправте мені ваші бампери за 8 доларів, щоб я на вас наварився». Наступного ранку, коли ми прийшли на роботу, отримали «листи щастя» і дізналися, що могли втратити 50 000 доларів. Усе сталося тому, що у нас не було якісного тестування.

Санкцій жодних не було. Ми всі були юні, менш як рік у професії, тому всі розуміли, що втрат на початку не уникнути. Та й звідки у кількох джунів гроші, щоб перекрити такі суми. Все-таки товарів на 50 000 доларів покупцю ми не надіслали, відправили тільки ваучер на знижку в магазині на 500 доларів. А ще на eBay та Amazon важливий рейтинг магазину, тож ми надіслали чоловікові лист з подякою як нашому «бета-тестувальнику».

Це була механічна помилка, можливо, особисто моя або когось із команди. Альо зрештою вся проблема полягала в тому, що ми не витрачали достатня годині на тестування. Якщо не робиш цього, то не можеш впевнитися, що продукт справді якісний. У світі IT багато хто — розробникі, тестувальники, менеджери тощо — не відчуває великої відповідальності, коли не розуміє, з чим працює. А коли знаєш, що сьогодні ти зробив або не зробив щось, а завтра через це втратив 50 000 доларів, починаєш думати, що краще наступного разу перевірити додатково 2-3 рази. Для мене ця помилка здавалася персональною, однак після цього кейсу загалом переосмислив свій підхід до справи.

Перевірила дрібниці та пропустила найважливіше

Олександра, Middle QA в продуктовій компанії

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

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

Ще колись у мене трапився фейл з локалізаціями. Ми створювали продукт з японською та китайською версіями. Цих мов я не знала, і за тексти малі відповідати інші люди, тож я намагалася переглядати матеріали на функціонал.

Одного разу побачила, що ієрогліфи якісь дивні: в одному абзаці дрібні, а в іншому широкі. Подумала про це. І що? І нічого. Вирішила, що в цьому нічого не розумію і, мабуть, так і треба. Ї апрувнула версії.

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

— А нормально в японській мові так перенесення робити?

— Це не японська, — відповідає мені колега.

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

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

Хотіла б я, щоб хтось раніше мені це сказавши.

Чому треба завжди фіксувати письмово завдання

Святослав, QA Engineer

На одному проєкті позаторік у грудні я виконував обов'язки і Project Coordinator, і QA. Тоді з релізом можна було не поспішати (це було не за Scrum) і всі спокійно перевірити. Функціонал треба було потестувати на платформах MySQL та Oracle. Разом зі мною над проєктом працював ще спеціаліст із сапорту — українськомовний хлопець з Канади. Він знав проєкт набагато краще за мене, а я просто тестував функціонал і навіть не знав його мету (цей проєкт був не в пріоритеті, я паралельно займався іншим, глобальнішим, де виконував обов'язки Senior QA). Тож часто запитував щось у колеги. А одного разу він сказавши, що сам перевірить функціонал на MySQL, щоб я не парився і тестував його на Oracle. Я подумавши, що це буде супер, адже це зекономило б мені годину.

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

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

Почали розбиратися, що сталося: я пригадав, що нібито все перевіряв на Oracle і домовився з хлопцем з Канади, що він перевірить MySQL. А коли я спитав, чи він це зробив, відповідь була: «Я нічого не перевіряв». Виявилося, що він просто забув чи не встигав. Альо його звинувачувати я не можу: завдання ми ніде не зафіксували, не було навіть листування — взагалі жодних доказів того, що це мав зробити він, а не я.

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

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

Чому ми зафейлили? Тому що я не тестував продукт на MySQL.
Чому не тестував? Тому що це мав зробити сапорт з Канади.
Чому він мав це зробити? Тому що ми так домовилися.
Чому ми так домовилися? Бо він це запропонував.

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

Один пропущений нюанс — і великий штраф за порушення сек'юрності

Дмитро, Head of QA

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

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

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

Я трохи переживав, бо теж був причетний до пропуску багу, але в нашій роботі ніхто не може дати гарантію, що все буде на 100% без помилок.

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

Чому важливо перевіряти деталі

Андрій, QA Engineer в e-commerce компанії

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

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

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

Опубліковано: 14/08/20 @ 10:00
Розділ Різне

SEO Блог