Ledarskap inom testning: kvalitetssäkring av affärsprocesser i företaget
Redaktörens anmärkning: Välkommen till serien Ledarskap inom testning från mjukvarutestningsgurun och konsulten Paul Gerrard. Serien är utformad för att hjälpa testare med några års erfarenhet – särskilt de som arbetar i agila team – att lyckas i sina roller som testledare och testchefer.
I den föregående artikeln tittade vi på verktygen du behöver för effektiv testning och samarbete. I den här artikeln diskuterar vi den avslutande testfasen och hur du kan bekräfta att dina system kommer att leverera enligt plan.
Prenumerera på nyhetsbrevet från The QA Lead för att få meddelanden när nya delar av serien publiceras. Dessa inlägg är utdrag ur Pauls kurs i Ledarskap inom testning, som vi varmt rekommenderar om du vill fördjupa dig i detta och andra ämnen. Om du gör det kan du använda vår exklusiva kupongkod QALEADOFFER för att få 60 dollar rabatt på hela kurspriset!
Vi har kommit fram till de två sista artiklarna i serien Ledarskap inom testning. Hittills har vi gått igenom hur man planerar och hanterar ett testprojekt från början till slut samt många av de verktyg och processer som ingår.
I den här artikeln vill jag diskutera säkring av affärsprocesser på företagsnivå (EBPA) – vad det är och hur man bör ta sig an det. Vi kommer att gå igenom:
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
- Vad är säkring av affärsprocesser på företagsnivå (EBPA)?
- Förstå systemintegration och testning
- Horisontell testning: E2E-testmetoden
- Integrationsrisker och E2E-testning
Det finns mycket att gå igenom, så låt oss sätta igång.
Vad är säkring av affärsprocesser på företagsnivå (EBPA)?
Alla organisationer som implementerar nya system har upplevt problem när de används för första gången. System som även bara i liten utsträckning inte överensstämmer med befintlig infrastruktur och befintliga affärsprocesser kan orsaka kaos och vara svåra att reparera.
Iterativa, agila och mer samarbetsinriktade arbetssätt hjälper, men utmaningarna med integration i hela företaget kan endast hanteras genom ett avslutande teststadium.
Vi kallar denna avslutande fas säkring av affärsprocesser på företagsnivå (EBPA). Framgången beror på en eller flera testfaser som visar att systemen, affärsprocesserna och data är integrerade och levererar de tjänster som utlovats.
Det finns få vetenskapliga artiklar om ämnet, trots att de senare faserna i alla storskaliga projekt domineras av denna aktivitet. För att ta fram vår EBPA-strategi ska vi först titta närmare på de typer av systemintegration och testning som du kommer att arbeta med.
För projekt på företagsnivå ökar komplexiteten exponentiellt. Därför kan valet av en databashanteringsprogramvara för företagsbruk bli avgörande för ditt arbete med kvalitetsutveckling.
Förstå systemintegration och testning
Vertikal integration
Ur ett tekniskt perspektiv representerar integration kopplingen mellan de olika lagren i den tekniska arkitekturen. Integrationstestning för utvecklare består huvudsakligen av kontroller som säkerställer att data som tas emot via användargränssnittet i en uppdateringstransaktion lagras korrekt i databasen.
Åt andra hållet kontrolleras den lagrade datan så att den kan presenteras korrekt i användargränssnittet när den efterfrågas. Kopplingarna och vägarna genom den tekniska arkitekturen kan ses som vertikala vägar eller vertikala integrationstester.
Horisontell integration
Slutanvändare ser inte den tekniska arkitekturen och all dess komplexitet. De ser systemet som en serie funktioner som används av olika användare i det som kan kallas en användarresa.
Dessa resor följer vägar genom användarnas affärsprocesser och får vid varje steg på vägen åtkomst till olika system och funktioner via användargränssnittet.
Agila team arbetar med berättelser i mindre skala och ser inte den större epiken. Utvecklare kan vanligtvis inte följa och testa längre användarresor ändå, eftersom de saknar miljöerna eller datan för att göra det. Därför förlitar sig organisationer vanligtvis på tester i större skala och team av testare för att validera dem.
Användarresor omfattar naturligt affärsprocessen och systemfunktionerna i kombination. På så sätt testar horisontella tester integrationen mellan systemen och affärsprocessen.
Vertikal integrationstestning utgår från ett mer tekniskt perspektiv, medan horisontell testning utgår från ett användar- eller affärsprocessperspektiv.
Låt oss nu använda dessa begrepp för att konstruera en modell som hjälper oss att förstå och planera EBPA. Vi kommer att hänvisa till de horisontella och vertikala integrationsmetoderna i modellen.
En modell för integration och testning
Integration är ett begrepp som ofta missförstås. Integrationsprocessen börjar faktiskt nästan så snart kodningen påbörjas. Man kan säga att integrationen börjar när vi har två kodrader – den andra kodraden måste integreras med den första. Integrationen avslutas när all funktionell testning avslutas vid användaracceptansen.
Låt oss fokusera på ett exempel med standardkomponenter (COTS) och moduler för affärssystem (ERP).
Programvaruföretaget som skapar COTS- eller ERP-moduler har genomfört enhets- och funktionstestning. När dessa komponenter anländer kan man vanligtvis anta att de fungerar och är tekniskt integrerbara. Men det finns alltid en risk att integrerade komponenter från olika leverantörer samverkar på oförutsedda sätt.
Om komponenterna dessutom anpassas kommer deras beteende att förändras, vilket återigen sannolikt orsakar subtila (och mindre subtila) bieffekter på andra ställen. Det finns fortfarande behov av vertikal integration för att verifiera utbytet av styrning och data i teknikstacken, samt av horisontell integration mellan komponenterna och affärsprocessen.
Vi representerar de fyra integrationsaktiviteterna i en modell med fyra kvadranter och två axlar. På X-axeln har vi skalan för systemet som testas – antingen en enskild komponent eller ett delsystem isolerat, eller de integrerade systemen i kontexten av affärsprocessen.
Den högra sidan av modellen är skuggad i blått och representerar EBPA. Att testa vårt system i kontexten av andra system (SIT) och affärsprocessen (BIT) är det vi kallar säkring av företagsaffärsprocesser.
Låt oss gå igenom de fyra kvadranterna i tur och ordning.
Testning av moduler, funktioner eller komponenter
Modulen måste funktionstestas, oavsett om den är specialbyggd eller är en COTS-komponent. Användarupplevelsen är alltid viktig och måste integreras med något steg eller någon aktivitet i affärsprocessen.
Integrationstestning av delsystem
Integration sker stegvis. När komponenter och funktioner på låg nivå blir tillgängliga integreras de i det allt större systemet och testas tills det fullständiga, sammanhängande systemet är klart. Detta kallar vi integrationstestning av delsystem.
Systemintegrationstestning (SIT)
Inget system existerar isolerat, så när vårt system är färdigt behöver vi integrera det med andra system. Vi installerar vårt system i en miljö med dess gränssnittssystem och testar dessa system när de arbetar som ett ”system av system” över dessa gränssnitt. Vårt mål i detta skede är att hantera de tekniska integrationsriskerna, och detta kallar vi systemintegrationstestning.
Affärsintegrationstestning (BIT)
Det finns ett slutligt integrationssteg som syftar till att säkerställa att de färdigbyggda systemen integreras med affärsprocesserna och användarnas (ofta manuella) rutiner för dessa system. Genom att inkludera systemets externa gränssnitt (om de inte redan har testats) validerar vi att systemen och affärsprocesserna, när de arbetar tillsammans, tillhandahåller sammanhängande och effektiva användarresor samt att de hanterar och överför data korrekt och konsekvent. Detta kallar vi normalt affärsintegrationstestning.
Under resten av denna artikel kommer vi att fokusera mycket på modellens horisontella EBPA-sida.
Relaterad läsning: 10 BÄSTA VERKTYG FÖR TESTDATAHANTERING
Horisontell testning: E2E-testmetoden
Horisontell integration är i hög grad beroende av det som ofta kallas testning från början till slut (E2E).
E2E-testning är en testdesignteknik som anropar en serie sammanlänkade transaktioner, vanligtvis över flera system, inklusive våra system under testning. Dessa tester följer vanligtvis användarresor genom deras affärsprocesser.
Utifrån en modell av en affärsprocess följer man vägar genom processen för att skapa en användbar serie transaktioner som simulerar hur användarna kommer att använda systemet i produktion.
Dessa modeller kan vara välbekanta diagram, till exempel flödesscheman eller simbanediagram, eller mer tekniska representationer, till exempel UML-sekvensdiagram eller samarbetsdiagram. (UML är det enhetliga modelleringsspråket som används av många IT-organisationer.)
E2E-tester hanterar specifika risker som inte enkelt kan hanteras genom tidigare testning av delsystem eller miljöer som är starkt beroende av stubbade gränssnitt och helt syntetiska data.
Inom horisontell testning kompletteras E2E-testmetoden ofta av specialiserad programvara. För en utvald lista över programvara som kan effektivisera denna process kan du läsa om dessa högt rankade lösningar för testhantering
Godkännande
Begreppet ”lämplighet” är relevant för komponent–komponent-integration, system–system-integration och integration mellan system och affärsprocesser.
Godkännande baseras normalt på resultaten från horisontella E2E-tester, eftersom verksamhetens intressenter kan lita på att dessa tester visar hur det nya systemet passar in i och stöder deras arbetssätt. Horisontella E2E-tester ger dem förtroende för att den levererade tjänsten kommer att fungera.
Godkännandeprocessen för system är vanligtvis, åtminstone delvis, beroende av framgångsrika horisontella E2E-tester. Detta beror på att endast E2E-tester testar systemet i en realistisk miljö och simulerar realistisk användaraktivitet.
I många organisationer är det endast möjligt att i testningens slutskeden demonstrera att systemen fungerar, vilket ger intressenterna förtroende för att systemet kommer att fungera som krävs.
Om du ombeds att planera ett godkännandetest förväntar vi oss att E2E-testtekniken kommer att spela en stor roll i din planering.
Integrationsrisker och E2E-testning
Som nämnts gäller integrationsrisker integration mellan system eller integration mellan system och affärsprocesser.
Vissa organisationer väljer att dela upp testerna som hanterar dessa två risktyper i systemintegrationstestning (SIT) och affärsintegrationstestning (BIT). Ofta slås dock riskerna och testerna ihop till ett enda teststeg som benämns E2E, godkännande eller verksamhetstestning.
Oavsett hur testningen struktureras använder den i stor utsträckning den E2E-testmetod som förklarades ovan. I din miljö kan de risker du möter vara variationer på dessa teman, och du kan behöva anpassa testmålet och din testmetod därefter.
Listan över risker som presenteras här bör endast betraktas som en utgångspunkt och som en påminnelse om var du bör fokusera din testning. Det är sannolikt att det finns risker som är specifika för din organisation, bransch eller teknik och som du behöver lägga till i denna utgångspunkt.
I tabellen nedan avser ”system” den samling integrerade system som består av det nya systemet eller de nya systemen under utveckling, andra äldre system eller infrastruktursystem samt externa system, till exempel banker eller partnerorganisationer.
| Risk | Testmål | Testmetod |
| Systemen är inte integrerade (dataöverföring). | Demonstrera att systemen är integrerade och genomför dataöverföringen korrekt. | Systemintegrationstest (SIT) |
| Systemen är inte integrerade (överföring av kontroll). | Demonstrera att systemen är integrerade (överföringen av kontroll med nödvändiga parametrar genomförs korrekt). | SIT |
| Gränssnitt slutar fungera när de används under en längre period. | Demonstrera att gränssnitten kan användas kontinuerligt under en längre period. | SIT (Dessa kontroller kan också genomföras som en del av tillförlitlighets- och/eller reservdriftstestning) |
| Systemen är inte integrerade (data överensstämmer inte mellan gränssnitten). | Demonstrera att systemen är integrerade (data som överförs via gränssnittet används konsekvent, till exempel valuta, språk, måttenheter, tidpunkter, noggrannhet och toleranser). | SIT |
| Systemen är inte synkroniserade (dataöverföringar utlöses inte, utlöses vid fel tidpunkt eller flera gånger). | Demonstrera att dataöverföringar utlöses korrekt. | SIT |
| Objekt eller entiteter som finns i flera system överensstämmer inte mellan systemen. | Demonstrera att tillstånden för affärsobjekt återges korrekt i de system som innehåller data om objekten. | Affärsintegrationstest (BIT) |
| Systemen är inte integrerade med affärsprocessen (leveranskedjan). | Demonstrera att systemen integreras med affärsprocesserna och stöder leveranskedjeprocessen. | BIT |
| Affärsprocesserna i bakänden stöder inte webb- eller mobilgränssnitten. | Demonstrera att leveranskedjeprocesserna är genomförbara och stöder verksamhetens mål. | BIT |
| Integrerade system som används av samma personal har inkonsekventa användargränssnitt eller beteenden för liknande eller relaterade uppgifter. | Demonstrera att användarna upplever ett konsekvent beteende mellan systemen när de utför liknande eller relaterade uppgifter. | BIT (Dessa kontroller kan också genomföras under UX-kontroll) |
Kommentarer till risktabellen
Vissa av riskerna ovan behöver förklaras lite mer.
Problem med dataöverföring
Ofta överförs data mellan system via nätverk. Om dessa överföringar körs som batchprocesser och misslyckas, eller misslyckas som en realtidsöverföring som utlöses av en användare, verksamheten eller en annan systemhändelse, kommer data att saknas i målsystemet.
Felaktig överföring av kontroll
En överföring av kontroll innebär att en användaraktivitet eller systemprocess överför användaren eller processen till en annan funktion i systemet.
Vanligtvis finns det ett val av målfunktion, och beroende på användarens åtgärd eller datainnehållet i en transaktion görs ett val av en annan väg genom applikationen.
Ur användarens perspektiv förs användaren till fel plats i applikationen, eller så förväntas en systemprocess utföra fel process och förlorar synkroniseringen.
Data överensstämmer inte
Ett system kan distribuera data som rör exempelvis pengar, tillgångars placering eller någon fysisk mängd som måste ”gå ihop” i alla system.
Om till exempel 100 lagerartiklar köps in och flyttas, säljs, används i tillverkningsprocesser, bedöms vara felaktiga och returneras eller kasseras, måste antalet artiklar som finns i varje delsystem stämma överens med det ursprungliga antalet på 100.
En variant av detta problem är till exempel de enheter som används i systemen som lagrar data. Batchstorlekarna eller aggregeringarna av det som räknas måste beaktas, eller så måste systemen överensstämma med metriska och brittiska måttenheter, och så vidare.
Systemen är inte synkroniserade
Detta är relaterat till problemet med dataöverföring ovan. De systemprocesser som utför överföringar schemaläggs så att de körs i rätt ordningsföljd, utlöses av korrekt auktoriserade processer eller personer och utlöses i rätt tid samt av rätt händelse eller en sammanvägning av händelser.
Vissa batchprocesser måste köras varje timme, dagligen, veckovis, i slutet av månaden, kvartalet eller året och så vidare, och måste kontrolleras. Mycket funktionellt beteende beror på den relativa tidpunkten för transaktioner eller datats ålder i olika system och måste också kontrolleras.
Objekten stämmer inte överens
I stället för antal objekt, pengar eller fysiska mått gäller dessa risker statusen för objekt som lagras i distribuerade system. Till exempel bör statusen för en anställd i en personalpost vara konsekvent mellan system som innehåller kopior av detta dataobjekt. Processerna som distribuerar statusändringar mellan system som innehåller kopior av samma objekt måste utlösas och deras åtgärder kontrolleras.
Systemen är inte integrerade med verksamheten
Systemens beteende måste synkroniseras med användarnas avsikter. Typiska problem uppstår när systemet visar information som är ofullständig, inaktuell eller felaktig. Den bakomliggande orsaken är att dataöverföringar eller synkroniseringar inte fungerar korrekt, men dessa problem visar sig via användargränssnittet.
Bakgrundsprocesser stöder inte användargränssnittet
Den här typen av problem visar sig som en inkonsekvens mellan informationssystem och system för användarinteraktion. Batchprocesser i bakgrunden som inte körs tillräckligt ofta, eller inte alls, gör inte data tillgängliga för användargränssnitten. På samma sätt återspeglas inte användartransaktioner genom användargränssnitten i informationssystemen.
Inkonsekventa användargränssnitt
När en verksamhet eller tjänst erbjuds via mobila gränssnitt, webbgränssnitt och kioskbaserade gränssnitt beter sig användargränssnittet på olika eller inkonsekventa sätt. Alla kan ha testats separat, men deras beteende skiljer sig åt. Till exempel tillämpas olika regler för validering av indata, olika datafält samlas in eller visas, eller så skiljer sig ordningsföljden för indata.
Avslutande tankar
Vi har presenterat en modell för integration och testning som ger företagsövergripande integration och affärsprocessen en framträdande roll. E2E-metoden är den enda som kräver fullständig systemintegration och baserar tester på fullständiga användarresor. På så sätt kan intressenter se bevis på att systemen fungerar korrekt i ett realistiskt sammanhang.
Många organisationer förlitar sig på att användare tillämpar en form av E2E-testning i sina acceptanstester och genomför dessa tester manuellt. Utifrån mina erfarenheter förespråkar jag en mer systematisk, riskbaserad metod som gör det enklare att automatisera en stor del av det arbetsintensiva testgenomförandet.
När organisationer inför agila och mer dynamiska utvecklingsmetoder för kontinuerlig leverans, där de agila teamen får större ansvar för att testa sina delsystem, är det lätt att försumma den senare företagsövergripande integrations- och acceptanstestningen.
EBPA-metoden, särskilt om den automatiseras, utvidgar regimen för kontinuerlig integration från delsystem till kvalitetssäkring av företagsövergripande affärsprocesser.
COTS- och ERP-paket gör det möjligt att implementera mycket kapabla men komplexa system med mindre utvecklingsarbete, men integrationsriskerna är lika framträdande som vid utveckling av skräddarsydd programvara.
I större miljöer blir agila metoder och metoder för kontinuerlig leverans allt populärare, så när komplexiteten och omfattningen ökar ökar även leveransfrekvensen och de tillhörande riskerna.
Lösningen är tydlig: organisationer måste ta EBPA på allvar. De behöver förstå integrationsriskerna och hur testningen ska struktureras för att hantera dem. Testare måste gå mot den moderna modellbaserade metoden, abstrahera sina affärsprocesser, system och tester samt implementera testautomatisering på ett systematiskt sätt.
Anmäl dig till nyhetsbrevet från The QA Lead för att få meddelanden när nya delar av serien publiceras. Dessa inlägg är utdrag ur Pauls kurs Ledarskap inom testning, som vi varmt rekommenderar för en djupare genomgång av detta och andra ämnen. Om du gör det kan du använda vår exklusiva kupongkod QALEADOFFER för att få $60 rabatt på ordinarie kurspris!
Rekommenderad läsning: 10 BÄSTA TESTHANTERINGSVERKTYGEN MED ÖPPEN KÄLLKOD
