Test Management Tutorial: En Ultimate Guide Til Test Management

Dette Er En Test Management Tutorial For Testing Av Programvare. Det inkluderer Testledelsesfaser, Verktøy Og Testledelse Vs Organisasjonsstruktur:

Testledelse er prosessen med å administrere alle testrelaterte aktiviteter, dokumenter og annet relatert arbeid. Organisasjonsstrukturer refererer til et hierarki av lag eller ansatte som arbeider med bestemte prosjekter.

tror du organisasjonsstruktur påvirker testledelse?

hvis svaret ditt er nei, vil vi se hvorfor? Hvis ja, la oss se hvordan det påvirker. For å finne forholdet mellom Disse to, må vi forstå disse emnene tydelig og deretter utforske forholdet Mellom Testledelse og Organisasjonsstruktur.

Introduksjon Til Test Management

Test Management betyr å administrere hele prosessen med testing av programvare for et bestemt prosjekt. Teststyringsprosessen brukes på hele programvareutviklingens livssyklus. Derfor, ideelt sett, så snart programvareutviklingsprosessen starter, bør teststyringsprosessen også starte.

Testleder hadde følgende ansvar-

• Testlederen bør sikre konsistens og kvalitet på disse arbeidsproduktene.
• Arbeid Med Testanalytiker og Teknisk Testanalytiker for å velge og tilpasse den aktuelle malen.
• Arbeid Med Testanalytiker og Teknisk Testanalytiker for å etablere standarder for disse produktene, som nivåer av detaljert grad.
• Gjennomgå arbeidsproduktene ved hjelp av passende teknikker.

Teststyringskomponenter

Teststyring er delt inn i 5 deler for bedre forståelse:

1. Testdokumentasjon
2. Testestimering
3. Testmål
4. Måling Av Testfremdrift
5. Beregninger For Overvåking Av Testens Livssyklus

#1) Testdokumentasjon

det finnes tre Typer Testdokumentasjon som er oppført nedenfor:

• Testpolicy
• Teststrategi
• Master Testplan

#1) Test Policy:

• Oppsummerer verdien som organisasjonen kommer fra testing.
• Definerer testpolicyer.
• Beskriver hvordan man evaluerer effektiviteten av testingen.
• Skisserer Testprosessen.
• Angi Hvordan organisasjonen vil forbedre Testprosessen?

#2) Teststrategi:

• Beskriver de generelle testmetodene som brukes til å håndtere Prosjekt-Og Produktrisiko.
• Analytiske Strategier: Som Risikobasert Testing.
• Modellbasert Strategi: Som en operativ profil der testteamet utvikler en modell basert på faktiske og aksepterte situasjoner av miljø, innspill og forhold.
• Metodisk Strategi: Kvalitetskarakteristikker der testteamet bruker et sett med testforhold, sjekkliste eller samling av generaliserte, logiske tester.
• Prosess eller standardkompatible teknikker: Følger et sett av prosessen som SCRUM / Agile.
• Reaktive Strategier: Bruk av defektbaserte ANGREP SOM UTFORSKENDE TESTING.
• Rådgivende Strategi: Som brukerstyrt testing der testteamet er avhengig av innspill fra en eller flere interessenter for å bestemme testforhold som Outsourcet Kompatibilitetstesting.
• beskriver Også:
  • Integrasjonsprosedyrer
  • Testspesifikasjonsteknikker
  • Uavhengighet av testing
  • Obligatoriske og valgfrie standarder
  • Testmiljø
  • Verktøy
  • Gjenbruk av programvareprodukter
  • retesting og regresjon.

#3) Master Test Plan:

• den dekker alle testoppgaver som må gjøres.
• den diskuterer hvordan testing vil implementere Teststrategi og-Politikk.
• Hvis Noe ikke er beskrevet, Bør Testplanen beskrive hvorfor og begrensningsplanen for det.
• Innholdet I Testplanen er:
  • Elementer som skal testes
  • Kvalitetsegenskaper som skal testes.
  • Tidsplan
  • Utføringssyklus
  • Feilvariabler
  • Testelementer i omfang
  • Avslutningskriterier
  • Prosjektrisiko
  • Overordnet styring av testinnsats,
  • Roller og ansvar
  • inngang og utgang

#2) Testestimering

Generelle Punkter:

• er en ledelsesaktivitet
• Den er basert på erfaring.
• Det gir en spesifikk og detaljert katalog over kostnader, ressurser, aktiviteter og personer.
• Estimering når utarbeidet, må leveres til ledelsen sammen med begrunnelsen.
• det endelige estimatet representerer best mulig balanse mellom organisasjons-og prosjektmål.
• estimatet er basert på informasjon tilgjengelig på det tidspunktet den ble utarbeidet.
• for å holde seg nøyaktige, bør estimatene oppdateres for å gjenspeile ny og endret informasjon.

Faktorer som påvirker Testestimering:

• Nødvendig Kvalitetsnivå
• Systemets Størrelse
• Historiske data
• prosessfaktorer som strategi, utvikling og livssyklus
• Materielle faktorer som testmiljø, automatisering, verktøy og data
• Personfaktor
• Prosessens Kompleksitet
• Opplæring og KT(Kunnskapsoverføring)
• Assimilering Og utvikling av nye verktøy og teknologi, prosess eller teknikker.
• kravet om en høyere grad av den detaljerte Testspesifikasjonen.
• Timing av komponent ankomst
• Testdata.

Gjetninger:

• arbeidsnedbrytingsstruktur
• Team Estimering økt
• Tester-Utvikler ratio
• Organisasjonshistorikk
• Funksjon punktanalyse, LOC.

Test Estimering er nærmere forklart senere i opplæringen.

#3) Testmålinger

• hva som blir målt, anses som gjort?
• Hva som ikke måler, er lett å bli ignorert?
• et begrenset sett med nyttige beregninger bør defineres.
• Bare disse beregningene skal defineres hvis tolkning er avtalt av alle.
• Rapportering og sammenslåing av beregninger skal automatiseres.
• Lederen skal validere informasjonen i beregning.

Prosjekt Metrisk: % av pass, mislykkes utført etc.

Produkt Metrisk:

• Egenskaper for produktet
• Defekt Tetthet

Prosess Metrisk: Måler evnen til å teste som % av feilen.

Personer: Individets Evne.

Testfremdriftsmåling:

• antall Testforhold / Tilfeller, Planlagt vs Utført.
• total defekt kategorisert etter alvorlighetsgrad, prioritet, nåværende tilstand og effekt delsystem.
• antall endringer Som Kreves, Aksepteres, Bygges og Testes.
• Planlagt vs Faktisk Kostnad.
• Planlagt vs Faktisk Varighet
• planlagt vs Faktisk Testing milepæl.
• Risikostatus For Produktkvalitet
• % tap Av Testinnsats, Kostnad eller Tid.

#4) Måling Av Testfremdrift

Produktrisiko:

• % Risiko dekket.
• % Av Risiko for feiltest
• % Risiko identifisert av den enkelte.

Defekter:

• Antall feil funnet vs antall feil innsendt.
• Gjennomsnittlig tid for feil ankomstrate
• Feil i de bestemte testelementene.
• Påvisning AV Rca (Rotårsaksanalyse)
• defekten Er Testutgivelser.
• Feil i fase
• Prioritet Og Alvorlighetsgrad
• Rapporten Avviser Vs Duplikat
• Det Tar Tid å løse
• antall nye feil som er innført på grunn av reparasjon av gamle feil.

Test:

• Totalt antall Test pass, mislykkes, runner, blokkert
• totalt Antall Regresjon testtilfeller.

Dekning:

• Krav-og Designdekning
• risikodekning
• Dekning Av Miljøkonfigurasjon
• kodedekning

#5) Beregninger For Overvåking Av Testlivssyklusen

Monitor Test Plan

• Antall Risiko Og Krav
• defekt oppdagelse
• Plan vs Faktisk innsats.

Monitor Test Design

• antall feil som ble funnet under design.

Monitor Test Analyse

• Antall forhold
• antall feil I Analyse

Monitor Test Implementering

• % av miljøkonfigurasjon
• % av testtilfellet automatisert.

Skjermutførelse

• % Blokkerte testtilfeller
• % Testtilfeller dekket
• Planlagte vs Faktiske feil løst
• % Av Plan vs Faktisk dekning

Skjermlukking

• % ail
• % av Testtilfellene sjekket inn i gjenbrukbar kategori
• % Av Testtilfellene automatisert.
• Antall Feil Løst / Ikke Løst.
• % Av Testarbeidsproduktet

testovervåkings-og kontrollfasen som er omtalt nedenfor, forklarer dette emnet ytterligere.

Testledelsesfaser

under Testledelsesprosessen må man vurdere følgende punkter. Med andre ord, følgende er de forskjellige faser Av Teststyringsprosessen:

1. Risikoanalyse
2. Testestimering
3. Testplanlegging
4. Testorganisasjon
5. Testovervåking og kontroll
6. Håndtering Av Problemer
7. Testrapport

Du kan legge merke til at de fire første fasene handler mer om planlegging og de resterende tre handler om gjennomføring. Derfor kan vi dele hele teststyringsprosessen i to deler, Dvs. Planlegging og Gjennomføring.

la oss utforske De ulike Testledelsesfasene i detalj.

# 1) Risikoanalyse

denne fasen inkluderer å finne ut risikofaktorer og mulige løsninger. Hvis risikoanalyse er gjort grundig, kan vi unngå fremtidige feil eller i det minste en slags løsning kan være tilgjengelig.

Risiko er noe som kan eller ikke kan skje. Men hvis det skjer så hva vil være dens innvirkning? Det kan dårlig påvirke kvaliteten på programvaren, omdømmet til selskapet og mye mer.

Risikofaktorer bør bli funnet ut for å unngå denne dårlige effekten. Risikoanalyse bør gjøres for å finne ut risikofaktorer. Det er to typer risikoer, dvs. Prosjektrisiko og Produktrisiko. Prosjektrisiko er risikoen som er relatert til arbeidsprosessen, Og Produktrisiko er risiko som er relatert til det utviklede produktet.

#2) Testestimering

Testestimering handler om prediksjon av tiden som kreves for hver testaktivitet / fase. Siden dette er et estimat, kan det ikke være nøyaktig. For bedre testestimering kan vi studere de siste prosjektene i vårt firma, eller vi kan konsultere lagmedlemmene som skal være ansvarlige for det arbeidet eller testfasen.

# 3) Testplanlegging

Testplanlegging i seg selv er en lang prosess. Det inkluderer å definere testmål, testomfang, teststrategi,tidsplanlegging, ressurser, kommunikasjonstilnærming, etc. Kravene bør være svært klare for å definere testmål og omfang. Testplanen er for testere, brukere og prosjektgruppemedlemmene.

testplanen beskriver testens rolle i prosjektet. Testplanen inneholder også roller og ansvar, liste over funksjoner som skal testes og ikke skal testes, testmiljø, liste over verktøy og forutsetninger hvis noen.

#4) Testorganisasjon

under testplanleggingsfasen har vi planlagt alle mulige ting om testing.

Derfor trenger vi dyktige teammedlemmer til å utføre denne planen eller for å gjøre planen vellykket. Testorganisasjon handler om å bygge det perfekte testteamet for et vellykket prosjekt.

#5) Testovervåking Og Kontroll

mens testarbeid pågår eller mens testerne utfører testplanen, må alle disse arbeidsfremdriften overvåkes. Man bør holde styr på alt dette testarbeidet. Hvis testovervåking er gjort, vil testteamet og testlederen få tilbakemelding på hvordan testfremgangen er?

ved hjelp av denne tilbakemeldingen kan testlederen veilede teammedlemmene for å forbedre kvaliteten på videre testarbeid. Ved hjelp av testovervåking vil prosjektgruppen få synlighet på testresultatene. Det hjelper også å vite om testdekning.

for store prosjekter utføres testovervåking ved hjelp av et automatisert verktøy, da datainnsamlingen blir enklere. For små prosjekter vil en person samle alle data eller dokumenter som er relatert til testfremdrift. For å samle testfremdriftsinformasjon, kan vi ta hjelp av ieee 829 testloggmalen. Dette handlet om Testovervåking.

La oss se Hvilken Testkontroll er? Prosjektarbeid vil ikke alltid gå som vi har planlagt. Det kan være noen forskjeller mellom planen og det faktiske arbeidet. For å minimere eller fjerne disse forskjellene, må vi gjøre noen endringer, og det er slik vi kontrollerer testarbeidet.

#6) Issues Management

Problemer kan være et problem som oppstår under programvareutvikling og testing. Det kan være den minste grunnen fordi vi ikke er i stand til å utvikle/levere et kvalitetsprodukt. Noen problemer er en show-stopper, dvs. uten å løse det problemet, vil vi ikke kunne fortsette med den videre prosessen.

Problemhåndtering handler om hvordan vi håndterer disse problemene/problemene. Vi kan også kalle Det Incident management. Problemstyring krever bedre planlegging for prosessen med å løse problemer. Bedre problemstyring avhenger av dyktighet og erfaring fra testlederen.

hvordan oppstår disse problemene?

det kan være flere årsaker til at et problem oppstår. Noen problemer er relatert til strategi og noen er relatert til definisjonen, HR, planlegging, etc.

Strategiproblemer:

Eksempler:

• prosjektet går tom for midler.
• Dårlig prosjektkommunikasjon.
• prosjektledelsesprosessen er ikke i henhold til de angitte standardene.

Definisjonsproblemer: Problemer som er relatert til krav.

Eksempler: Uklare krav. Mange problemer kan innføres på grunn av uklare krav.

Planleggingsproblemer: Dette er den vanligste typen problem. Ansatte må kjempe for å møte fristen.

HR-Problemer:

Eksempler:

• det er mangel på ferdigheter i laget.
• Feil ansattkartlegging for arbeid.

det kan være mange flere typer problemer, og vi kan ikke nevne dem alle her. Dermed problemet ledelse handler om logging, sporing og løse problemer.

#7) Testrapport

Testrapport bidrar til å identifisere testdekning, kvalitet på det utviklede produktet og nødvendige prosessforbedringer. Vi kan bestemme ‘hvor mye testing er nødvendig?’

hvis nok testing er gjort, kan vi sende denne testrapporten til interessenter eller klienter. Slik at de også vil bli kjent med kvaliteten på produktet og ha en ide om hvor mye testing som utføres på produktet.

Teststyringsverktøy

Teststyring blir komplisert når Vi fortsetter i vår programvareutviklingsprosess, og det er en av hovedgrunnene til at så mange teststyringsverktøy er tilgjengelige i dag.

disse verktøyene vil hjelpe i de fire siste fasene av teststyringsprosessen (Testorganisasjon, Testovervåking & Kontroll, Problemhåndtering og Testrapport). Da disse verktøyene hjelper til med de viktige fasene av teststyring, bør de vurderes først i prosjektet.

Enlisted nedenfor er de mest populære Teststyringsverktøyene:

1. qTest
2. Praktisk
3. Zephyr
4. Test Collab
5. TestFLO FOR JIRA
6. XQual
7. Xray – Cutting Edge Test Management
8. testrail
9. qacoverage
10. Krav Og Teststyring For Jira (Rtm)
11. Spiratest Ved Inflectra
12. Kualitee
13. aqua
14. Testpad
15. Junoone

=> Klikk her for detaljerte vurderinger AV TOPP Teststyringsverktøy

Organisasjonsstrukturer

La oss se de ulike organisasjonsstrukturene.

det kan være visse regler for organisasjonsstrukturer eller det kan være noen ideelle strukturer, men uavhengig av at enhver organisasjon kan ha sin struktur. Det er så mange organisasjonsstrukturer, og hver har sine fordeler og ulemper.

her vil vi diskutere noen av dem.

For det første vil Vi se den enkleste organisasjonsstrukturen som brukes til små prosjekter.

i denne strukturen rapporterer både testere og programmerere Til Utviklingslederen.

1. utviklingsansvarlig har god kontroll over prosjektaktiviteter.
2. det vil være mindre mulighet for et kommunikasjonsgap mellom test-og utviklingsteamene.
3. Også i møter er det bra for å bestemme frister for utviklingsleder som han / hun har full kunnskap om testing og utviklingsarbeid.
4. Lagarbeid vil være effektivt på grunn av minimale lag.

Ulemper med Denne Strukturen inkluderer:

1. siden det ikke er noen testleder, er det en mulighet for at testing vil bli vurdert sent i prosjektet.
2. det er en annen mulighet for at testing vil få mindre betydning for prosjektet. Det kan betraktes sent i prosjektet.

Generelt i små organisasjoner for små prosjekter, skjer det at utviklingslaget tar mer tid enn nevnt, og testteamet må lide, dvs.testteamet må teste produktet innen fristen, slik at testteamet får mindre tid til å teste produktet.

i denne strukturen, for å fullføre et prosjekt vellykket, må utviklingslederen huske på at hans mål ikke bare er å fullføre prosjektet, men å utvikle kvalitetsprogramvare.

Den nest mest brukte Organisasjonsstrukturen:

Dette er den vanligste typen organisasjonsstruktur. I denne strukturen rapporterer testerne Til Testledere og utviklerne rapporterer Til Utviklingsleder. Både Testleder og Utviklingsleder rapporterer Til Prosjektleder.

Testlederen vil være ansvarlig for alle testrelaterte aktiviteter, Og Det er Utviklingslederens ansvar å få programvaren til å utvikle seg. Prosjektlederen vil kontrollere både test-og utviklingsaktiviteter.

Fordeler:

• I Motsetning til den forrige strukturen, her i denne strukturen, er det forskjellige ledere for testing og utvikling, derfor kan begge fokusere på sitt arbeid. De vil forbli dedikert til sitt arbeid, og det vil være færre distraksjoner for dem.
• i denne strukturen kan testaktivitetene ikke overses, eller det kan ikke betraktes som sent i prosjektet. Dette betyr at både testing og utvikling vil få like stor betydning.
• når det gjelder å ta kritiske beslutninger, har testteamet med fordel uavhengighet.

Ulemper:

• det er en mulighet for et kommunikasjonsgap på grunn av flere nivåer.

Testledelse Vs Organisasjonsstrukturer

Organisasjonsstrukturer påvirker Testledelsen direkte. Ulike organisasjonsstrukturer har en annen innvirkning på testledelse, derfor varierer testledelsen i henhold til testlederens ferdigheter og erfaring, samt i henhold til testlederens posisjon i organisasjonsstrukturen.

vi har sett to organisasjonsstrukturer her. I den første strukturen er utviklingsleder og testleder den samme personen, og det påvirker derfor testledelsen. Utviklingslederen har som mål å utvikle programvare, og mens han/hun gjør dette, må han / hun også se på testarbeidet.

Dermed kan han/hun til tider gi partiske meninger. Han / hun kan bare overse problemet og gå videre. På denne måten kan det påvirke testadministrasjonen. En uavhengig testleder vil kunne gi mer rettferdighet og testledelse vil bli bedre med uavhengige testledere.

Konklusjon

vi har sett både temaene testledelse og organisasjonsstrukturer separat og sammen med forholdet mellom disse to. Vi kan konkludere med at organisasjonsstrukturer påvirker teststyring.

mens du sammenligner begge strukturene nevnt ovenfor, i den andre strukturen, vil teststyring håndteres bedre enn den første. Årsaken bak dette kan være en dedikert testleder.

Organisasjonsstrukturer er forskjellige fra en organisasjon til en annen. Selv om det er noen definert prosess for testledelse (eller team kan bruke teststyringsverktøy), vil testledelse variere på grunn av ulike organisasjonsstrukturer, testledere, testleders ferdigheter og erfaring.