Регресійне тестування

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

Ніхто не відкриває сторінку про регресійне тестування заради визначення. Її відкривають, бо баг повернувся, або бо набір тепер триває сорок хвилин і люди мерджать, не чекаючи. Нижче — шістнадцять кейсів із набору інтернет-магазину, чиї smoke-ворота наводить сторінка «Smoke-тестування». Рядки 1–4 походять від багів, що дійшли до клієнтів, 5–8 — від розборів інцидентів, 9–12 — від обіцянок, які дав магазин, а 13–16 — від шляхів, якими йдуть гроші. Кожен рядок називає найнижчий рівень, що може його довести, і ярус, де він запускається. Наступні розділи посилаються на рядки за номерами.

Регресія — це порушена обіцянка там, де нічого не збиралися чіпати

Глосарій ISTQBISTQBInternational Software Testing Qualifications Board — орган сертифікації тестувальниківМіжнародна організація, що стоїть за найпоширенішими сертифікаціями з тестування ПЗ і видає глосарій термінів тестування. Її визначення — поширене спільне джерело на співбесідах і в контрактах; вони фіксують словник, а не те, як має працювати команда.Усі терміни визначає регресійне тестування як тестування, повʼязане зі змінами, мета якого — виявити, чи не внесено або не відкрито дефекти в незмінених частинах програми. Зміст цього речення несуть два слова. «Незмінених» каже, куди дивитися: не на фічу, яку ви редагували, — її вже покривають власні тести, — а на все довкола. А «відкрито» визнає те, що команди забувають. Зміна може оголити дефект, який уже був і тихо сидів за поведінкою, що тепер зрушила.

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

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

Що заслуговує на постійний кейс — і єдине, що його прибирає

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

• Баг, що дійшов до клієнта, — рядки 1–4

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

• Розбір інциденту — рядки 5–8

  Розбір називає умову, яку ніхто не перевіряв. Перетворити це речення на кейс — та частина розбору, що переживає квартал.

• Обіцянка — рядки 9–12

  Опублікована форма API, правило повернень, вимога регулятора. Обіцянка існує незалежно від тесту, — тож нехай тест теж існує.

• Шлях, яким ідуть гроші, — рядки 13–16

  Оформлення, повернення коштів, подарункові картки. Про збої тут не повідомляють клієнти тікетами; їх знаходить бухгалтер через три тижні.

Де живе кейс, важить не менше, ніж те, чи він є. Порада Мартіна Фаулера щодо піраміди тестів: перш ніж виправляти баг, який виявив високорівневий тест, відтворіть його юніт-тестом — і тоді юніт-тест гарантує, що баг лишиться мертвим. Магазин робить саме так. Про рядок 1 повідомили клієнти, які подивилися на свої бали, але його кейс — юніт-тест, що працює мілісекунди й сам називає причину, коли падає. Рядок 3 є браузерним маршрутом лише тому, що cookiecookieдані, які браузер надсилає назадНевеликий фрагмент даних, який сайт просить браузер зберегти й надсилати назад із кожним запитом до цього сайту, — так сервер пам’ятає, що ви увійшли. Оскільки браузер додає його автоматично, навіть до запиту, який спровокував інший сайт, cookie сесії потребує правильних прапорців і перевірки проти підробки запитів на сервері.Усі терміни в Safari не можна довести ніде нижче за справжній Safari.

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

Що запускається коли — набір переростає очікування

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

Корисне значення за замовчуванням: спершу розпаралелити, далі — яруси, і скептично ставитися до хитрого відбору, доки кількість змін на день не зробить його неминучим. Купити машини дешевше, ніж інженер, що зʼясовує, чому регресія проскочила крізь розумну підмножину. Хоч що ви оберете, два правила не обговорюються. Ярус мерджу тестує кожну зміну, злиту з поточною головною гілкою, — саме це робить черга злиття, а сторінка про стратегії гілок у Git пояснює, чому два зелені пулреквести можуть разом зламати main. І повний набір запускається перед кожним релізом, бо цей запуск — останній момент, коли памʼять повна.

Нестабільні тести — виміряні, а не загадкові

Нестабільний тест на тому самому коді то проходить, то падає. Google опублікував свої цифри 2016 року: близько 1,5% усіх запусків тестів давали нестабільний результат, майже 16% тестів мали певну нестабільність, а приблизно 84% переходів від «пройшов» до «впав», які бачила система CICI/CDContinuous Integration / Continuous Delivery — автоматична збірка й доставкаКожен коміт автоматично складається і проганяється через тести (CI), а придатна збірка так само автоматично їде на сервери (CD). Сенс не в автоматизації як такій, а в тому, що поломку видно за хвилини, а не в день релізу.Докладніше в статті →Усі терміни, стосувалися нестабільного тесту. Прочитайте останнє число двічі. У пʼяти випадках із шести тест, що щойно почервонів, — це тест, який падає й без жодної зміни. На середньому проєкті приблизно з тисячі тестів 1,5% — це десь пʼятнадцять падінь на кожен реліз, які хтось має розслідувати.

Шкода не в змарнованому розслідуванні. Вона в тому, чого люди з нього вчаться. Мартін Фаулер сказав це прямо 2011 року: щойно ви почали ігнорувати падіння регресійного тесту, цей тест марний. Гірше, що звичка поширюється: команда, яка знизує плечима на нестабільні кейси, скоро знизує плечима й на здорові. Розмір усе погіршує. За рік після першої публікації Google виявив, що за тиждень нестабільними були 0,5% його малих тестів, 1,6% середніх і 14% великих, і що розмір передбачав нестабільність краще, ніж інструмент, яким тест написано.

Причини теж відомі. Ло з колегами дослідили 201 коміт, що виправляв нестабільні тести в 51 проєкті з відкритим кодом, і класифікували причину для 161. Три причини охопили понад три чверті з них, і для кожної є виправлення, що її прибирає, а не ховає.

Ще два висновки того самого дослідження змінюють те, як команді варто поводитися з нестабільним кейсом. 78% тестів були нестабільними від дня, коли їх написали, тож новий кейс, що пʼятдесят разів запускається, перш ніж отримати право щось блокувати, дає більшості нестабільних кейсів шанс проявитися до того, як хтось навчиться їх ігнорувати. А 24% виправлень змінювали код, що тестується, а не тест. У чверті випадків «нестабільний тест» був справжнім дефектом, який знайшов тест і який усі вирішили назвати нестабільністю.

Тестові дані, утримання й числа, за якими варто стежити

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

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

Чотири регресії — і кейс, якого бракувало

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

Де це вироджується

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

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

• Набір, що лише росте, без правила виходу: третина його тестує поведінку, якої в продукті вже немає.
• Регресія як фаза перед релізом, а не запуск на кожну зміну: дефекти знаходять у найдорожчий момент.
• Кожен кейс написано браузерним тестом, бо саме це належить команді QA, — там, де API-тест довів би те саме в сто разів швидше.
• Список карантину без власника й без ліміту — цвинтар із оптимістичнішою назвою.
• Автоматичні повтори всюди: пайплайн зелений, і ніхто не знає, як часто він спершу був червоним.
• Повний ярус, пропущений перед релізом «лише цього разу», — єдиний запуск, відсутності якого ніхто не помічає, доки не помітить клієнт.
• Міряти набір кількістю кейсів чи покриттям коду, а не регресіями, що дійшли до клієнтів.
• Виправлення закривають, щойно проходять кроки зі звіту, і жодного кейса не лишається: бага немає, але немає й памʼяті про нього.

Коли це застосовувати

Пов’язані сторінки

• QASmoke-тестуванняSmoke-тестування — це малий фіксований набір перевірок, що запускається одразу після розгортання білда й вирішує, чи вартий цей білд чийогось часу. Сторінка починається з готового набору одного магазину — одинадцять перевірок, що доводить кожна і що зупиняє червоний результат, — далі звідки взявся термін, що належить набору, чим він відрізняється від перевірок справності й моніторингу, де запускається, назви, які плутають, і чотири розгортання, де перевірки бракувало або її проігнорували.
• QAНаскрізне тестування (E2E)Наскрізне тестування проводить бізнес-процес через зібрану систему від початку до кінця, як це зробив би клієнт, в умовах, близьких до продакшну. Сторінка починається з повного набору одного магазину — дванадцять маршрутів, шов, який доводить лише кожен із них, і що в ньому справжнє, а що підмінене, — далі що не доведе жоден нижчий рівень, яких форм набуває набір тестів, чого коштує червоний маршрут, як обирати маршрути й тримати їх надійними, і три збої, де тест зупинився за крок до кінця.
• МенеджментGit-стратегія гілкуванняGit-стратегія гілкування — це домовленість про те, як команда розділяє роботу на гілки і як знову їх зводить. Вибір виглядає справою смаку, але нею не є: змінна, що передбачає біль, — скільки живе гілка до злиття, і кожна модель — це позиція щодо цього числа плюс правило, звідки беруться релізи й виправлення. Сторінка починається з шести моделей на одному екрані й п’яти питань, що обирають між ними; далі — час життя гілки, звідки взялася кожна модель і що її автори сказали згодом, релізні гілки й шлях виправлення, що робить короткі гілки можливими, merge проти rebase проти squash і де все це вироджується.