Meny

Slik forbereder du deg på prøveskriving (Produktivitetstips)

how prepare yourself

Prøv Instrumentet Vårt For Å Eliminere Problemer

Slik forbereder du deg på prøveskriving og forbedrer produktiviteten din:

Når en tester bestemmer seg for å skrive høykvalitets testsaker og ønsker å forbedre effektiviteten og produktiviteten ved skriving av testsaker, er det få viktige punkter som hjelper testerne til å nå disse målene.

Først må de forberede seg profesjonelt og psykologisk med noen av de viktigste punktene som er nødvendige for alle vellykkede programvaretestere i IT-bransjen. Dette vil bli behandlet som “ Innganger ”For en tester før du begynner å skrive testsaker.

prøvesakeskriving

Deretter må de forstå kvalitetsmålingene som er involvert i prosjektet, som brukes som et verktøy for å evaluere testerenes ytelse i forskjellige faser av testets livssyklus. Dette vil bli behandlet som “ Utganger ”For en tester etter fullført prøvesakeskriving .

Til slutt må testeren vite hvordan feilen rapporteres, problemer eskaleres og hvordan testrapportene blir utarbeidet i samsvar med standardprosedyren og kan forstås av interessentene i prosjektet.

Hva du vil lære:

beste gratis PC renere programvare for Windows 10

Forbered deg på prøveskriving

1) Prøvesakeskriving er en kunst og er ikke bare en jobb eller oppgave. Et stykke eller et segment av programvare kan utformes og utvikles, men inntil og med mindre det er fullstendig testet for alle scenarioene med en effektiv testtilnærming, vil det være ubrukelig og ikke kvalifisert for utgivelse og bruk av noen. Så, behandle deg selv som en viktig person i prosjektet og behandle testaktiviteten din som en viktig oppgave i prosjektet .

2) De lidenskap med en positiv holdning , som er det aller mest personlige kvalitetstestere burde ha gjennom hele prosjektets livssyklus. Lidenskap motiverer teambyggingsegenskapene og holdningen gir stor produktivitet i å skrive kvalitetsprøvesaker. Midler, testskrivingsaktiviteten er en blanding av profesjonelle og personlige egenskaper for et felles mål om å oppnå gode resultater som en endelig utgang i prosjektet.

3) Positivt og negative testsaker er en del av å skrive testsaker, men testerne bør ha en semi-positiv tankegang for å bryte applikasjonen under test gjennom å finne feil . Dette er ikke et negativt tankesett, snarere å unngå situasjonen med å identifisere en feil av noen etter løslatelse eller unngå situasjonen der systemet vil bli ødelagt av noen brukere av systemet.

4) Testers effektivitet bør ikke estimeres ut fra antall feil identifisert i systemet som testes, men på mulighetene til å skrive vellykkede testsaker som resulterer i oppdagelsen av feilene. Så testtilfellene skal skrives på en slik måte at dekningen og sporbarhet bør være maksimalt basert på systemgrensa og omfanget.

5) Forstå søknaden Domain grundig .For eksempel, å teste et nettsted er enklere enn å teste en finansiell programvare utviklet for børs som brukes av tusenvis av mennesker samtidig. Enkel nettstedsfunksjonalitet kan forstås av alle tester, mens de økonomiske vilkårene og funksjonalitetene ikke kan forstås av alle testere før og med mindre de har relevant utdanningsbakgrunn eller opplæring eller har domenerfaring .

Så når en tester blir tildelt på et nytt prosjekt, bør han / hun gjøre en egenvurdering, enten de er kvalifisert og kan utføre jobben i henhold til forventningene eller ikke. Hvis funksjonskravene er tøffe å forstå, bør det eskaleres til prosjektgruppen i god tid for å unngå fremtidige misforståelser om testers effektivitet og ytelse. Det vil bli håndtert av prosjektleder eller testleder gjennom riktige planer og opplæring.

6) Prosjektets krav og typer testing som skal utføres, varierer fra prosjekt til prosjekt. En tester bør være forberedt på å gjøre noen form for testing. Ikke begrens evnene dine til dine ferdigheter og spesialiteter. Vær forberedt på å ta ansvar og utfordringer for å skrive og gjennomføre testsaker for alle typer tester.

Mange testere prøver å tilpasse seg selv eller projisere seg som bare manuelle eller automatiseringstestere. Når det gjelder ytelsestesting, belastningstesting eller stresstesting, tar svært få testere rollene og forbereder seg ved å trene eller samle nødvendig kunnskap. Så, være en rask lærer og vær klar til å ta ansvar og vokse i karrieren din.

7) Identifiser testtypene som skal utføres og ferdighetene som kreves for å teste AUT. For eksempel, noen prosjekter krever bare black-box testing, og noen krever white box testing ferdigheter. Kunnskapen om “ skripting ”Eller erfaring i“ SQL ”Eller arbeider med“ merke språk ”Som HTML / XML etc., eller til og med en systemkunnskap om hvordan du installerer / feilsøker installasjon av programvaren, etc. er noen prosjektspesifikke krav du må lære deg selv eller få opplæring for det samme.

8) Forsikre deg om at testtilfellene dekker Ytelsestesting, sikkerhetstesting og regresjonstestingstyper. For eksempel, for å logge på applikasjonen ved hjelp av påloggingsskjermen nedenfor:

Test Case effektivitet 2

  • Det kan være nødvendig med ytelsestesting for å sjekke om applikasjonen er stabil når 1000-tallet av brukere er pålogget på systemet samtidig, og testtilfellene bør skrives for å dekke dette scenariet.
  • Det kan være nødvendig med sikkerhetstesting for å sjekke om applikasjonen bare tillater brukere som har de rette rettighetene og tillatelsene, å være autorisert til å bruke systemet, og testtilfellene bør skrives for å dekke disse scenariene.
  • Regresjonstesting kan være nødvendig for å sjekke om kjernefunksjonaliteten og de kritiske funksjonene fungerer som de skal på hver utgivelse.

9) Test Case Review : En av de viktigste og mest oversettede faser av programvareutvikling og testets livssyklus er “ ANMELDELSE ”. Når en prosjektplan inkluderer nok tidsavdeling for en gjennomgangsprosess på hvert trinn av prosjektutviklingen, de mest kvalitetsleveransene og resultatene vi kan forvente det samme.

For eksempel, før testere begynner å skrive testtilfeller, bør testere sjekke om 'kravspesifikasjon' -dokumentet blir gjennomgått, og alle gjennomgangspunktene blir vurdert og oppdatert i dokumentet. Hvis organisasjonen følger en riktig og modnet prosess, bør alle dokumentmalene ha denne endringsinformasjonen på første side av selve dokumentet.

Testcase Dokumenter bør gjennomgås minst 3 ganger gjennom:

i) Selvgjennomgang
ii) Peer review
iii) Gjennomgang av andre for fullstendighet, testdekning, sporbarhet og om testsaken kan testes eller ikke.

10) Endelig, forstå hvordan du kan estimere og planlegge testoppgavene . Planlegg å jobbe bare for den planlagte estimerte tiden på en dag. Dette kan oppnås ved å starte og fullføre oppgavene i tide og legge ut på dagen med planene for neste dags oppgaver.

Unngå å bo sene netter og tilbringe helger på kontoret. I dag er det effektive prosjektledelsesmetoder tilgjengelig og prosjekter blir utført i et smidig miljø. Hvis ikke milepæler oppnås av prosjektgruppene, vil det bli behandlet som ineffektiv prosjektledelse i stedet for ineffektivitet fra prosjektgruppene.

Merk : Husk, selv for automatisert testing , bør testtilfeller være tydelig skrevet og gjennomgå minst en gang, og dekke den funksjonelle strømmen til applikasjonen som testes fullstendig. Ethvert automatiseringsprøveverktøy kan bare registrere og utføre testsaker når manuelle testsaker er klart definert og skrevet.

forskjellen mellom b og b + tre

Kvalitetsmålinger

Dette er en viktig aktivitet i programvaretestfasene. Testteamet bør være fullstendig klar over de forskjellige testmålingene som brukes for å nå prosjektmålet. Testerens ytelse blir ikke evaluert basert på bare testutførelsesfasen, men fra alle testberegningene samlet fra kravanalyse, skriving av testsaker, utførelse, feilrapportering og til slutt testrapporteringsfase.

Nedenfor finner du noen viktige testberegninger etterfulgt av de fleste av organisasjonene for bedre produktivitet av testere og effektiviteten i testfaser.

Se ogsåandre nyttige testberegninger som brukes i testfaser:

=> Viktige programvaretestmålinger og målinger og Live Project Bug Tracking, Test Metrics, og Test Sign Off Process.

1) Gjennomsnittlig testeffektivitet

  • Feil per årsbruk av testinnsatsen.
  • Beregnet som gjennomsnitt (totalt antall feil under testinnsats i månedene).
  • Skal beregnes etter hver intern utgivelse så vel som etter at test er fullført.
  • Akseptgrense: bør være mindre enn 50

2) Gjennomsnittlig tetthet av kundefeil

  • Feil rapportert av klienten etter levering Vs totale testinnsats i månedene.
  • Beregnet som gjennomsnitt (Totalt antall feil etter levering / testinnsats i månedene).
  • Skal beregnes etter ekstern utgivelse og prosjektavslutning.
  • Akseptgrense: bør være mindre enn 1

3) Funksjonelle testfeil

  • Et antall mislykkede funksjonstesttilfeller / Totalt antall utførte funksjonstesttilfeller.
  • Skal beregnes hver måned eller to uker.

4) Feil med alvorlighetsgrad 1

  • Totalt antall feil identifisert med alvorlighetsgrad 1 (blokkering).
  • Testing kan ikke fortsette for programvaren på grunn av problemer med blokkeringen.
  • Skal beregnes ukentlig.

5) Feil med alvorlighetsgrad 2

  • Totalt antall feil identifisert med alvorlighetsgrad 2 (store feil).
  • Testing kan ikke fortsette for funksjonen på grunn av de store feilene, men kan fortsette med andre deler av systemet.
  • Skal beregnes ukentlig.

6) Feil med alvorlighetsgrad 3

  • Totalt antall feil identifisert med alvorlighetsgrad 3 (mindre feil).
  • Testing kan fortsette ettersom den identifiserte feilen er mindre og ikke stopper testingen.
  • Skal beregnes ukentlig.

7) Feil med alvorlighetsgrad 4

  • Totalt antall feil identifisert med alvorlighetsgrad 4 (kosmetiske problemer).
  • Testingen kan fullføres uten problemer, da de identifiserte feilene er kosmetiske og skal løses for neste utgivelse.
  • Skal beregnes ukentlig.

Feilrapportering

Feilrapporteringsmekanisme bør kontrolleres med en modnet testprosess for å opprettholde applikasjonskvaliteten. Det bør være en ordentlig opptrappingsprosess til de rette autoriserte personene for å vite status, alvorlighetsgrad og prioritet for feilen. Det er mange gratis og kommersielle feilrapporteringsverktøy tilgjengelig som Bugzilla, Mantis, etc., som er veldig effektive i sporingsmekanismer og kan enkelt integreres med ethvert testadministrasjonsverktøy som brukes i prosjektet.

I hvert testprosjekt må standardprosedyrer følges for en online statusrapporteringsmekanisme på daglig basis. Alle feil / problemer som er logget og rapportert i disse feilsporingssystemene, bør umiddelbart sende en e-post til de respektive myndighetene som vil hjelpe dem med å planlegge og utføre tiltak deretter.

For å lære feilrapporteringsprosessen i detaljles følgende artikler:

=> Hvordan skriver jeg en god feilrapport? Tips og triks
=> Eksempel på feilrapport
=> Hvorfor feilrapportering er en kunst som bør læres av hver tester?
=> Feil livssyklus
=> Eksempel på feilrapporter for nett- og produktapplikasjoner

Testrapporter

Bortsett fra feilrapportene som er hevet, logget og eskalert i feilrapporteringssystemet, er en testrapport et av de viktigste dokumentene for å vite status for testing og andre viktige beregninger som er identifisert og beregnet i løpet av testrapporteringstiden.

Nedenfor er en så enkel testrapport:

Les også de følgende nyttige opplæringene foreffektiv testrapportering:

=> Veiledning for å skrive en effektiv testsammendragsrapport
=> Slik rapporterer du smarttestutføring smart (Last ned mal for statusrapport)

hvordan du legger til elementer i en array-java

seirende

jaya1

Konklusjon

Prosessen med å forberede seg på å skrive testsaker er ikke bare bare tildeling av ressurser i prosjektet, men det er få viktige krav som å forberede oss som kvalifiserte tester og forstå kvalitetsmålingene som overvåkes gjennom testens livssyklus og til og med etter utgivelsen.

Så, ved å følge prosessen, kan standarder, prosedyrer og strengt overholdelse av kvalitetsmålingene med lidenskap automatisk gi deg stor testeffektivitet, produktivitet og en kvalitetstester i deg, noe som vil bli en vane i ditt yrkesliv.

Disse kvalitetsfaktorene kan selvanalyseres eller gruppeanalyseres ved å stille noen spørsmål som vil fortelle om vi er på rett spor for selv- og prosessforbedring i målet om å oppnå en effektiv tilnærming i testsaksskriving og -utførelse:

  • Har du gått gjennom funksjonskravene / brukerkrav / forretningsdokument?
  • Har funksjonskravdokumentet blitt gjennomgått og oppdatert riktig med gjennomgangskommentarer?
  • Har du mottatt skjermprototypene for alle funksjonene som skal testes?
  • Er du komfortabel med å skrive testsaker som kan testes og kan spores gjennom testets livssyklus?
  • Har du den nødvendige ferdighetssettet og domenekunnskapen for å teste applikasjonen som testes?
  • Trenger du noen opplæring eller teknisk kunnskap som kreves for å gjennomføre testsakene?
  • Har du tidsplanen for skriving, gjennomgang og gjennomføring av testsaker, som dekker tiden for utarbeidelse av kvalitetsdokumenter?
  • Har du jevnaldrende til å gjennomgå testsakene dine og en autorisert fagekspert for å kontrollere fullstendighet og dekning av funksjonene og funksjonene som skal testes?
  • Har du nok testsaker for alle funksjonskravene?
  • Har du nok testsaker for ytelse, belastningstesting og sikkerhetstesting?
  • Har du nok testsaker for installasjon og regresjonstesting?
  • Har du kontaktpunktet for å eskalere problemene eller rapportere feil?
  • Er feilsporingsverktøyet riktig konfigurert med den nødvendige tillatelsen til alle?
  • Er du komfortabel med å følge alle prosessene som er definert i testplanen?
  • Blir du involvert i alle gjennomgangsmøter og får sjansen til å snakke med utviklings- eller ledergruppen?
  • Er produktiviteten og effektiviteten din forbedret, eller trenger du å ta noen tiltak for det samme?

Anbefalt lesing = >> Beste online kurs for kreativ skriving

Det er mange lignende spørsmål testere kan stille seg for selvforbedringsanalyse, avhengig av type prosjekt eller organisasjonen de jobber med. Det viktigste er at alle disse aktivitetene ikke skal følges bare for å følge prosessene, men skal gjøres som dine daglige vaner som kan gjøres gjennom PASSION FOR TESTING kun.

PREV Opplæring | NESTE veiledning

Anbefalt lesing

^