Vi er nået til de sidste par artikler i serien Ledelse inden for test. Indtil videre har vi gennemgået, hvordan man planlægger og styrer et testprojekt fra start til slut, samt mange af de involverede værktøjer og processer.
I denne artikel vil jeg diskutere kvalitetssikring af virksomhedens forretningsprocesser (EBPA) – hvad det er, og hvordan man griber det an. Vi kommer ind på:
- Hvad er kvalitetssikring af virksomhedens forretningsprocesser?
- Forståelse af systemintegration og test
- Horisontal test: E2E-testtilgangen
- Integrationsrisici og E2E-test
Der er meget at dække, så lad os komme i gang.
Hvad er kvalitetssikring af virksomhedens forretningsprocesser?
Alle organisationer, der implementerer nye systemer, har oplevet problemer, når de bruger dem for første gang. Systemer, der selv i mindre grad ikke passer med den eksisterende infrastruktur og de eksisterende forretningsprocesser, kan skabe kaos og være vanskelige at reparere.
Iterative, agile og mere samarbejdsorienterede arbejdsmetoder hjælper, men udfordringerne ved integration på tværs af virksomheden kan kun håndteres gennem en afsluttende testfase.
Vi kalder denne afsluttende fase for kvalitetssikring af virksomhedens forretningsprocesser (EBPA). Succes afhænger af en eller flere testfaser, der demonstrerer, at systemerne, forretningsprocesserne og dataene er integreret og leverer de lovede tjenester.
Der findes kun få akademiske artikler om emnet, selv om de afsluttende faser i alle store projekter er domineret af denne aktivitet. For at informere vores EBPA-strategi vil vi først se nærmere på de typer systemintegration og test, som du kommer til at arbejde med.
For projekter på virksomhedsniveau vokser kompleksiteten eksponentielt. Derfor kan valget af et databaseadministrationssystem i virksomhedsklassen være en afgørende faktor i dit arbejde med kvalitetsudvikling.
Forståelse af systemintegration og test
Vertikal integration
Fra et teknisk perspektiv repræsenterer integration forbindelsen mellem de forskellige lag i den tekniske arkitektur. Integrationstest for udviklere består for det meste af kontroller af, at data, der modtages gennem brugergrænsefladen i en opdateringstransaktion, bliver gemt korrekt i databasen.
Den anden vej kontrolleres de lagrede data, så de kan præsenteres korrekt i brugergrænsefladen, når der anmodes om dem. Forbindelserne og stierne gennem den tekniske arkitektur kan ses som vertikale stier eller vertikale integrationstest.
Horisontal integration
Slutbrugere ser ikke den tekniske arkitektur og al dens kompleksitet. De ser systemet som en række funktioner, der anvendes af forskellige brugere i det, man kan kalde en brugerrejse.
Disse brugerrejser følger stier gennem brugernes forretningsprocesser og tilgår forskellige systemer og funktioner ved hvert trin på stien ved hjælp af brugergrænsefladen.
Agile teams arbejder med historier i mindre skala og ser ikke det større epos. Udviklere kan som regel heller ikke følge og teste længere brugerrejser, fordi de ikke har miljøerne eller dataene til det. Derfor er organisationer typisk afhængige af test i større skala og teams af testere til at validere dem.
Brugerrejser omfatter naturligt forretningsprocessen og systemfunktionerne i kombination. På denne måde tester horisontale tests integrationen mellem systemerne og forretningsprocessen.
Vertikal integrationstest anlægger et mere teknisk perspektiv; horisontal testning anlægger et bruger- eller forretningsprocesperspektiv.
Lad os nu bruge disse begreber til at konstruere en model, der hjælper os med at forstå og planlægge EBPA. Vi henviser til de horisontale og vertikale integrationstilgange i modellen.
Have an account? Log In
En model for integration og testning
Integration er et begreb, der ofte misforstås. Integrationsprocessen begynder faktisk næsten samtidig med, at kodningen påbegyndes. Man kan sige, at integrationen starter, når vi har to kodelinjer — den anden kodelinje skal integreres med den første. Integration afsluttes, når al funktionel testning slutter ved brugeraccept.
Lad os fokusere på et eksempel, der bruger kommercielt tilgængelige standard- (COTS) og moduler til ressourceplanlægning i virksomheden (ERP).
Softwarevirksomheden, der udvikler COTS- eller ERP-moduler, har udført enheds- og funktionel testning. Når disse komponenter ankommer, kan man normalt antage, at de fungerer og kan integreres teknisk. Men der er altid en risiko for, at integrerede komponenter fra forskellige leverandører interagerer på uforudsete måder.
Hvis komponenterne desuden er tilpasset, vil deres adfærd ændre sig, og det vil igen sandsynligvis medføre subtile (og ikke så subtile) bivirkninger andre steder. Der er stadig behov for vertikal integration for at verificere udvekslingen af kontrol og data i teknologistakken samt horisontal integration på tværs af komponenterne og forretningsprocessen.
Vi repræsenterer de fire integrationsaktiviteter i en model med fire kvadranter og to akser. På X-aksen har vi skalaen for systemet under test – enten en enkelt komponent eller et undersystem isoleret eller de integrerede systemer i forbindelse med forretningsprocessen.
Den højre side af modellen er markeret med blåt og repræsenterer EBPA. Testning af vores system i sammenhæng med andre systemer (SIT) og forretningsprocessen (BIT) er det, vi kalder kvalitetssikring af virksomhedens forretningsprocesser.
Lad os se på de fire kvadranter én ad gangen.
Testning af moduler, funktioner eller komponenter
Modulet skal testes funktionelt, uanset om det er specialudviklet eller er en COTS-komponent. Brugeroplevelsen er altid vigtig og skal integreres med et trin eller en aktivitet i forretningsprocessen.
Integrationstest af undersystemer
Integration sker trinvist. Efterhånden som komponenter og funktioner på lavt niveau bliver tilgængelige, integreres de i det stadigt større system og testes, indtil det komplette, sammenhængende system er klar. Dette kalder vi integrationstest af undersystemer.
Systemintegrationstest (SIT)
Intet system eksisterer isoleret, så når vores system er færdigt, skal vi integrere det med andre systemer. Vi installerer vores system i et miljø med dets grænsefladesystemer og tester disse systemer, der fungerer som et »system af systemer« på tværs af grænsefladerne. Vores mål på dette trin er at håndtere de tekniske integrationsrisici, og dette kalder vi systemintegrationstest.
Forretningsintegrationstest (BIT)
Der er et afsluttende integrationstrin, som skal sikre, at de færdigbyggede systemer integreres med brugernes forretningsprocesser og (ofte manuelle) procedurer. Inklusive systemets eksterne grænseflader (hvis de ikke allerede er testet) validerer vi, at systemerne og forretningsprocesserne i samarbejde leverer sammenhængende og effektive brugerrejser, og at de håndterer og overfører data korrekt og konsekvent. Dette kalder vi normalt forretningsintegrationstest.
I resten af denne artikel vil vi i høj grad fokusere på den horisontale EBPA-side af modellen.
Relateret læsning: 10 BEDSTE VÆRKTØJER TIL TESTDATAHÅNDTERING
Horisontal testning: E2E-testtilgangen
Horisontal integration er i høj grad afhængig af det, der ofte kaldes ende-til-ende-testning (E2E).
E2E-testning er en testdesignteknik, der igangsætter en række forbundne transaktioner, som typisk spænder over flere systemer, herunder vores system(er) under test. Disse tests følger typisk brugerrejser gennem deres forretningsprocesser.
Med udgangspunkt i en model af en forretningsproces følges stier gennem processen for at skabe en nyttig række transaktioner, der simulerer den måde, brugerne vil anvende systemet på i produktionen.
Disse modeller kan være velkendte diagrammer såsom flowdiagrammer eller svømmebanediagrammer, eller de kan være mere tekniske repræsentationer såsom UML-sekvens- eller samarbejdsdiagrammer. (UML er et samlet modelleringssprog, som anvendes af mange IT-organisationer).
E2E-tests håndterer specifikke risici, som ikke nemt kan håndteres gennem tidligere testning af undersystemer eller miljøer, der i høj grad er afhængige af grænseflader erstattet af stubs og udelukkende syntetiske data.
Inden for horisontal testning suppleres E2E-testtilgangen ofte af specialiseret software. Se disse bedst vurderede teststyringsløsninger for at finde en kurateret liste over software, der kan effektivisere denne proces.
Godkendelse
Begrebet »egnethed« er relevant for integration mellem komponenter, integration mellem systemer og integration mellem systemer og forretningsprocesser.
Godkendelse baseres normalt på resultaterne af horisontale E2E-tests, fordi forretningsinteressenter kan have tillid til, at disse tests viser, hvordan det nye system passer ind i og understøtter deres arbejdsmetoder. Horisontale E2E-tests giver dem tillid til, at den leverede tjeneste vil fungere.
Godkendelsesprocessen for systemer afhænger normalt, i hvert fald delvist, af vellykket horisontal E2E-test. Det skyldes, at det kun er E2E-tests, der afprøver systemet i et realistisk miljø og simulerer realistisk brugeraktivitet.
I mange organisationer er det først muligt i de afsluttende testfaser at demonstrere, at systemerne fungerer, og det giver interessenterne tillid til, at systemet vil fungere som krævet.
Hvis du bliver bedt om at planlægge en godkendelsestest, forventer vi, at E2E-testteknikken vil spille en stor rolle i din planlægning.
Integrationsrisici og E2E-test
Som beskrevet vedrører integrationsrisici integration mellem systemer eller integration mellem systemer og forretningsprocesser.
Nogle organisationer vælger at opdele de tests, der håndterer disse to risikotyper, i systemintegrationstest (SIT) og forretningsintegrationstest (BIT). Men ofte samles risiciene og testene i en enkelt testfase, der betegnes E2E, godkendelse eller forretningstest.
Uanset hvordan testen struktureres, gør den omfattende brug af E2E-testtilgangen, der er forklaret ovenfor. I dit miljø kan de risici, du står over for, være variationer over disse temaer, og du kan være nødt til at tilpasse testmålet og din testtilgang derefter.
Listen over risici, der præsenteres her, bør kun betragtes som et udgangspunkt og som en påmindelse om, hvor du bør fokusere din testning. Det er sandsynligt, at der findes risici, som er specifikke for din organisation, branche eller teknologi, og som du skal føje til denne startliste.
I tabellen nedenfor henviser »systemer« til samlingen af integrerede systemer, der omfatter det eller de nye systemer under udvikling, andre ældre systemer eller infrastruktursystemer samt eksterne systemer, f.eks. banker eller partnerorganisationer.
| Risiko | Testmål | Testtilgang |
| Systemerne er ikke integreret (dataoverførsel). | Demonstrere, at systemerne er integreret, og at dataoverførslen udføres korrekt. | Systemintegrationstest (SIT) |
| Systemerne er ikke integreret (overførsel af kontrol). | Demonstrere, at systemerne er integreret (overførsel af kontrol med de krævede parametre udføres korrekt). | SIT |
| Grænseflader svigter, når de anvendes i en længere periode. | Demonstrere, at grænseflader kan anvendes kontinuerligt i en længere periode. | SIT (Disse kontroller kan også udføres som en del af pålideligheds- og/eller omkoblingstest) |
| Systemerne er ikke integreret (data stemmer ikke overens på tværs af grænseflader). | Demonstrere, at systemerne er integreret (data, der overføres via grænsefladen, anvendes konsekvent, f.eks. valuta, sprog, måleenheder, tidspunkter, nøjagtighed og tolerancer). | SIT |
| Systemerne er ikke synkroniseret (dataoverførsler udløses ikke, udløses på det forkerte tidspunkt eller flere gange). | Demonstrere, at dataoverførsler udløses korrekt. | SIT |
| Objekter eller entiteter, der findes i flere systemer, stemmer ikke overens på tværs af systemerne. | Demonstrere, at forretningsobjekternes tilstande er repræsenteret nøjagtigt på tværs af de systemer, der indeholder data om objekterne. | Forretningsintegrationstest (BIT) |
| Systemerne er ikke integreret med forretningsprocessen (forsyningskæden). | Demonstrere, at systemerne integreres med forretningsprocesserne og understøtter forsyningskædeprocessen. | BIT |
| Forretningsprocesser i bagvedliggende systemer understøtter ikke web- eller mobilbrugerfladerne. | Demonstrere, at forsyningskædeprocesserne fungerer i praksis og understøtter forretningsmålet. | BIT |
| Integrerede systemer, der anvendes af det samme personale, har uensartede brugergrænseflader eller adfærd ved lignende eller relaterede opgaver. | Demonstrere, at brugerne oplever ensartet adfærd på tværs af systemerne, mens de udfører lignende eller relaterede opgaver. | BIT (Disse kontroller kan også udføres under UX-kontrol) |
Bemærkninger til risikotabellen
Nogle af risiciene ovenfor kræver lidt mere forklaring.
Problemer med dataoverførsel
Data overføres ofte mellem systemer via netværk. Hvis disse overførsler køres som batchprocesser og mislykkes, eller hvis de mislykkes som en realtidsoverførsel udløst af en bruger, en forretningshændelse eller en hændelse i et andet system, vil der mangle data i målsystemet.
Fejlagtig overførsel af kontrol
En overførsel af kontrol forekommer, når en brugeraktivitet eller en systemproces overfører brugeren eller processen til en anden funktion i systemet.
Der er typisk et valg af målfunktion, og afhængigt af brugerens handling eller datainholdet i en transaktion vælges en anden rute gennem applikationen.
Fra brugerens perspektiv føres brugeren til det forkerte sted i applikationen, eller en systemproces forventer at udføre den forkerte proces og mister synkroniseringen.
Data stemmer ikke overens
Et system kan distribuere data om f.eks. penge, aktivplacering eller en fysisk mængde, som skal »gå op« på tværs af alle systemerne.
Hvis der for eksempel købes og flyttes 100 lagerenheder, som sælges, bruges i fremstillingsprocesser, erklæres defekte og returneres eller kasseres, skal antallet af enheder i hvert delsystem stemme overens med det oprindelige antal på 100.
En variation af dette problem er for eksempel de enheder, der bruges i de systemer, som indeholder data. Der skal tages højde for batchstørrelserne eller aggregeringerne af de optalte enheder, eller systemerne skal matche metriske og imperiale måleenheder og så videre.
Systemer er ikke synkroniserede
I forbindelse med ovenstående problem med dataoverførsel skal de systemprocesser, der udfører overførsler, være planlagt til at køre i den rigtige rækkefølge, udløses af processer eller personer med passende autorisation og udløses rettidigt af den relevante hændelse eller en kombination af hændelser.
Nogle batchprocesser skal køres hver time, dagligt, ugentligt, ved udgangen af måneden, kvartalet eller året og så videre, og de skal kontrolleres. Meget funktionel adfærd afhænger af den relative timing af transaktioner eller dataenes alder på tværs af systemer og skal også kontrolleres.
Objekter stemmer ikke overens
I stedet for optællinger af objekter, penge eller fysiske målinger vedrører disse risici status for objekter, der opbevares i distribuerede systemer. For eksempel bør en medarbejders status i en personaleregistrering være ensartet på tværs af systemer, der indeholder kopier af dette dataobjekt. De processer, der distribuerer ændringer i status på tværs af systemer, som indeholder kopier af det samme objekt, skal udløses, og deres handlinger skal kontrolleres.
Systemer er ikke integreret med virksomheden
Systemernes adfærd skal være synkroniseret med brugernes intentioner. Typiske problemer opstår, når systemet viser oplysninger, der er ufuldstændige, forældede eller forkerte. Den underliggende årsag er, at dataoverførsler eller synkroniseringer ikke fungerer korrekt, men disse problemer viser sig gennem brugergrænsefladen.
More Articles
Baggrundsprocesser understøtter ikke brugergrænsefladen
Denne type problem viser sig som en uoverensstemmelse mellem registreringssystemer og brugerinteraktionssystemer. Batchprocesser i baggrunden, der ikke køres ofte nok eller slet ikke, gør ikke data tilgængelige for brugerinteraktionssystemerne i brugergrænsefladen. På samme måde afspejles brugertransaktioner gennem brugerinteraktionssystemer ikke i registreringssystemerne.
Uensartede brugergrænseflader
Når en virksomhed eller tjeneste tilbydes via mobil-, web- og kioskbaserede grænseflader, opfører brugergrænsefladen sig forskelligt eller uensartet. De er muligvis alle blevet testet uafhængigt af hinanden, men deres adfærd er forskellig. For eksempel anvendes der forskellige regler til validering af input, forskellige datafelter registreres eller vises, eller rækkefølgen af input er forskellig.
Afsluttende bemærkninger
Vi har præsenteret en model for integration og test, der lægger vægt på integration på tværs af virksomheden og forretningsprocessen. E2E-tilgangen er den eneste, der kræver fuld systemintegration og baserer test på komplette brugerrejser. På den måde kan interessenter se dokumentation for, at systemerne fungerer korrekt i en realistisk sammenhæng.
Mange organisationer er afhængige af, at brugerne anvender en form for E2E-test i deres accepttest og udfører disse test manuelt. Baseret på min erfaring anbefaler jeg en mere systematisk, risikobaseret tilgang, som gør det lettere at automatisere en stor del af den arbejdskrævende testudførelse.
Efterhånden som organisationer tager agile og mere dynamiske udviklingstilgange med kontinuerlig levering i brug og giver agile teams større ansvar for at teste deres delsystemer, er det let at forsømme den efterfølgende integrations- og accepttest på tværs af virksomheden.
EBPA-tilgangen udvider, især hvis den automatiseres, den kontinuerlige integrationsproces fra delsystemet til kvalitetssikring af virksomhedens forretningsprocesser.
COTS- og ERP-pakker gør det muligt at implementere meget kapable, men komplekse systemer med en mindre udviklingsindsats, men integrationsrisiciene er lige så fremtrædende som ved udvikling af skræddersyet software.
I større miljøer bliver agile tilgange og tilgange med kontinuerlig levering stadig mere populære, så efterhånden som kompleksiteten og omfanget vokser, øges også leveringsfrekvensen og de dermed forbundne risici.
Løsningen er klar: Organisationer skal tage EBPA alvorligt. De skal forstå integrationsrisiciene og vide, hvordan test skal struktureres for at håndtere dem. Testere skal bevæge sig i retning af den moderne modelbaserede tilgang, abstrahere deres forretningsprocesser, systemer og test samt implementere testautomatisering systematisk.
Tilmeld dig nyhedsbrevet fra The QA Lead for at få besked, når nye dele af serien udkommer. Disse indlæg er uddrag fra Pauls kursus i testledelse, som vi varmt anbefaler, hvis du vil gå mere i dybden med dette og andre emner. Hvis du gør det, kan du bruge vores eksklusive kuponkode QALEADOFFER og få $60 i rabat på den fulde kursuspris!
Foreslået læsning: 10 BEDSTE VÆRKTØJER TIL TESTSTYRING MED ÅBEN KILDEKODE
