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

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

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

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

Теми: automation QA, QA, обговорення, П’ятнична флудильня, тестування

Ctrl + Enter

Denys Poltorak Embedded | C++ (opentowork) 16.09.2022 20:49

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

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

Відповісти

Підтримати

Олексій Пєніє 17.09.2022 06:46

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

Denys Poltorak

Denys Poltorak Embedded | C++ (opentowork) 17.09.2022 09:50

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

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

Олексій Пєніє

Beaver Green 16.09.2022 19:30

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

Олексій Пєніє 17.09.2022 07:07

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

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

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

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

Beaver Green

Alexander Grinko 16.09.2022 17:54

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

Олексій Пєніє 17.09.2022 07:11

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

Alexander Grinko

Artem Grygorenko Працює в QA Коуч 16.09.2022 17:49

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

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

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

Схожі топіки

8 коментарів

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

Новини