Meny

6 grundläggande färdigheter som varje testare (huvudsakligen färskare) borde ha

6 basic skills that every tester should have

Prova Vårt Instrument För Att Eliminera Problem

Software Testing eller QA är den bästa plattformen för nykomlingar att gå in i IT-branschen trots missuppfattningarna att det är ett mindre eller lägre betalt jobb.

Den viktigaste färdigheten som en testare behöver är förmåga att hitta buggar . Och om du är den typ av person som älskar att hitta buggar, kommer du att älska och växa inom detta område.

Med detta sagt finns det få fler färdigheter som kan hjälpa dig att hitta buggar och arbeta bättre med QA-processer.

Det här är artikeln som visar QA-processen eftersom den följs i de flesta företag och kommer att ge nya testare förtydliganden om testning.

I detalj lär du dig dokumentationsprocessen och standarderna, testets förarbete, begränsningar baserad testning, testning under partiell utveckling och slutligen avloggningsprocessen.

grundläggande testfärdigheter

Låt oss börja.

Vad du kommer att lära dig:

# 1. Dokumentation

Dokumentation är viktigt för testning. De flesta företag tilldelar denna uppgift till nykomlingar. För att lyckas borde du ha bra ordförråd eftersom resten av saker som dokumentationsstandarder etc. inte är under din kontroll och beror på teamets och företagets processer.

Se också till att du ser värdet av dokumentationsprocessen. Fördelarna är många - de hjälper dig att spåra kravförändringar, spåra dina teststeg, logga ditt arbete etc.

Rekommenderad läsning=> Varför dokumentation är viktigt vid programvarutestning

# 2. Testförberedelse

Av alla tillgängliga dokument kan följande inte ignoreras. Dessa kallas också som levererbara dokument och de överbryggar förståelse för klient, utvecklare och testare.

a) Testplan: Kartlägger testflödet från början till slut .

Testplanen visar testfasens omfattning och aktiviteter. Teamet är skapat av QA-ledaren och måste bidra och hålla sig uppdaterad om allt som står skrivet i testplanen.

Vissa lag har flera nivåer av testplaner: Masterplan och fasvisa planer.

En testplan måste ha:

  • Projektnamn och version
  • Testplanidentifierare - Skapare, utkast nr, skapat datum etc.
  • Inledning - Översikt över projektet, målet och begränsningarna
  • Referenser - Lista över referenser som används som ingång. (Se till att du använder de korrekta och senaste versionerna)
  • Testartiklar - Moduler, version, scope, out of scope, etc.
  • Övergripande testmetod / teststrategi - Verktyg att använda, defektspårningsprocess, testnivåer att utföra etc.
  • Kriterier för godkänd / underkänd post - riktlinjer för testutförande
  • Suspension & återupptagningskriterier
  • Testleveranser - Testfall, testrapporter, felrapport, testmätvärden etc.
  • Testa miljöinformation
  • Team Roster med kontaktpunktinfo. för varje modul eller testtyp
  • Testberäkningar - tid och ansträngning. Budgetuppgifterna är konfidentiella och du hittar dem inte här
  • Risker och begränsningsplaner
  • Godkännanden
  • Andra riktlinjer

Läs också=>

b) Testscenarier:

En rad pekar på 'vad man ska testa' baserat på varje krav och brukar dokumenteras och spåras genom kalkylblad.

De flesta av dem innehåller:

  • Modul / komponent / funktionsnamn (inloggning, admin, registrering, etc.)
  • Scenario-ID är som referens (t.ex. TS_Login_001)
  • Scenariobeskrivning - ”Vad ska jag testa” t.ex.: Validera om inloggning tillåter användare med giltiga referenser att logga in framgångsrikt
  • Scenariovikt - Att prioritera vid otillräcklig tid - Hög / Medium / Låg
  • Kravs-ID - För spårbarhet

Vidare läsning=>

c) Testfall:

Exakta testfall ger korrekta testresultat. Kalkylark är fortfarande det populära mediet för skrivning av testfall, särskilt för nybörjare, även om vissa företag anpassar testhanteringsverktyg. Grunden för skrivning av testfall är SRS / FRD / Req-dokumentet. Men det räcker inte ofta, så du måste använda mycket antagande och diskussion med BA / Dev-team.

Skriva effektiva testfall är den viktigaste kvalifikationen en testare måste ha. Vanligtvis kategoriseras alla testfall som positiva / negativa. Positivt testfall ger giltiga insatser och får positiva resultat. Negativt testfall ger ogiltiga ingångar och får exakt felmeddelande.

Mer information om dessa finns i:

Några av de vanliga attributen som alla testfall har är:

  • Scenario-ID - Hämtat från testscenariedokumentet
  • Testfall ID - för unik identifiering och spårning. Till exempel: TC_login_001
  • Testbeskrivning - Kort förklaring av testet
  • Steg att utföra - Detaljerade steg-för-steg-instruktioner om hur man testar
  • Testdata - Data levereras till teststegen
  • Förväntat resultat - Resultat som förväntat
  • Verkligt resultat - AUT: s svar när testet körs
  • Status - godkänd / misslyckad / ingen körning / ofullständig / blockerad - Beskriver testresultatet
  • Kommentarer - Till ytterligare information
  • Utförd av - Testers namn
  • Exekverat datum - Datum då testet körs
  • Defekt-ID - Defekt loggad mot testfallet om testfel misslyckades
  • Konfigurationsinformation - OS, webbläsare, plattform, enhetsinformation (valfritt)

Rekommenderad läsning=>

# 3. Testprocess - Vilka tester ska du utföra?

Det finns ett stort antal testtyper, men inte alla kan utföras på den AUT. Tid, budget, verksamhetens natur, applikationens natur och kundens intresse är de viktigaste aktörerna i valet av vilka tester som ska göras på applikationen.

Till exempel: Om det är en online-handelsportal är stresstester och belastningstest obligatoriska. Några av de testtyper som inte bör missas är dock:

# 4. Testning vid delutvecklingsstadiet

Generellt sett finns det begränsad tid och resurser med medelstora företag och nystartade företag. Testare här kan börja testprocessen innan modulintegration, vilket innebär att vi kan göra enhetstest och mellanliggande integrationstest.

Det är viktigt att notera att resultaten från dessa steg inte kan räknas som exakta, så du kan behöva planera för ett övergripande svart lådatest när allt är klart. Att se över den delen kan visa sig kostsamt och testa, ineffektivt.

# 5. Felrapportdokument

Hands on, detta är det mest kritiska QA-dokumentet du någonsin kommer att göra.

Följande är fälten som en bra felrapport måste ha:

  • Defekt-ID - Vanligtvis ett serienummer
  • Felbeskrivning - En rad förklaring av problemet
  • Plats - Modul / område för AUT där problemet finns
  • Byggnummer - Version och kodbyggnr.
  • Steg för att reproducera - Lista över steg som leder dig till problemet
  • Allvarlighetsgrad - Ställ in en nivå för att beskriva problemets allvar - Låg, medel, hög, blockerare etc.
  • Prioritet - Ställ in av utvecklare för att bestämma i vilken ordning defekten ska åtgärdas (P1, P2, P3, etc. P1- högst)
  • Tilldelad till - Ägaren av defekten vid den tidpunkten
  • Rapporterat av - Testers namn
  • Status - Olik status för att representera felet livscykel scenen
    • Nytt - Bugg hittas och rapporteras bara
    • Öppen - Validerad av QA-ledningen
    • Tilldelad - skickas till utvecklingsledningen för tilldelning till respektive utvecklare
    • In Progress / Work in Progress - Dev började arbeta med det
    • Fast / löst - Utvecklaren är klar med att arbeta med det
    • Verifierad / stängd - QA-teamet har testat om och hittat felet rättat
    • Omprövning - QA-teamet håller inte med Devs upplösning och fortsätter felet för omarbetning
    • Dubblett - Liknande fel finns redan
    • Uppskjuten - Giltigt fel men kommer att åtgärdas i senare versioner
    • Ogiltigt - Inte ett fel eller är inte reproducerbart eller det finns inte tillräckligt med information

Vidare läsning=>

# 6. Avloggningsprocess

Logga ut att skicka slutlig dokumentation är QA-chefens / chefens uppgift. Teamet måste emellertid skicka in ovanstående dokument (testscenario, testfall och defektloggdokument) för slutlig granskning och granskning.

Se till att du korrekturläser dem alla och skickar de slutliga versionerna.

Läs också=>

Slutsats

Detta är den process som jag har sett och upplevt från första hand när jag var testare och jag hoppas att detta har gett dig några användbara tips.

bästa programmet för att klona hårddisken

Slutligen har en karriär inom testning varit en absolut glädje för mig och jag hoppas att det är för dig också.

Allt det bästa för din karriär!

Rekommenderad läsning

^