Menu

Sådan forbereder du dig til testskrivning (Produktivitetstip)

how prepare yourself

Prøv Vores Instrument Til At Fjerne Problemer

Sådan forbereder du dig til skrivning af testsager og forbedrer din produktivitet:

Når en tester beslutter at skrive testsager af høj kvalitet og ønsker at forbedre deres effektivitet og produktiviteten ved test case-skrivning, er der få nøglepunkter, der hjælper testere med at nå disse mål.

For det første skal de forberede sig professionelt og psykologisk med nogle af de nøglepunkter, der er nødvendige for alle succesrige softwaretestere i IT-branchen. Dette vil blive behandlet som “ Indgange ”Til en tester, inden du begynder at skrive testsager.

test sagsskrivning

Derefter er de nødt til at forstå de kvalitetsmålinger, der er involveret i projektet, som bruges som et værktøj til evaluering af testers ydeevne i forskellige faser af testets livscyklus. Dette vil blive behandlet som “ Udgange ”Til en tester efter afslutningen test sagsskrivning .

Endelig skal testeren vide, hvordan fejlen rapporteres, problemer eskaleres, og hvordan testrapporterne udarbejdes i overensstemmelse med standardproceduren og kan forstås af projektets interessenter.

Hvad du lærer:

hvad er den bedste e-mail at have

Forbered dig på skrivning af testsager

1) Test case skrivning er en kunst og er ikke kun et job eller en opgave. Et stykke eller et segment af software kan designes og udvikles, men indtil og medmindre det er fuldstændigt testet for alle scenarier med en effektiv testtilgang, vil det være ubrugeligt og ikke berettiget til at blive frigivet og brugt af nogen. Så, behandle dig selv som en vigtig person i projektet og behandle din testaktivitet som en vigtig opgave i projektet .

to) Det lidenskab med en positiv holdning , som er det yderste personlige kvalitetstestere burde have gennem hele projektets livscyklus. Lidenskab motiverer teambuilding kapaciteter og holdning bringer stor produktivitet i skrivning kvalitet test tilfælde. Midler, testskrivningsaktiviteten er en blanding af professionelle og personlige kvaliteter til et fælles mål om at opnå gode resultater som et endeligt output i projektet.

3) Positiv og negative testsager er en del af at skrive testsager, men testerne skal have en semi-positiv tankegang for at bryde applikationen under test ved at finde fejl . Dette er ikke en negativ tankegang, snarere at undgå situationen med at identificere en fejl af nogen efter frigivelse eller undgå den situation, hvor systemet vil blive brudt af nogle brugere af systemet.

4) Testers effektivitet bør ikke estimeres ud fra antallet af fejl identificeret i systemet under test, men på mulighederne for at skrive vellykkede testsager, der resulterer i opdagelsen af ​​manglerne. Så testkasserne skal skrives på en sådan måde, at dækningen og sporbarhed bør være maksimalt baseret på systemgrænsen og omfanget.

5) Forstå applikationsdomænet grundigt .For eksempel, at teste et websted er lettere end at teste en finansiel software udviklet til børs, der bruges af tusinder af mennesker på samme tid. Enkel webstedsfunktionalitet kan forstås af enhver tester, mens de økonomiske vilkår og funktionaliteter ikke kan forstås af alle testere, før og medmindre de har den relevante uddannelsesmæssige baggrund eller uddannelse eller har domæneoplevelse .

Så når en testere tildeles et nyt projekt, skal han / hun foretage en egenvurdering, uanset om de er berettigede og kan udføre deres job i henhold til forventningerne eller ej. Hvis de funktionelle krav er svære at forstå, skal det eskaleres til projektteamet i god tid for at undgå fremtidige misforståelser om testers effektivitet og ydeevne. Det håndteres af projektlederen eller testlederen gennem ordentlige planer og træning.

6) Projektets krav og typer af test, der skal udføres, varierer fra projekt til projekt. En tester skal være forberedt på at udføre enhver form for test. Begræns ikke dine muligheder til dine færdigheder og specialiteter. Vær parat til at tage ansvar og udfordringer til at skrive og udføre testsager til enhver form for test.

Mange testere prøver at tilpasse sig selv eller projicere sig som kun manuelle eller automatiseringstestere. Når man kommer til præstationstest, tager belastningstest eller stresstest meget få testere rollerne og forbereder sig ved at træne eller indsamle den krævede viden. Så, være en hurtig lærer og være klar til at tage ansvar og vokse i din karriere.

7) Identificer testtyperne skal udføres og de nødvendige færdigheder til test af AUT. For eksempel, nogle projekter kræver kun test af sort boks, og andre kræver færdigheder til test af hvid boks. Viden om “ scripting ”Eller oplevelse i“ SQL ”Eller arbejde med“ markere sprog ”Som HTML / XML osv., Eller endda en systemviden om, hvordan man installerer / fejlfinder installation af softwaren osv. Er nogle projektspecifikke krav, du skal lære dig selv eller få træning i det samme.

8) Sørg for, at testsagerne dækker Ydelsestest, sikkerhedstest og regressionstesttyper. For eksempel, for at logge ind på applikationen ved hjælp af loginskærmen nedenfor:

Test sag effektivitet 2

  • Ydelsestest kan være påkrævet for at kontrollere, om applikationen er stabil, når tusindvis af brugere logger ind på systemet på samme tid, og testcases skal skrives for at dække dette scenario.
  • Der kan være behov for sikkerhedstest for at kontrollere, om applikationen kun tillader brugere, der har de rette rettigheder og tilladelser, at få tilladelse til at bruge systemet, og testsagerne skal skrives for at dække disse scenarier.
  • Regressionstest kan være påkrævet for at kontrollere, om kernefunktionaliteten og de kritiske funktioner fungerer korrekt på hver udgivelse.

9) Test case review : En af de vigtigste og mest oversete faser af enhver softwareudvikling og testets livscyklus er “ ANMELDELSE ”. Når en projektplan inkluderer tilstrækkelig tidsallokering til en gennemgangsproces på hvert eneste trin i projektudviklingen, de mest kvalitetsleverancer og output, vi kan forvente det samme.

god gratis musik downloader til android

Før testere f.eks. Begynder at skrive testsager, skal de kontrollere, om dokumentet 'kravspecifikation' gennemgås, og alle gennemgangspunkter overvejes og opdateres i dokumentet. Hvis organisationen følger en ordentlig og modnet proces, skal alle dokumentskabeloner have denne ændringsinformation på den første side af selve dokumentet.

Testcase-dokumenter skal gennemgås mindst 3 gange gennem:

i) Selvvurdering
ii) Peer review
iii) Gennemgang af andre for fuldstændighed, testdækning, sporbarhed, og om testsagen kan testes eller ej.

10) Langt om længe, forstå, hvordan man estimerer og planlæg testopgaverne . Planlæg kun at arbejde i det planlagte estimerede tidspunkt på en dag. Dette kan opnås ved at starte og afslutte opgaverne til tiden og forlade dagen med planerne for den næste dags opgaver.

Undgå at blive sene nætter og tilbringe weekender på kontoret. I dag er effektive projektledelsesmetoder tilgængelige, og projekter udføres i et agilt miljø. Hvis milepæle ikke opnås af projektteamene, behandles det som ineffektiv projektledelse snarere end ineffektivitet fra projektteamene.

Bemærk : Husk, selv for automatiseret test skal testcases være tydeligt skrevet og gennemgå mindst en gang og fuldstændigt dække den funktionelle strøm af applikationen, der testes. Ethvert værktøj til automatiseringstest kan kun registrere og udføre testsager, når de manuelle testsager er klart defineret og skrevet.

Kvalitetsmålinger

Dette er en vigtig aktivitet i softwaretestfaserne. Testteamet skal være helt opmærksom på de forskellige testmålinger, der bruges til at nå projektmålet. Testers ydeevne evalueres ikke kun på baggrund af testudførelsesfasen, men ud fra alle testmålinger indsamlet fra kravanalyse, skrivning af testsager, udførelse, fejlrapportering og endelig testrapporteringsfase.

Nedenfor finder du et par vigtige testmålinger efterfulgt af de fleste organisationer for bedre produktivitet af testere og effektiviteten af ​​testfaser.

Se ogsåandre nyttige testmålinger anvendt i testfaser:

=> Vigtige softwaretestmålinger og målinger og Live Project Bug Tracking, Test Metrics og Test Sign-off proces.

1) Gennemsnitlig testeffektivitet

  • Fejl pr. Måned efter testindsatsen.
  • Beregnet som gennemsnit (samlede fejl under testindsats i mandmåneder).
  • Skal beregnes efter hver intern frigivelse såvel som efter testafslutning.
  • Acceptgrænse: skal være mindre end 50

2) Gennemsnitlig kundefejltæthed

  • Fejl rapporteret af klienten efter levering Vs samlede testindsats i mandmåneder.
  • Beregnet som gennemsnit (samlede fejl efter leverings- / testindsats i mandater).
  • Skal beregnes efter ekstern frigivelse og projektafslutning.
  • Acceptgrænse: skal være mindre end 1

3) Funktionelle testfejl

  • Et antal mislykkede sager om funktionel test / Samlet antal udførte funktionelle testsager.
  • Beregnes månedligt eller hver fjortende dag.

4) Fejl med sværhedsgrad 1

  • Det samlede antal fejl identificeret med sværhedsgrad 1 (blokering).
  • Test kan ikke fortsættes for softwaren på grund af problemer med blokeringen.
  • Skal beregnes ugentligt.

5) Fejl med sværhedsgrad 2

  • Det samlede antal fejl identificeret med sværhedsgrad 2 (større fejl).
  • Test kan ikke fortsættes for funktionen på grund af de store fejl, men kan fortsættes med andre dele af systemet.
  • Skal beregnes ugentligt.

6) Fejl med sværhedsgrad 3

  • Det samlede antal bugs identificeret med sværhedsgrad 3 (mindre bugs).
  • Test kan fortsættes, da den identificerede fejl er mindre og ikke stopper testen.
  • Skal beregnes ugentligt.

7) Fejl med sværhedsgrad 4

  • Det samlede antal bugs identificeret med sværhedsgrad 4 (kosmetiske problemer).
  • Test kan afsluttes uden problemer, da de identificerede bugs er kosmetiske relaterede og skal rettes til næste udgivelse.
  • Skal beregnes ugentligt.

Fejlrapportering

Fejlrapporteringsmekanisme skal styres med en modnet testproces for at opretholde applikationens kvalitet. Der skal være en ordentlig eskaleringsproces til de rigtige autoriserede personer for at kende fejlens status, sværhedsgrad og prioritet. Der er mange gratis og kommercielle fejlrapporteringsværktøjer til rådighed som Bugzilla, Mantis osv., som er meget effektive i sporingsmekanismer for problemer og let kan integreres med ethvert teststyringsværktøj, der bruges i projektet.

I hvert testprojekt skal standardprocedurer følges for en online statusrapporteringsmekanisme dagligt. Alle fejl / problemer, der er logget og rapporteret i disse fejlsporingssystemer, skal straks sende en e-mail til de respektive myndigheder, som vil hjælpe dem med at planlægge og tage handlinger i overensstemmelse hermed.

At lære fejlrapporteringsprocessen detaljeretlæs følgende artikler:

=> Hvordan skriver jeg en god fejlrapport? Tips og tricks
=> Eksempel på fejlrapport
=> Hvorfor fejlrapportering er en kunst, der bør læres af alle testere?
=> Bug livscyklus
=> Eksempel på fejlrapporter til web- og produktapplikationer

Testrapporter

Bortset fra fejlrapporterne, der er rejst, logget og eskaleret i bugrapporteringssystemet, er en testrapport et af de vigtigste dokumenter, der kender testens status og andre vigtige målinger, der er identificeret og beregnet i løbet af testrapporteringstiden.

Nedenfor er en sådan simpel testrapport:

Læs også følgende nyttige vejledninger tileffektiv testrapportering:

=> Vejledning til at skrive en effektiv testoversigtsrapport
=> Sådan rapporteres smart udførelse af test (Download statusrapportskabelon)

hvor du finder netværkssikkerhedsnøglen

sejrende

jaya1

Konklusion

Processen med at forberede sig på at skrive testsager er ikke kun bare tildeling af ressourcer i projektet, men der er kun få nøglekrav som at forberede os som kvalificerede tester og forstå de kvalitetsmålinger, der overvåges gennem testets livscyklus og selv efter frigivelsen.

Så ved at følge processen, kan standarder, procedurer og nøje overholdelse af kvalitetsmålene med lidenskab automatisk medføre stor testeffektivitet, produktivitet og en kvalitetstester i dig, hvilket bliver en vane i dit professionelle liv.

Disse kvalitetsfaktorer kan selvanalyseres eller gruppeanalyseres ved at stille nogle få spørgsmål som vil fortælle, om vi er på rette spor af selv- og procesforbedring i målet om at opnå en effektiv tilgang til skrivning og udførelse af testsager:

  • Har du gennemgået funktionelle krav / brugerkrav / forretningsdokumenter?
  • Er dokumentet om funktionelle krav blevet gennemgået og opdateret korrekt med anmeldelse af kommentarer?
  • Har du modtaget skærmprototyperne til alle de funktioner, der skal testes?
  • Er du fortrolig med at skrive testsager, der kan testes og spores gennem testens livscyklus?
  • Har du den nødvendige færdighed og domæne viden til at teste den applikation, der testes?
  • Har du brug for uddannelse eller teknisk viden, der kræves til at udføre testsagerne?
  • Har du tidsplanen for at skrive, gennemgå og udføre testsager, der dækker tiden til udarbejdelse af kvalitetsdokumenter?
  • Har du jævnaldrende til at gennemgå dine testsager og en autoriseret fagekspert til at kontrollere fuldstændighed og dækning af de funktioner og funktioner, der skal testes?
  • Har du nok testcases til alle funktionelle krav?
  • Har du nok testcases til ydeevne, belastningstest og sikkerhedstest?
  • Har du nok testcases til installation og regressionstest?
  • Har du kontaktpunktet for at eskalere problemerne eller rapportere fejl?
  • Er bug tracking-værktøjet konfigureret korrekt med den krævede tilladelse til alle?
  • Er du fortrolig med at følge alle de processer, der er defineret i testplanen?
  • Bliver du involveret i alle gennemgangsmøder og får en chance for at tale med udviklings- eller ledelsesteamet?
  • Forbedres din produktivitet og effektivitet, eller er du nødt til at træffe foranstaltninger for det samme?

Anbefalet læsning = >> Bedste online kreative skrivekurser

Der er mange lignende spørgsmål, som testere kan stille sig selv til selvforbedringsanalyse, afhængigt af typen af ​​projekt eller den organisation, de arbejder med. Det vigtigste er, at alle disse aktiviteter ikke skal følges kun for at følge processerne, men skal laves som dine daglige vaner, som kan gøres gennem PASSION TIL TESTING kun.

PREV-vejledning | NÆSTE vejledning

Anbefalet læsning

^