Наскрізне тестування (E2E)

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

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

Що доводить лише наскрізний тест

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

Кожен тест нижче працює в контрольованих умовах. Юніт-тест замінює сусідів підробками. Інтеграційний бере справжню базу й замінник платіжного провайдера. Контрактний тест доводить, що два сервіси згодні щодо повідомлення, і жоден із них не запускає інший. Усе це цінне, і ніщо з цього не покаже, що розгорнута система з її справжньою маршрутизацією, справжніми змінними середовища, справжніми сесіями та справжньою збіркою фронтенду дає людині завершити те, заради чого вона прийшла. Класичний дефект, що втікає з добре протестованої системи, — не хибний розрахунок. Це неправильно налаштований редирект, атрибут cookiecookieдані, які браузер надсилає назадНевеликий фрагмент даних, який сайт просить браузер зберегти й надсилати назад із кожним запитом до цього сайту, — так сервер пам’ятає, що ви увійшли. Оскільки браузер додає його автоматично, навіть до запиту, який спровокував інший сайт, cookie сесії потребує правильних прапорців і перевірки проти підробки запитів на сервері.Усі терміни, що ламає сесію в одному браузері, фіче-флаг, увімкнений на стейджингу й вимкнений у продакшні. Кожен живе на шві, і кожен нижчий тест підмінив саме цей шов.

Ця схема — механізм за кожним випадком наприкінці сторінки. Розділіть маршрут на відрізки, протестуйте кожен із замінником на стику — і кожен відрізок може бути зеленим, коли маршрут падає: дефект живе на стику, а стик — єдине, чого не запускав жоден тест відрізка. Мартін Фаулер додає застереження щодо слів: команди змішують поняття наскрізних тестів, UIUIUser Interface — те, що бачить користувачУсе, що користувач бачить і чим керує: екрани, кнопки, поля, стани. UI відповідає за те, ЯК виглядає взаємодія; чи має вона сенс узагалі — це вже питання UX, і ці два поняття плутають постійно.Усі терміни-тестів і тестів з погляду клієнта, хоча це незалежні одна від одної характеристики. Тест, що клацає крізь браузер проти підробленого бекенду, — це UI-тест. Він не наскрізний і не може довести шов, який сам підмінив.

Піраміда, кубок, стільник — три форми, один аргумент про ціну

Майк Кон описав піраміду тестів у книжці «Succeeding with Agile» 2009 року, а нотатка Мартіна Фаулера 2012 року зробила її відомою: багато юніт-тестів унизу, менше тестів сервісів посередині, мало наскрізних угорі — бо тести, що проходять наскрізь крізь інтерфейс, крихкі, дорогі в написанні й довго виконуються. Глосарій ISTQB тепер має для неї окремий запис. Відтоді намалювали й інші форми — кожну люди, що працювали над іншим видом систем, — і таблиця ставить їх поруч.

Форми не згодні щодо середини й згодні щодо верхівки. Стільник Spotify хоче «ще менше інтегрованих тестів (в ідеалі жодного)», де інтегрований тест — це тест, що проходить чи падає залежно від правильності іншої системи. Пост Google 2015 року погоджується приблизно на десяту частину. Доддс лишає кілька. Розбіжність справжня, і її варто тримати на виду: команда незалежних сервісів може тестувати більшість взаємодій через контракти й APIAPIApplication Programming Interface — контракт між програмамиПравила, за якими одна програма звертається до іншої: які запити можна надіслати, у якому вигляді й що прийде у відповідь. Для того, хто звертається, це контракт — усе, що за ним, лишається чорною скринькою, і саме тому другий бік можна переписати, не зламавши вас.Докладніше в статті →Усі терміни кожного сервісу, а магазин, що за одну хвилину клієнта проводить гроші крізь пʼять систем, — не може. Чого не каже жодна з форм, — що верхній шар має бути великим. Фаулер подає причину, чому він малий, як припущення, а не закон: якби високорівневі тести були швидкими, надійними й дешевими в зміні, нижчі рівні були б не потрібні. Такими вони бувають рідко.

Чого коштує червоний маршрут — арифметика нестабільності

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

Розмір робить це ймовірнішим. Google виявив, що за тиждень нестабільними були 0,5% його малих тестів, 1,6% середніх і 14% великих. Маршрут — найбільший тест, який має команда. А малі ймовірності накопичуються: якщо кожен кейс падає без причини з імовірністю p, запуск n кейсів стає червоним, коли все гаразд, з імовірністю 1 − (1 − p)ⁿ. Таблиця це рахує.

Читайте таблицю як бюджет, а не як скаргу. Набір із шістдесяти маршрутів по 2% кожен червоний у семи запусках із десяти, коли все гаразд. Чотириста маршрутів за найкращої ймовірності з таблиці червоні майже дев’ять разів із десяти. Тому «просто додамо повтори» — хибний перший крок, а вдесятеро більше маршрутів — не вдесятеро більше захисту, а набір, який ігноруватимуть. Дванадцять маршрутів по 0,5% червоніють без причини приблизно раз на сімнадцять запусків — а таке команда може дозволити собі розслідувати щоразу.

Обирайте маршрути, а не фічі

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

• Шлях грошей — маршрути 1, 4–6

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

• Увійти й лишитися — маршрути 2, 3, 11

  Зареєструватися, увійти, лишитися в акаунті після перезавантаження, відновити пароль. Поведінка сесій і cookie невидима для кожного нижчого тесту.

• Через межу — маршрути 7–10

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

• Жорстке правило — маршрут 12

  Межа доступу, обовʼязкове розкриття, перевірка віку. Місця, де помилка — юридична подія, а не тікет у підтримку.

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

Як зробити дванадцять маршрутів такими, яким вірять

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

• Чекайте на умову, ніколи на тривалість. Фіксована пауза закоротка на завантаженій машині й марна на швидкій; очікування елемента, листа чи запису на складі і швидше, і стабільніше.
• Дайте кожному маршруту власні дані. Він створює потрібних йому клієнта, замовлення й подарункову картку — і прибирає їх після себе. Маршрут, що залежить від запису, створеного кимось іншим, падає у вівторок без причини.
• Знаходьте елементи так, як це робить людина, — за роллю й видимою назвою — або за test-idtest-idатрибут, за який чіпляється тестАтрибут, доданий у розмітку з єдиною метою — дати тестам спосіб знайти елемент. Він існує, щоб тест не чіплявся за CSS-клас чи видимий текст: і те, і те змінюється з причин, які не мають стосунку до поведінки.Докладніше в статті →Усі терміни, і ніколи за CSS-класом чи позицією: обидва змінюються щоразу, коли дизайнер торкається сторінки.
• Керуйте годинником. Маршрут, що залежить від сьогоднішньої дати, проходить у березні й падає в останній день місяця; задайте дату — а тоді навмисно пройдіть дати, що ламають речі, — 30-й день повернення, 29 лютого.
• Збирайте при падінні досить, щоб діагностувати без відтворення: трасу, відео, мережевий лог і консоль браузера. Ціна червоного маршруту — розслідування, і саме артефакти його скорочують.

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

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

Три збої, де тест зупинився за крок до кінця

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

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

Чесне обмеження в тому, що дванадцять маршрутів доводять, що дванадцять шляхів спрацювали один раз, в одному середовищі, з одним набором даних. Наближене до продакшну — не продакшн: справжній трафік, справжні треті сторони й справжній календар приходять лише після розгортання. Там естафету переймають smoke-ворота й синтетичний моніторинг, що за розкладом проганяють ті самі маршрути проти продакшну. А наскрізний набір не знайде дефекту на шляху, яким ніхто не пройшов; він лише стежить, щоб пройдені шляхи не ламалися непомітно.

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

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

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

• QASmoke-тестуванняSmoke-тестування — це малий фіксований набір перевірок, що запускається одразу після розгортання білда й вирішує, чи вартий цей білд чийогось часу. Сторінка починається з готового набору одного магазину — одинадцять перевірок, що доводить кожна і що зупиняє червоний результат, — далі звідки взявся термін, що належить набору, чим він відрізняється від перевірок справності й моніторингу, де запускається, назви, які плутають, і чотири розгортання, де перевірки бракувало або її проігнорували.
• QAРегресійне тестуванняРегресійне тестування — це повторний запуск тестів після зміни, щоб спіймати все, що працювало й перестало, у частинах системи, яких ніхто не збирався чіпати. Сторінка починається з шістнадцяти кейсів із набору одного магазину — чому кожен там, який рівень його доводить і коли він запускається, — далі що заслуговує на кейс і що його прибирає, яка підмножина запускається коли, нестабільні тести в цифрах, витрати, яких ніхто не планує, і чотири регресії, де кейса бракувало.
• QAPlaywrightPlaywright — відкрита бібліотека автоматизації браузера й раннер тестів від Microsoft, що керує Chromium, Firefox і WebKit ззовні браузера. Сторінка починається з дванадцяти маршрутів зі сторінки «Наскрізне тестування», написаних на Playwright, — механізму, на який спирається кожен, і конфігурації, що проганяє їх приблизно за чотири хвилини, — далі одне зʼєднання, з якого випливає все, браузери, які він насправді запускає, автоочікування, контексти й воркери, чого тест може дістати, крім сторінки, траси й повтори, чотири зміни під робочими наборами і де він не допомагає.