Нояб. 26

Синергія розробника і тестувальника: як запобігти негативному впливу когнітивних упереджень

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

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

Ілюстрації автора

Упередження, що впливають на роботу

Коли людина тільки починає працювати тестувальником, вона сповнена ентузіазму й запалу, відповідально ставиться до своїх завдань. Цього зазвичай досить, щоб наважитися подужати «Силлабус ISTQB» і, можливо, навіть скласти сертифікацію. Після 2–3 місяців запал вщухає, і «Силлабус» обертається на завжди відкриту вкладку в браузері, яку ніколи не проглядають. Але дуже важливо те, що до першого розділу «Силлабусу» обов’язково дійдуть усі, хто наважився на крок підвищити свою професійність.

Перший розділ дає нам розуміння деяких важливих речей: основ і головних принципів тестування. Зокрема, підрозділ 1.5 The Psychology of Testing (ISTQB Foundation Level Syllabus 2018) розповість про всі структурні особливості аджайл-команд: хто яку роль грає і яка роль у тестувальника. Як тестувальник має доносити до розробника або менеджера результати своєї роботи й на яку реакцію він може сподіватися. Тобто спеціальність, яка спочатку здавалася винятково технічною, виявилася значно складнішою з психологічного погляду, і це навіть підкреслили в збірнику для сертифікації. Це природно, що всі ми, працюючи разом, комунікуємо, а отже, впливаємо одне на одного.

Коли тестувальник не знайомий з розробниками, його підхід до тестування сталий: є тест-план, чек-лист, тест-кейс — певна процедура. Процедура, за якою відбувається тестування, і воно якнайоб’єктивніше, бо йде за планом. Але з часом робота стає цікавішою і, хоч як дивно, простішою. І ось уже розробник, якого тиждень тому ми вперше побачили, стає вам знайомішим. Ми вже знаємо, що він п’є каву без молока, а в розрахунках завжди робить помилки в десятих, але ніколи не нехтує піксельною точністю. Ще через деякий час розуміємо, що парадокс пестициду (ISTQB Foundation Level Syllabus 2018, розділ 1.3) уже працює на нас, що ми вже, як штучний інтелект, працюємо з прецедентами й вибудовуємо алгоритм у підсвідомості. Ми розуміємо, що залежно від того, хто виконував завдання, по-різному тестуватимемо.

Уявімо собі, що беремо в роботу завдання від інтерна. Перш за все ми подумаємо, що людина без досвіду, і помилок має бути багато. Через деякий час бачимо, що працівник ретельно перевіряє свою роботу й віддає в тестування лише попередньо протестовані завдання та, як наслідок, ми не знайдемо багато помилок у цьому коді. Ми перестанемо так ретельно перевіряти роботу цього розробника, бо підсвідомо довіряємо програмістові. Водночас до нас у роботу надходять завдання від іншого розробника (не вказуватиму тут рівень програміста, оскільки це неважливо). І ось раз у раз ми бачимо, що людина припускається якихось дрібних помилок, але кожне завдання з ними: десь, у титулці, літеру пропустив, десь колір переплутав, десь — мінус з плюсом. І щоразу щось незначне, але трапляється. Звичайно, ми намагатимемося бути якнайуважнішими з завданнями від цього розробника й витратимо більше часу на пошук дрібного багу. У третій ситуації нам надійдуть завдання, які, ймовірно, можуть бути недороблені. Наприклад, в описі завдання 5 пунктів, а людина виконала тільки 4. Відволіклась і забула про той 5-й пункт. Але перші 4 ідеальні. І таке трапляється приблизно в 30% завдань. У такому разі ми уважніше читатимемо опис й Acceptance criteria. Отже, для кожного спеціаліста в нас буде свій алгоритм роботи. Випадків безліч, і до кожного ми так чи інакше адаптуємося.

З одного боку, це упереджене ставлення, що для тестувальника погана характеристика, але, з іншого, є група методів тестування (ISTQB Foundation Level Syllabus 2018, розділ 4.4), які базуються на досвіді, тести створюють на основі вміння, інтуїції й досвіду тестувальника. Тобто виходить, що наша підсвідомість дає саме нам цей інструмент тестування. Цікаво те, що коли розробник, якого ми аналізуємо, не розвиватиметься, ми звикнемо до нього і, так би мовити, зафіксуємо модель як сталу. Пряма залежність — розробник розвивається, і ми також. Але ж головне, щоб ми це вчасно помітили. Саме тут може спрацювати упередженість. Ми тестимо код джуніор смарта, а він уже рік як сеньйор мерседес.

З психологічного погляду, такий феномен називають когнітивним упередженням — відхилення в судженнях, яке супроводжується можливою нелогічністю у висновках про інших людей і ситуації. Людина створює свою «суб’єктивну соціальну реальність» на основі власного сприйняття даних зовнішнього світу. Когнітивних упереджень, спотворень безліч (~65), і всі вони в нас є.

Серед тих, які я помітила за собою, хочу виділити такі:

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

Ретроспективне упередження — це спроба підтвердити думку, яка вже є в наших думках (експеримент Форера). Усе просто: якщо ти не «любиш» того «гівнюка», то знайдеш баги в його коді (навіть якщо їх там немає — нічо’, будуть). Проблема в тому, що, намагаючись підтягнути реальність до наших сподівань, ми можемо побачити те, чого немає. Наприклад, розмір кнопки, відтінок, швидкість кліку. Якщо все це, наприклад, чітко не прописано в Acceptance criteria, то підстав для дискусії багато, і треба керуватися здоровим глуздом, а він у кожного свій. І витрачати час на баг через колір відтінку кнопки під час натискання просто нераціонально.

Ефект прилучення до більшості — ми більш схильні погоджуватися з думками більшості, ніж відстоювати або навіть генерувати власні. Особливо якщо ми знайомі з цими людьми чи вони для нас авторитети (експеримент Соломона Аша). Якщо я в чомусь не впевнена, то піду по пораду до інших людей і послухаю їх. Головне — так чоловіка не вибирати. Звичайно, прислухатися до думок решти варто, але вирішувати треба самостійно. Як мама казала: «А якщо всі з мосту підуть стрибати, ти теж підеш?» Не треба з мосту за всіма — є й інші джерела інформації, коли з’являється спірне питання. Перш за все — документація. Якщо її немає, а немає її часто, то варто звернутися до Product Owner — він на проекті, щоб розв’язувати проблеми (хоча це теж спірне питання). Наприклад, нам дали нове завдання: протестувати інтеграцію з іншою програмою. Ми знайшли спірний баг, але дослідили питання й з’ясували, що аналогічна проблема траплялася на інших проектах, де використовували цю програму. Колеги ж дотримуються думки, що проблема наша. І в такому разі, з ними погодившись, ми не зробимо краще. У ситуації, коли наше рішення безпідставне, ліпше прислухатися до тих, хто краще тямить саме в цьому питанні. На мій погляд, якщо ви знаєте, що потім пошкодуєте, як не висловите свою думку, то треба її відстоювати.

Сліпота неуважності зумовлена фреймінгом. Це прояв класичної неуважності, якщо ми зосереджені на чомусь одному, то на інше подекуди просто не звертаємо уваги. Нове завдання може бути цікавішим і пріоритетнішим, ніж старий функціонал. Унаслідок цього те, у чому ми, здавалося, були впевнені, може підкласти свиню у вигляді критичного багу. Тому що туди просто ніхто давно не лазив і не тиснув ту кнопку.

Ефект негативу — скептичне ставлення до всього. Така собі «Баба-Яга проти». В окремих ситуаціях це непогано (негативне тестування). Але коли ти бачиш усюди зраду, то потрібно до лікаря. Зацикленість може бути проявом маніакальних схильностей :) Цей випадок — прекрасний приклад важливості пріоритизації та серйозності (Priority/Severity).

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

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

Для мене це явище цікаве не в негативному розумінні, адже там воно, безумовно, має значний вплив, а в позитивному. Наскільки корисною може бути ця особливість людського мозку? Адже ми насправді заощаджуємо час, не перевіряючи там, де це не потрібно, адже ймовірність зустріти баг невисока, і докладаємо більше зусиль там, де, найпевніше, це буде виправдано. За моїми спостереженнями, з часом продуктивність роботи тестувальника знижується — набридає проект, він втрачає концентрацію, доводить навички до автоматизму. Метрик для визначення ефективності роботи тестувальників досить багато: вимоги до розроблюваного ПЗ; якість розроблюваного продукту; можливості й ефективність команди QA; якість роботи команди тестування; зворотний зв’язок та задоволеність користувачів.

З одного боку, зменшувати показники буде когнітивним спотворенням, але з іншого, наша схильність до оптимізації роботи через визначення слабких і сильних сторін розробника компенсує втрати продуктивності. Зазвичай такі метрики збирають раз на квартал. Середній термін роботи інженера в одній компанії — від 1 до 2 років. За такий термін з моніторингом раз на 3 місяці простежити динаміку змін досить складно. Будьмо оптимістами й візьмімо середній термін у 2,5 року. За цей час маємо 10 точок спостереження. Можна їх усі проаналізувати й побачити, коли упередження почали впливати на людину. Але так ми втратимо час. А от з правильним плануванням й аналізом упереджень, а також застосуванням кроків на усунення наслідків ефективність роботи не тільки не знизиться, а й зросте.

Поради

У більшості випадків усім схожим спотворенням можна запобігати так:

Знати, що когнітивне спотворення є й закладати це як ризики, плануючи проект.
Досконалості немає — усі роблять помилки, їх треба лише помітити.
Треба вміти пріоритизувати — не всі помилки для тестувальника важливі, треба вміти вчасно зупинитись і подивитися на баг об’єктивно.
У всіх є емоції, хтось сильно керований ними, хтось мало, але вони є у всіх, і наші думки від них залежать.
Треба бути уважними — насамперед до себе.
Не довіряйте собі — усі брешуть, і ви — також.
Самі собі менеджер — подивіться на себе з боку. Якщо ви відчуваєте, що ваш ККД впав нижче за допустиму межу, змінюйте проект або усвідомте, що ви маєте бути більш бюрократичним, ніж раніше.
Процедури — це корисно, хоча б для того, щоб бути завжди готовими до співбесіди.
Автоматизуйте дурну роботу — не засмічуйте мозок.
Фіксуйте під час кожного спринту якість тестування вимірювальними показниками: знайдено помилок з першого разу, з другого. Знайдено помилок після релізу. Оптимально налаштовуйте такі показники в системі керування проектами, щоб можна було завжди формувати звіти на основі зібраних даних.
Створюйте додаткові точки перевірки роботи команди, наприклад раз на два місяці. Якщо кількість помилок, що їх виявив тестувальник, знижується на 10/20/30%, то варто перевірити дві гіпотези: або розробник працює ліпше, або тестувальник гірше. Як варіант, можна залучити тестувальника зі стороннього проекту: якщо він виявить більш як на 20% помилок, ніж «свій» тестувальник, саме час «струснути» команду.
Постійно стежте за кількістю помилок, виявлених після релізу. Якщо їх кількість зростає, очевидно, знижується якість внутрішнього тестування.

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

Замість висновку

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