dette er en Test Management Tutorial til test. Det inkluderer Teststyringsfaser, værktøjer og Teststyring Vs organisationsstruktur:
Teststyring er processen med at styre alle testrelaterede aktiviteter, dokumenter og andet relateret arbejde. Organisationsstrukturer henviser til et hierarki af teams eller medarbejdere, der arbejder på bestemte projekter.
tror du organisationsstruktur påvirker teststyring?
hvis dit svar er nej, vil vi se hvorfor? Hvis ja, lad os se, hvordan det påvirker. For at finde forholdet mellem disse to er vi nødt til at forstå disse emner klart og derefter undersøge forholdet mellem testledelse og organisationsstruktur.
Introduktion til Test Management
Test Management betyder styring af hele processen med programmel test for et bestemt projekt. Teststyringsprocessen anvendes på hele programudviklingens livscyklus. Derfor bør teststyringsprocessen ideelt set også starte, så snart programmeludviklingsprocessen starter.
Test Manager havde følgende ansvarsområder-
- Testlederen skal sikre konsistens og kvalitet af disse arbejdsprodukter.
- Arbejd med Testanalytiker og teknisk Testanalytiker for at vælge og tilpasse den relevante skabelon.
- Arbejd med Testanalytiker og teknisk Testanalytiker for at etablere standarder for disse produkter, som niveauer af detaljeret grad.
- gennemgå arbejdsprodukterne ved hjælp af passende teknikker.
Teststyringskomponenter
Teststyring er opdelt i 5 dele for bedre forståelse:
- Testdokumentation
- Testestimering
- testmålinger
- måling af Testfremskridt
- målinger til overvågning af testens livscyklus
#1) Testdokumentation
der er tre typer Testdokumentation, der er angivet nedenfor:
- Testpolitik
- teststrategi
- Master testplan
#1) Testpolitik:
- opsummerer værdi, som organisationen stammer fra test.
- definerer testpolitikker.
- beskriver, hvordan man vurderer effektiviteten af testen.
- skitserer testprocessen.
- Angiv, hvordan organisationen vil forbedre testprocessen?
#2) teststrategi:
- beskriver de generelle testmetoder, der bruges til at styre projekt-og Produktrisici.
- Analytiske Strategier: Ligesom Risikobaseret Test.
- Modelbaseret Strategi: Som en operationel profil, hvor testteamet udvikler en model baseret på faktiske og accepterede situationer med miljø, input og forhold.
- metodologisk strategi: kvalitetsegenskaber, hvor testteamet bruger et sæt testbetingelser, tjekliste eller indsamling af generaliserede, logiske tests.
- proces eller standard-kompatible teknikker: følger et sæt af processen som SCRUM/Agile.
- reaktive strategier: brug af defektbaserede angreb som sonderende test.
- Rådgivende Strategi: Ligesom brugerstyret test, hvor testteamet er afhængig af input fra en eller flere interessenter for at bestemme testbetingelser som outsourcet kompatibilitetstest.
- beskriver også:
- Integrationsprocedurer
- testspecifikationsteknikker
- testens uafhængighed
- obligatoriske og valgfri standarder
- testmiljø
- værktøjer
- genbrug af programmelprodukter
- retesting og regression.
#3) Master Test Plan:
- det dækker alle testopgaver, der skal udføres.
- den diskuterer, hvordan test vil implementere teststrategi og-politik.
- hvis noget ikke er beskrevet, skal testplanen beskrive hvorfor og afbødningsplanen for det.
- Testplanens indhold er:
- emner, der skal testes
- kvalitetsegenskaber, der skal testes.
- tidsplan
- Udførelsescyklus
- Fejlvariabler
- testelementer i omfang
- Udgangskriterier
- projektrisici
- samlet styring af testindsats,
- roller og ansvar
- input og output
#2) Prøvningsestimering
generelle punkter:
- er en ledelsesaktivitet
- den er baseret på erfaring.
- det giver et specifikt og detaljeret katalog over omkostninger, ressourcer, opgaver og personer.
- estimering, når den er udarbejdet, skal leveres til ledelsen sammen med begrundelsen.
- det endelige skøn repræsenterer den bedst mulige balance mellem organisatoriske og projektmål.
- estimatet er baseret på tilgængelige oplysninger på det tidspunkt, det blev udarbejdet.
- for at forblive nøjagtige bør estimater opdateres for at afspejle nye og ændrede oplysninger.
faktorer, der påvirker Testestimering:
- påkrævet kvalitetsniveau
- systemets størrelse
- Historiske data
- Procesfaktorer som Strategi, udvikling og livscyklus
- materielle faktorer som testmiljø, automatisering, værktøjer og data
- People factor
- procesens kompleksitet
- træning og KT(videnoverførsel)
- assimilering og udvikling af nye værktøjer og teknologi, proces eller teknikker.
- kravet om en højere grad af den detaljerede Testspecifikation.
- Timing af komponent ankomst
- testdata.
Gæt:
- arbejde opdeling struktur
- Team Estimation session
- Tester – Udvikler ratio
- organisation historie
- funktion punkt analyse, LOC.
Test estimering er yderligere forklaret senere i tutorial.
#3) Test Metrics
- hvad bliver målt, betragtes som gjort?
- hvad måler ikke, er let at blive ignoreret?
- et begrænset sæt nyttige målinger bør defineres.
- kun disse målinger skal defineres, hvis fortolkning er aftalt af alle.
- rapportering og sammenlægning af metrics bør automatiseres.
- lederen skal validere oplysningerne i metrisk.
projekt Metric: % af pass, mislykkes udført osv.
produkt metrisk:
- attributter for produktet
- Defektdensitet
Process Metric: måler evnen til at teste som % af defekten.
mennesker: individets evne.
Test Fremskridt Metrisk:
- antallet af testbetingelser/sager, planlagt vs udført.
- Total defekt kategoriseret efter sværhedsgrad, prioritet, nuværende tilstand og effekt delsystem.
- antallet af ændringer, der kræves, accepteret, Bygge og testet.
- planlagt vs faktiske omkostninger.
- planlagt vs faktisk varighed
- planlagt vs faktisk test milepæl.
- Produktkvalitetsrisikostatus
- % tab af Testindsats, omkostninger eller tid.
#4) måling af Testfremskridt
Produktrisici:
- % risiko dækket.
- % af risikoen for fail test
- % risiko identificeret af den enkelte.
mangler:
- antallet af fundne mangler kontra antallet af indsendte mangler.
- Middeltid for fejl ankomstrate
- fejl i de særlige testelementer.
- påvisning af RCA(Root Cause Analysis)
- fejlen er Testudgivelser.
- defekt i fase
- prioritet og sværhedsgrad
- rapport afviser vs duplikat
- Tid-taget til at løse
- antallet af nye fejl indført på grund af fastsættelse af gamle fejl.
Test:
- Samlet antal Testpas, fail, runner, blokeret
- det samlede antal Regressionstesttilfælde.
dækning:
- krav og Design dækning
- risiko dækning
- miljø konfiguration dækning
- kode dækning
#5) målinger til overvågning af testens livscyklus
Monitor Test Plan
- antal risici og krav
- Defektopdagelse
- Plan vs faktisk indsats.
Monitor Test Design
- antallet af fejl fundet under design.
Monitor Test analyse
- antal betingelser
- antal fejl i analyse
Monitor test implementering
- % af miljøkonfiguration
- % af testcase automatiseret.
Monitor udførelse
- % af beståede, mislykkede, ingen løb, blokerede testsager
- % testsager dækket
- planlagte vs faktiske defekter løst
- % af planen vs faktisk dækning
Monitor lukning
- % af testcases pass, ail
- % af testcases kontrolleret i genanvendelig kategori
- % af testcases automatiseret.
- antallet af fejl løst / ikke løst.
- % af Testarbejdsproduktet
testovervågnings-og kontrolfasen diskuteret nedenfor forklarer yderligere dette emne.
Teststyringsfaser
under Teststyringsprocessen skal man overveje følgende punkter. Med andre ord er følgende de forskellige faser af Teststyringsprocessen:
- risikoanalyse
- Testestimering
- testplanlægning
- testorganisation
- Testovervågning og kontrol
- Issues management
- testrapport
du kan bemærk, at de første fire faser handler mere om planlægning, og de resterende tre handler om udførelse. Derfor kan vi opdele den komplette teststyringsproces i to dele, dvs.planlægning og udførelse.
lad os undersøge de forskellige Teststyringsfaser i detaljer.
#1) risikoanalyse
denne fase omfatter at finde ud af risikofaktorer og mulige løsninger. Hvis risikoanalysen udføres grundigt, kan vi undgå fremtidige fejl, eller i det mindste en slags løsning kan være tilgængelig.
risiko er noget, der måske eller måske ikke sker. Men hvis det sker, hvad vil dens indvirkning være? Det kan påvirke kvaliteten af programmet, virksomhedens omdømme og meget mere.
risikofaktorer bør findes for at undgå denne dårlige indvirkning. Risikoanalyse skal udføres for at finde ud af risikofaktorer. Der er to typer risici, dvs. Projektrisici og Produktrisici. Projektrisici er de risici, der er relateret til arbejdsprocessen, og Produktrisiko er risici, der er relateret til det udviklede produkt.
#2) Testestimering
Testestimering handler om forudsigelsen af den tid, der kræves for hver testaktivitet/fase. Da dette er et skøn, kan det ikke være nøjagtigt. For bedre testestimering kan vi studere vores virksomheds tidligere projekter, eller vi kan konsultere de teammedlemmer, der skal være ansvarlige for det arbejde eller testfasen.
#3) testplanlægning
testplanlægning i sig selv er en lang proces. Det inkluderer definition af testmål, testomfang, teststrategi, tidsplanlægning, ressourcer, kommunikationsmetode osv. Kravene skal være meget klare for at definere testmål og omfang. Testplanen er for testere, brugere og projektteammedlemmer.
testplanen beskriver testens rolle i projektet. Testplanen inkluderer også roller og ansvar, liste over funktioner, der skal testes og ikke skal testes, testmiljø, liste over værktøjer og antagelser, hvis nogen.
#4) testorganisation
i testplanlægningsfasen har vi planlagt alle mulige ting om test.
derfor har vi brug for dygtige teammedlemmer til at udføre denne plan eller for at gøre planen vellykket. Testorganisation handler om at opbygge det perfekte testteam til et vellykket projekt.
#5) Testovervågning og kontrol
mens testarbejdet er i gang, eller mens testerne udfører testplanen, skal alle disse arbejdsforløb overvåges. Man bør holde styr på alt dette testarbejde. Hvis testovervågning er udført, vil testteamet og testlederen få feedback om, hvordan testfremskridt er?
ved hjælp af denne feedback kan testlederen guide teammedlemmerne til at forbedre kvaliteten af yderligere testarbejde. Ved hjælp af testovervågning får projektteamet synlighed på testresultaterne. Det hjælper også med at vide om testdækning.
for store projekter udføres testovervågning ved hjælp af et automatiseret værktøj, da dataindsamling bliver lettere. For små projekter samler en person alle de data eller dokumenter, der er relateret til testfremskridt. Til indsamling af oplysninger om testfremskridt kan vi tage hjælp fra IEEE 829 testlogskabelon. Det handlede om Testovervågning.
lad os se, hvad testkontrol er? Projektarbejde vil ikke altid gå som vi har planlagt. Der kan være nogle forskelle mellem planen og det faktiske arbejde. For at minimere eller fjerne disse forskelle er vi nødt til at foretage nogle ændringer, og det er sådan, vi kontrollerer testarbejdet.
#6) Issues Management
Issues kan være ethvert problem, der opstår under programudviklings-og testprocessen. Det kan være den mindste grund, fordi vi ikke er i stand til at udvikle/levere et kvalitetsprodukt. Uden at løse dette problem vil vi ikke være i stand til at fortsætte med den videre proces.
Issue management handler om, hvordan vi håndterer disse spørgsmål/problemer. Vi kan også kalde det Incident management. Issue management kræver bedre planlægning for processen med at løse problemer. Bedre problemstyring afhænger af testlederens dygtighed og erfaring.
Hvordan opstår disse problemer?
der kan være flere grunde til, at der opstår et problem. Nogle spørgsmål er relateret til strategi, og nogle er relateret til definitionen, HR, planlægning osv.
Strategiproblemer:
eksempler:
- projektet løber tør for midler.
- dårlig projektkommunikation.
- projektstyringsprocessen er ikke i overensstemmelse med de angivne standarder.
Definitionsproblemer: problemer, der er relateret til krav.
eksempler: uklare krav. Mange problemer kan introduceres på grund af uklare krav.
planlægningsproblemer: dette er den mest almindelige type problem. Medarbejderne skal kæmpe for at overholde fristen.
HR spørgsmål:
eksempler:
- der er mangel på færdigheder i holdet.
- forkert medarbejderkortlægning til arbejde.
der kan være mange flere typer problemer, og vi kan ikke nævne dem alle her. Således handler issue management om logning, sporing og løsning af problemer.
#7) testrapport
testrapport hjælper med at identificere testdækning, kvaliteten af det udviklede produkt og de nødvendige procesforbedringer. Vi kan beslutte ‘hvor meget test er påkrævet?’
hvis der udføres nok test, kan vi indsende denne testrapport til interessenterne eller klienterne. Så de vil også lære kvaliteten af produktet at kende og få en ide om, hvor meget test der udføres på produktet.
Teststyringsværktøjer
Teststyring bliver kompliceret, når vi fortsætter i vores programmeludviklingsproces, og det er en af hovedårsagerne til, at så mange teststyringsværktøjer er tilgængelige i dag.
disse værktøjer hjælper i de sidste fire faser af teststyringsprocessen (testorganisation, Testovervågning & kontrol, Issues management og testrapport). Da disse værktøjer hjælper med de vigtige faser af teststyring, bør de overvejes først i projektet.
hyret nedenfor er de mest populære Test Management værktøjer:
- kvalitetstest
- praksis
- Testkollab
- TestFLO for JIRA
- Kvalitet
- røntgen – banebrydende Teststyring
- testrail
- gennemsnit
- krav og Teststyring for Jira (RTM)
- Spiratest by Inflectra
- Kualitee
- vand
- Testpad
- Junoone
=> Klik her for detaljerede anmeldelser af TOP Test Management Tools
organisationsstrukturer
lad os se de forskellige organisationsstrukturer.
der kan være visse regler for organisationsstrukturer, eller der kan være nogle ideelle strukturer, men uanset at enhver organisation kan have sin struktur. Der er så mange organisatoriske strukturer, og hver enkelt har deres fordele og ulemper.
her vil vi diskutere nogle af dem.
for det første vil vi se den enkleste organisationsstruktur, der bruges til små projekter.
i denne struktur rapporterer både testere og programmører til udviklingschefen.
- udviklingschefen har god kontrol over projektaktiviteter.
- der vil være mindre mulighed for et kommunikationsgab mellem test-og udviklingsholdene.
- også i møder er det godt at beslutte deadlines for udviklingschefen, da han/hun har fuldstændig viden om test-og udviklingsarbejdet.
- samarbejde vil være effektivt på grund af minimale lag.
ulemper ved denne struktur omfatter:
- da der ikke er nogen testleder, er der en mulighed for, at test vil blive betragtet sent i projektet.
- der er en anden mulighed for, at test får mindre betydning for projektet. Det kan betragtes som sent i projektet.
generelt i små organisationer til små projekter sker det, at udviklingsholdet tager mere tid end nævnt, og testteamet skal lide, dvs.testteamet bliver nødt til at teste produktet inden fristen, så testteamet får mindre tid til at teste produktet.
i denne struktur skal udviklingschefen huske på, at hans mål ikke kun er at gennemføre projektet, men at udvikle kvalitetsprogrammer.
den næstmest anvendte organisationsstruktur:
dette er den mest almindelige type organisationsstruktur. I denne struktur rapporterer testerne til Testcheferne, og udviklerne rapporterer til udviklingschefen. Både Testlederen og udviklingschefen rapporterer til projektlederen.
Testlederen er ansvarlig for alle testrelaterede aktiviteter, og det er Udviklingschefens ansvar at få programmet til at udvikle sig. Projektlederen vil styre både test-og udviklingsaktiviteterne.
fordele:
- i modsætning til den tidligere struktur er der her i denne struktur forskellige ledere til test og udvikling, og derfor kan de begge fokusere på deres arbejde. De vil forblive dedikeret til deres arbejde, og der vil være færre distraktioner for dem.
- i denne struktur kan testaktiviteterne ikke overses, eller det kan ikke betragtes som sent i projektet. Det betyder, at både test og udvikling får lige stor betydning.
- når det kommer til at træffe kritiske beslutninger, har testteamet med fordel uafhængighed.
ulemper:
- der er mulighed for et kommunikationsgab på grund af flere niveauer.
testledelse Vs organisationsstrukturer
organisationsstrukturer påvirker direkte Teststyring. Forskellige organisationsstrukturer har en anden indflydelse på testledelsen, derfor varierer testledelsen alt efter testlederens dygtighed og erfaring såvel som i henhold til testlederens position i organisationsstrukturen.
vi har set to organisationsstrukturer her. I den første struktur er udviklingschefen og testlederen den samme person, og det påvirker derfor teststyring. Udviklingschefen har til formål at udvikle programmel, og samtidig skal han/hun også se på testarbejdet.
Således kan han/hun til tider give partiske meninger. Han / hun kan bare overse problemet og gå videre. På denne måde kan det påvirke teststyring. En uafhængig testleder vil være i stand til at give mere retfærdighed, og teststyring vil være bedre med uafhængige testledere.
konklusion
vi har set både emnerne, dvs.testledelse og organisationsstrukturer separat og sammen med forholdet mellem disse to. Vi kan konkludere, at organisationsstrukturer påvirker teststyring.
mens man sammenligner begge ovennævnte strukturer, vil teststyring i den anden struktur blive håndteret bedre end den første. Årsagen bag dette kan være en dedikeret test manager.
organisationsstrukturer adskiller sig fra en organisation til en anden. Selvom der er en defineret proces til teststyring (eller teams bruger muligvis teststyringsværktøjer), vil testledelsen variere på grund af forskellige organisationsstrukturer, testledere, testlederens færdigheder og erfaring.