×Закрыть

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Санкцій жодних не було. Ми всі були юні, менш як рік у професії, тому всi розумiли, що втрат на початку не уникнути. Та й звiдки у кiлькох джунiв грошi, щоб перекрити такі суми. Все-таки товарів на 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 хвилин, і серйозних наслідків не було. Зате після схожого провалу почали постійно перевіряти цю функціональність і в чек-листи для продакшену додали, що треба обов’язково стежити, чи картка заблокована.

LinkedIn

18 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Фейл ревью — моя любимая рубрика :)

Найпростіший, навіть очевидний висновок із цих ситуацій — не варто боятися чогось не знати.

Уже длительное время думаю, почему у нас есть этот страх незнания. Типа со школы — «стыдно не знать»? Это реально сильно мешает в работе — и тому, кто боится, и тем, у кого боится спросить

QA и тестирование — это не одно и то же. Ошибки тестировщиков имеют значительно меньшее влияние при настроенных QA-процессах. Так что честно было бы убрать QA из заголовка и добавить что-то про тестирование

Мене здивувала ситуація з тестовою картою в останньому кейсі. Я так розумію це ваша тестова карта і про дані якої знають лише всередині команди або тільки відділ розробки і тестування. То як так вийшло що хтось з клієнтів нею зміг розрахуватися? Інакше це могли зробити тільки спеціалісти з компанії. Тоді це не вигідно для них — бо це можна легко перевірити) Чи я чогось не розумію? Буду радий за відповідь ;)

Скоріш за все, мова йде про тестові карти, які надають платіжні системи.
Наприклад, 4111 1111 1111 1111

Да, но про эти тестовые карты от конкретной платёжной системы тоже нужно знать. Там же тоже не рандомный набор цифр для получения успешного ответа.

може автозаповнення по дефолту стояло.

Допустим в процессе тестирования тестовая карта появляется среди платежных карт во всех аккаунтах.

Я всегда руководствуюсь перым правилом программиста «Если про баг знаешь только ты, то это не баг»

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

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

Вспоминается Илья Ильф:
Решено было не допустить ни одной ошибки. Держали двадцать корректур, и всё равно на титульном листе было напечатано: «Британская энциклопудия».

А я знаю компанию, директор которой прекратил разработку проекта с бюджетом 60 миллионов евро, потому что он устал постоянно слышать, что «система почти готова и вот-вот заработает».

Это все детский лепет, знаю компанию, которая недавно потеряла ~100 миллионов долларов из-за бага (причем не самого сложного).

Расскажите, пожалуйста.

Долго обьяснять, нужно знать специфику области.
Если коротко это trading компания у которой не правильно сработал assets liquidation in case of margin call. Margin call рассчитывался из рассчета, что цена на asset-ты не может быть меньше 0. Всё мы знаем, что недавно цена oil futures ушла в «negative territory», а именно в −37.63. Например, клиент купил oil futures с leverage на большую сумму, а если рассчитывать margin call = strike price — current price (всегда больше 0), то будет совсем другая цифра в случае если рассчитывать margin call = strike price — current price (и при этом current price может быть < 0). Это был в баг в системе, которая не учитывала, что цена может уйти < 0. Из-за этого liquidation process не правильно рассчитывал margin call для клиентов у которых были позиции на oil feature, которые на следующий день expired. Из-за того, что софт не правильно отработал компания потеряла 100 миллионов долларов, которые должна была компенсировать клиентам (в новостях это было кстати подробно описано).

А скільки мамкіних трейдерів у РФ не встигли вчасно опціони продати і винні тепер мільйони)))

Статья интересная, но я не могу согласиться с заголовком, что это промахи qa.
В статье описаны типичные примеры проблем процессов компании.
к примеру — показ демо на том же окружении где активно работает QA. Не могу сказать, что такая практика правильная и хорошая. И соот. она не могла не выстрелить, что и случилось

Ватра контент!
Останнім часом dou прям агонь контент лупить!

За термін «ватра контент!» підтримав би десяток разів.

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