Vi har kommet til de to siste artiklene i serien Ledelse i testing. Så langt har vi gått gjennom hvordan du planlegger og styrer et testprosjekt fra start til slutt, samt mange av verktøyene og prosessene som inngår.
I denne artikkelen vil jeg diskutere kvalitetssikring av forretningsprosesser i virksomheten (EBPA) – hva det er, og hvordan du kan gå frem. Vi skal dekke:
- Hva er kvalitetssikring av forretningsprosesser i virksomheten?
- Forstå systemintegrasjon og testing
- Horisontal testing: E2E-testtilnærmingen
- Integrasjonsrisikoer og E2E-testing
Det er mye å ta for seg, så la oss komme i gang.
Hva er kvalitetssikring av forretningsprosesser i virksomheten?
Alle organisasjoner som implementerer nye systemer, har opplevd problemer når de brukes for første gang. Systemer som i liten grad samsvarer med eksisterende infrastruktur og forretningsprosesser, kan skape kaos og være vanskelige å reparere.
Iterative, smidige og mer samarbeidsorienterte arbeidsmetoder hjelper, men utfordringene ved integrasjon på tvers av virksomheten kan bare håndteres gjennom en avsluttende testfase.
Vi kaller denne avsluttende fasen kvalitetssikring av forretningsprosesser i virksomheten (EBPA). Suksess avhenger av én eller flere testfaser som viser at systemene, forretningsprosessene og dataene er integrert og leverer tjenestene som er lovet.
Det finnes få vitenskapelige artikler om temaet, selv om de siste fasene i alle store prosjekter domineres av denne aktiviteten. For å utforme EBPA-strategien vår skal vi først se nærmere på typene systemintegrasjon og testing du vil arbeide med.
I prosjekter på virksomhetsnivå øker kompleksiteten eksponentielt. Derfor kan det å velge en databaseadministrasjonsprogramvare for virksomheter bli en avgjørende faktor i arbeidet med kvalitetsutvikling.
Forstå systemintegrasjon og testing
Vertikal integrasjon
Fra et teknisk perspektiv representerer integrasjon forbindelsen mellom de ulike lagene i den tekniske arkitekturen. Integrasjonstesting for utviklere består for det meste av kontroller av at data som mottas gjennom brukergrensesnittet i en oppdateringstransaksjon, lagres korrekt i databasen.
I motsatt retning kontrolleres dataene som er lagret, slik at de kan presenteres nøyaktig i brukergrensesnittet når de etterspørres. Forbindelsene og banene gjennom den tekniske arkitekturen kan ses på som vertikale baner eller vertikale integrasjonstester.
Horisontal integrasjon
Sluttbrukere ser ikke den tekniske arkitekturen og all kompleksiteten i den. De ser systemet som en rekke funksjoner som brukes av ulike brukere i det som kan kalles en brukerreise.
Disse reisene følger baner i brukernes forretningsprosesser og gir tilgang til ulike systemer og funksjoner ved hvert trinn på veien ved hjelp av brukergrensesnittet.
Smidige team arbeider med historier i mindre skala og ser ikke det større eposet. Utviklere kan vanligvis heller ikke følge og teste lengre brukerreiser fordi de ikke har miljøene eller dataene som trengs. Derfor er organisasjoner vanligvis avhengige av tester i større skala og team av testere for å validere dem.
Brukerreiser dekker naturlig nok forretningsprosessen og systemfunksjonene i kombinasjon. På denne måten tester horisontale tester integrasjonen mellom systemene og forretningsprosessen.
Vertikal integrasjonstesting anlegger et mer teknisk perspektiv; horisontal testing anlegger et bruker- eller forretningsprosessperspektiv.
La oss nå bruke disse konseptene til å konstruere en modell som vil hjelpe oss med å forstå og planlegge EBPA. Vi vil vise til de horisontale og vertikale integrasjonstilnærmingene i modellen.
Have an account? Log In
En modell for integrasjon og testing
Integrasjon er et konsept som ofte misforstås. Integrasjonsprosessen starter faktisk nesten så snart kodingen begynner. Man kan si at integrasjonen starter når vi har to kodelinjer — den andre kodelinjen må integreres med den første. Integrasjonen avsluttes når all funksjonell testing avsluttes ved brukeraksept.
La oss fokusere på et eksempel som bruker kommersielt tilgjengelige standardmoduler (COTS) og virksomhetsressursplanleggingsmoduler (ERP).
Programvareselskapet som lager COTS- eller ERP-moduler, har utført enhets- og funksjonell testing. Når disse komponentene ankommer, kan man vanligvis anta at de fungerer og kan integreres teknisk. Men det er alltid en risiko for at integrerte komponenter fra ulike leverandører samhandler på uforutsette måter.
Hvis komponentene tilpasses, vil dessuten atferden deres endres, og dette vil igjen sannsynligvis føre til subtile (og ikke så subtile) bieffekter andre steder. Det er fortsatt behov for vertikal integrasjon for å verifisere utvekslingen av kontroll og data i teknologistakken, samt horisontal integrasjon på tvers av komponentene og forretningsprosessen.
Vi representerer de fire integrasjonsaktivitetene i en modell med fire kvadranter og to akser. På X-aksen har vi skalaen til systemet som testes – enten én enkelt komponent eller ett delsystem isolert, eller de integrerte systemene i konteksten av forretningsprosessen.
Den høyre siden av modellen er skyggelagt blå og representerer EBPA. Testing av systemet vårt i konteksten av andre systemer (SIT) og forretningsprosessen (BIT) er det vi kaller Enterprise Business Process Assurance.
La oss se på de fire kvadrantene etter tur.
Testing av moduler, funksjoner eller komponenter
Modulen må testes funksjonelt, enten den er spesialutviklet eller er en COTS-komponent. Brukeropplevelsen er alltid viktig og må integreres med et trinn eller en aktivitet i forretningsprosessen.
Integrasjonstesting av delsystemer
Integrasjon skjer trinnvis. Etter hvert som komponenter og funksjoner på lavt nivå blir tilgjengelige, integreres de i det stadig større systemet og testes frem til det komplette, sammenhengende systemet er klart. Dette kaller vi integrasjonstesting av delsystemer.
Systemintegrasjonstesting (SIT)
Ingen systemer eksisterer isolert, så når systemet vårt er komplett, må vi integrere det med andre systemer. Vi installerer systemet vårt i et miljø med systemene det kommuniserer med, og tester disse systemene når de fungerer som et «system av systemer» på tvers av disse grensesnittene. Målet vårt på dette stadiet er å håndtere de tekniske risikoene ved integrasjon, og dette kaller vi systemintegrasjonstesting.
Forretningsintegrasjonstesting (BIT)
Det finnes et siste integrasjonsstadium som skal sikre at systemene slik de er bygget, integreres med forretningsprosessene og (ofte manuelle) prosedyrene til brukerne av disse systemene. Vi validerer, inkludert systemets eksterne grensesnitt (hvis de ikke allerede er testet), at systemene og forretningsprosessene, når de samarbeider, gir sammenhengende og effektive brukerreiser, og at de håndterer og overfører data korrekt og konsekvent. Vanligvis kaller vi dette forretningsintegrasjonstesting.
I resten av denne artikkelen vil vi i stor grad fokusere på den horisontale EBPA-siden av modellen.
Relatert lesning: 10 BESTE VERKTØY FOR TESTDATAADMINISTRASJON
Horisontal testing: E2E-testtilnærmingen
Horisontal integrasjon er i størst grad avhengig av det som ofte kalles ende-til-ende-testing (E2E).
E2E-testing er en testdesignteknikk som starter en serie sammenkoblede transaksjoner, vanligvis på tvers av flere systemer, inkludert systemet eller systemene våre som testes. Disse testene følger gjerne brukerreiser gjennom forretningsprosessene.
Med utgangspunkt i en modell av en forretningsprosess spores stier gjennom prosessen for å lage en nyttig serie transaksjoner som simulerer måten brukerne vil bruke systemet på i produksjon.
Disse modellene kan være kjente diagrammer, for eksempel flytskjemaer eller svømmebanediagrammer, eller de kan være mer tekniske representasjoner, som UML-sekvens- eller samarbeidsdiagrammer. (UML er et enhetlig modelleringsspråk som brukes av mange IT-organisasjoner.)
E2E-tester håndterer spesifikke risikoer som det er vanskelig å håndtere gjennom tidligere testing av delsystemer eller miljøer som i stor grad er avhengige av stubber for grensesnitt og rent syntetiske data.
Innen horisontal testing suppleres E2E-testtilnærmingen ofte av spesialisert programvare. Du finner en kuratert liste over programvare som kan effektivisere denne prosessen, i disse høyt rangerte testadministrasjonsløsningene
Aksept
Begrepet «samsvar» er passende for integrasjon mellom komponenter, integrasjon mellom systemer og integrasjon mellom systemer og forretningsprosesser.
Aksept baseres normalt på resultatene fra horisontale E2E-tester fordi forretningsinteressenter kan ha tillit til at disse testene viser hvordan det nye systemet passer inn i og støtter arbeidsmåtene deres. Horisontale E2E-tester gir dem trygghet for at den leverte tjenesten vil fungere.
Akseptprosessen for systemer avhenger vanligvis, i hvert fall delvis, av vellykket horisontal E2E-testing. Dette skyldes at det bare er E2E-tester som utøver systemet i et realistisk miljø og simulerer realistisk brukeraktivitet.
I mange organisasjoner er det først i de avsluttende testfasene mulig å demonstrere at systemene fungerer, og dette gir interessentene trygghet for at systemet vil fungere som krevd.
Hvis du blir bedt om å planlegge en akseptansetest, forventer vi at E2E-testteknikken vil spille en stor rolle i planleggingen din.
Integrasjonsrisikoer og E2E-testing
Som omtalt gjelder integrasjonsrisikoer integrasjon mellom systemer eller integrasjon mellom systemer og forretningsprosesser.
Noen organisasjoner velger å dele testene som håndterer disse to risikotypene, inn i systemintegrasjonstesting (SIT) og forretningsintegrasjonstesting (BIT). Men ofte slås risikoene og testene sammen til én enkelt testfase kalt E2E, akseptansetesting eller forretningstesting.
Uansett hvordan testingen struktureres, benytter den i stor grad E2E-testtilnærmingen som er forklart ovenfor. I ditt miljø kan risikoene du står overfor være varianter av disse temaene, og du kan måtte justere testmålet og testtilnærmingen deretter.
Listen over risikoer som presenteres her, bør bare betraktes som et utgangspunkt og som en påminnelse om hvor du bør rette oppmerksomheten i testingen. Det er sannsynlig at det finnes risikoer som er spesifikke for organisasjonen, bransjen eller teknologien din, og som du må legge til i denne startlisten.
I tabellen nedenfor viser «systemer» til samlingen av integrerte systemer som omfatter det nye systemet eller systemene som er under utvikling, andre eldre systemer eller infrastruktursystemer og eksterne systemer, for eksempel banker eller samarbeidende organisasjoner.
| Risiko | Testmål | Testtilnærming |
| Systemene er ikke integrert (dataoverføring). | Demonstrere at systemene er integrert og utfører dataoverføring korrekt. | Systemintegrasjonstest (SIT) |
| Systemene er ikke integrert (overføring av kontroll). | Demonstrere at systemene er integrert (overføring av kontroll med nødvendige parametere utføres korrekt). | SIT |
| Grensesnitt svikter når de brukes over en lengre periode. | Demonstrere at grensesnittene kan brukes kontinuerlig over en lengre periode. | SIT (Disse kontrollene kan også utføres som en del av pålitelighets- og/eller reserveløsningstesting) |
| Systemene er ikke integrert (data stemmer ikke overens på tvers av grensesnittene). | Demonstrere at systemene er integrert (data som overføres via grensesnittet, brukes konsekvent, for eksempel valuta, språk, måleenheter, tidspunkter, nøyaktighet og toleranser). | SIT |
| Systemene er ikke synkronisert (dataoverføringer utløses ikke, utløses på feil tidspunkt eller flere ganger). | Demonstrere at dataoverføringer utløses korrekt. | SIT |
| Objekter eller enheter som finnes i flere systemer, stemmer ikke overens på tvers av systemene. | Demonstrere at tilstandene til forretningsobjekter er nøyaktig representert på tvers av systemene som lagrer data om objektene. | Forretningsintegrasjonstest (BIT) |
| Systemene er ikke integrert med forretningsprosessen (forsyningskjeden). | Demonstrere at systemene integreres med forretningsprosesser og støtter forsyningskjedeprosessen. | BIT |
| Forretningsprosessene i bakenden støtter ikke nett- eller mobilgrensesnittene. | Demonstrere at forsyningskjedeprosessene er gjennomførbare og støtter forretningsmålet. | BIT |
| Integrerte systemer som brukes av det samme personalet, har inkonsistente brukergrensesnitt eller ulik atferd for lignende eller relaterte oppgaver. | Demonstrere at brukerne opplever konsekvent atferd på tvers av systemene mens de utfører lignende eller relaterte oppgaver. | BIT (Disse kontrollene kan også utføres under UX-kontroll) |
Merknader til risikotabellen
Noen av risikoene ovenfor trenger litt mer forklaring.
Problemer med dataoverføring
Ofte overføres data mellom systemer via nettverk. Hvis disse overføringene kjøres som satsvise prosesser og mislykkes, eller mislykkes som en sanntidsoverføring utløst av en bruker, virksomhet eller annen systemhendelse, vil data mangle i målsystemet.
Feil ved overføring av kontroll
En overføring av kontroll skjer når en brukeraktivitet eller systemprosess overfører brukeren eller prosessen til en annen funksjon i systemet.
Vanligvis finnes det et valg av målfunksjon, og avhengig av brukerhandlingen eller datainnholdet i en transaksjon velges en annen rute gjennom applikasjonen.
Fra brukerens perspektiv blir brukeren ført til feil sted i applikasjonen, eller en systemprosess forventer å utføre feil prosess og mister synkroniseringen.
Data stemmer ikke overens
Et system kan distribuere data som gjelder for eksempel penger, plasseringen av eiendeler eller en fysisk mengde som må «gå opp» på tvers av alle systemene.
For eksempel, når 100 lagerbeholdningsenheter kjøpes inn og flyttes, selges, brukes i produksjonsprosesser, anses som defekte og returneres eller kasseres, må antallet enheter som finnes i hvert delsystem, stemme overens med det opprinnelige antallet på 100.
En variant av dette problemet gjelder for eksempel enhetene som brukes i systemene som inneholder data. Partistørrelsene eller aggregeringene av det som telles, må tas med i beregningen, eller systemene må samsvare når det gjelder metriske og britiske måleenheter, og så videre.
Systemer som ikke er synkronisert
I tilknytning til dataoverføringsproblemet ovenfor må systemprosessene som utfører overføringer, planlegges til å kjøre i riktig rekkefølge, utløses av prosesser eller personer med riktig autorisasjon og utløses i tide og av riktig hendelse eller kombinasjon av hendelser.
Enkelte batchprosesser må kjøres hver time, daglig, ukentlig, ved slutten av måneden, kvartalet eller året og så videre, og må kontrolleres. Mye funksjonell atferd avhenger av den relative timingen for transaksjoner eller alderen på data på tvers av systemer, og dette må også kontrolleres.
Objekter stemmer ikke overens
I stedet for antall objekter, penger eller fysiske målinger gjelder disse risikoene statusen til objekter som oppbevares i distribuerte systemer. For eksempel bør statusen til en ansatt i en personaloppføring være konsekvent på tvers av systemer som inneholder kopier av dette dataobjektet. Prosessene som distribuerer statusendringer på tvers av systemer som inneholder kopier av det samme objektet, må utløses, og handlingene deres må kontrolleres.
More Articles
Systemer som ikke er integrert med virksomheten
Systemenes atferd må synkroniseres med brukernes hensikter. Typiske problemer oppstår når systemet viser informasjon som er ufullstendig, utdatert eller feil. Den underliggende årsaken er at dataoverføringer eller synkroniseringer ikke fungerer som de skal, men problemene viser seg gjennom brukergrensesnittet.
Bakendeprosesser støtter ikke forenden
Denne typen problem viser seg som en inkonsekvens mellom registreringssystemer og engasjementssystemer. Batchprosesser i bakenden som ikke kjøres ofte nok, eller i det hele tatt, gjør ikke data tilgjengelig for engasjementssystemer i forenden. På samme måte gjenspeiles ikke brukertransaksjoner gjennom engasjementssystemer i registreringssystemene.
Avsluttende tanker
Vi har presentert en modell for integrasjon og testing som legger vekt på integrasjon på tvers av hele virksomheten og forretningsprosessen. E2E-tilnærmingen er den eneste som krever fullstendig systemintegrasjon og baserer testene på komplette brukerreiser. På denne måten kan interessenter se dokumentasjon på at systemene fungerer korrekt i en realistisk kontekst.
Mange organisasjoner er avhengige av at brukerne gjennomfører en form for E2E-testing i akseptansetestene sine og utfører disse testene manuelt. Basert på erfaring anbefaler jeg en mer systematisk, risikobasert tilnærming som gjør det enklere å automatisere mye av den arbeidsintensive testgjennomføringen.
Etter hvert som organisasjoner tar i bruk smidige og mer dynamiske utviklingstilnærminger basert på kontinuerlig levering, og gir smidige team mer ansvar for testing av delsystemene sine, er det lett å forsømme senere integrasjons- og akseptansetesting på tvers av hele virksomheten.
EBPA-tilnærmingen, særlig hvis den automatiseres, utvider regimet for kontinuerlig integrasjon fra delsystemnivå til kvalitetssikring av forretningsprosesser på virksomhetsnivå.
COTS- og ERP-pakker gjør det mulig å implementere svært funksjonsrike, men komplekse systemer med mindre utviklingsinnsats, men integrasjonsrisikoen er like fremtredende som ved utvikling av skreddersydd programvare.
I større miljøer blir smidige tilnærminger og tilnærminger basert på kontinuerlig levering stadig mer populære. Når kompleksiteten og omfanget øker, øker derfor også leveringsfrekvensen og den tilknyttede risikoen.
Løsningen er klar: Organisasjoner må ta EBPA på alvor. De må forstå integrasjonsrisikoene og hvordan testingen skal struktureres for å håndtere dem. Testere må bevege seg mot den moderne modellbaserte tilnærmingen, abstrahere forretningsprosessene, systemene og testene sine og implementere testautomatisering på en systematisk måte.
Meld deg på nyhetsbrevet til The QA Lead for å få beskjed når nye deler av serien publiseres. Disse innleggene er utdrag fra Pauls Leadership In Test-kurs, som vi på det varmeste anbefaler for å gå dypere inn i dette og andre emner. Hvis du gjør det, kan du bruke vår eksklusive rabattkode QALEADOFFER og få $60 rabatt på full kurspris!
Anbefalt lesning: DE 10 BESTE ÅPENKILDEVERKTØYENE FOR TESTHÅNDTERING
