softify.pro Flow — testováno pomocí COCO

Control. Clarity. Flow.

Každý vážný softwarový produkt nakonec vyvine druhý produkt za produktem.

Zákazníci ho možná nikdy neuvidí. Návštěvníci možná nikdy nebudou vědět, že existuje. Ale administrátoři, operátoři, a vývojáři se na něj spoléhají každý den.

Pro softify.pro Flow je touto aplikací Administration — provozní konzole odpovědná za správu uživatelů, rolí, úrovní přístupu, stavů autentizace, prostředí databází, a další konfigurace, která udržuje nasazení Flow pod kontrolou.

Její přihlašovací obrazovka nese tři slova:
Control. Clarity. Flow.

Byla původně zvolena, aby popsala zážitek, který jsme chtěli, aby administrátoři měli při provozování systému.

Ale také překvapivě dobře popisují, jak podle nás má být software testován.

To udělalo softify.pro Flow — Administration zjevným kandidátem na skutečný test COCO.

Ne laboratorní demonstraci.
Ne sbírku izolovaných tlačítek připravených speciálně pro AI demo.
Skutečnou multiplatformní desktopovou aplikaci se skutečnou logikou aplikace, více okny, více backendy databází, autentizací, oprávněními, lokalizací, a dostatečným stavem, aby zdánlivě malé regrese byly těžko postřehnutelné ručně.

Pro veřejnou demonstraci ukázanou zde, COCO pracovalo výhradně s vygenerovanými demonstračními daty. Aplikace byla licencována pro fiktivní firmu Presentation GmbH, a žádné produkční informace zákazníků, přihlašovací údaje, ani osobní údaje nebyly použity.

Cíl byl jednoduchý:
Nechat COCO přistupovat k aplikaci tak, jak by to udělal tester, a určit, zda se kompletní administrativní pracovní postup stále chová tak, jak software tvrdí.

Výzva

Na první pohled se testování administrativní aplikace zdá jednoduché.

Otevři ji.
Přihlas se.
Klikni přes několik oken.
Zkontroluj, zda vše vypadá správně.

Tento předpoklad se rychle mění, jakmile aplikace roste.

softify.pro Flow — Administration není jeden statický formulář. Je to sbírka vzájemně propojených provozních pohledů uvnitř jednoho obalu aplikace.

Mimo jiné může administrátor pracovat s:

• uživatelskými účty
• rolemi a úrovněmi přístupu
• autentizačními informacemi
• stavem dvoufaktorové autentizace
• informacemi o operačním systému
• síťovými a IP informacemi
• konfigurací databáze
• možnostmi třídění a prezentace
• výběrem jazyka naživo
• informacemi o aplikaci a licencování

Rozhraní momentálně podporuje jedenáct jazyků. Aplikace také funguje s backendy databází MySQL a PostgreSQL. Jednotlivě žádná z těchto funkcí nepředstavuje neobvyklý testovací problém.

Obtíž pochází z jejich kombinací.
Tabulka uživatelů může fungovat správně v angličtině, ale zobrazovat zastaralý název sloupce v chorvatštině.
Třídění může fungovat správně připojené k MySQL, ale chovat se jinak po přepnutí na PostgreSQL.

Změna jazyka může aktualizovat většinu prvků rozhraní, přičemž ponechá jednu statusovou zprávu nepřeloženou. Aplikace může úspěšně přepnout databáze, ale zachovat zastaralé informace z předchozího připojení. Nové vydání může zavést funkci, zatímco dialog About stále popisuje předchozí. Program se nemusí zhroutit, aby kterákoli z těchto situací byla regresí. Ve skutečnosti některé z nejnepříjemnějších softwarových defektů jsou přesně ty, kde vše vypadá, že funguje.

Aplikace se spustí.
Okno se otevře.
Tlačítko reaguje.
Ale něco pod povrchem už není zcela v pořádku.
Proto je opakované regresní testování důležité.

A je to také přesně ten druh práce, ve které se lidé stávají čím dál horšími po opakování stejné sekvence desítky krát.

Proč se ruční testování stává nákladným

Otestovat něco jednou je jednoduché.
Testovat to spolehlivě po každém relevantním vydání je jiné.

Zvažte jen tři rozměry: 11 jazyků rozhraní × 2 backendy databází × více pracovních postupů aplikace.

Počet kombinací rychle roste.
Přidejte různé uživatelské role, stavy autentizace, chování třídění, změny konfigurace, a provozní prostředí, a testovací matice se stává příliš velkou, aby se s ní zacházelo jako s příležitostným ručním kontrolním seznamem.

Zde regresní testování často začíná erodovat.
Ne záměrně.
Termín vydání se blíží.
Někdo si vzpomene, že aplikace byla testována minulý týden.
Vývojář rychle zkontroluje nejdůležitější obrazovku.

Němčina funguje.
Angličtina funguje.
MySQL funguje.
Předpoklad se stává:
„Zbytek je pravděpodobně v pořádku."

Obvykle je. Až do vydání, kde není.
COCO existuje částečně proto, aby tento předpoklad odstranilo z procesu.

Co COCO skutečně udělalo

COCO spustilo softify.pro Flow — Administration ze studeného stavu aplikace, bez spoléhání na dříve připravenou obrazovku nebo ručně umístěný pracovní postup.

První interakce byla stejná, jaká se prezentuje lidskému administrátorovi: přihlašovací okno.

COCO identifikovalo autentizační rozhraní obsahující:

• uživatelské jméno
• heslo
• kód dvoufaktorové autentizace

a řádek přímo pod identitou softify.pro Flow:
Control. Clarity. Flow.

Odtud COCO pokračovalo přes definovanou regresní relaci. Cílem nebylo jednoduše určit, zda se aplikace dá otevřít.

Cílem bylo ověřit, zda stav aplikace zůstal interně konzistentní, zatímco s ní COCO interagovalo.

Autentizace je jen začátek

Testování přihlášení je jedním z nejzjevnějších kandidátů na automatizaci, ale samotná úspěšná autentizace nám říká velmi málo o zbytku administrativní aplikace.

Po vstupu se COCO přesunulo do skutečného provozního prostředí. Prozkoumalo rozhraní administrace uživatelů a ověřilo, že očekávané informace byly přítomny.

To zahrnovalo data jako:

• uživatelská jména
• maskovaná hesla
• ukazatele 2FA
• přiřazené role
• informace o operačním systému
• IP adresy

COCO pak interagovalo s tabulkou, místo aby ji jen pozorovalo.
Seznam uživatelů byl seřazen podle uživatelského jména.
Výsledné pořadí bylo prozkoumáno.
Důležitou částí nebylo, zda kliknutí na hlavičku sloupce vyvolalo nějakou viditelnou změnu.

COCO ověřilo, že výsledný stav tabulky odpovídal požadované operaci.

Tento rozdíl je důležitý.
Funkční test se ptá:
„Reagovalo tlačítko?"

Užitečný regresní test se ptá:
„Skončila aplikace ve správném stavu?"

Testování hranice databáze

softify.pro Flow podporuje více než jeden backend databáze.

To dělá přepínání databází obzvlášť důležitou regresní hranicí.
COCO změnilo aktivní backend z MySQL na PostgreSQL.

Po přepnutí znovu prozkoumalo informace o uživatelích.
Test hledal víc než úspěšné připojení.
Zkontroloval, zda aplikace nadále prezentovala očekávané záznamy a zda informace zobrazené přes rozhraní zůstaly konzistentní.

COCO se pak znovu přepnulo zpět.


Tento druh přechodu je snadné podcenit.
Uživatelské rozhraní může zůstat vizuálně identické, zatímco vrstva úložiště pod ním se úplně mění.
Z pohledu administrátora by měl tento přechod působit téměř nudně.
Stejní uživatelé by měli být stále srozumitelní.
Stejné role by měly stále dávat smysl.

Stejné chování rozhraní by mělo stále platit.

Tato zdánlivě neudálostná kontinuita je přesně to, co je třeba dokázat.

Jedenáct jazyků, jeden stav aplikace

Lokalizace je další oblast, kde je povrchní testování obzvlášť nebezpečné.

Je relativně snadné ověřit, že se aplikace dokáže spustit v jiném jazyce.
Je mnohem hodnotnější ověřit, co se stane, když se jazyk změní, zatímco aplikace už běží a udržuje stav.

COCO přepínalo jazyk rozhraní naživo.

Relace zahrnovala přechody mezi jazyky jako:
němčina → angličtina → chorvatština
zatímco pohled administrace zůstal aktivní.

COCO pozorovalo, zda se prvky rozhraní měnily správně na místě:

• hlavičky tabulek
• ovládací prvky
• tlačítka
• štítky
• statusové zprávy

Podkladová tabulka a stav aplikace také musely přežít tento přechod.
Toto záleží, protože vícejazyčný software se skládá z více než přeložených řetězců.
Změny jazyka mohou odhalit:

• zapomenuté zdroje
• zastaralé štítky
• problémy s rozvržením
• nepřeložené statusové zprávy
• problémy s kódováním
• resety stavu
• problémy s překreslováním ovládacích prvků

Okno, které vypadá správně, když je spuštěno přímo v chorvatštině, se může stále chovat nesprávně, když uživatel přepne z němčiny na chorvatštinu během aktivní relace.

To je rozdíl mezi kontrolou snímku obrazovky a testováním pracovního postupu.

Obnovení stavu aplikace

COCO následně obnovilo výchozí konfiguraci třídění aplikace.

Opět, test neskončil samotným kliknutím.

Výsledné pořadí a potvrzení prezentované přes oblast statusu aplikace byly vyhodnoceny. Tento typ ověření se může zdát bezvýznamný ve srovnání s testováním autentizace nebo přístupu k databázi.

Není.

Podnikové aplikace akumulují stovky takových malých přechodů stavu.
Uživatelé se na ně spoléhají, aniž by o nich vědomě přemýšleli.
Software působí spolehlivě právě proto, že tyto interakce zůstávají předvídatelné.
Regresní testování existuje, aby chránilo tuto předvídatelnost.

Testování informací kolem softwaru

COCO také otevřelo dialog About aplikace.

Proč testovat okno About?

Protože softwarová dokumentace začíná uvnitř samotného softwaru.
Číslo verze, popis funkcí, a licenční informace prezentované operátorovi by měly odpovídat aplikaci, která skutečně běží.

Aplikace může fungovat dokonale, přičemž stále prezentuje zastaralé informace o verzi nebo popisuje schopnosti, které už neodpovídají vydání.

Toto nezhroutí databázi.
Dělá něco jemnějšího:
snižuje důvěru.

Pro podnikový software provozní přesnost zahrnuje tyto zdánlivě malé detaily. COCO je proto také zkontrolovalo.

Control.

První slovo ve sloganu softify.pro Flow je také prvním principem testovacího prostředí.

Control znamená vědět, co se testuje, oproti jakému stavu, a s jakými daty.

Veřejná demonstrace COCO nepoužívá produkční záznamy klienta.

Běží se záměrně připravenými demonstračními daty, jejichž očekávaný stav je znám.

To dělá výsledky reprodukovatelnými.

Také to znamená, že rozdíly mezi testovacími běhy lze zkoumat, místo aby byly vysvětlovány jako náhodné změny v produkčních datech.

Ještě důležitější je, že COCO je navrženo jako samostatně hostovaný systém AI testování.

Testovací důkazy, snímky obrazovky aplikace, a interní informace o pracovním postupu mohou zůstat uvnitř infrastruktury pod vlastní kontrolou zákazníka nebo operátora, místo aby byly ve výchozím nastavení odesílány do nesouvisející cloudové služby třetí strany.

Pro interní obchodní aplikace to není jen infrastrukturní preference. Může to být součástí samotného testovacího požadavku.

Clarity.

Automatizace není obzvlášť užitečná, pokud je jejím konečným výstupem: FAILED
následovaný stovkami řádků technického výstupu, které někdo musí ručně zrekonstruovat, než pochopí, co se stalo.

COCO je navrženo tak, aby zachovalo srozumitelnou důkazní stopu.

Zpráva popisuje:

• co bylo testováno
• která interakce se uskutečnila
• v jakém pořadí se to stalo
• co COCO pozorovalo
• jaký stav se očekával
• kde se chování lišilo, když něco selhalo

Snímky obrazovky a důkazy provedení mohou tuto sekvenci doprovázet.
Účelem není skrýt technické detaily.

Je jím udělat výsledek srozumitelným předtím, než někdo musí otevřít debugger.

Inženýr by měl být schopen odpovědět:
Co se stalo? předtím, než se zeptá:
Kde v kódu se to stalo?

Tento rozdíl dramaticky zkracuje vyšetřování, když se objeví regrese.

Flow.

Tradiční UI automatizace často myslí v prvcích.

Najdi selektor.
Klikni na selektor.
Najdi další selektor.
Zkontroluj hodnotu.

Tento přístup zůstává užitečný, ale aplikace se nezažívají jako sbírky selektorů.

Lidé zažívají toky.

Přihlas se.
Otevři administraci.
Najdi uživatele.
Změň nastavení.
Přepni databázi.
Změň jazyk.
Ověř výsledek.

Pokračuj v práci.

COCO proto považuje sekvenci za proces, ne za náhodnou sbírku ovládacích prvků.

Sleduje, co se uživatel snaží dosáhnout, a hodnotí aplikaci v kontextu.

To se stává obzvlášť hodnotné při testování skutečného podnikového softwaru, protože selhání se často vyskytují mezi obrazovkami nebo mezi stavy, ne uvnitř jednotlivého tlačítka.

Logistický pracovní postup může obsahovat objednávku, rezervaci zásoby, operaci vychystávání, dodací list, a potvrzení expedice.
Každá jednotlivá obrazovka může vypadat správně, zatímco kompletní proces je špatný.
Stejný princip platí zde v menším měřítku.
Okno administrace není produktem.

Pracovní postup skrz něj je.

Důkaz místo předpokladu

Jednou z nejdůležitějších úloh COCO není klikání. Je jí zapamatování si toho, co se stalo.
Lidské regresní testování často končí tvrzením jako:
„Otestoval jsem to a vše vypadalo v pořádku."

To může být zcela přesné.
Ale o několik týdnů později, když se objeví problém, jsou užitečné otázky jiné:

• Které vydání bylo testováno?
• Která databáze?
• Který jazyk?
• Jaký byl stav uživatele?
• Co se stalo před problémem?
• Co přesně bylo viditelné?

V jakém pořadí byly akce provedeny?
Testovací běhy COCO jsou navrženy tak, aby za sebou zanechaly důkazy.

To transformuje výsledek testu z názoru na něco, co lze prozkoumat. Úspěšný běh se proto také stává užitečným.
Ustanovuje známý referenční stav, oproti kterému lze porovnat pozdější chování.

COCO není ten, kdo rozhoduje

Existuje důležitá hranice ve způsobu, jakým používáme AI k testování softwaru.
COCO nemá za cíl nahradit inženýrskou odpovědnost.

Nerozhoduje o tom, jaké by mělo být obchodní pravidlo.

Testuje chování oproti scénářům, požadavkům, a očekáváním definovaným pro aplikaci. Pro citlivá rozhodnutí zahrnující oprávnění, ceny, zásobu, finanční transakce, nebo jiné kritické obchodní stavy, definice správného chování zůstává lidskou odpovědností.

Tento rozdíl je důležitý.
AI je vynikající v opakování podrobného testu bez ztráty koncentrace. Je vynikající ve sbírání důkazů.
Může zkontrolovat obrazovky, porovnat očekávané a pozorované chování, a vysvětlit nesrovnalosti. Ale byznys stále definuje, co znamená správné.

COCO dělá tuto definici testovatelnou.

Test, který nikdo nechce opakovat

Existuje jednoduchý důvod, proč automatizace zde přidává hodnotu.
Lidský tester dokáže tuto regresní relaci absolutně provést.
První jazyk dostává plnou pozornost.
Pravděpodobně i druhý.
Pak další.
Pak další.
MySQL už bylo zkontrolováno.
PostgreSQL ještě potřebuje zkontrolovat.
Test třídění už byl proveden několikrát.
Dialog About se nezměnil měsíce.

Je páteční odpoledne.

A lidská pozornost dělá to, co lidská pozornost přirozeně dělá. Začíná optimalizovat.
COCO ne. V duchu samotného COCO:

• Nenudí mě klikání na stejné tlačítko v jedenácti jazycích. Nepřeskakuji přechod PostgreSQL, protože je páteční odpoledne. Nepředpokládám, že pořadí třídění se zachovalo, protože fungovalo v předchozím vydání.

Pro COCO lze každou regresní relaci považovat za první. To není inteligence nahrazující lidského testera.
Je to automatizace chránící lidského testera před částí testování, kde je lidská pozornost nejméně hodnotná.

Od opakovaného testování k inženýrskému důkazu

Větším účelem COCO není maximalizovat počet automatizovaných akcí.
Tisíc automatizovaných kliknutí je bezvýznamných, pokud nikdo nerozumí tomu, co dokazují. Užitečným výsledkem je důvěra podpořená důkazy.

Pro softify.pro Flow to znamená být schopen říct, že vydání bylo prověřeno napříč provozními oblastmi, na kterých záleží:

• autentizace
• administrace uživatelů
• role a informace o přístupu
• stav dvoufaktorové autentizace
• chování třídění
• provoz MySQL
• provoz PostgreSQL
• živá lokalizace
• statusová zpětná vazba
• informace o aplikaci
• licenční informace

a že výsledek je zachován ve formě, kterou lze později prozkoumat. Stejný princip se škáluje daleko za tuto aplikaci.
Proces přihlášení lze testovat takto.
Pracovní postup rezervace lze testovat takto.
Logistický proces lze testovat takto.
Multiplatformní desktopovou aplikaci lze testovat takto.
Obrazovky se mění.
Obchodní pravidla se mění.
Princip ne:
definuj očekávaný pracovní postup, prováděj ho konzistentně, sbírej důkazy, a udělej výsledek srozumitelným.

Proč testujeme náš vlastní software pomocí COCO

Existuje další důvod, proč je softify.pro Flow důležitý jako případová studie COCO.

Je to náš vlastní software.
To odstraňuje pohodlný odstup, který někdy existuje mezi technologickou demonstrací a lidmi, kteří ji demonstrují.

Pokud má COCO testovat podnikový software, musí být dostatečně užitečné, abychom mu mohli důvěřovat se softwarem, který skutečně sami vyvíjíme a vydáváme.

Flow tedy funguje jak jako produkt, tak jako zkušební prostor.
Nové testovací schopnosti lze prověřit oproti skutečné aplikaci.
Neočekávané chování může odhalit slabiny v aplikaci, testovacím plánu, nebo samotném COCO.

Každá strana zlepšuje tu druhou.
Tato smyčka zpětné vazby je mnohem hodnotnější než budování umělých demonstrací navržených jen k tomu, aby uspěly. Testovací systém by neměl vypadat přesvědčivě, protože demonstrace byla jednoduchá.
Měl by se stát přesvědčivým, protože nadále nachází malé věci, které by lidé nakonec přestali kontrolovat.

Výsledek

softify.pro Flow — Administration má nyní zdokumentovaný a opakovatelný regresní proces, který COCO může provést před relevantními vydáními.

Test pokrývá obě podporovaná databázová prostředí a jedenáctijazyčné rozhraní aplikace, přičemž sleduje aplikaci tak, jak by ji používal administrátor, místo aby traktoval každou obrazovku jako izolovaný testovací cíl.

COCO vytváří důkazní stopu ukazující, co bylo testováno, co bylo pozorováno, a v jakém pořadí se relace uskutečnila.

Tento důkaz může zůstat lokálně kontrolovaný.
Vývojáři získávají reprodukovatelný výchozí bod, když se něco změní.
Lidští testeři tráví méně času opakováním předvídatelných interakcí a více času zkoumáním situací, které skutečně vyžadují úsudek.

A softify.pro Flow dostává něco hodnotnějšího než zelený indikátor PASS.

Dostává důkaz, že zážitek slíbený na jeho přihlašovací obrazovce nadále existuje i poté, co se kód pod ní změní.

Control. Věz, co se testuje, a udržuj prostředí pod kontrolou.

Clarity. Rozuměj tomu, co se stalo, bez rekonstrukce neprůhledného automatizačního deníku.

Flow. Testuj aplikaci jako proces, který lidé skutečně používají.

Control. Clarity. Flow.

Bylo to napsáno pro software.
Ukázalo se, že to stejně dobře popisuje i testovací filozofii za ním.