softify.pro Flow — Testet av COCO

Control. Clarity. Flow.

Ethvert seriøst programvareprodukt utvikler før eller siden et andre produkt bak produktet.

Kunder ser det kanskje aldri. Besøkende vet kanskje aldri at det finnes. Men administratorer, operatører og utviklere er avhengige av det hver dag.

For softify.pro Flow heter denne applikasjonen Administration — den operative konsollen som er ansvarlig for å administrere brukere, roller, tilgangsnivåer, autentiseringsstatuser, databasemiljøer og annen konfigurasjon som holder en Flow-installasjon under kontroll.

Innloggingsskjermen bærer tre ord:
Control. Clarity. Flow.

De ble opprinnelig valgt for å beskrive opplevelsen vi ønsket at administratorer skulle ha når de driftet systemet.

Men de beskriver også overraskende godt hvordan vi mener programvare bør testes.

Det gjorde softify.pro Flow — Administration til en åpenbar kandidat for en reell COCO-test.
Ikke en laboratoriedemonstrasjon.
Ikke en samling isolerte knapper forberedt spesielt for en AI-demo.
En ekte plattformuavhengig skrivebordsapplikasjon med reell applikasjonslogikk, flere vinduer, flere databasebackender, autentisering, tillatelser, lokalisering og nok tilstand til at tilsynelatende små regresjoner er vanskelige å oppdage manuelt.

For den offentlige demonstrasjonen som vises her, jobbet COCO utelukkende med generert demodata. Applikasjonen var lisensiert til det fiktive selskapet Presentation GmbH, og ingen produksjonskundeinformasjon, ingen legitimasjon og ingen personopplysninger ble brukt.

Målet var enkelt:
la COCO nærme seg applikasjonen slik en tester ville gjort, og avgjøre om hele den administrative arbeidsflyten fortsatt oppfører seg slik programvaren hevder.

The Challenge

Ved første øyekast virker det enkelt å teste en administrasjonsapplikasjon.

Åpne den.
Logg inn.
Klikk gjennom flere vinduer.
Sjekk at alt ser riktig ut.

Den antagelsen endrer seg raskt etter hvert som applikasjonen vokser.

softify.pro Flow — Administration er ikke ett enkelt statisk skjema. Det er en samling sammenkoblede operative visninger inne i ett applikasjonsskall.

Blant annet kan en administrator jobbe med:

• brukerkontoer
• roller og tilgangsnivåer
• autentiseringsinformasjon
• status for tofaktorautentisering
• informasjon om operativsystem
• nettverks- og IP-informasjon
• databasekonfigurasjon
• sorterings- og visningsalternativer
• live språkvalg
• applikasjons- og lisensinformasjon

Grensesnittet støtter for øyeblikket elleve språk. Applikasjonen fungerer også med MySQL og PostgreSQL som databasebackender. Hver for seg representerer ingen av disse funksjonene et uvanlig testproblem.

Vanskeligheten oppstår fra kombinasjonene deres.
En brukertabell kan fungere korrekt på engelsk, men vise et utdatert kolonnenavn på kroatisk.
Sortering kan fungere korrekt tilkoblet MySQL, men oppføre seg annerledes etter bytte til PostgreSQL.

Et språkbytte kan oppdatere de fleste grensesnittelementer, men la én statusmelding forbli uoversatt. Applikasjonen kan bytte database vellykket, men beholde utdatert informasjon fra den forrige tilkoblingen. En ny versjon kan introdusere en funksjon mens Om-dialogen fortsatt beskriver den forrige. Programmet trenger ikke krasje for at noen av disse situasjonene skal være en regresjon. Faktisk er noen av de mest ubeleilige programvarefeilene nettopp de der alt ser ut til å fungere.

Applikasjonen starter.
Vinduet åpnes.
Knappen reagerer.
Men noe under er ikke lenger helt riktig.
Det er derfor gjentagende regresjonstesting er viktig.

Og det er også nøyaktig den typen arbeid mennesker blir gradvis dårligere til å utføre etter å ha gjentatt den samme sekvensen dusinvis av ganger.

Why Manual Testing Becomes Expensive

Å teste noe én gang er enkelt.
Å teste det pålitelig etter hver relevante versjon er noe annet.

Vurder bare tre dimensjoner: 11 grensesnittspråk × 2 databasebackender × flere applikasjonsarbeidsflyter.

Antallet kombinasjoner vokser raskt.
Legg til ulike brukerroller, autentiseringsstatuser, sorteringsatferd, konfigurasjonsendringer og driftsmiljøer, og testmatrisen blir for stor til å behandles som en sporadisk manuell sjekkliste.

Det er her regresjonstesting ofte begynner å eroderes.
Ikke bevisst.
En releasefrist nærmer seg.
Noen husker at applikasjonen ble testet forrige uke.
En utvikler sjekker raskt det viktigste skjermbildet.

Tysk fungerer.
Engelsk fungerer.
MySQL fungerer.
Antagelsen blir:
"Resten er sannsynligvis i orden."

Vanligvis er den det.
Helt til den versjonen der den ikke er det.
COCO finnes delvis for å fjerne den antagelsen fra prosessen.

What COCO Actually Did

COCO startet softify.pro Flow — Administration fra en kald applikasjonstilstand, uten å basere seg på et tidligere forberedt skjermbilde eller en manuelt plassert arbeidsflyt.

Den første interaksjonen var den samme som presenteres for en menneskelig administrator: innloggingsvinduet.

COCO identifiserte autentiseringsgrensesnittet som inneholdt:

• brukernavn
• passord
• kode for tofaktorautentisering

og linjen rett under softify.pro Flow-identiteten:
Control. Clarity. Flow.

Derfra fortsatte COCO gjennom en definert regresjonsøkt. Poenget var ikke bare å avgjøre om applikasjonen kunne åpnes.

Poenget var å verifisere om applikasjonens tilstand forble internt konsistent mens COCO interagerte med den.

Authentication Is Only the Beginning

Testing av innlogging er en av de mest åpenbare kandidatene for automatisering, men vellykket autentisering alene sier svært lite om resten av en administrasjonsapplikasjon.

Når den var inne, flyttet COCO seg til det faktiske driftsmiljøet. Den inspiserte brukeradministrasjonsgrensesnittet og verifiserte at forventet informasjon var til stede.

Det inkluderte data som:

• brukernavn
• maskerte passord
• 2FA-indikatorer
• tildelte roller
• informasjon om operativsystem
• IP-adresser

COCO samhandlet deretter med tabellen i stedet for bare å observere den.
Brukerlisten ble sortert etter brukernavn.
Den resulterende rekkefølgen ble inspisert.
Det viktige var ikke om klikk på kolonneoverskriften ga en synlig endring.

COCO verifiserte at den resulterende tabelltilstanden samsvarte med den forespurte operasjonen.

Det skillet betyr noe.
En funksjonell test spør:
"Reagerte knappen?"

En nyttig regresjonstest spør:
"Endte applikasjonen i riktig tilstand?"

Testing the Database Boundary

softify.pro Flow støtter mer enn én databasebackend.

Det gjør databasebytte til en spesielt viktig regresjonsgrense.
COCO endret den aktive backenden fra MySQL til PostgreSQL.

Etter byttet inspiserte den brukerinformasjonen på nytt.
Testen så etter mer enn en vellykket tilkobling.
Den sjekket om applikasjonen fortsatte å vise de forventede postene, og om informasjonen vist gjennom grensesnittet forble konsistent.

COCO byttet deretter tilbake igjen.

Denne typen overgang er lett å undervurdere.
Brukergrensesnittet kan forbli visuelt identisk mens lagringslaget under det endres fullstendig.
Fra en administrators perspektiv bør den overgangen føles nesten kjedelig.
De samme brukerne bør fortsatt være forståelige.
De samme rollene bør fortsatt gi mening.

Den samme grensesnittatferden bør fortsatt gjelde.

Den tilsynelatende hendelsesløse kontinuiteten er nøyaktig det som må bevises.

Eleven Languages, One Application State

Lokalisering er et annet område der overfladisk testing er spesielt farlig.

Det er relativt enkelt å verifisere at en applikasjon kan starte på et annet språk.
Det er mye mer verdifullt å verifisere hva som skjer når språket endres mens applikasjonen allerede kjører og holder tilstand.

COCO byttet grensesnittspråk live.

Økten inkluderte overganger mellom språk som:
Tysk → Engelsk → Kroatisk
mens administrasjonsvisningen forble aktiv.

COCO observerte om grensesnittelementer endret seg korrekt på stedet:

• tabelloverskrifter
• kontroller
• knapper
• etiketter
• statusmeldinger

Den underliggende tabellen og applikasjonstilstanden måtte også overleve den overgangen.
Dette betyr noe fordi flerspråklig programvare består av mer enn oversatte strenger.
Språkendringer kan avsløre:

• glemte ressurser
• utdaterte etiketter
• layoutproblemer
• uoversatte statusmeldinger
• kodingsproblemer
• tilstandstilbakestillinger
• problemer med gjenoppretting av kontroller

Et vindu som ser riktig ut når det startes direkte på kroatisk, kan likevel oppføre seg feil når brukeren bytter fra tysk til kroatisk under en aktiv økt.

Det er forskjellen mellom å sjekke et skjermbilde og å teste en arbeidsflyt.

Restoring Application State

COCO gjenopprettet deretter applikasjonens standard sorteringskonfigurasjon.

Igjen, testen sluttet ikke med selve klikket.

Den resulterende rekkefølgen og bekreftelsen presentert gjennom applikasjonens statusområde ble evaluert. Denne typen verifisering kan virke ubetydelig sammenlignet med å teste autentisering eller databasetilgang.

Det er den ikke.

Enterprise-applikasjoner samler opp hundrevis av slike små tilstandsoverganger.
Brukere stoler på dem uten å bevisst tenke på dem.
Programvaren føles pålitelig nettopp fordi disse interaksjonene forblir forutsigbare.
Regresjonstesting finnes for å beskytte den forutsigbarheten.

Testing the Information Around the Software

COCO åpnet også applikasjonens Om-dialog.

Hvorfor teste et Om-vindu?

Fordi programvaredokumentasjon starter inne i selve programvaren.
Versjonsnummeret, funksjonsbeskrivelsen og lisensinformasjonen som presenteres for operatøren, bør samsvare med applikasjonen som faktisk kjører.

En applikasjon kan fungere perfekt samtidig som den viser utdatert versjonsinformasjon eller beskriver funksjoner som ikke lenger samsvarer med versjonen.

Det krasjer ikke en database.
Det gjør noe mer subtilt:
det reduserer tilliten.

For enterprise-programvare inkluderer operativ nøyaktighet også disse tilsynelatende små detaljene. COCO sjekket derfor også disse.

Control.

Det første ordet i softify.pro Flow-slagordet er også det første prinsippet for testmiljøet.

Control betyr å vite hva som testes, mot hvilken tilstand og med hvilke data.

Den offentlige COCO-demonstrasjonen bruker ikke kunders produksjonsdata.

Den kjører med bevisst forberedt demodata der forventet tilstand er kjent.

Det gjør resultatene reproduserbare.

Det betyr også at forskjeller mellom testkjøringer kan undersøkes i stedet for å forklares bort som tilfeldige endringer i produksjonsdata.

Enda viktigere er det at COCO er designet som et selvhostet AI-testsystem.

Testbevis, applikasjonsskjermbilder og intern arbeidsflytinformasjon kan forbli innenfor infrastruktur under kundens eller operatørens egen kontroll, i stedet for å sendes som standard til en urelatert tredjeparts skytjeneste.

For interne forretningsapplikasjoner er dette ikke bare en infrastrukturpreferanse.
Det kan være en del av selve testkravet.

Clarity.

Automatisering er ikke spesielt nyttig hvis sluttresultatet er: FAILED
etterfulgt av hundrevis av linjer med teknisk utdata som noen må rekonstruere manuelt før de forstår hva som skjedde.

COCO er designet for å bevare et forståelig bevisspor.

Rapporten beskriver:

• hva som ble testet
• hvilken interaksjon som fant sted
• i hvilken rekkefølge det skjedde
• hva COCO observerte
• hvilken tilstand som var forventet
• hvor atferden avvek når noe feilet

Skjermbilder og utførelsesbevis kan følge den sekvensen.
Formålet er ikke å skjule tekniske detaljer.

Det er å gjøre resultatet forståelig før noen må åpne en debugger.

En ingeniør bør kunne svare på:
Hva skjedde? før de spør:
Hvor i koden skjedde det?

Det skillet forkorter undersøkelsen dramatisk når en regresjon oppstår.

Flow.

Tradisjonell UI-automatisering tenker ofte i elementer.

Finn selektor.
Klikk selektor.
Finn en annen selektor.
Sjekk verdi.

Den tilnærmingen forblir nyttig, men applikasjoner oppleves ikke som samlinger av selektorer.

Mennesker opplever flyter.

Logg inn.
Åpne administrasjon.
Finn en bruker.
Endre en innstilling.
Bytt database.
Bytt språk.
Verifiser resultatet.

Fortsett å jobbe.

COCO behandler derfor sekvensen som en prosess snarere enn en tilfeldig samling kontroller.

Den følger hva brukeren prøver å oppnå og vurderer applikasjonen i kontekst.

Dette blir spesielt verdifullt ved testing av reell forretningsprogramvare, fordi feil ofte oppstår mellom skjermbilder eller mellom tilstander, ikke inne i en enkelt knapp.

En logistikkarbeidsflyt kan inneholde en ordre, en lagerreservasjon, en plukkoperasjon, en følgeseddel og en forsendelsesbekreftelse.
Hvert enkelt skjermbilde kan virke korrekt mens hele prosessen er feil.
Det samme prinsippet gjelder her i mindre skala.
Administrasjonsvinduet er ikke produktet.

Arbeidsflyten gjennom det er det.

Evidence Instead of Assumption

En av COCOs viktigste oppgaver er ikke å klikke. Det er å huske hva som skjedde.
Menneskelig regresjonstesting ender ofte med en uttalelse som:
"Jeg testet det, og alt så bra ut."

Det kan være helt korrekt.
Men flere uker senere, når et problem dukker opp, er de nyttige spørsmålene andre:

• Hvilken versjon ble testet?
• Hvilken database?
• Hvilket språk?
• Hvilken brukertilstand?
• Hva skjedde før problemet?
• Hva nøyaktig var synlig?

I hvilken rekkefølge ble handlingene utført?
COCOs testkjøringer er designet for å etterlate bevis.

Det forvandler et testresultat fra en mening til noe som kan inspiseres.
En vellykket kjøring blir dermed også nyttig.
Den etablerer en kjent referansetilstand som senere atferd kan sammenlignes mot.

COCO Is Not the Decision Maker

Det er en viktig grense i måten vi bruker AI for programvaretesting på.
COCO er ikke ment å erstatte ingeniøransvar.

Den bestemmer ikke hvordan en forretningsregel bør være.

Den tester atferd mot scenarier, krav og forventninger definert for applikasjonen.
For sensitive beslutninger som involverer tillatelser, priser, lagerbeholdning, finansielle transaksjoner eller andre kritiske forretningstilstander, forblir definisjonen av korrekt atferd et menneskelig ansvar.

Det skillet betyr noe.
AI er utmerket til å gjenta en detaljert test uten å miste konsentrasjonen.
Den er utmerket til å samle bevis.
Den kan inspisere skjermbilder, sammenligne forventet og observert atferd og forklare avvik.
Men det er fortsatt virksomheten som definerer hva korrekt betyr.

COCO gjør den definisjonen testbar.

The Test Nobody Wants to Repeat

Det er en enkel grunn til at automatisering tilfører verdi her.
En menneskelig tester kan absolutt utføre denne regresjonsøkten.
Det første språket får full oppmerksomhet.
Sannsynligvis det andre også.
Så et til.
Så et til.
MySQL er allerede sjekket.
PostgreSQL må fortsatt sjekkes.
Sorteringstesten er allerede utført flere ganger.
Om-dialogen har ikke endret seg på måneder.

Det er fredag ettermiddag.

Og menneskelig oppmerksomhet gjør det menneskelig oppmerksomhet naturlig gjør.
Den begynner å optimalisere.
COCO gjør ikke det.
I COCOs egen ånd:

• Jeg blir ikke lei av å klikke på den samme knappen på elleve språk. Jeg hopper ikke over PostgreSQL-runden bare fordi det er fredag ettermiddag. Jeg antar ikke at sorteringen holdt bare fordi den fungerte i forrige versjon.

For COCO kan hver regresjonsøkt behandles som om den var den første.
Det er ikke intelligens som erstatter en menneskelig tester.
Det er automatisering som beskytter den menneskelige testeren fra den delen av testingen der menneskelig oppmerksomhet er minst verdt.

From Repetitive Testing to Engineering Evidence

Det bredere formålet med COCO er ikke å maksimere antallet automatiserte handlinger.
Tusen automatiserte klikk er meningsløse hvis ingen forstår hva de beviser. Det nyttige resultatet er tillit understøttet av bevis.

For softify.pro Flow betyr det å kunne si at en versjon er testet på tvers av de operative områdene som betyr noe:

• autentisering
• brukeradministrasjon
• rolle- og tilgangsinformasjon
• status for tofaktorautentisering
• sorteringsatferd
• MySQL-drift
• PostgreSQL-drift
• live-lokalisering
• statustilbakemelding
• applikasjonsinformasjon
• lisensinformasjon

og at resultatet bevares i en form som kan gjennomgås i ettertid.
Det samme prinsippet skalerer langt utover denne applikasjonen.
En innloggingsprosess kan testes på denne måten.
En bestillingsarbeidsflyt kan testes på denne måten.
En logistikkprosess kan testes på denne måten.
En plattformuavhengig skrivebordsapplikasjon kan testes på denne måten.
Skjermbildene endrer seg.
Forretningsreglene endrer seg.
Prinsippet gjør ikke det:
definer den forventede arbeidsflyten, utfør den konsekvent, samle bevis og gjør resultatet forståelig.

Why We Test Our Own Software With COCO

Det er en annen grunn til at softify.pro Flow betyr noe som en COCO-casestudie.

Det er vår egen programvare.
Det fjerner den behagelige avstanden som noen ganger finnes mellom en teknologidemonstrasjon og menneskene som viser den frem.

Hvis COCO er ment å teste enterprise-programvare, må den være nyttig nok til at vi stoler på den med programvare vi selv utvikler og lanserer.

Flow fungerer derfor både som produkt og prøvefelt.
Nye testfunksjoner kan utøves mot en reell applikasjon.
Uventet atferd kan avsløre svakheter i applikasjonen, testplanen eller COCO selv.

Hver side forbedrer den andre.
Den tilbakemeldingssløyfen er mye mer verdifull enn å bygge kunstige demonstrasjoner designet kun for å lykkes. Et testsystem bør ikke virke overbevisende fordi demonstrasjonen var enkel.
Det bør bli overbevisende fordi det fortsetter å finne de små tingene mennesker til slutt ville sluttet å sjekke.

The Result

softify.pro Flow — Administration har nå en dokumentert og repeterbar regresjonsprosess som COCO kan kjøre før relevante versjoner.

Testen spenner over begge de støttede databasemiljøene og applikasjonens ellevespråklige grensesnitt, samtidig som den følger applikasjonen slik en administrator ville brukt den, i stedet for å behandle hvert skjermbilde som et isolert testmål.

COCO produserer et bevisspor som viser hva som ble testet, hva som ble observert, og i hvilken rekkefølge økten fant sted.

Disse bevisene kan forbli under lokal kontroll.
Utviklere får et reproduserbart utgangspunkt når noe endres.
Menneskelige testere bruker mindre tid på å gjenta forutsigbare interaksjoner og mer tid på å undersøke situasjoner som virkelig krever skjønn.

Og softify.pro Flow får noe mer verdifullt enn en grønn PASS-indikator.

Den får bevis på at opplevelsen som loves på innloggingsskjermen, fortsetter å eksistere etter at koden bak den har endret seg.

Control. Vit hva som testes, og hold miljøet under kontroll.

Clarity. Forstå hva som skjedde uten å måtte rekonstruere en uigjennomsiktig automatiseringslogg.

Flow. Test applikasjonen som en prosess folk faktisk bruker.

Control. Clarity. Flow.

Det ble skrevet for programvaren.
Det viste seg å beskrive testfilosofien bak den like godt.