Cognitive QA: чому ми не бачимо очевидні баги

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

Мене звати Дмитро Пеня, я QA Engineer у Redwerk. Це моя перша стаття на DOU, і вона присвячена темі, яка неодноразово допомагала мені пояснити «як я міг це пропустити?» — когнітивним викривленням у тестуванні.

Cognitive QA: чому ми не бачимо очевидні баги

Як я зрозумів, що справа не в уважності? У кожного тестувальника був такий момент: відкриваєш прод, бачиш очевидний баг — і ловиш себе на думці:

«Та як я міг це пропустити?!»

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

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

Так почалася моя цікавість до теми когнітивних викривлень. Я накидав нотатки, зберіг різні текстові файли з інформацією і... на якийсь час забув, але надалі із цього виросла доповідь для QA Days UA 2025 — «Cognitive QA: як працює мозок тестувальника і чому ми не бачимо очевидні баги».

Що таке когнітивні викривлення — і до чого тут QA

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

Мозок каже:

«Я вже бачив схожу ситуацію — отже, і результат буде таким самим».

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

Переможця обираєш ТИ! 👏

Приклади з практики

1. Confirmation bias — «Я впевнений, що все працює»

Ми звикли перевіряти те, що повинно працювати. Запускаємо тест — і вже очікуємо зелений колір і «Pass».

Я ловив себе на тому, що, коли бачу зелений результат у логах, то просто переходжу далі, не придивляючись. Одного разу я через це пропустив помилку в API — запит повертав неправильний код, але тест не фейлився. Мозок «підказував»: усе ж зелене — все ок.

І це класичний confirmation bias — коли ми шукаємо підтвердження своїх очікувань, а не спростування.

2. Inattentional blindness -«Горила у кадрі»

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

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

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

3. Anchoring — «Перший баг формує мислення»

Якщо перший знайдений дефект був у стилі кнопки, то ти підсвідомо шукаєш подібні.

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

4. Sunk cost fallacy — «Я вже витратив стільки часу»

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

У QA це часто веде до «впертої перевірки» того, що треба просто переробити з нуля. Був в мене такий досвід, з коллєгами, які поголовно «хворіли» на Sunk cost fallacy. Ох і намучався...

Реальні кейси з проєктів

Кейс 1. Баг, який не бачили три спринти

У формі дропдаун перекривався іншим елементом і ставав неклікабельним. Жоден QA не звернув увагу, бо «усі вже тестували цей компонент». Класичний мікс confirmation bias + inattentional blindness.

Після фіксу ми знайшли ще три подібні місця — просто змінивши фокус.

Кейс 2. «Нормальна» валідація

Форма перевіряла номер документа. Усе здавалося ок, поки не ввели «000000000000000». З технічного боку — валідно. З точки зору бізнесу — нісенітниця.

Але QA перевіряли лише «що має пройти». І знову — спрацювала прив’язка до позитивного сценарію.

Кейс 3. «Усе працювало на деві»

На dev-оточенні всі користувачі мали дефолтні права, а на проді з ролями обмеження були жорсткіші. Кнопка «Submit» просто не рендерилась. Ніхто не перевірив через інші ролі, бо «на деві все було ок».

Тут зійшлись inattentional blindness і recency effect — останні дефекти були про дані, і ми шукали подібні.

Кейс 4. Порожні дати у проді

На QA-середовищі айтеми мали чекбокс «прив’язати до дати». Тестувальники вручну його ставили, все працювало. Але в проді чекбокс був активним за замовчуванням — і айтеми мали порожні дати, що зламало логіку.

Ніхто не перевірив варіант із відмінною поведінкою, бо «на деві так не було».

Тут спрацювали декілька викривлень: Confirmation bias: QA очікували, що функціонал працює, як при ручному встановленні, й не думали перевіряти інший сценарій «за замовчуванням».

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

Recency effect: перед цим тестували сценарії із ручним введенням дат — і саме вони залишилися в фокусі уваги, не лишаючи місця на випадки з дефолтними значеннями.

Як із цим боротися

Когнітивні викривлення не можна «вимкнути». Але можна створити умови, щоб вони шкодили менше.

Pair / Buddy testing

Двоє тестувальників бачать світ по-різному. Один може бути «засліплений» confirmation bias, а інший — помітить нестиковку одразу.

У мене не раз було: колега під час спільної перевірки помічав баги в знайомому модулі, які я просто «пролітав очима».

Чек-листи та anti-checklists

Чек-листи нагадують про базові речі — ролі, валідацію, кнопки, тексти.

Anti-checklists, навпаки, допомагають мислити нестандартно:

• А що, якщо мережа впаде?
• А якщо користувач натисне Enter п’ять разів поспіль?
• А якщо поле залишиться порожнім?

Вони вибивають нас із автоматизованого режиму — і дають шанс побачити більше.

Тестування негативних сценаріїв

Більшість тестів перевіряє, що працює. Але найцікавіше починається, коли перевіряєш, що не має працювати.

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

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

Інструменти Cognitive QA

SFDPOT — Structure, Function, Data, Platform, Operations, Time

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

Добре працює тоді, коли «застрягаєш» на одному рівні й перестаєш бачити інше.

CRUDL — Create, Read, Update, Delete, List

Класика для всіх CRUD-сервісів. Дуже просто, але саме в простих речах ми часто й помиляємось. Зазвичай ми пам’ятаємо про створення і читання, а от видалення чи сортування списків «випадають». CRUDL нагадує про базу, яку легко прогледіти.

Картки перевірки викривлень (Bias Checklist Cards)

Це маленькі підказки перед тест-сесією. Вони нагадують зупинитися і запитати себе:

«Я зараз дивлюсь об’єктивно чи очима людини, яка хоче побачити, що все працює?»

«Я перевірив тільки позитивний шлях чи ще й крайні значення?»

Є кілька відкритих наборів, які можна взяти безкоштовно:

• Mindset Cards (by Beren Van Daele & colleagues) — на жаль, безкоштовні картки не вдалося знайти, тому тільки платний продукт.
• Bias Cheat Sheet (by Buster Benson).
• TestSphere Cards (by Ministry of Testing).

Особисто я час від часу беру одну-дві картки перед дослідженням модуля — ніби перемикач уваги з «автопілота» на свідомий режим.

Exploratory Charters (чартери дослідницького тестування)

Це короткі мінізавдання, які задають напрям тестування. Наприклад:

«Перевірити, як поводяться фільтри, якщо даних взагалі немає».

«Спробувати знайти спосіб зламати пагінацію».

Чартери не дають застрягти на підтвердженні очікуваного й добре ламають confirmation bias.

Bug Bash з ролями

Командна активність, яка дуже швидко розширює «поле бачення».

Кожен тестує продукт «з іншого боку»:

• як новачок;
• як користувач із повільним інтернетом;
• як людина з дальтонізмом;
• як «хуліган», що намагається все зламати.

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

Чому всі ці інструменти працюють? Вони не борються з викривленнями напряму — вони змушують змінити фокус. А коли змінюється фокус, мозок перестає працювати за інерцією. І тоді ми бачимо більше.

Висновки

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

QA — це не лише техніка, автоматизація чи документація. Це вміння мислити інакше, змінювати кут зору й не довіряти навіть власним очам.

Бо якість продукту починається з якості мислення.

Сподобалась стаття? Підписуйтесь на автора, щоб отримувати сповіщення про нові публікації на пошту.