difference between test plan
Lær hva som er forskjellen mellom testplan, teststrategi, testtilfelle, testskript, testscenario og testtilstand med eksempler:
Programvaretesting inkluderer flere grunnleggende så vel som viktige konsepter som hver programvaretester bør være klar over.
Denne artikkelen vil forklare de forskjellige konseptene i programvaretesting sammen med sammenligningen.
Testplan vs Teststrategi, Test Case vs Test Script, Test Scenario vs Test Condition og Test Procedure vs Test Suite blir forklart i detalj for enkel forståelse.
=> Klikk her for fullstendig testplanopplæringsserie
Ovennevnte spørsmål stilt av Sasi C. er det ofte stilte spørsmålet i vårt Programvare Testing klasse og jeg forteller alltid deltakerne at vi med opplevelsen knapt legger merke til disse ordene, og at de blir en del av ordforrådet vårt.
Men ofte er det forvirring rundt disse, og i denne artikkelen prøver jeg å definere noen vanlige begreper.
Ulike konsept for programvaretesting
Nedenfor er de forskjellige programvaretestkonseptene sammen med sammenligningen deres.
La oss begynne!!
Hva du vil lære:
- Forskjellen mellom testplan og teststrategi
- Forskjellen mellom test case og test script
- Forskjellen mellom testscenario og testtilstand
- Forskjellen mellom testprosedyre og test suite
- Konklusjon
Forskjellen mellom testplan og teststrategi
Teststrategi og testplan er to viktige dokumenter i testets livssyklus for ethvert prosjekt. Her prøver vi å gi deg en grundig kunnskap om teststrategi og testplandokumenter.
Testplan
En testplan kan defineres som et dokument som definerer omfanget, målet og tilnærmingen til å teste programvaren. Testplanen er et begrep og kan leveres.
Testplanen er et dokument som lister opp alle aktivitetene i et QA-prosjekt, planlegger dem, definerer omfanget av prosjektet, roller og ansvar, risikoer, inngangs- og utgangskriterier, testmål og alt annet du kan tenke deg.
Testplanen er som jeg liker å kalle et ‘superdokument’ som lister opp alt det er å vite og trenger. Vær så snill sjekk denne lenken for mer informasjon og et utvalg.
Testplanen skal utformes ut fra kravene. Mens du tildeler testingeniørene arbeid av en eller annen grunn, blir en av testerne erstattet av en annen. Her blir testplanen oppdatert.
Teststrategien skisserer testtilnærmingen og alt annet som omgir den. Det er forskjellig fra testplanen, i den forstand at en teststrategi bare er en delmengde av testplanen. Det er et hardcore testdokument som til en viss grad er generisk og statisk. Det er også et argument om på hvilke nivåer teststrategi eller plan brukes - men jeg ser virkelig ingen kresne forskjeller.
Eksempel: Testplanen gir informasjon om hvem som skal teste når. For eksempel, Modul 1 skal testes av “X tester”. Hvis testeren Y erstatter X av en eller annen grunn, må testplanen oppdateres.
beste gratis DVD-ripper for Mac
Testplan dokument
Testplan er et dokument som gir fullstendig informasjon om testoppgaver knyttet til et programvareprosjekt. Den gir detaljer som omfanget av testingen, testtyper, mål, testmetodikk, testinnsats, risiko og uforutsetninger, frigjøringskriterier, testleveranser osv. Den holder oversikt over mulige tester som kjøres på systemet etter koding.
Testplanen er åpenbart satt til å endres. I utgangspunktet vil det bli utviklet et utkast til testplan basert på prosjektets klarhet på den tiden. Denne første planen blir endret etter hvert som prosjektet skrider frem. Testteamleder eller testleder kan utarbeide testplandokumentet. Den beskriver spesifikasjonene og kan endres basert på de samme.
Hva du skal teste, når du skal teste, hvem som skal teste, og hvordan du skal teste, vil bli definert i testplanen. Testplan vil sortere ut en liste over problemer, avhengigheter og de underliggende risikoene.
Typer testplan
Testplaner kan være av forskjellige typer basert på testfasen. I utgangspunktet vil det være en mastertestplan for hele prosjektgjennomføringen. Det kan lages separate testplaner for spesifikke testtyper som systemtesting, systemintegrasjonstesting, testing av brukeraksept, etc.
En annen tilnærming er å ha separate testplaner for funksjonell og ikke-funksjonell testing. I denne tilnærmingen vil testing ha en egen testplan.
Innholdet i testplandokumentet ( IEEE-829 testplanstruktur )
Det er vanskelig å tegne et tydelig format for testplanen. Testplanformatet kan variere avhengig av prosjektet. IEEE har definert en standard for testplaner som er beskrevet som IEEE-829 testplanstruktur.
Nedenfor finner du IEEE-anbefalinger for standard testinnhold:
- Testplanidentifikator
- Introduksjon
- Test elementer
- Problemer med programvarerisiko
- Funksjoner som skal testes
- Funksjoner som ikke skal testes
- Nærme seg
- Varekort / ikke-godkjente kriterier (eller) akseptkriterier
- Suspensjonskriterier og gjenopptakelseskrav
- Testleveranser
- Test oppgaver
- Miljøkrav
- Bemannings- og opplæringsbehov
- Ansvar
- Rute
- Godkjenninger
Foreslått lese => Testplanopplæring - En perfekt guide
Teststrategi
Teststrategi er et sett med retningslinjer som forklarer testdesignet og bestemmer hvordan testing må gjøres.
Eksempel: En teststrategi inkluderer detaljer som “Individuelle moduler skal testes av medlemmene av testteamet”. I dette tilfellet spiller ingen rolle hvem som tester det - så det er generisk, og endringen i teammedlemmet trenger ikke å oppdateres, og holder det statisk.
Test strategidokument
Hensikten med teststrategien er å definere testtilnærmingen, typer tester, testmiljøer og verktøy som skal brukes til testing og detaljer på høyt nivå om hvordan teststrategien vil bli tilpasset andre prosesser. Teststrategidokumentet er ment å være et levende dokument og vil bli oppdatert ** når vi får mer klarhet om Krav, SLA-parametere, Testmiljø og Build management-tilnærming, etc.
Teststrategi er ment for hele prosjektgruppen som består av prosjektsponsorer, forretnings-små og mellomstore bedrifter, applikasjons- / integrasjonsutvikling, systemintegrasjonspartnere, datakonverteringsteam, bygge / frigjøre ledelsesteam som tekniske ledere, arkitekturledninger og distribusjons- og infrastrukturteam.
** Noen hevder at teststrategi når den er definert, aldri skal oppdateres. I de fleste testprosjekter blir det vanligvis oppdatert etter hvert som prosjektet skrider frem.
Nedenfor er de viktige delene som et teststrategidokument skal ha:
# 1) Prosjektoversikt
Denne delen kan begynne med å gi en oversikt over organisasjonen, etterfulgt av en kort beskrivelse av prosjektet. Det kan inneholde detaljer nedenfor
- Hva var behovet for prosjektet?
- Hvilke mål vil prosjektet nå?
Tabell over akronymer: Det er bedre å inkludere en tabell med akronymer som dokumentleseren kan komme med når du refererer til dokumentet.
# 2) Krav Omfang
Kravets omfang kan omfatte applikasjonsomfang og funksjonelt omfang
Søknadsomfang definerer systemet som testes og innvirkningen på systemet på grunn av ny eller endret funksjonalitet. Beslektede systemer kan også defineres.
System | Effekt (ny eller endret funksjonalitet) | Relatert system |
---|---|---|
Den beskriver hvordan man skal teste, når man skal teste, hvem som skal teste og hva man skal teste. | Den beskriver hvilken type teknikk som skal følges og hvilken modul du skal teste. | |
System A | Nye forbedringer og feilrettinger | • System B • System C |
Funksjonelt omfang definerer innvirkningen på forskjellige moduler i systemet. Her vil hvert relaterte system med hensyn til funksjonalitet bli forklart.
System | Modul | Funksjonalitet | Relatert system |
---|---|---|---|
System C | Modul 1 | Funksjonalitet 1 | System B |
Funksjonalitet 2 | System C |
# 3) Testnivå på høyt nivå
Testplan er et eget dokument. I teststrategien kan en testplan på høyt nivå inkluderes. En testplan på høyt nivå kan inkludere testmål og testomfang. Testomfang skal definere både i omfang og utenfor omfanget av aktiviteter.
# 4) Testtilnærming
Denne delen beskriver testtilnærmingen som vil bli fulgt i løpet av testens livssyklus.
I henhold til ovenstående diagram vil testingen bli utført i to faser, dvs. teststrategi og planlegging og testutførelse. Teststrategi og planleggingsfase vil være en gang for et overordnet program, mens testutførelsesfasene blir gjentatt for hver syklus av det samlede programmet. Ovenstående diagram viser forskjellige stadier og leveranser (utfall) i hver fase av utførelsesmetoden.
Testtilnærmingen bør inkludere under-seksjoner nedenfor
a) Testplan: Forklar den foreslåtte tidslinjen for prosjektet i dette underavsnittet
b) Funksjonell testtilnærming: Bruk av dette underavsnittet gir en oversikt over hver fase og de respektive inn- og utgangskriteriene. Ulike testfaser er Unit testing, System testing, System Integration testing, User Acceptance Testing, and End-to-End testing.
c) Testing av viktige ytelsesindikatorer:
- Prioritering av prøvesaker: Definer tilnærmingen til prioritering av testtilfelle slik at i tilfelle tidsbegrensninger kan scener med høy prioritet utføres av testteamet. Det bør være en avtale mellom prosjektinteressenter om mulige risikoer ved å ikke gjennomføre alle de planlagte scenariene.
- Defektprioritering: Defektprioriteringsstrategi er neste tema å dekke her. Definer prioritetsnivå og gi beskrivelsen til hvert nivå som kritisk, høy, middels osv. Også
- Feiltid: Mangeltid er definert som tiden mellom feilen først ble reist og når mangelen er løst og kommer for en ny test. Rask behandling gir rask testing og overholdelse av prosjektets tidslinje. For hvert prioritetsnivå for defekter definerer du behandlingstiden.
Prioritetsnivå | Defekt vendetid |
---|---|
1 - Kritisk | Responstid: 2 timer eller mindre Fix Klar for migrasjon: 1 virkedag eller mindre |
# 5) Testdekning
Denne delen beskriver prosessene som QA-teamet vil følge for å optimalisere dekningen av forretnings- / funksjonskrav i testscenarier og testtilfeller. Kravsporbarhetsmatrise: (RTM) kan brukes til å spore alle kravene med respektive testscenarier og testtilfeller.
# 6) Testmiljø
Definer de forskjellige tilgjengelige kvalitetsmiljøene. Nevn hvilken testing som skal utføres i hvilket miljø og av hvem. Lag en miljøsikkerhetsplan for å ivareta kriser. Tilgang til hvert miljø bør reguleres og kalles ut med klarhet.
Testverktøy som skal brukes, kan også nevnes i dette avsnittet.
Aktivitet | Verktøy | Merknader |
---|---|---|
Testledelse | HP ALM | Nevn årsaken til bruk av dette verktøyet |
Feilbehandling | JIRA | Nevn årsaken til bruk av dette verktøyet |
# 7) QA-leveranser og beregninger
Liste opp alle kvalitetsleveranser
S. Nei | Leveres |
---|---|
1 | Test strategidokument |
to | Krav Sporbarhetsmatrise |
3 | ST-testskript |
4 | Testoversiktsrapport |
5 | Liste over automatiserte kvalifiserte scenarier |
Liste opp alle QA-beregningene
# | Metrisk navn | Metrisk definisjon | Metrisk formel | Metrisk måleenhet | Rapporter der beregningene skal brukes |
---|---|---|---|---|---|
1 | Krav om dekning (RCM) | Dekningen av kravene fra QA | Forholdet mellom antall krav testet og antall identifiserte krav | % | Ukentlig QA-statusrapport, Testoppsummeringsrapport |
to | Test dekning | Dekningen av prøvesaken utført | Andel antall utførte testsaker / antall testsaker planlagt | % | Daglig henrettelsesrapport, Ukentlig QA-statusrapport, Testoppsummeringsrapport |
# 8) Feilbehandling
Definere en defektstyringsstrategi tydelig ved å opprette en arbeidsflyt for mangler, metodikk for mangelsporing og defektprosess. Nevn mangelfull ansvar for hver testers roller. Periodisk feilanalyse og rotårsaksanalyse vil forbedre den generelle kvaliteten på testingen
# 9) Kommunikasjonsledelse
Sett retningslinjer for statusrapporter, statusmøter og offshore-kommunikasjon.
# 10) Antakelser, risikoer og avhengigheter
Beskriv forutsetninger som prosjektet er basert på. Disse kan omfatte timing, ressurser og systemfunksjoner. Beskriv eventuelle avhengigheter som andre prosjekter, tilgjengeligheten av midlertidige ressurser, andre tidsfrister som kan påvirke prosjektet
# 11) Vedlegg
Inkluder ting som roller og ansvar, arbeidstidssone og referanser i denne delen
Videre lesning=> Veiledning til å skrive et dokument med god teststrategi .
Testplan mot teststrategi
TESTPLAN | TESTSTRATEGI |
---|---|
Den er avledet fra spesifikasjon for programvarekrav (SRS). | Det er avledet fra Business Requirement document (BRS). |
Den utarbeides av testledelsen eller lederen. | Den er utviklet av prosjektleder eller forretningsanalytiker. |
Testplan-ID, funksjoner som skal testes, testteknikker, testoppgaver, funksjoner som består eller ikke bestått kriterier, testleveranser, ansvar og tidsplan osv. Er komponentene i testplanen. | Mål og omfang, dokumentasjonsformater, testprosesser, teamrapporteringsstruktur, klientkommunikasjonsstrategi, etc. er komponentene i teststrategien. |
Hvis det er en ny funksjon eller en endring i kravet som skjer, blir testplandokumentet oppdatert. | Teststrategi opprettholder standardene mens dokumentet utarbeides. Det kalles også som statisk dokument. |
Vi kan utarbeide testplanen individuelt. | I mindre prosjekter finnes ofte teststrategi som en del av en testplan. |
Vi kan utarbeide en testplan på prosjektnivå. | Vi kan bruke teststrategi på flere prosjekter. |
Vi kan beskrive spesifikasjonene ved å bruke en testplan. | Teststrategi beskriver om generelle tilnærminger. |
Testplan vil endres i løpet av prosjektet. | Teststrategi endres vanligvis ikke når den er godkjent. |
Testplanen skrives etter at kravet er signert av. | Teststrategi er laget før testplanen. |
Testplaner kan være av forskjellige typer. Det vil være en mastertestplan og en egen testplan for forskjellige typer testing som systemtestplan, ytelsestestplan osv. | Det vil bare være ett teststrategidokument for et prosjekt. |
Testplanen skal være klar og kortfattet. | Teststrategi gir overordnet veiledning for prosjektet. |
Forskjellen mellom disse to dokumentene er subtil. En teststrategi er et høyt nivå statisk dokument om prosjektet. På den annen side vil testplanen spesifisere hva du skal teste, når du skal teste, og hvordan du skal teste.
Forskjellen mellom test case og test script
Etter min mening kan disse to begrepene brukes om hverandre. Ja, jeg sier at det ikke er noen forskjell. Test saken er en sekvens av trinn som hjelper oss med å utføre en bestemt test på applikasjonen. Testskriptet er også det samme.
Nå er det en tankegang at en testtilfelle er et begrep som brukes i det manuelle testmiljøet, og testskript brukes i et automatiseringsmiljø. Dette er delvis sant, på grunn av komfortnivået til testerne i de respektive feltene, og også på hvordan verktøyene refererer til testene (noen anropstestskripter og noen kaller dem for å teste saker).
Så i praksis er testskript og testtilfelle begge trinn som skal utføres på et program for å validere funksjonaliteten, enten manuelt eller gjennom automatisering.
Videre lesning=> Hvordan skrive effektive testtilfeller? og Eksempelmal for prøvesak .
TESTFORSØK | TESTSKRIFT |
---|---|
Det er grunnskjemaet for å teste en søknad i rekkefølge. | Når vi har utviklet, vil skriptet kjøre det flere ganger til kravet endres. |
Det er en trinnvis prosedyre som brukes til å teste en applikasjon | Det er et sett med instruksjoner for å teste en applikasjon automatisk. |
Begrepet Test Case brukes i det manuelle testmiljøet. | Begrepet Test Script brukes i testmiljø for automatisering. |
Det gjøres manuelt. | Det gjøres med skriptformat. |
Den er utviklet i form av maler. | Den er utviklet i form av skripting. |
Test case mal inkluderer testdrakt-ID, testdata, testprosedyre, faktiske resultater, forventede resultater etc. | I Test Scrip kan vi ikke bruke forskjellige kommandoer til å utvikle skript. |
Brukes til å teste en applikasjon. | Den brukes også til å teste en applikasjon. |
Eksempel: Vi må bekrefte påloggingsknappen i en applikasjon, Trinnene inkluderer: a) Start applikasjonen. b) Bekreft om påloggingsknappen vises eller ikke. | Eksempel: Vi ønsker å klikke på en bildeknapp i et program. Manuset inkluderer: a) Klikk på Bildeknappen. |
Forskjellen mellom testscenario og testtilstand
Test Scenario: Det er en måte å definere alle mulige måter å teste en applikasjon på. Det er en enkelt uttalelse som dekker alle mulige måter å teste en søknad på.
Testforhold: Testtilstand er spesifikasjonen som en tester må følge for å teste en applikasjon.
Dette er en linjepeker som testere oppretter som et innledende, overgangstrinn inn i testdesignfasen. Dette er for det meste en linjedefinisjon av 'Hva' vi skal teste med hensyn til en bestemt funksjon. Vanligvis er testscenarier inndata for oppretting av testsaker.
I smidige prosjekter er testscenarier de eneste resultatene for testdesign, og ingen testtilfeller er skrevet etter disse. Et testscenario kan resultere i flere tester.
Eksempler på testscenarier:
- Bekreft om et nytt land kan legges til av administratoren
- Bekreft om et eksisterende land kan slettes av administratoren
- Valider hvis et eksisterende land kan oppdateres
Testforhold er derimot mer spesifikke. Det kan grovt defineres som mål / mål for en bestemt test.
Eksempel på testtilstand: I eksemplet ovenfor, hvis vi skulle teste scenariet 1, kan vi teste følgende forhold:
- Skriv inn landnavnet som “India” (gyldig) og sjekk om landet er lagt til
- Skriv inn et tomt og sjekk om landet blir lagt til.
- I hvert tilfelle blir de spesifikke dataene beskrevet, og målet for testen er mye mer presist.
Videre lesning=> 180+ eksempler på testscenarier for testing av nett- og skrivebordsprogrammer.
TESTSENARIO | TESTFORHOLD |
---|---|
Dette er en linjeuttrykk for å forklare hva vi skal teste. | Testtilstand beskriver hovedmålet for å teste en applikasjon. |
Det er en prosess for å teste en applikasjon på alle mulige måter. | Testbetingelser er at de statiske reglene skal følges for å teste en applikasjon. |
Testscenarier er et innspill for opprettelse av testsaker. | Det gir hovedmålet å teste en søknad. |
Testscenario dekker alle mulige tilfeller for å teste en applikasjon. | Testtilstand er veldig spesifikk. |
Det reduserer kompleksiteten. | Det gjør systemet feilfritt. |
Testscenario kan være en enkelt eller en gruppe testsaker. | Det er målet med testsaker. |
Ved å skrive scenarier vil det være lett å forstå funksjonaliteten til en applikasjon. | Testtilstand er veldig spesifikk. |
Eksempler på testscenarier: # 1) Bekreft om administratoren kan legge til et nytt land. # 2) Bekreft om et eksisterende land kan slettes av administratoren. # 3) Valider om et eksisterende land kan oppdateres. | Eksempler på testbetingelser: # 1) Skriv inn landnavnet som 'India' og se etter tillegget til landet. # 2) Legg igjen tomme felt og sjekk om landet blir lagt til. |
Forskjellen mellom testprosedyre og test suite
Testprosedyren er en kombinasjon av testsaker basert på en viss logisk grunn, som å utføre en ende-til-ende-situasjon eller noe i den retning. Rekkefølgen prøvesakene skal kjøres på er fast.
Test prosedyre: Det er ingenting annet enn testens livssyklus. Det er ti trinn i Testing Life Cycle.
De er:
- Anslagsestimering
- Prosjekt igangsettelse
- Systemstudie
- Testplan
- Design Test Case
- Test automatisering
- Utfør testsaker
- Rapporter feil
- Regresjonstesting
- Analyse og oppsummeringsrapport
For eksempel , hvis jeg skulle teste sendingen av en e-post fra Gmail.com, vil rekkefølgen på testsaker som jeg kombinerer for å danne en testprosedyre være:
- Testen for å sjekke påloggingen
- Testen for å komponere en e-post
- Testen for å feste ett / flere vedlegg
- Formatering av e-post på ønsket måte ved hjelp av forskjellige alternativer
- Legge til kontakter eller e-postadresser i To, BCC, CC feltene
- Sende en e-post og sørge for at den vises i delen 'Sendt e-post'
Alle testsakene ovenfor er gruppert for å oppnå et bestemt mål på slutten av dem. Testprosedyrer har også noen få testtilfeller kombinert når som helst.
Testpakken er derimot listen over alle testsakene som må utføres som en del av en testsyklus eller en regresjonsfase osv. Det er ingen logisk gruppering basert på funksjonalitet. Rekkefølgen der de testende sakene blir utført, kan eller ikke være viktig.
Test Suite: Test Suite er en container som har et sett med tester som hjelper testerne med å utføre og rapportere testutførelsesstatusen. Det kan ta noen av de tre tilstandene, dvs. aktive, pågår og fullføres.
Eksempel på Test Suite : Hvis en applikasjons gjeldende versjon er 2.0. Den forrige versjonen 1.0 hadde kanskje 1000 testtilfeller for å teste den helt. For versjon 2 er det 500 testtilfeller for å bare teste den nye funksjonaliteten som er lagt til i den nye versjonen.
Så den nåværende testpakken vil være 1000 + 500 testtilfeller som inkluderer både regresjon og den nye funksjonaliteten. Suiten er også en kombinasjon, men vi prøver ikke å oppnå en målfunksjon.
Test suiter kan inneholde 100 eller til og med 1000 test tilfeller.
TEST PROSEDYRE | TEST SUITE |
---|---|
Opprettelse av testprosedyrer er basert på teststrømmen fra ende til slutt. | Testpakker blir opprettet basert på syklusen eller basert på omfanget. |
Det er en kombinasjon av testtilfeller for å teste en søknad. | Det er en gruppe testsaker for å teste en søknad. |
Det er en logisk gruppering basert på funksjonaliteten. | Det er ingen logisk gruppering basert på funksjonaliteten. |
Testprosedyrer er leverbare produkter i programvareutviklingsprosessen. | Det utføres som en del av testsyklusen eller regresjonen. |
Rekkefølgen er utført. | Rekkefølgen er kanskje ikke viktig. |
Testprosedyren inneholder end-to-end testtilfeller. | Testpakke inneholder alle nye funksjoner og regresjonstesttilfeller. |
Testprosedyrer er kodet på et nytt språk som heter TPL (Test Procedure language). | Testpakke inneholder manuelle testtilfeller eller automatiseringsskript. |
Konklusjon
Konsept for programvaretesting spiller en viktig rolle i livssyklusen for programvaretesting.
En klar forståelse av de ovennevnte konseptene sammen med sammenligningen er veldig viktig for hver programvaretester for å utføre testprosessen effektivt.
Vanligvis er artikler som disse gode utgangspunkt for dypere diskusjoner. Så vær så snill å bidra med dine tanker, avtaler, uenigheter og annet, i kommentarene nedenfor. Vi ser frem til tilbakemeldingene dine.
Vi ønsker også spørsmål om spørsmål om programvaretesting generelt eller noe som er relatert til testkarrieren din. Vi vil ta opp disse mer detaljert i våre kommende innlegg i samme serie.
Glad lesning !!
=> Besøk her for komplett testplanopplæringsserie
PREV Opplæring | NESTE veiledning
Anbefalt lesing
- Testplanopplæring: En guide til å skrive et programvaretestplandokument fra bunnen av
- Hvordan skrive teststrategidokument (med eksempel på teststrategimal)
- Slik forbereder du deg på prøveskriving (Produktivitetstips)
- Hva er testscenario: testscenariomal med eksempler
- Forskjellen mellom ytelsestestplan og ytelsesteststrategi
- Hvordan skrive testsaker: Den ultimate guiden med eksempler
- Eksempel på programvare Testplanmal med format og innhold
- Test Scenario Vs Test Case: Hva er forskjellen mellom disse?