🐞 П’ятнична флудильня для QA-спільноти #16. Наведіть приклади серйозного, але не пріоритетного бага

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

Привіт, друзі! 🙌

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

Тема на сьогодні: давайте обговоримо пріоритезацію багів, як з’ясувати, який баг більш важливий, а який менш? Наведіть приклади серйозного, але не пріоритетного бага. Діліться чим керуєтеся під час класифікації/пріоритезації багів. 💬

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
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

Робили телефонію для роутера. На компі воно нормально бігає, а на роутері в 5% випадків при виході прога або висне, або крешиться. Поковирялись — виявилось, що проблема під час деініціалізації бібліотеки для IP-телефонії. Якщо просто вийти, і нічого не вимикати — то не висне. Бага стала непріоритетною. Ковиряли в бекграунді ще з пів-року. Кому цікаво: за стандартом POSIX видалення залоченого мютекса є undefined behaviour. Але десктопний лінух повертає помилку. А вбудований в роутер — кораптив пам’ять десь в libc.

Яндекс браузер під Андроїд. Заходиш на сайт з великою картинкою, дивишся картинку в повний розмір, закриваєш вкладку — креш. Так мало хто робить, і всім пофіг. Кому цікаво: об’єкт-обгортка для mmap() робив {munmap(ptr_, size_); ptr_ = NULL;} і в методі unmap() і в деструкторі. Проблема, що при великому size_ munmap(NULL, size_) зачіпав хвостом пам’ять, виділену під стек.

Ну, з Яндекс браузером проблема має просте вирішення. Зносиш це лайно і ставиш замість нього Mailru Amigo нормальний браузер.

Ну вона була вирішена тим, що Гугл в Хроміку цей клас відрефакторив, поки я її інвестигейтив. А так був би такий прикольний фікс(

Насправді, там під капотом Хроміум (як і в більшості сучасний браузерів), тому якість не має відрізнятись.

Я нещодавно писав про одну з топ ІТ компаній, у якій нема QA, а є тільки Software Engineer (dou.ua/...​rums/topic/39903/#2481571). А ще є сапорт. І от критичні баги, які роблять неможливою нормальну роботу — то проблема Software Engineer. Як він перевіряв свою роботу якщо воно не працює?! Але якшо бага така, що її можна «обійти» і нормально працювати далі — то вже робота сапорта. Тому що попрохати у клієнта вибачення і допомогти обійти багу — швидше, ніж її чинити і робити новий реліз. Є безліч багів, які клієнти бачать кожен день: щось не вмикається з першого разу, чи той славнозвісний «зсув на 2 пікселі» — і клієнти це навіть не репортять! Бо не заважає — а репортити це треба писати чи дзвонити у сапорт.
Отже поступово окреме QA стає зайвим: користувачі самі знайдуть проблеми! Якщо це критично — то можна просто швидко відкотитися на попередню версію. Якщо можна обійти — сапорт допоможе, а пофіксять у майбутньому. Якщо користувачі не скаржаться — то це і не проблема!
Я замислився — а звідки така тенденція нехтувати якістю? Хіба не варто прагнути зробити систему без відомих дефектів?
І виявилося, що це питання значно ширше за ІТ чи технології — воно філософське, я б навіть сказав екзистенціальне!
Почнемо з аксіоми: завжди є і будуть похибки та дефекти. Тобто ідеальна система без жодного дефекту неможлива саме тому, чому КПД 100% і «вічний двигун» (тут має бути лекція про ентропію). Дефекти можливо знаходити і усувати, а якщо цього не робили то з часом вони будуть накопичуватись зі зростаючою швидкістю. До того моменту, коли стабільне функціонування системи стане неможливим. Але ще раніше використання системи стане неефективним настільки, що не буде мати сенсу.
Тобто у нас є два протилежних «граничних» сценарію. Перший — ми використовуємо систему, ніколи не лагодимо, а коли використовувати стає неефективним — міняємо на нову. Другий — ми постійно мониторімо систему, виявляємо навіть потенційні проблеми і лагодимо завчасно аби з часом наша система не псувалася. Здавалося б: чудово мати завжди працюючу систему, але це має свій кошт! Час і ресурси, які постійно витрачаються на підтримку існуючої системи могли — вони насправді «вкрадені» у майбутнього! Адже якщо вони могли б бути використані на створення нової, кращої системи.
Я не буду зараз писати про одвічний «холівар»: постійно підтримувати старе, чи робити нову версію? Намагатися пихати нові фічі у стару систему чи чекати доки конкуренти створять нову і кращу?
Уявимо практичну реалізацію цих сценаріїв: чи можна було б у лабораторних умовах створити людину, яка б прожила, скажімо, 200 років? Обрати генетичний матеріал без дефектів, створити стерильні умови, постійно моніторити, планувати навантаження, додавати корисні елементи. Може використовувати нано-боти аби знищувати ракові клітини, може клонувати заміну пошкодженим органам ... тобто якшо максимально швидко усувати усі дефекти — скільки років могло б існувати людське тіло? Звичайно що не вічно — це виходить з аксіоми про неминучість помилок. Хай навіть якщо 200 років — це більш ніж вдвічі більше за середнє життя!
Але якщо порахувати скільки часу з цих 200 років було витрачено саме на попередження та усунення дефектів — то може виявитись, що це буде більше половини! Адже з часом дефектів буде більше і підтримувати буде усе важче. А якщо ще рахувати усі обмеження — то виявиться шо час, який ця «стерильна» людина могла повноцінно жити — не більше за якусь звичайну людину, якої поталанило з генетикою і вона прожила 90 років.
Мене не припиняє дивувати, як розмірковуючи про те, як зробити щось краще, ми спочатку вигадуємо фантастичні ідеї, постійно їх обмірковуємо, удосконалюємо, і врешті-решт повертаємось до того, що оптимальним виявляться саме те, як воно є зараз!
Здавалося б: перемогти старіння та смерть — це природна ціль людського прогресу. Але виявляється що завжди підтримувати старе — то не краще рішення! Навіть більше — старе стає невигідним як тільки прогрес дозволяє створити нове (і краще) на заміну за ті ж ресурси. Тобто старіння і смерть — це і є оптимальна стратегія, яка закладена у всесвіті!
Повертаючись до питання: яка якість є достатньою і чи є сенс лагодити дефекти? Якості потрібно вистачити до запланованої смерті! Наприклад якщо людина буде користуватися смартфоном 2-3 роки поки замінить на новий — то це і є його запланована довжина життя. А скільки років людина користується програмою доки замінить на нову? Чи через скільки років модний інтерфейс на Ангулярі стане вважатися мотлохом?
Ось так ІТ цікаво перетинається з питаннями життя і смерті. Скільки років ви плануєте жити? Бажаєте побачити правнуків? — ЗОЖ і повне медичне обстеження кожен рік. Треба жити поки молодий? — тоді усі проблеми можна маскувати знеболюваним.

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

QA є зайвим із самого початку. Щоб його мати справжнім, а не п’ятим колесом у возі, треба спочатку пройти стадію Inversion of control. Тобто фактично народити QA від сапорту, принаймні менеджмент. А розумно — від системи контроля якості продукту/сервісу в цілому, але її також має хтось народити.

Бажаєте побачити правнуків? — ЗОЖ і повне медичне обстеження кожен рік. Треба жити поки молодий? — тоді усі проблеми можна маскувати знеболюваним.

А ще є наркотики, інструмент прямої дії. Проблема в тому, що для окремої людини наркотики визнані злом, хоча із точки зору біології вони є самим добром, як гроші в економіці. Але чи є насправді в менеджменті добром час та гроші? І відповідь та сама: вони формують наркотичну залежність. А ще — механізми винагородження та покарання, які у менеджменті набувають маразму із ростом висоти ієрархії. І цього маразму досить щоб вбити навіть цілком по науці побудовані процеси, що вже казати про традиційні побудови методом «а ми через паркан побачили», «у п’ятницю в барі конкуренти вихвалялися, як у них».
__________
Бобер пише українською. Тільки зараз побачив :)

Сломалась стабилизация синхронизации кластеризации стойкого глубокого циклического дисконнекта

И тут она возьми да раскройся
(анекдот про боксёра)

«Наведіть приклади серйозного, але не пріоритетного бага»

Коли для того, щоб вітворити багу, тобі треба 10 разів зі швидкістю світла натиснути на одну і ту саму кнопку, зробити свайп зверху, а потім вирубити інет.
І тоді закрешиться мобільний додаток :D

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