Тестування швидке й повільне. Як обрати для свого проєкту

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

Мене звуть Роман, і я Middle QA в Geniusee вже понад 3 роки. Всі 3 роки доки я працюю на позиції QA. Я працював в тій самій компанії на одному проєкті, з яким пов’язаний весь мій професійний досвід. За цей час проєкт дуже сильно виріс та розширився. Через те, що я прийшов відносно на початку проєкту і пропрацював на ньому вже досить довгий час, то в мене виробилось хороше розуміння проєкту і всього функціоналу. Тому почав старатися максимально використовувати досвід, з чого й почались спроби все більшого використання технік тестування на основі досвіду. Що й привело мене до написання цієї статті.

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

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

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

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

Звідки взялася ідея

Ідея зосередитися на «швидкому» тестуванні виникла під час роботи над одним із проєктів. Проєкт спочатку розвивався як стартап із невеликою командою, яка з часом масштабувалася, але відділ QA залишився пропорційно невеликим: лише двоє тестувальників на дев’ятьох розробників.

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

16-17 травня, Київ. Квитки тут!👇

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

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

Швидке й повільне тестування: аналогія з мисленням

Як і у випадку з двома системами мислення, які описує Канеман, тестування можна умовно поділити на «повільне» та «швидке» залежно від підходів та цілей.

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

«Швидке» тестування, своєю чергою, використовує experience-based техніки, які дозволяють враховувати досвід тестувальників та адаптувати підхід до особливостей проєкту. Сюди входять, наприклад, exploratory testing та error guessing, які дають змогу швидко реагувати на зміни й виявляти проблеми, що могли б бути пропущені при формальному плануванні.

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

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

Experience-based тестування як елемент швидкого тестування

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

Основні форми experience-based тестування

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

Коли використовується:

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

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

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

Залежно від цілей тестування можуть бути використані різні «тури», які фокусуються на конкретних аспектах продукту:

• Supermodel tour — тестування лише інтерфейсу, як його бачить користувач, без глибокого аналізу функціонування системи.
• Collector tour — збирання максимальної кількості артефактів під час сесії тестування.
• Існують й інші види турів, які роблять тестування не тільки більш ефективним, але й захоплюючим процесом.

Переваги:

• Фокусування на сесії: у процесі exploratory тестування тестувальники працюють без відволікань на створення документації. Важливо лише створювати записи, які будуть використані для подальшої роботи.
• Гнучкість: тестувальник може адаптувати свій підхід залежно від виявлених аномалій і результатів.
• Залучення творчості: цей підхід дозволяє тестувальникам використовувати свою інтуїцію та творчість, щоб виявити дефекти, які можуть бути важко передбачені під час написання стандартних тест-кейсів.

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

Переваги та ризики experience-based підходу

Переваги:

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

Ризики:

• Висока залежність від кваліфікації тестувальника.
• Можливість упустити важливі аспекти через відсутність чіткої структури.
• Складнощі у повторенні тестів, якщо вони не були належно задокументовані.

Як ефективно використовувати experience-based тестування:

1. Ідентифікація ризиків. Важливо визначити області, де ризик помилок є найвищим, і комбінувати experience-based підхід із формалізованими методами для зменшення ймовірності пропуску критичних дефектів.
2. Автоматизація. Використовуйте автоматизацію для перевірки стабільних зон продукту та повторюваних сценаріїв, що дозволить зосередитися на дослідженні найбільш проблемних зон.
3. Баланс між швидким і повільним тестуванням. Використання experience-based підходу ефективне в динамічних умовах, але для проєктів із високими ризиками слід збалансувати його ретельною підготовкою та документуванням.

Experience-based тестування можна порівняти з джазовою імпровізацією. Для успішної імпровізації музикант повинен:

• Мати міцну теоретичну базу.
• Покладатися на свій досвід, щоб створювати унікальні комбінації звуків.
• Швидко реагувати на зміну ритму чи настрою.

Аналогічно тестувальник використовує свої знання, досвід і креативність, щоб забезпечити якість продукту. Такий підхід дозволяє не лише знаходити баги, а й відкривати нові шляхи для вдосконалення.

Як це виглядає на практиці

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

Проєкти з високими ризиками

У проєктах, де ціна помилки дуже висока, наприклад, у фінансових, медичних системах чи авіаційній індустрії, experience-based тестування використовується обмежено. Головний акцент робиться на «повільному» тестуванні з чіткими сценаріями, оскільки навіть незначний дефект може призвести до серйозних наслідків.

Як застосовувати:

• Використовуйте experience-based тестування для вторинної перевірки або пошуку неочевидних дефектів після основного етапу формального тестування.
• Використовуйте Exploratory Testing для аналізу інтеграційних зон або нетипових сценаріїв, які важко врахувати в документації.
• Автоматизуйте перевірку стабільних функцій, щоб звільнити час для більш креативних досліджень.

Приклад:
У медичному програмному забезпеченні після основного раунду тестування тестувальники проводять Exploratory Testing, щоб знайти дефекти, які могли залишитися непоміченими через нестандартні сценарії.

Динамічні проєкти

Проєкти зі швидким темпом розробки, частими змінами або обмеженими ресурсами ідеально підходять для використання experience-based підходу. Тут важливі гнучкість, креативність і швидка адаптація, тому формальне тестування часто поступається місцем більш інтуїтивним методам.

Як застосовувати:

• Використовуйте Ad-Hoc Testing для швидкої перевірки нових функцій у ситуаціях обмеженого часу.
• Залучайте Exploratory Testing для пошуку нетипових сценаріїв або тестування зон із високою ймовірністю дефектів.
• Використовуйте досвід і знання команди для аналізу змін і визначення потенційних ризиків.

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

Змішані проєкти

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

Як застосовувати:

• Ідентифікуйте критичні зони, які потребують «повільного» підходу, і приділяйте їм більше уваги.
• У зонах із низьким рівнем ризику використовуйте experience-based методи для економії ресурсів.
• Постійно адаптуйте баланс між швидким і повільним підходом залежно від змін у проєкті.

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

Загальні рекомендації:

1. Визначте особливості проєкту: оцініть його масштаб, складність, швидкість змін і рівень ризиків.
2. Розподіліть пріоритети: визначте критичні функції, які потребують ретельного тестування, і зони, де можна експериментувати.
3. Створіть гнучку стратегію: поєднуйте швидкі та повільні методи тестування залежно від поточних потреб проєкту.

Успішне використання experience-based підходу залежить від здатності тестувальника адаптуватися до контексту та правильно розподіляти ресурси. У цьому питанні, як на мене, важливий досвід і багато-багато практики.

Як це було на моєму проєкті

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

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

До того ж клієнт не вважав пошук потенційних суперечностей пріоритетом. У такій ситуації ми звернулися до exploratory тестування, яке дало змогу швидко й ефективно дослідити взаємодію старої та нової логіки. Це дозволило нам перевірити «стики» між підходами й виявити неочевидні баги, які могли залишитися поза увагою в рамках традиційного тест-дизайну.

Висновок

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

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

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