Ми відмовились від 1000+ регресійних скриптів. І це найкраще, що ми зробили для якості продукту
Півтора тижня регресії, понад тисяча тестів, усі зелені. Через тиждень після релізу користувач знайшов баг, який ми не побачили.
І це був не якийсь рідкісний випадок, а звичайний сценарій, яким люди користуються щодня. Знайомо?
Мене звати Владислав Бабенко, я Quality Engineering Manager в EPAM. Майже 25 років слідкую за Формулою 1 і вболіваю за Scuderia Ferrari, і, як не дивно, саме це хобі дало мені найкращу метафору для пояснення того, чим ми зараз займаємось у тестуванні. Але до Ferrari повернемось трохи згодом.
Ця стаття для QA-інженерів і тест-менеджерів, які дивляться на свій набір регресійних скриптів і відчувають його радше як тягар, ніж як гарантію. А ще для тих, хто чув про дослідницьке тестування, але не розуміє, як його порахувати, спланувати і пояснити менеджменту: тут буде і теорія, і те, як вона виглядає на реальному проєкті.
Якщо ви тімлід або продакт, чий реліз щоразу впирається в регресію, або просто шукаєте реальні приклади застосування AI у процесах, а не чергову статтю про те, як попросити ChatGPT написати тест-кейси, вам теж сюди.
Розповім, як моя команда за кілька місяців повністю відмовилась від скриптованої UI-регресії, перейшла на дослідницьке тестування, а потім віддала його логістику AI. З цифрами, реальними помилками та висновками, які я б хотів почути пару років раніше.
Продукт, який не влазить у скрипти
Ми з командою працюємо над коучинговою платформою, яка входить у топ-3 своєї ніші і має близько 3000 активних користувачів щодня.
У продукті є дві ролі, і логіки вистачає в обох. Але складність у них різного типу.
Client-частина живе одразу в десятках конфігурацій. Одну й ту саму фічу тут треба перевірити кожною мовою, на кожній темі й на кожній платформі, бо в різних комбінаціях вона поводиться по-різному. Це перетворюється на десятки окремих задач.
Coach-частина не простіша, але складність там іншого роду: це бізнес-логіка. Календар і доступність тренера, керування сесіями, бібліотека статей і зовнішніх ресурсів, синхронізація зі сторонніми календарями.
Тепер додайте темп. Спринт: два тижні. Реліз: кожні два спринти. На регресію ми закладали тиждень, але по факту вона стабільно розтягувалась на півтора.
Ідея «протестувати все» в такому ритмі не потребує оптимізації. Вона просто математично неможлива.
Чому тисяча зелених тестів нічого не гарантувала
Одразу уточню, щоб не було плутанини. Йдеться саме про UI-регресію, тобто про регресійні тест-кейси на інтерфейс. API-тести і юніт-тести на проєкті були, працювали і працюють досі. Їх ми не чіпали, і ця стаття не про них.
Скрипти в нас були непогані. Добре підтримувані, з пристойним покриттям на папері.
І все одно UI-регресія забирала півтора тижня, ми ганяли понад тисячу кейсів щоразу, а критичні баги все одно доходили до продакшену.
Була ще одна деталь, яку я довго недооцінював. Півтора тижня — це не тільки виконання. Значна частина цього часу йшла на аналіз результатів.
Найприкріше було не те, що баги траплялись — вони трапляються завжди. Розчаровувало те, що саме знаходили після релізу.
Скрипти ловили те, що ми вже і так знали, а проблеми жили там, куди ми не здогадувались подивитись.
Уявіть охоронця, який щоночі обходить будівлю за однаковим маршрутом. Двадцять років, той самий шлях, ті самі двері. Він робить свою роботу бездоганно. Але якщо хтось заліз через вікно на третьому поверсі, повз яке маршрут не проходить, охоронець його не побачить. Не тому що поганий. Тому що маршрут написали до того, як з’явилося те вікно.
Наші скрипти були тим охоронцем.
Є ще один ефект, про який варто сказати окремо. Скриптований прогін привчає увагу дивитись рівно туди, куди вказує крок сценарію. Усе інше на екрані стає фоном, навіть якщо там коїться щось дивне.
Це не про уважність конкретної людини, це властивість самого формату. Ти звіряєш фактичний результат з очікуваним, і саме на цьому зосереджена вся увага. Питання «а що ще тут відбувається» сценарій просто не ставить.
Що таке експлораторне тестування (і до чого тут Ferrari)
Українською його називають дослідницьким тестуванням. Далі я користуватимусь обома термінами як синонімами, бо в роботі ми частіше кажемо «експлораторне».
Тут варто зупинитись, бо це поняття плутають одразу з трьома різними речами.
Дослідницьке тестування не є ad-hoc тестуванням (тестуванням навмання). Ad-hoc — це хаотичне клікання без плану, без запису, без мети.
Це не monkey testing (мавпяче тестування), тобто хаос заради хаосу.
І це не протилежність скриптованому тестуванню, ніби вибір стоїть між скриптами і повним безладом.
Трохи теорії, бо без неї нікуди
Термін увів Сем Канер ще у 1984 році. Формальне визначення звучить так: одночасне навчання, проєктування тестів і їх виконання.
Розберемо по частинах, бо саме тут ховається суть.
Навчання. Ти вивчаєш застосунок просто зараз, під час сесії. Не читаєш специфікацію завчасно, а бачиш реальну поведінку системи на власні очі.
Проєктування. Наступний тест ти вигадуєш на основі того, що застосунок щойно показав. Побачив дивну поведінку на формі оплати? Наступні п’ять кроків будуть про неї, хоча п’ять хвилин тому ти про це не думав.
Виконання. Все це відбувається паралельно, а не послідовними фазами.
Ключова відмінність від скриптів не в тому, що підготовки немає. Вона є. Просто вона відбувається в реальному часі, а не заздалегідь.
Сесія, чартер і як не перетворити свободу на хаос
Найпоширеніше заперечення, яке я чув: «Це ж некерований процес, як ти зрозумієш, що зроблено?»
На це є відповідь, і називається вона «Session-Based Test Management», тобто управління тестуванням на основі сесій. Підхід придумали брати Джонатан і Джеймс Бах.
Логіка проста. Робота ділиться на сесії, кожна з яких має три обов’язкові елементи.
Тайм-бокс. Сесія обмежена в часі, зазвичай 60 або 90 хвилин. Не «тестуй, поки не набридне», а конкретний відрізок, який можна порахувати й спланувати.
Чартер. Це завдання сесії, одне речення про те, що ми досліджуємо і навіщо. Наприклад, реальний чартер з нашого проєкту: «Дослідити процес бронювання сесії з обмеженим календарем тренера, щоб знайти проблеми в обробці помилок».
Чартер задає напрямок, але не диктує кроки. Він каже «їдь у той бік», а не «на третьому повороті бери ліворуч».
Нотатки й дебриф. Під час сесії тестувальник записує, що робив і що знайшов. Після сесії коротко обговорює це з командою. Саме нотатки перетворюють дослідження на щось вимірюване.
Є ще одне поняття, без якого картина неповна: оракул. Це ознака, за якою ти взагалі розумієш, що перед тобою баг. Специфікація, аналогічний продукт конкурента, здоровий глузд, консистентність застосунку. У скриптованому тестуванні оракул зашитий в очікуваний результат. У дослідницькому підході ти тримаєш усе в голові й застосовуєш на льоту, тому він так сильно залежить від досвіду людини.
А тепер обіцяна Ferrari
Кожен гоночний вікенд у Формулі 1 починається з вільних заїздів. Пілот виїжджає на трасу без жодного скрипта. Ніхто не дає йому папірець: «На третьому повороті гальмуй за сто метрів». Він їде і шукає межу сам. Пробує різні траєкторії, різне гальмування, різні режими. Він досліджує трасу, яка сьогодні поводиться інакше, ніж торік: інша температура асфальту, інший вітер, інша гума.
Це і є дослідницьке тестування у чистому вигляді. З тайм-боксом (сесія триває рівно годину), з чартером (сьогодні перевіряємо довгу серію на м’якій гумі) і з нотатками (телеметрія пише все).
А от піт-стоп, навпаки, це скрипт. Двадцять людей, дві секунди, рухи відпрацьовані тисячі разів. Жодної імпровізації.
Обидва потрібні. Але гонки не виграють на піт-стопах. Їх виграють там, де пілот побачив на трасі те, чого не було в жодному плані.
Тури: як не загубитись у свободі
Найкорисніше, що я знайшов у книзі Джеймса Віттакера «Exploratory Software Testing», це метафора турів.
Уявіть, що досліджуєте застосунок як турист місто. Можна взяти путівник і пройти головні пам’ятки (Guidebook Tour). Можна піти в район, куди туристів зазвичай не пускають (Bad-Neighborhood Tour, тобто прогулянка найбагованішими закутками продукту). Можна цілий день ходити за кимось одним і дивитись, куди він вас приведе (FedEx Tour, де ти слідуєш за даними через усю систему).
Кожен тур це інший фокус уваги. І кожен ловить свій тип проблем.
У нас в ротації опинилось 23 такі тури.
Друга книга, яка сильно вплинула на мій підхід, це «Explore It!» Елізабет Гендріксон. Вона про дисципліну, яка стоїть за свободою: чартери, евристики, практика проведення сесій так, щоб вони давали результат, а не просто відчуття зайнятості.
Як ми запускали це вручну
Скажу прямо, бо це важливо: коли пізніше додали AI, ідеологія не змінилась ні на йоту. Змінилась тільки логістика навколо неї.
Спершу ми все робили руками. Підхід тримався на чотирьох принципах:
- Розбили застосунок на чекпоінти (контрольні точки). Замість нескінченних скриптів ми виділили функціональні чекпоінти: менші, змістовні одиниці поведінки. Вийшло 134 на реліз.
- Розподілили навантаження чесно. Кожен тестувальник отримує збалансований набір, приблизно порівну між Client і Coach частинами.
- Дали кожному свій сетап. Одна локаль і одна тема на людину за раз. Так покриття розповзається по матриці, а не дублюється.
- Розділили платформи. Половина команди на мобайлі, половина на вебі з конкретним браузером.
Спрацювало. Але кожен реліз коштував нам кількох годин планування в таблицях і ручної ротації турів, щоб ніхто не застрягав на одному й тому самому.
Чотири речі, які ми не передбачили
На папері процес виглядав ідеально. У реальності ми побачили чотири проблеми, до яких не готувались.
«А що таке взагалі це ваше дослідницьке тестування?»
Наші джуніори щиро не розуміли підхід. Уявіть, що вам кажуть: цього релізу ти робиш Supermodel Tour, а наступного Couch Potato. Без контексту це звучить як назви коктейлів, а не як техніки тестування.
Найприкріше, що за кожною назвою стоїть проста ідея. Supermodel Tour означає дивитись виключно на зовнішній вигляд: верстку, шрифти, вирівнювання, анімації, і не занурюватись у логіку. Couch Potato Tour — це прохід застосунком узагалі без ручного введення, коли всюди лишаєш значення за замовчуванням і просто тиснеш далі. Але з назви цього не видно, а книжку на той момент ніхто з команди не читав.
Вирішили просто: прив’язали кожен тур до конкретних чекпоінтів і зробили таблицю сумісності. Тепер видно, який тур має сенс для якої частини застосунку.
«Чи я вже закінчив?»
Без скрипта, який можна відмітити галочкою, прогрес відстежувати важко. Тестувальник не розуміє, скільки лишилось. Менеджер не розуміє, коли можна релізити.
Зробили чекпоінт одиницею роботи з видимим статусом. Питання зникло.
Люди обирали ті самі тури.
Це виявилось найцікавішим. Тестувальники, цілком природно, тяжіли до знайомого. Один любив Guidebook, інший завжди брав Money Tour. Через кілька релізів у нас утворились передбачувані сліпі зони.
Спершу боролись ручною ротацією. Згодом саме це стало першим кандидатом на автоматизацію.
Скоупінг перетворився на другу роботу.
Розподілити ролі, локалі, платформи й тури між командою вручну перед кожним релізом займало години роботи сеньйора. Кожні чотири тижні. Завжди.
Оце і був той момент, коли ми звернулись до AI.
Коли до процесу долучився AI
Одразу застереження: інструмент, яким користується моя команда, це внутрішній AI-асистент EPAM CodeMie, не публічний продукт. Але суть не у вендорі. Будь-який кастомний GPT-агент чи власний пайплайн навколо будь-якої LLM виконає задачу, якщо збудувати навколо нього такий самий процес.
Проблема, яку ми вирішували, була суто логістична. Ротація турів, пристроїв, браузерів і локалей між командою з джуніорів і сеньйорів це кошмар, у якому легко помилитись.
Процес зараз виглядає так.
Крок 1. Аналіз змін. Асистент отримує номер релізу. Читає всі тікети та pull requests (запити на злиття коду), пов’язані з ним. Повертає стислий список ключових слів, які описують реальні зміни в поведінці застосунку.
Крок 2. Мапінг на чекпоінти. Другий асистент бере ці ключові слова і зіставляє їх з конкретними чекпоінтами й ролями. На виході — таблиця: ключове слово, роль, область застосунку.
Крок 3. Оркестрація скоупу. Тут все сходиться в одну команду. Даєш список активних тестувальників і кастомні побажання (наприклад, у цієї людини цього тижня немає iPhone).
Асистент підтягує історію турів кожного тестувальника, ділить чекпоінти, виділяє кожному одну локаль, одну платформу і новий тур, який ця людина ще не використовувала. І одразу оновлює базу історії, щоб наступного разу все було коректно.
Пріоритетні лейбли
Окремо варто сказати, як AI розуміє, куди спрямувати основне покриття. Ми задали п’ять лейблів:
Повертаючись до аналогії з Формулою 1, це, по суті, стратегія на піт-волл. Інженери рахують сценарії, дивляться на дані, готують варіанти. Але рішення на трасі все одно ухвалює пілот.
AI не тестує замість людини. Він прибирає з її столу всю логістику, щоб людина займалась тим, що вміє краще за будь-яку модель: дивитись на застосунок і думати «а що, якщо».
Історія турів зберігається централізовано, а кожен тестувальник відкриває свій персональний чекліст із тим самим пріоритетним лейблом прямо там, де працює щодня.
Цифри, які закрили питання
Я не люблю статті, де результат описаний фразою «значно покращилось» без жодної цифри поруч. Тому ось конкретика.
Півтора тижня перетворились на два дні. Коли я вперше побачив цю цифру у репорті, я не повірив.
Головне в цих таблицях навіть не окремі числа. Головне те, що швидкість не коштувала нам якості.
Ми очікували компроміс. Готувались до розмови «так, ловимо трохи менше, але встигаємо». Компромісу не сталося. Якість зросла разом зі швидкістю.
Оце був момент, коли мій власний скепсис щодо «а чи не втратимо ми контроль без скриптів» остаточно закінчився.
Що я зрозумів за цей шлях
Структура — це те, що перетворює свободу на результат. Без чартерів, турів і чекпоінтів дослідницьке тестування перетворюється на «йди подивись, може щось знайдеш». З ними воно стає вимірюваним і зрозумілим.
AI має відповідати за логістику, а не за судження. Автоматизація скоупінгу звільнила команду для справжнього дослідження. Мислення лишилось людським, і я не бачу причин це змінювати.
Покриття і якість можуть рости одночасно. Але тільки якщо процес побудований правильно з самого початку, а не накладений поверх старого хаосу.
Команда виграє не менше за продукт. Джуніори швидше опановують різні техніки через тури. Сеньйори більше не витрачають години на планування скоупу і займаються задачами, де від них більше користі. А кожен реліз тепер приносить інший набір турів, тому робота не повторюється з місяця в місяць. І це все, чесно кажучи, я вважаю окремою перемогою.
Спробуйте на одному шматочку продукту
Ми не додали дослідницьке тестування поруч зі скриптованою регресією як ще одну галочку в процесі. Ми нею стару регресію замінили. Усі 1000+ UI-скриптів ми вивели з експлуатації, а API-тести й юніт-тести лишились на місці й роблять свою роботу.
Якщо ваш набір регресійних скриптів відчувається радше як борг, ніж як гарантія, візьміть один модуль. Один реліз. Спробуйте провести регресію турами замість скриптів і порівняйте, що знайдете.
Мені щиро цікаво почути в коментарях, чи є у когось схожий досвід. І особливо цікаво почути про підводні камені, яких ми поки не зустріли. Бо вони точно є, просто ми ще не доїхали до того повороту.
Слава Україні!
33 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарівПо кількості та величині коментів стаття імхо залетіла. Але технічно імхо це провал так було робити, локалізацію тестити руками на різних темах, браузерах та ос.
Автоматизація як раз би це питання вирішила що статична що динамічна браузерами справжніми
Ось огляд мій на вашу статтю та фідбек як потрібно було це автоматизувати youtube.com/watch?v=...YlNzI?si=ZkSEL1vG7QPu7Rmr
Вітаю, Романе. Дякую, що знайшли час на детальний розбір, відео подивився повністю.
Почну з головного, бо звідси ростуть майже всі зауваження. Стаття про підхід до дослідницького тестування. Вона не про стратегію тестування продукту загалом, не про архітектуру автоматизації і не про повний опис процесів, обмежень і контексту застосунку. Факти в ній стосуються одного напрямку: мануального дослідницького тестування, плюс трохи деталей про автоматизацію для повноти картини.
Я побачив багато коментарів саме про автоматизацію і про те, що частина речей не були зрозумілі одразу. Беру це до уваги. Якщо є ідеї, які процеси або підходи варто розкрити наступного разу, пишіть, я розгляну і врахую в наступному матеріалі.
Локалізація. Розумію вашу логіку як AQA, і щодо перевірки наявності ключів ви праві: статичний аналізатор або параметризований прогін закриють це швидше за людину. Але тестування локалізації не зводиться до того, чи існує переклад. Поза цією перевіркою лишаються переповнення і обрізання текстів, коректність перекладу в контексті (у нас є окрема команда, яка дає переклади згідно з контекстом), формати дат, часу й чисел. Для продукту з календарем і бронюванням сесій це критична частина. Ключ може бути на місці, а продукт при цьому зламаний.
Теми. Згоден, на логіку вони не впливають. Але впливають на видимість: контраст, нечитабельний текст, елементи, які губляться на темному фоні. Перевіркою ключів це не ловиться.
Браузери та WebKit. Ваше твердження правдиве частково. Якщо заглибитись у деталі нашого застосунку, близько 70% це Xamarin, фреймворк, м’яко кажучи, не найактуальніший на сьогодні. Решта справді WebKit. Запитуйте про деталі застосунку, якщо цікаво, розкажу. Одне питання тут дало б більше, ніж ваш готовий висновок.
Десктоп. Він є, і про браузери в статті йшлося саме в цьому контексті. Схоже, тут виникло непорозуміння.
Цифри. Тут вийшла плутанина. 1000+ це мануальні UI тест-кейси. 198 це не кількість тестів, а розмір комбінаторного простору на одну фічу. 134 це чекпоінти на реліз. Три різні сутності. І теза статті була саме в тому, що 198 комбінацій на фічу покрити неможливо в принципі, ні руками, ні автотестами. Здається, у цьому ми з вами якраз згодні.
Заголовок. Я вживаю термін у значенні з глосарію ISTQB. Test script не означає за замовчуванням автоматизацію. Використовую саме цю термінологію, щоб ми всі говорили однією мовою.
Оркестрація і AI. У статті я не розкривав, як AI використовується в інших процесах, це окрема тема. Але звичайний автотест цю задачу не закриває. Кожен реліз це інші зміни, і потрібне розуміння ризикованих областей, варіативність і генерація потенційно нових сценаріїв. Тут немає сталого плану, який повторюється з релізу в реліз, а автотест саме на сталий план і розрахований (параметризація тут не рятує: вона розширює рамки, але не прибирає їх).
Про тире. Аргумент дивний. Довге тире вам поставить Word, Grammarly і будь-який редактор з автозаміною, це звичайний типографський знак, а не підпис. Бачу, що ви й самі пишете статті, тож із вимогами DOU добре знайомі. Усі вимоги дотримані, стаття додатково проходила перевірку.
Стаття покриває один напрямок, тож багато чого в неї просто не увійшло. Буду вдячний за питання саме по її змісту, а висновки про непокриті частини без контексту виходять передчасними. Запитуйте, я відкритий.
Якщо я пропустив якусь тему з вашого відео, дайте знати, відповім окремо.
Что-то прям очень много. У меня сейчас 1200+ тест кейсов, из них 150+ — UI. Это всё бегает меньше10-ти мин на 10-ти потоках. Если проапгрейдить CI машину на более мощную (ща там t3.large на AWS) — смогу скинуть до примерно 5..6 мин.
Анализ результатов тоже почти ничего не занимает: flakiness примерно 1..2 теста максимум (и те стабильно чинятся, возникает из-за того, что с каждым коммитом в продукт я меняю или добавляю тесты). Баги через @Issue аттачатся в аллюр, поэтому, если тест красный из-за known issue — я об этом знаю сразу. Туда же: всё анализируется автоматически клодом при nightly run — он же пытается сразу починить те тест кейсы, которые упали и баг к ним ещё не приаттачен. Починил — отлично, нет и видит объективное расхождение со спецификацией (у него есть туда доступ) — завёл сразу баг. Таким образом, я не жду regression run, чтоб завести тонну багов — я (точнее, клод :) ) их завожу, как только они находятся, на следующий день после коммита максимум. Если я успел обработать коммит до этого — баг будет заведен раньше.
Pairwise testing в помощь )
Берём по очереди комбинацию темы + браузера + ... — и прогоняем тесты на CI в рандомной комбинации атрибутов: сегодня тема 1, браузер 3, завтра тема 3 браузер 2 и т.д. Следим, чтоб каждый элемент списка списка выпадал регулярно (чтоб не получилось так, что браузер 2, к примеру, за 2 недели не выпал ни разу: в этом случае форсим именно его). И рано или поздно все комбинации будут перекрыты.
Если для репродьюса необходимо какое-то специальное значение атрибута — в CI это можно сконфижить, иначе — random.
Крайне плохой сигнал. Проверить coverage, добиться 2 вещей:
1. QA лид должен всегда знать coverage, в любой момент времени. Если что-то не покрыто автоматизацией — перед релизом это необходимо протестить вручную.
2. В идеале — coverage должен быть проверен как изменение кода (PR в дев репу) против изменения требований. Все возможные пути должны быть покрыты тестами. Не забываем о тестовой пирамиде: всё, что можно протестить на низком уровне (API, контракты и т.д.) — должно быть скинуто туда.
3. Optional. Раз в пару недель просить клод пересчитать coverage против текущего состояния требований и найти то, что было пропущено. И, естессно, покрыть тестами. Помогает находить мелкие недочёты до того, как их станет слишком много.
По сути, заменили автоматизированное UI тестирование мануальным :)
Я б сказал, проблемы надо было искать в подходе к UI тестам (из того, что вижу в статье навскидку: оч медленные, возможно flaky, плохой coverage, скорее всего, плохая актуальность, как вариант — несоблюдение пирамиды тестов).
Вітаю і дякую за коментар у гілці, відповім по пунктах.
Спершу головне, бо на цьому будується ваш висновок. Ми не міняли автоматизацію на мануальне тестування. Автоматизація лишилась на місці. Ми замінили ручне скриптоване тестування новим підходом. Це різні речі.
Автоматизовані UI-тести у нас покривають базовий функціонал, і саме тому ми в ньому впевнені. Питання в іншому: навіщо тягнути UI-автоматизацію далі, якщо покрити все нею однаково неможливо. Кількість конфігурацій і можливих дій користувача зростає швидше, ніж ви встигаєте писати тести. І тут вмикається ROI: кожен наступний UI-тест на рідкісну комбінацію коштує стільки ж у написанні й підтримці, скільки тест на базовий флоу, а приносить у рази менше. У якийсь момент ви просто платите за підтримку набору, який усе одно не закриває матрицю. Тому тут ми пам’ятаємо про піраміду тестування та покриття.
Про pairwise: підхід справді цікавий, і ми його пробували. Але повністю проблему він не закриває. Ті самі сценарії й конфігурації можна пройти дуже різними шляхами, і pairwise покриває комбінації атрибутів, а не траєкторії всередині них. Аналогія, яка мені тут ближча. Уявіть 100 різних трас, і кожну з них можна проїхати унікальною траєкторією. Pairwise гарантує, що ви побуваєте на кожній трасі. Він не гарантує, що ви пройдете її новою траєкторією. У нас саме тому кожна регресія це щось нове.
Тепер про «крайне плохой сигнал». Тут я не зовсім зрозумів. У тому й річ, що ми знаємо свій кавередж. Автоматизація закриває базу, ми це бачимо, а те, що не автоматизовано, свідомо тестуємо дослідницьким підходом. Це не прогалина, це розподіл ролей між рівнями.
А ваш пункт про ідеал, тобто перевірку покриття як зміни коду проти зміни вимог, це фактично опис нашого рішення. Перший крок у нас саме такий: AI аналізує зміни в тікетах і pull requests, мапить їх на конкретні області застосунку і на цій основі підказує, які чекпоінти й тури брати в цей реліз.
Аа, у вас UI тестирование ручное было?
Понял. Ну, это жесть :) Об этом ниже.
1000 мануальных тестов — ну, это писец как неэффективно. Почему не автоматизировали, с учётом наличия API и базовых UI автотестов? Это же надо держать целую армию мануальщиков.
Раньше было трудно. Хотя и не «невозможно». Сейчас это несложно с наличием клод кода. Дело в контроле регрессии. Сначала клод пишет мануальные тесты, затем автоматизирует их. Такой подход позволяет ничего не провтыкивать. Туда же встраиваются техники тест дизайна и критерии полноты тестов (к примеру, «каждый контрол на странице должен быть задействован хотя бы в 1 UI тесте»). А с работой в мультиагентном режиме вопрос всего лишь в лимите токенов, а не в кол-ве необходимых тестов. В результате. на выходе вы получаете набор регрессионных автотестов, которые гарантируют, что ничего не сломано, вместо error guessing. К примеру, я за день могу добавить до 100 автотестов за рабочий день (UI + API). Сравним с метриками до AI, где нормой считалось 4 :)
Сейчас стоимость автоматизации значительно уменьшилась. Вопросы сейчас в другом: как организовать её правильно, чтоб скажем через 300 тестов не пришлось выкинуть это всё на помойку? Что решается правильной стратегией написания тестов (self-seeding, рандомизация данных, отсутствие зависимых тестов, мультипоточность, нормальные локаторы, верификация через метрики — как минимум).
Сейчас стоимость написания — копейки. Стоимость поддержки, если правильно написан — тоже.
Оч странно, с учётом того, что у вас тесты мануальные. Любой нормальный мануальщик, который знает продукт, вполне способен осознать, что если некий функционал можно пройти 2 раза по-разному, то это стоит сделать. А ещё лучше — сделать новый мануальный тест, чтоб об этом не забыть. Его ж 3 минуты делать. У вас мануальщики ленятся писать тесты? :) Я за такое руки на ревью отрываю, если регулярно вижу недоделки со стороны 1 и того же человека. Если же тесты написаны чек-листами типа «проверить, что оплата работает» — то тут нормальный чувак должен включить голову и проверить все возможные варианты: оплата картой, переводом на счёт и т.д. Если он это не сделал и баг прошёл на прод — то ему надо на lessons learned оторвать голову, чтоб в следующий раз учился ей думать, а не просто тыкать кнопки :)
Как по мне, coverage должен стремиться к 100%. В идеале, автоматизацией. Но если есть объективные причины, делающие это невозможным — то хотя бы мануальными тестами. И я как лид должен его знать в любой момент времени. Особенно перед релизом. И осознавать риски, если вижу дыры в покрытии. Т.е., моя стратегия была бы такой в текущем раскладе:
1. Проходим high-priority тесты.
2. Проходим тесты, отобранные через impact analysis для данного релиза (т.е., для функционала, который был добавлен / изменён в этом релизе + то, что с ним интегрировано).
3. Закрываем дыры в покрытии вот тем самым exploratory testing. Именно тут ему самое место.
4. Оставляем тасочку на закрыть дыры в следующем цикле. И не забываем её делать :)
5. Проходим тесты, которые нашли баги в текущем релизе. По сути, перепроверяем все баги цикла.
6. Если вдруг осталось время — проходим что-нить, что давно никто не смотрел. Если это делать регулярно — мы избегаем «ХЗ функционала», который никем никогда не верифицируется.
Это хорошо работает в короткой перспективе, но в длинной скорее всего приведёт к проблеме. Такой подход крайне уязвим к:
— размыванию знаний: чувак, который хорошо знал какой-то кусок продукта, уволился, остальные его попросту не знают норм. Ротация поможет, но не слишком. Всё равно найдётся вариант, при котором условное «2» в дропдауне будет означать какую-то свою логику, которая описана в сносочке в требованиях или вообще в таске, которая уже спринтов 10 как закрыта. Об этом знает чувак, который это тестировал — и никто больше;
— сложности продукта: чем больше разных путей, которые нигде более не описаны — тесты выброшены на помойку — тем выше риск того, что чувак просто не покроет какой-то возможный путь, просто потому, что он вообще не подумал / забыл, что там ещё что-то есть.
Exploratory подход неплох в discovery фазе продукта или если продукт крайне примитивен и не содержит сложной логики. В ином случае это приведёт к проблемам, ибо данный подход по сути неуправляем: нет ни одной метрики, которая показала бы, прошёл чувак все необходимые пути или забы(и)л половину.
Ага. До Impact analysis вы дошли. Уже хорошо :) Но моё решение не только в этом. См. выше — это только 1 из пунктов.
Дякую за розгорнуту думку.
Ваша стратегія, до речі, дуже близька до нашої: пріоритети, impact analysis і дослідницьке тестування на решту. Різниця радше в тому, яку вагу несе кожна частина.
Уточню лише два моменти. Підхід не некерований: у кожної сесії є тайм-бокс, завдання, нотатки й дебриф, а чекпоінти мають видимий статус, тож у будь-який момент видно, що в релізі закрито, а що ні. І справа не в тому, що хтось лінується: коли регресія з релізу в реліз іде майже тим самим набором, увага звикає до маршруту. Це властивість формату, а не людей.
Ризики, які ви описали, реальні, і жоден підхід не дає стовідсоткової гарантії. Для нашого продукту цей баланс спрацював краще.
Дякую!
Для цього є АІ який по ваших тест кейсах напише авто тести.
Сам таке робив хоч я і не тестер.
Я так розумію, що про принципи тестування і парадокс пестициду просто забули?
Вітаю. Не забули, це і є діагноз зі статті. Скрипти, які щоразу йдуть тим самим маршрутом, з часом перестають знаходити нове.
Наша відповідь на цей парадокс не в оновленні набору, а в тому, що варіативність тепер живе в сесії.
тішуся що стара добра нудна робота може бути і цікавою і корисною, якщо проявити творчий підхід
мені думається дослідницьке тестування як воно описане — мало б вимагати гарного знання предметної області і явно досвіду і певної інтуїції на основі нього, тобто це не джуніорська робота і відповідно це не може бути дешево. Це шось типу різниці між грою в шахи не знаючи нічого крім правил і бути каспаровим який хаотично ходить. І те і те виглядає як малозрозуміла гра в шахи, але єсть нюанс
Тому дивно було читати про джуніорів і я був не здивований проблемам і
в принципі цікаво було читати як це долали
класна стаття, дякую
Ну і, користуючись нагодою, не можу не спитати, як ви ставитесь до водіння шкільних автобусів?
Вітаю. Дякую за фідбек і аналогію.
Щодо джуніорів дозволю собі не погодитись. У самому визначенні дослідницького тестування навчання про продукт, дизайн тесту й виконання відбуваються одночасно. Тобто знання продукту не передумова, а результат: людина набуває його саме через такі сесії, і швидше, ніж проходячи чужий сценарій по кроках.
Аналогію я б трохи поправив: сесія це не гра навмання. Тайм-бокс, завдання сесії, нотатки, дебриф після. Хід думки лишається видимим, і на дебрифі видно, де новачок помилився, а де знайшов те, повз що досвідчені могли ходити місяцями. Свіже око тут перевага, бо той, хто знає продукт роками, багато чого вже не помічає.
А щодо шкільних автобусів — кажуть, там стабільний графік, але насправді цей мем — крутий спосіб порефлексувати.
Пожалійте дідуся будь-ласочка, напишіть1-2 реченнями що ви конкретно зробили? А то ж хочеця трохи відстрілювати молодіжні бест-практізи, а читати оце все не варіант. Дякую.
Вітаю. Дякую, що знайшли час залишити коментар.
Якщо однією думкою: ми перестали щоразу перевіряти одне й те саме, бо замість фіксованого списку кейсів кожен тестувальник отримує свій шлях та мету тестування, і AI стежить, щоб це не повторювалось та оптимізує. Регресія скоротилась з півтора тижня до двох днів, а знаходити стали більше.
я аж зарегався
QA неякісно роблять роботу, тому придумаєм для них тестові тури, чого нє
і це все обгорнем у АІ, бо як ми раньше жили без нього, і інакших способів розподіляти роботу аллах не дав нам, ну і в cv жеш треба шось написать
і статистика норм. база в 3 реліза низька, приписав на графіку кореляцію з аі-ротацією, северіті знайденого непонятна і ващє це могли бути фіча-хеві релізи чи новий дев зайшов у тіму і наплужив і так співпало
а так то да, рух від бездушних скриптів у сторону чуйки manual QA правильний
Вітаю. Дякую за конструктивний коментар, у ньому є що обговорити по суті.
Почну з турів. Ми їх не вигадували. Це метафора з книги Джеймса Віттакера, вона давно описана і має свою практику застосування. І проблема, яку ми вирішували, була не в тому, що люди неякісно роблять роботу. Вона в самому форматі: коли регресія з релізу в реліз іде тим самим шляхом, увага звикає до цього шляху. Це властивість повторюваного сценарію, а не характеристика команди.
Щодо AI. Ми запускали цей підхід вручну кілька місяців до того, як він взагалі з’явився в процесі, і він працював. Але розподіл вручну забирав години підготовки перед кожним релізом, і саме цю задачу ми віддали AI. Він не тестує і не оцінює якість. Він розподіляє скоуп між людьми, стежить, щоб тури не повторювались, і закриває ще кілька логістичних завдань.
Тепер про статистику, це найцінніша частина вашого коментаря. Цифри відображають стабільну картину, а не зріз декількох вдалих релізів. Якби показники стрибали від релізу до релізу, я б написав саме про це, бо тоді це була б стаття зовсім про інше. При цьому ви маєте рацію: наповнення релізу, зміни в складі команди, поведінка конкретного розробника, усе це впливає, і повністю відокремити ці фактори на реальному проєкті неможливо.
І щодо обсягу. Стаття свідомо про підхід і загальну картину, а не про повний розбір метрик з поправками на всі змінні. Такий розбір це окремий матеріал, і, чесно кажучи, цікавий.
За останній абзац дякую окремо. Саме про цей рух стаття і є.
так в том і суть, шо не відображають у тебе цифри поки нічого
і якби стрибали цифри, це теж би нічо не означало
рано ще судить, тим більш графіки успєха показувать
а характеристика команди — ну камон, поки ти qa не почав тикать у конкретну роботу, вони самі брали шо хотіли і їх не смущало
як ем ти харашо придумав задешево піднять мораль тімі, бо замість тупих скриптів ви граєтесь у нову гру, оце пока найцінніше
всьо решта — може да може нє, ми не знаєм
Можливо Вам стала б у нагоді тулза, яку я розробив — github.com/...akymenko-create/FlowScout
Вона ходить по сайту та шукає унікальні маршрути. Глибину скану Ви задаєте самі. А потім порівнює їх з тест-кейсами та каже, де у Вас Gap покриття.
Тобто вона симулює саме реальний користувацький досвід та порівнює його з Вашою документацією.
Вітаю, Ігоре. Дякую, що поділились, виглядає цікаво. Обов’язково подивлюсь на ваше рішення і повернусь до вас, якщо виникнуть питання. Дякую!
трохи бракує контексту, а без контексту виглядає так що писали погані тести і врешті вирішили вернутись до manual qa. Хоча ймовірно все було не так :) Давайте більше деталей.
Вітаю, Андрію. Дякую за питання.
Уточню ключове: стаття саме про ручне тестування. Автоматизація на проєкті лишилась і живе своїм життям. Юніт, інтеграційні та API-тести працюють як працювали і роблять свою роботу, підтверджуючи, що ми не зламали те, що давно стабільне.
Проблема, яку ми вирішували, лежала в іншій площині. Коли ручна регресія з релізу в реліз іде за тим самим патерном, команда поступово перестає перевіряти додаткові сценарії. Це не питання дисципліни чи мотивації, це властивість самого формату: увага звикає до маршруту. Дослідницьке тестування розв’язує саме цю проблему, бо кожна сесія має інший фокус.
Побічний ефект теж суттєвий: команда MQA більше не витрачає ресурс на підтримку сотень кейсів, оскільки перевірку основного функціоналу закриває автоматизація.
Підкажіть, будь ласка, якої саме конкретики бракує, і я розкрию детальніше. Можу тут або окремо в повідомленнях.
А чому не має е2е? Все одно ж ви проклацуєье певні сценарії, хоч і називаєте це exploratory
Вітаю. E2E є і працює, але покриває базові сценарії.
Специфіка застосунку в тому, що кожна фіча живе в багатьох конфігураціях, і той самий функціонал тестується дуже різними шляхами. Основне автоматизовано, але 100% покриття не буває ні в автотестах, ні в ручному тестуванні. Ми дійшли до етапу, коли з проду приходили конфігурації, яких ми просто не могли собі уявити наперед.
Щодо «все одно проклацуєте»: клікає людина в обох випадках, різниця в тому, хто вирішує, куди клікнути далі. У скрипті це рішення ухвалене раз і назавжди місяці тому. У сесії воно ухвалюється динамічно. Саме звідси і береться те, чого в сценаріях не було.
Дякую. Тепер більше зрозуміло
Нарешті попалась цікава стаття з якимось новим підходом
А чи не пробували делегувати Аішці вигадування сценаріїв?
Дякую, радий, що зайшло.
Якраз про це і думали. Але щоб таке працювало, AI має дуже добре знати специфіку застосунку і постійно навчатись, інакше генеруватиме псевдоневалідні сценарії: формально правдоподібні, а по суті беззмістовні для нашого продукту.
Це наступний етап, яким ми зараз і займаємось, але він потребує часу. На цей момент ми переконались, що наявних турів достатньо, вони закривають потребу у варіативності. А як напрямок для зростання ми бачимо саме те, щоб у майбутньому повністю делегувати цю частину AI.
схоже не я один неправильно зрозумів термін «скрипт» Ви очевидно мали тест кейси для мануального тестування. А більшість тут подумали про скрипти автоматизованого тестування. Лишається не зрозуміло чому ці тест кейси не оновлювались зі зміною функціоналу. В голому залишку ви просто застосували новий процес для мануального тестування.
«Скрипт» я вживав у значенні з глосарію ISTQB: test script — це послідовність інструкцій для виконання тесту, незалежно від того, виконує їх людина чи машина. Як я писав у статті, автоматизація лишається на місці й робить свою роботу.
Щодо оновлення. Кейси оновлюються, але скоуп при цьому постійно розростається, і підтримка з’їдає дедалі більше часу. Саме тому зараз, коли ми пишемо тест-кейси, ми робимо це переважно як основу для автоматизації, а не для ручного прогону.
І щодо вашого висновку: так, ви праві, по суті це новий процес для ручного тестування. Саме про це стаття.
Дякую за фідбек. Для наступних статей спробую давати ще більше деталей.
Смисл авто тестів в тому що вони виконуються самі, коли треба і не тільки перед релізом. Зробили сторі — заранили тести.
Смоук тестінг (оті «чекпоінти») робляться додатково.
І тепер людина має вручну проклікувати юайку.
Без тестера регресію тепер не проведеш.
Як девелоперу перевірити що його фіча щось не ламає?
Раніше він б просто залив зміни на дев енв (якщо ваші тести не вміють ранитись локально), і за годину вже б знав чи все ок.
Дякую за коментар.
Дійсно, вони і запускались коли треба, і не тільки перед релізом. Біль був не в розкладі, а в тому, що покриття було сталим: тисяча кейсів щоразу перевіряла те саме.
А те, що пропускається в прод, у скриптах не описане взагалі. Розклад запусків тут не рятує.
І уточню: чекпоінт це не смоук, а одиниця сегментації застосунку. Глибину задає тур.
Ну так це і є регресійним тестуванням, ні?
А тепер його у вас немає.
Так добавте.
За такою ж дивною логікою можна всі тести викинути бо вони не зловили прод баг.
Але скільки багів вони не допустили?
Кароч, це дуже дивна ідея перестати підтримувати тест кейси бо це важко. Я б такого QA ліда звільнив.
Норм написаний тест кейс це вже 90% авто тесту (написаного АІ).
Замість того щоб автоматизувати ручне регресійне тестування ви просто відмовились її робити.
Регресія у нас нікуди не зникла, вона проводиться турами. Ми вивели з експлуатації скрипти, які з регресії в регресію мали сталий набір перевірок. Навіть параметризований набір лишається рамками, просто ширшими, а нам потрібно було саме вийти за рамки.
Кейси ми оновлювали, але кейс на пропущений сценарій з’являється тільки після бага в проді, а скоуп росте швидше, ніж встигаєш його підтримувати. Передбачити все заздалегідь не виходить: для цього треба бути на кілька кроків попереду кожної людини, яка користуватиметься застосунком.
З тим, що добрий тест-кейс це основа автотесту, згоден. Пріоритетні перевірки ми автоматизуємо, і, як я вже не раз писав і в статті, і в коментарях, автоматизація нікуди не поділась.
Тож регресію ми не прибрали, а розділили: стабільне на автоматизації, варіативне на дослідницьких сесіях.
Будь ласка, не робіть висновків на припущеннях. Якщо щось незрозуміло, ставте питання, я із задоволенням відповім.
Дякую!
Розробник не лишився без зворотного зв’язку. Юніт, інтеграційні та API-тести працюють і дають відповідь на «чи щось поламалось» швидше, ніж будь-який ручний UI-прогін це коли-небудь робив.
Так зробіть нормальні енд ту енд.
Клікається по апці, перевіряється бізнес результат а не мокані дані
Дякую за думку. E2E у нас є і працюють саме так, по застосунку і з перевіркою бізнес-результату. Але навіть добрий E2E перевіряє лише ті сценарії, які хтось заздалегідь придумав, а в проді трапляються якраз ті, які ми не завжди могли передбачити. Саме цю варіативність і нетривіальні, не завжди очікувані шляхи проходження і закриває дослідницьке тестування.