softify.pro Flow — Testad av COCO

Control. Clarity. Flow.

Varje seriös mjukvaruprodukt utvecklar förr eller senare en andra produkt bakom produkten.

Kunder ser den kanske aldrig. Besökare vet kanske aldrig att den finns. Men administratörer, operatörer och utvecklare är beroende av den varje dag.

För softify.pro Flow heter den applikationen Administration — den operativa konsolen som ansvarar för att hantera användare, roller, åtkomstnivåer, autentiseringsstatus, databasmiljöer och annan konfiguration som håller en Flow-installation under kontroll.

Inloggningsskärmen bär tre ord:
Control. Clarity. Flow.

De valdes ursprungligen för att beskriva den upplevelse vi ville att administratörer skulle ha när de använder systemet.

Men de beskriver också förvånansvärt väl hur vi tycker att mjukvara bör testas.

Det gjorde softify.pro Flow — Administration till en självklar kandidat för ett verkligt COCO-test.
Ingen laboratoriedemonstration.
Ingen samling isolerade knappar förberedda specifikt för en AI-demo.
En riktig plattformsoberoende skrivbordsapplikation med verklig applikationslogik, flera fönster, flera databas-backends, autentisering, behörigheter, lokalisering och tillräckligt med tillstånd för att till synes små regressioner ska vara svåra att upptäcka manuellt.

För den offentliga demonstrationen som visas här arbetade COCO uteslutande med genererad demodata. Applikationen var licensierad till det fiktiva företaget Presentation GmbH, och ingen produktionskundinformation, inga inloggningsuppgifter och inga personuppgifter användes.

Målet var enkelt:
låta COCO närma sig applikationen som en testare skulle göra och avgöra om hela det administrativa arbetsflödet fortfarande beter sig som mjukvaran påstår.

The Challenge

Vid första anblicken verkar det enkelt att testa en administrationsapplikation.

Öppna den.
Logga in.
Klicka igenom flera fönster.
Kontrollera att allt ser korrekt ut.

Det antagandet förändras snabbt när applikationen växer.

softify.pro Flow — Administration är inte ett enda statiskt formulär. Det är en samling sammankopplade operativa vyer inuti ett applikationsskal.

Bland annat kan en administratör arbeta med:

• användarkonton
• roller och åtkomstnivåer
• autentiseringsinformation
• status för tvåfaktorsautentisering
• operativsysteminformation
• nätverks- och IP-information
• databaskonfiguration
• sorterings- och presentationsalternativ
• liveval av språk
• applikations- och licensinformation

Gränssnittet stödjer för närvarande elva språk. Applikationen fungerar också med MySQL och PostgreSQL som databas-backends. Var för sig utgör ingen av dessa funktioner ett ovanligt testproblem.

Svårigheten uppstår ur deras kombinationer.
En användartabell kan fungera korrekt på engelska men visa ett föråldrat kolumnnamn på kroatiska.
Sortering kan fungera korrekt ansluten till MySQL men bete sig annorlunda efter byte till PostgreSQL.

Ett språkbyte kan uppdatera de flesta gränssnittselement men lämna ett statusmeddelande oöversatt. Applikationen kan byta databas framgångsrikt men behålla inaktuell information från den föregående anslutningen. En ny version kan introducera en funktion medan Om-dialogen fortfarande beskriver den föregående. Programmet behöver inte krascha för att någon av dessa situationer ska vara en regression. Faktum är att några av de mest besvärliga mjukvarufelen är just de där allt ser ut att fungera.

Applikationen startar.
Fönstret öppnas.
Knappen svarar.
Men något under ytan är inte längre helt rätt.
Det är därför upprepad regressionstestning är viktig.

Och det är också exakt den typ av arbete som människor blir allt sämre på efter att ha upprepat samma sekvens dussintals gånger.

Why Manual Testing Becomes Expensive

Att testa något en gång är enkelt.
Att testa det tillförlitligt efter varje relevant version är något annat.

Betrakta bara tre dimensioner: 11 gränssnittsspråk × 2 databas-backends × flera applikationsarbetsflöden.

Antalet kombinationer växer snabbt.
Lägg till olika användarroller, autentiseringsstatus, sorteringsbeteende, konfigurationsändringar och driftmiljöer, och testmatrisen blir för stor för att behandlas som en tillfällig manuell checklista.

Det är här regressionstestning ofta börjar eroderas.
Inte avsiktligt.
En releasedeadline närmar sig.
Någon minns att applikationen testades förra veckan.
En utvecklare kontrollerar snabbt den viktigaste skärmen.

Tyska fungerar.
Engelska fungerar.
MySQL fungerar.
Antagandet blir:
"Resten är förmodligen okej."

Vanligtvis är det så.
Fram till den version då det inte är det.
COCO finns delvis för att ta bort det antagandet ur processen.

What COCO Actually Did

COCO startade softify.pro Flow — Administration från ett kallt applikationstillstånd, utan att förlita sig på en tidigare förberedd skärm eller ett manuellt positionerat arbetsflöde.

Den första interaktionen var densamma som presenteras för en mänsklig administratör: inloggningsfönstret.

COCO identifierade autentiseringsgränssnittet som innehöll:

• användarnamn
• lösenord
• kod för tvåfaktorsautentisering

och raden direkt under softify.pro Flow-identiteten:
Control. Clarity. Flow.

Därifrån fortsatte COCO genom en definierad regressionssession. Poängen var inte enbart att avgöra om applikationen kunde öppnas.

Poängen var att verifiera om applikationens tillstånd förblev internt konsekvent medan COCO interagerade med den.

Authentication Is Only the Beginning

Inloggningstestning är en av de mest uppenbara kandidaterna för automatisering, men lyckad autentisering ensam säger väldigt lite om resten av en administrationsapplikation.

Väl inne flyttade COCO in i den faktiska driftmiljön. Den inspekterade användarhanteringsgränssnittet och verifierade att den förväntade informationen fanns.

Det inkluderade data som:

• användarnamn
• maskerade lösenord
• 2FA-indikatorer
• tilldelade roller
• operativsysteminformation
• IP-adresser

COCO interagerade sedan med tabellen istället för att bara observera den.
Användarlistan sorterades efter användarnamn.
Den resulterande ordningen inspekterades.
Den viktiga delen var inte om klick på kolumnrubriken gav någon synlig förändring.

COCO verifierade att det resulterande tabelltillståndet matchade den begärda operationen.

Den distinktionen spelar roll.
Ett funktionellt test frågar:
"Svarade knappen?"

Ett användbart regressionstest frågar:
"Hamnade applikationen i rätt tillstånd?"

Testing the Database Boundary

softify.pro Flow stöder mer än en databas-backend.

Det gör databasbyte till en särskilt viktig regressionsgräns.
COCO ändrade den aktiva backenden från MySQL till PostgreSQL.

Efter bytet inspekterade den användarinformationen igen.
Testet letade efter mer än en lyckad anslutning.
Det kontrollerade om applikationen fortsatte att visa de förväntade posterna och om informationen som visades genom gränssnittet förblev konsekvent.

COCO bytte sedan tillbaka igen.

Den här typen av övergång är lätt att underskatta.
Användargränssnittet kan förbli visuellt identiskt medan lagringsskiktet under det förändras helt.
Ur en administratörs perspektiv borde den övergången kännas nästan tråkig.
Samma användare borde fortfarande vara begripliga.
Samma roller borde fortfarande vara meningsfulla.

Samma gränssnittsbeteende borde fortfarande gälla.

Den till synes odramatiska kontinuiteten är exakt det som behöver bevisas.

Eleven Languages, One Application State

Lokalisering är ett annat område där ytlig testning är särskilt farlig.

Det är relativt enkelt att verifiera att en applikation kan starta på ett annat språk.
Det är mycket mer värdefullt att verifiera vad som händer när språket ändras medan applikationen redan körs och håller tillstånd.

COCO bytte gränssnittsspråk live.

Sessionen inkluderade övergångar mellan språk som:
Tyska → Engelska → Kroatiska
medan administrationsvyn förblev aktiv.

COCO observerade om gränssnittselement ändrades korrekt på plats:

• tabellrubriker
• kontroller
• knappar
• etiketter
• statusmeddelanden

Den underliggande tabellen och applikationens tillstånd måste också överleva den övergången.
Detta spelar roll eftersom flerspråkig mjukvara består av mer än översatta strängar.
Språkbyten kan avslöja:

• bortglömda resurser
• inaktuella etiketter
• layoutproblem
• oöversatta statusmeddelanden
• kodningsproblem
• tillståndsåterställningar
• problem vid återskapande av kontroller

Ett fönster som ser korrekt ut när det startas direkt på kroatiska kan ändå bete sig fel när användaren byter från tyska till kroatiska under en aktiv session.

Det är skillnaden mellan att kontrollera en skärmdump och att testa ett arbetsflöde.

Restoring Application State

COCO återställde därefter applikationens standardsorteringskonfiguration.

Även här slutade testet inte med själva klicket.

Den resulterande ordningen och bekräftelsen som presenterades genom applikationens statusområde utvärderades. Denna typ av verifiering kan tyckas obetydlig jämfört med att testa autentisering eller databasåtkomst.

Det är den inte.

Enterprise-applikationer samlar hundratals sådana små tillståndsövergångar.
Användare litar på dem utan att medvetet tänka på det.
Mjukvaran känns tillförlitlig just för att dessa interaktioner förblir förutsägbara.
Regressionstestning finns för att skydda den förutsägbarheten.

Testing the Information Around the Software

COCO öppnade också applikationens Om-dialog.

Varför testa ett Om-fönster?

Eftersom mjukvarudokumentation börjar inuti själva mjukvaran.
Versionsnumret, funktionsbeskrivningen och licensinformationen som presenteras för operatören bör motsvara den applikation som faktiskt körs.

En applikation kan fungera perfekt samtidigt som den visar inaktuell versionsinformation eller beskriver funktioner som inte längre motsvarar versionen.

Det kraschar ingen databas.
Det gör något mer subtilt:
det minskar förtroendet.

För enterprise-mjukvara inkluderar operativ noggrannhet dessa till synes små detaljer. COCO kontrollerade därför även dessa.

Control.

Det första ordet i softify.pro Flow-sloganen är också den första principen för testmiljön.

Control betyder att veta vad som testas, mot vilket tillstånd och med vilka data.

Den offentliga COCO-demonstrationen använder inga produktionsdata från kunder.

Den körs med avsiktligt förberedd demodata vars förväntade tillstånd är känt.

Det gör resultaten reproducerbara.

Det innebär också att skillnader mellan testkörningar kan undersökas istället för att förklaras bort som slumpmässiga förändringar i produktionsdata.

Ännu viktigare är att COCO är designat som ett självhostat AI-testsystem.

Testbevis, applikationsskärmdumpar och intern arbetsflödesinformation kan förbli inom infrastruktur under kundens eller operatörens egen kontroll, istället för att som standard skickas till en icke-relaterad molntjänst från tredje part.

För interna affärsapplikationer är det inte bara en infrastrukturpreferens.
Det kan vara en del av själva testkravet.

Clarity.

Automatisering är inte särskilt användbar om dess slutliga utdata är: FAILED
följt av hundratals rader teknisk utdata som någon manuellt måste rekonstruera innan de förstår vad som hänt.

COCO är designat för att bevara ett begripligt bevisspår.

Rapporten beskriver:

• vad som testades
• vilken interaktion som ägde rum
• i vilken ordning det skedde
• vad COCO observerade
• vilket tillstånd som förväntades
• var beteendet skiljde sig när något misslyckades

Skärmdumpar och exekveringsbevis kan följa den sekvensen.
Syftet är inte att dölja tekniska detaljer.

Det är att göra resultatet begripligt innan någon måste öppna en debugger.

En ingenjör bör kunna svara på:
Vad hände? innan de frågar:
Var i koden hände det?

Den distinktionen förkortar utredningen dramatiskt när en regression uppstår.

Flow.

Traditionell UI-automatisering tänker ofta i element.

Hitta selektor.
Klicka selektor.
Hitta en annan selektor.
Kontrollera värde.

Det tillvägagångssättet förblir användbart, men applikationer upplevs inte som samlingar av selektorer.

Människor upplever flöden.

Logga in.
Öppna administration.
Hitta en användare.
Ändra en inställning.
Byt databas.
Byt språk.
Verifiera resultatet.

Fortsätt arbeta.

COCO behandlar därför sekvensen som en process snarare än en slumpmässig samling kontroller.

Den följer vad användaren försöker uppnå och utvärderar applikationen i kontext.

Det blir särskilt värdefullt vid testning av verklig affärsmjukvara, eftersom fel ofta uppstår mellan skärmar eller mellan tillstånd, inte inuti en enskild knapp.

Ett logistikarbetsflöde kan innehålla en order, en lagerreservation, en plockoperation, en följesedel och en leveransbekräftelse.
Varje enskild skärm kan verka korrekt medan hela processen är fel.
Samma princip gäller här i mindre skala.
Administrationsfönstret är inte produkten.

Arbetsflödet genom det är det.

Evidence Instead of Assumption

En av COCOs viktigaste uppgifter är inte att klicka. Det är att komma ihåg vad som hände.
Mänsklig regressionstestning slutar ofta med ett uttalande som:
"Jag testade det och allt såg bra ut."

Det kan vara helt korrekt.
Men flera veckor senare, när ett problem dyker upp, är de användbara frågorna andra:

• Vilken version testades?
• Vilken databas?
• Vilket språk?
• Vilket användartillstånd?
• Vad hände innan problemet?
• Vad exakt var synligt?

I vilken ordning utfördes åtgärderna?
COCOs testkörningar är designade för att lämna bevis efter sig.

Det förvandlar ett testresultat från en åsikt till något som kan inspekteras.
En lyckad körning blir därför också användbar.
Den etablerar ett känt referenstillstånd som senare beteende kan jämföras mot.

COCO Is Not the Decision Maker

Det finns en viktig gräns i hur vi använder AI för mjukvarutestning.
COCO är inte avsett att ersätta ingenjörsansvar.

Den bestämmer inte hur en affärsregel borde vara.

Den testar beteende mot scenarier, krav och förväntningar definierade för applikationen.
För känsliga beslut som rör behörigheter, priser, lager, finansiella transaktioner eller andra kritiska affärstillstånd förblir definitionen av korrekt beteende ett mänskligt ansvar.

Den distinktionen spelar roll.
AI är utmärkt på att upprepa ett detaljerat test utan att tappa koncentrationen.
Den är utmärkt på att samla bevis.
Den kan inspektera skärmar, jämföra förväntat och observerat beteende och förklara avvikelser.
Men det är fortfarande företaget som definierar vad korrekt betyder.

COCO gör den definitionen testbar.

The Test Nobody Wants to Repeat

Det finns en enkel anledning till varför automatisering tillför värde här.
En mänsklig testare kan definitivt utföra den här regressionssessionen.
Det första språket får full uppmärksamhet.
Förmodligen det andra också.
Sedan ett till.
Sedan ett till.
MySQL har redan kontrollerats.
PostgreSQL behöver fortfarande kontrolleras.
Sorteringstestet har redan utförts flera gånger.
Om-dialogen har inte ändrats på månader.

Det är fredag eftermiddag.

Och mänsklig uppmärksamhet gör vad mänsklig uppmärksamhet naturligt gör.
Den börjar optimera.
COCO gör inte det.
I COCOs egen anda:

• Jag blir inte trött på att klicka på samma knapp på elva språk. Jag hoppar inte över PostgreSQL-omgången bara för att det är fredag eftermiddag. Jag antar inte att sorteringen höll bara för att den fungerade i föregående version.

För COCO kan varje regressionssession behandlas som om den vore den första.
Det är inte intelligens som ersätter en mänsklig testare.
Det är automatisering som skyddar den mänskliga testaren från den del av testningen där mänsklig uppmärksamhet är minst värd.

From Repetitive Testing to Engineering Evidence

COCOs bredare syfte är inte att maximera antalet automatiserade åtgärder.
Tusen automatiserade klick är meningslösa om ingen förstår vad de bevisar. Det användbara resultatet är förtroende understött av bevis.

För softify.pro Flow innebär det att kunna säga att en version har testats över de operativa områden som spelar roll:

• autentisering
• användaradministration
• roll- och åtkomstinformation
• status för tvåfaktorsautentisering
• sorteringsbeteende
• MySQL-drift
• PostgreSQL-drift
• live-lokalisering
• statusåterkoppling
• applikationsinformation
• licensinformation

och att resultatet bevaras i en form som kan granskas i efterhand.
Samma princip skalar långt utöver denna applikation.
En inloggningsprocess kan testas på detta sätt.
Ett bokningsarbetsflöde kan testas på detta sätt.
En logistikprocess kan testas på detta sätt.
En plattformsoberoende skrivbordsapplikation kan testas på detta sätt.
Skärmarna förändras.
Affärsreglerna förändras.
Principen gör inte det:
definiera det förväntade arbetsflödet, utföra det konsekvent, samla bevis och göra resultatet begripligt.

Why We Test Our Own Software With COCO

Det finns ytterligare en anledning till varför softify.pro Flow spelar roll som COCO-fallstudie.

Det är vår egen mjukvara.
Det tar bort det bekväma avståndet som ibland finns mellan en teknikdemonstration och de personer som visar upp den.

Om COCO är tänkt att testa enterprise-mjukvara måste den vara tillräckligt användbar för att vi ska lita på den med mjukvara vi själva utvecklar och släpper.

Flow fungerar därför både som produkt och testbädd.
Nya testfunktioner kan prövas mot en verklig applikation.
Oväntat beteende kan avslöja svagheter i applikationen, testplanen eller COCO själv.

Varje sida förbättrar den andra.
Den återkopplingsslingan är mycket mer värdefull än att bygga artificiella demonstrationer designade enbart för att lyckas. Ett testsystem bör inte verka övertygande för att demonstrationen var enkel.
Det bör bli övertygande för att det fortsätter hitta de små sakerna som människor så småningom skulle sluta kontrollera.

The Result

softify.pro Flow — Administration har nu en dokumenterad och repeterbar regressionsprocess som COCO kan köra före relevanta versioner.

Testet spänner över båda de databasmiljöer som stöds och applikationens elvaspråkiga gränssnitt, samtidigt som det följer applikationen som en administratör skulle använda den, istället för att behandla varje skärm som ett isolerat testmål.

COCO producerar ett bevisspår som visar vad som testades, vad som observerades och i vilken ordning sessionen ägde rum.

De bevisen kan förbli under lokal kontroll.
Utvecklare får en reproducerbar startpunkt när något ändras.
Mänskliga testare lägger mindre tid på att upprepa förutsägbara interaktioner och mer tid på att utreda situationer som verkligen kräver omdöme.

Och softify.pro Flow får något mer värdefullt än en grön PASS-indikator.

Den får bevis på att upplevelsen som utlovas på inloggningsskärmen fortsätter att existera efter att den underliggande koden har ändrats.

Control. Veta vad som testas och hålla miljön under kontroll.

Clarity. Förstå vad som hände utan att behöva rekonstruera en ogenomskinlig automatiseringslogg.

Flow. Testa applikationen som en process människor faktiskt använder.

Control. Clarity. Flow.

Det skrevs för mjukvaran.
Det visade sig beskriva testfilosofin bakom den precis lika väl.