Про причинно-наслідкові помилки

#testing #curious #fallacies #thinking

Причинно-наслідкові помилки (causal fallacy) виникають, коли хтось бере дві окремі незв'язані між собою події та визначає, що одна подія викликає іншу.

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

Але щоб такої помилки уникнути - треба лишень глибше досліджувати проблеми та докопуватись до суті проблеми (а причини може бути в недостатньо оптимізованому коді із купою sleep() або копіпасти)

Дуже легко прийняти "очевидну" відповідь та побудувати хибні причинно-наслідкові зв'язки. Особливо, коли дві події дійсно можна пов'язати між собою. Якщо ви хочете побачити більше подібних помилок у кореляції двох подій - зацініть ресурс Spurious Correlations.

Про помилку незворотніх витрат a.k.a Sunk-Cost Fallacy

#testing #curious #fallacies #thinking

Помилки можуть виникати усюди. Найчастіше ми маємо справу з помилками в софті або якихось хардварних частинах. (Або у ваших автотестах ...)
Але чи існують помилки у тому, як ми мислимо? Виявляється, що так. Це помилки у логіці мислення. Ми робимо такі помилки навіть не помічаючи цього. 

У цьому циклі дописів, я спробую коротко розповісти про такі помилки із прикладами з тестування та автоматизації. Декілька днів тому я вже розповідав про causal fallacy. 

Що таке sunk-cost fallacy?
Сьогодні настав час для наступної помилки - sunk-cost fallacy або помилки незворотніх витрат. 
Уявімо ситуацію. Хтось у минулому прийняв рішення. Через деякий час виявилося, що рішення було неправильним. Але оскільки на це рішення було витрачено вже багато часу, зусиль та грошей - людина (або команда чи компанія) продовжують працювати над цим хибним рішенням. Та ще й відмовляються його переглядати. 

Приклади:
- менеджмент вважав, що автоматизація - то "легко" та купив усім ліцензії на відому та рекламовану low-code / no-code тулзу. Через деякий час виявилося, що тести дуже важко підтримувати та вони швидко ламаються після кожної зміни на фронтенді. Але гроші на річну ліцензію вже були витрачені, тому тестувальникам треба працювати з цими інструментами "через силу"
- те ж саме стосується будь-яких нових інструментів чи підходів (BDD, shift-left and right, etc) Особливо, коли інструменти "спускають зверху". Рішення вже "прийняті" або "нічого не знаю, клієнт так хоче!" або "це модний фреймворк, на ньому усі круті інженери пишуть - це майбутнє!"

Як запобігти цій помилці?
- Приймайте зважені рішення з порівнянням наявних альтернатив
- Розробляйте proof of concept будь-яких нових інструментів
- Думайте не тільки про плюси, а й про час на підтримку, переписування, інтеграцію нового у інфраструктуру
- Постійно оцінюйте прийняті рішення та не бійтеся відмовлятися від хибних та неефективних (навіть якщо сил та грошей було витрачено багато)

Помилка більшості a.k.a. Bandwagon Fallacy

#testing #curious #fallacies #thinking

Продовжуємо розбиратись з помилками в логіці та як вони можуть впливати на роботу інженера.

Що таке bandwagon fallacy?
Суть цієї помилки полягає в тому, що ми приймаємо рішення базуючись тільки на факті, що так робить більшість людей в індустрії. При цьому, ми не думаємо, а чи підходить це рішення для нашої конкретної ситуації.

Приклади
- AI та ChatGPT зараз на хайпі - саме тому треба його не просто вивчати, але й пхати усюди де тільки можна!
- Багато хто застосовує low-code або no-code інструменти - тому й вам потрібно почати!
- Усі пишуть автотести (шифтують вліво чи право, вивчають JS чи якийсь конкретний фреймворк) - тому й вам потрібно вивчати та застосовувати саме ці мови та підходи!
- Усі навкруги пишуть пишуть чек-лісти замість тест кейсів, тому й вам потрібно робити те саме!
- Усі міряють тестове покриття та ставлять не нижче 75-80-90% - тому й у вас на проєкті потрібно впроваджувати таке!

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