Meny

Vad är programvarutestning? 100+ gratis manuella testhandledning

what is software testing

Prova Vårt Instrument För Att Eliminera Problem

En komplett testguide för programvara med 100+ manuella testhandledning med testdefinition, typer, metoder och processdetaljer:

Vad är programvarutestning?

Programvarutestning är en process för att verifiera och validera funktionerna i ett program för att hitta om det uppfyller de angivna kraven. Det är processen att hitta fel i en applikation och kontrollera var applikationen fungerar enligt slutanvändarens krav.

Vad är manuell testning?

Manuell testning är en process där du jämför beteendet hos en utvecklad kod (programvara, modul, API, funktion, etc.) mot det förväntade beteendet (Krav).

Vad du kommer att lära dig:

Lista över handledning för testning av manuell programvara

Det här är den mest djupgående serien av självstudier om programvarutestning. Gå noggrant igenom ämnena i denna serie för att lära dig de grundläggande och avancerade testteknikerna.

Denna serie handledning skulle berika din kunskap och kommer i sin tur att förbättra dina testfärdigheter.

Öva manuell testning från slutet till slut Gratis utbildning på ett liveprojekt:

Handledning nr 1: Grunderna för manuell programvarutestning
Handledning nr 2: Live-projektintroduktion
Självstudie 3: Test Scenario Skriva
Självstudie 4: Skriv ett testplandokument från Scratch
Handledning nr 5: Skriva testfall från SRS-dokument
Självstudie nr 6: Testutförande
Handledning nr 7: Bug Tracking och Test Sign off
Självstudie 8: Programvarutestkurs

Programvarutestning livscykel:

Handledning nr 1: STLC

Webbtestning:

Handledning nr 1: Testning av webbapplikationer
Handledning nr 2: Cross Browser Testing

Testfallshantering:

hur man installerar .bin-filen

Handledning nr 1: Testfall
Handledning nr 2: Exempel på testfallsmall
Självstudie 3: Krav Spårbarhetsmatris (RTM)
Självstudie 4: Test täckning
Handledning nr 5: Testa datahantering

Testhantering:

Handledning nr 1: Teststrategi
Handledning nr 2: Testplanmall
Självstudie 3: Test uppskattning
Självstudie 4: Testhanteringsverktyg
Handledning nr 5: HP ALM-handledning
Självstudie nr 6: Jira
Handledning nr 7: TestLink-handledning

Tekniska tester:

Handledning nr 1: Använd falltestning
Handledning nr 2: Test av statlig övergång
Självstudie 3: Gränsvärde-analys
Självstudie 4: Partitionering av ekvivalens
Handledning nr 5: Testmetoder för programvara
Självstudie nr 6: Agil metodik

Defekthantering:

Handledning nr 1: Bug Life Cycle
Handledning nr 2: Felrapportering
Självstudie 3: Defektprioritet
Självstudie 4: Bugzilla Tutorial

Funktionell testning

Handledning nr 1: Enhetstestning
Handledning nr 2: Förnuft och rökprovning
Självstudie 3: Regressionstestning
Självstudie 4: Systemtestning
Handledning nr 5: Acceptantestning
Självstudie nr 6: Integrationstestning
Handledning nr 7: UAT-test för användaracceptans

Icke-funktionell testning:

Handledning nr 1: Icke-funktionell testning
Handledning nr 2: Prestandatester
Självstudie 3: Säkerhetstestning
Självstudie 4: Säkerhetstestning av webbapplikationer
Handledning nr 5: Testning av användbarhet
Självstudie nr 6: Kompatibilitetstestning
Handledning nr 7: Installationstestning
Självstudie 8: Dokumentationstestning

Programvarutestningstyper:

Handledning nr 1: Typer av testning
Handledning nr 2 : Testning av svart låda
Självstudie 3: Databastestning
Självstudie 4: Testning från slut till slut
Handledning nr 5: Exploratory Testing
Självstudie nr 6: Inkrementell testning
Handledning nr 7: Testning av tillgänglighet
Självstudie 8: Negativ testning
Handledning nr 9: Backend Testing
Handledning nr 10: Alpha Testing
Handledning nr 11: Betatestning
Handledning nr 12: Alpha vs Beta Testing
Handledning nr 13: Gammatestning
Handledning nr 14: ERP-testning
Handledning nr 15: Statisk och dynamisk testning
Handledning nr 16: Adhoc-testning
Handledning nr 17: Testning av lokalisering och internationalisering
Handledning nr 18: Automationstestning
Handledning nr 19: Vitlåda testning

Programvarutestkarriär:

Handledning nr 1: Välja en programvarutestkarriär
Handledning nr 2: Hur får man ett QA-testjobb - Komplett guide
Självstudie 3: Karriäralternativ för testare
Självstudie 4: Icke-IT till programvarutestningsbrytare
Handledning nr 5: Starta din manuella testkarriär
Självstudie nr 6: Lärdomar från tio års testning
Handledning nr 7: Överlev och framsteg inom testfältet

Intervjuförberedelse:

Handledning nr 1: Förberedelse av CV-CV
Handledning nr 2: Manuella testintervjuer
Självstudie 3: Intervjufrågor om automatiseringstest
Självstudie 4: QA-intervjufrågor
Handledning nr 5: Hantera alla jobbintervjuer
Självstudie nr 6: Få testjobb som en fräschare

Testa olika domänapplikationer:

Handledning nr 1 : Testning av bankansökan
Handledning nr 2: Testning av hälso- och sjukvårdstillämpningar
Självstudie 3: Payment Gateway Testing
Självstudie 4: Testplats för försäljning (POS)
Handledning nr 5: Testning av e-handelswebbplatser

Testa QA-certifiering:

Handledning nr 1: Guide för certifiering av programvarutestning
Handledning nr 2: CSTE-certifieringsguide
Självstudie 3: CSQA-certifieringsguide
Självstudie 4: ISTQB-guide
Handledning nr 5: ISTQB Advanced

Avancerade ämnen för manuell testning:

Handledning nr 1: Cyklomatisk komplexitet
Handledning nr 2: Migration Testing
Självstudie 3: Molntestning
Självstudie 4: ETL-testning
Handledning nr 5: Programvarutestning
Självstudie nr 6: Webbservice

Gör dig redo att ta en titt på den första handboken i denna Manual Testing-serie !!!

Introduktion till manuell programvarutestning

Manuell testning är en process där du jämför beteendet hos en utvecklad kod (programvara, modul, API, funktion, etc.) mot det förväntade beteendet (Krav).

Och hur vet du vad som är förväntat beteende?

Du kommer att veta det genom att läsa eller lyssna på kraven noggrant och förstå det helt. Kom ihåg att förstå kraven helt är mycket viktigt.

hur man lägger till element i en array-Java

Tänk dig själv som en slutanvändare av vad du ska testa. Därefter är du inte bunden till programvarukravsdokumentet eller orden i det längre. Du kan sedan förstå kärnkravet och inte bara kontrollera systemets beteende mot det som skrivs eller berättas utan också mot din egen förståelse och mot saker som inte är skrivna eller berättade.

Ibland kan det vara ett missat krav (ofullständigt krav) eller implicit krav (något som inte behöver nämnas separat men som ska uppfyllas), och du måste också testa för detta.

Vidare behöver ett krav inte nödvändigtvis vara dokumenterat. Du kan mycket väl ha kunskap om programvarans funktionalitet eller du kan till och med gissa och sedan testa ett steg i taget. Vi kallar det i allmänhet ad hoc-testning eller utforskande testning.

Låt oss ta en djupgående titt:

Låt oss först förstå fakta - Oavsett om du jämför testning av en programvara eller något annat (låt oss säga ett fordon), förblir konceptet detsamma. Tillvägagångssätt, verktyg och prioriteringar kan skilja sig, men huvudmålet förblir Samma och det är ENKEL, dvs att jämföra det faktiska beteendet med det förväntade beteendet.

För det andra - Testning är som en attityd eller tänkesätt som ska komma inifrån. Färdigheter kan läras in, men du blir bara en framgångsrik testare när du har några kvaliteter inom dig som standard. När jag säger att testfärdigheter kan läras menar jag fokuserad och formell utbildning kring programvarutestningsprocessen.

Men vad är egenskaperna hos en framgångsrik testare? Du kan läsa om dem på länken nedan:

Läs det här => Högeffektiva testares egenskaper

Jag rekommenderar starkt att du går igenom artikeln ovan innan du fortsätter med den här handledningen. Det hjälper dig att jämföra dina egenskaper mot de som förväntas i Software Testers roll.

För de som inte har tid att gå igenom artikeln, här är en sammanfattning:

“Din nyfikenhet, uppmärksamhet, disciplin, logiska tänkande, passion för arbete och förmåga att dissekera saker betyder mycket för att vara en destruktiv och framgångsrik testare. Det fungerade för mig och jag tror starkt att det också kommer att fungera för dig. Om du redan har dessa egenskaper måste det verkligen fungera för dig. ”

Vi har pratat om de viktigaste förutsättningarna för blir en mjukvarutestare. Låt oss nu förstå varför manuell testning har och alltid kommer att ha sin oberoende existens med eller utan automatiseringstesttillväxt.

Varför krävs manuell testning?

Vet du vad som är det bästa med att vara testare, det också en manuell testare?

Det är det faktum att du inte bara kan lita på kompetens här. Du måste ha / utveckla och förbättra din tankeprocess. Det här är något du inte kan köpa för några få dollar. Du måste själv arbeta med det.

Du måste utveckla vanan att ställa frågor och du måste fråga dem varje minut när du testar. Oftast bör du ställa dessa frågor till dig själv än till andra.

Jag hoppas att du har gått igenom artikeln som jag rekommenderade i föregående avsnitt (dvs. egenskaperna hos mycket effektiva testare). Om ja, skulle du veta att testning anses vara en tankeprocess och hur framgångsrik du kommer att bli som testare beror helt på de egenskaper du har som person.

Låt oss se detta enkla flöde:

  • Du gör något ( utföra åtgärder ) medan du observerar det med viss avsikt (jämför med det förväntade). Nu din observation färdigheter och disciplin att utföra saker kommer in i bilden här.
  • Voila! Vad var det? Du märkte något. Du märkte det för att du gav perfekt uppmärksamhet på detaljerna framför er. Du kommer inte att släppa det för att du är det nyfiken . Det var inte i din plan att något oväntat / konstigt kommer att hända, du kommer att märka det och du kommer att undersöka det vidare. Men nu gör du det. Du kan släppa det. Men du ska inte släppa det.
  • Du är glad, du fick reda på orsaken, stegen och scenariot. Nu kommer du att kommunicera detta ordentligt och konstruktivt till utvecklingsteamet och de andra intressenterna i ditt team. Du kan göra det via något spårningsverktyg eller muntligt, men du måste se till att du är kommunicera det konstruktivt .
  • hoppsan! Vad händer om jag gör det på det sättet? Vad händer om jag anger rätt heltal som inmatning men med ledande vita mellanslag? Tänk om? … Tänk om? … Tänk om? Det slutar inte lätt, det borde inte sluta lätt. Du kommer tänka många situationer och scenarier och du kommer verkligen att frestas att utföra dem också.

Diagrammet nedan representerar testarens liv:

Life of a Tester

Läs igenom de fyra punkterna som nämns ovan igen. Märkte du att jag höll det mycket kort men ändå markerade den rikaste delen av att vara en manuell testare? Och märkte du den djärva markeringen över några ord? Det är just de viktigaste egenskaperna som en manuell testare behöver.

Tror du verkligen att dessa handlingar helt kan ersättas med något annat? Och den heta trenden idag - kan den någonsin ersättas med automatisering?

I SDLC med någon utvecklingsmetod förblir alltid få saker konstanta. Som testare kommer du att konsumera kraven, konvertera dem till testscenarier / testfall. Du kommer sedan att utföra dessa testfall eller automatisera dem direkt (jag vet att några företag gör det).

När du automatiserar det är ditt fokus stadigt, vilket automatiserar de skrivna stegen.

Låt oss gå tillbaka till den formella delen, dvs. genomföra de testfall som är skrivna manuellt.

Här fokuserar du inte bara på att utföra de skriftliga testfallet, utan du utför också mycket utforskande testning medan du gör det. Kommer du ihåg att du är nyfiken? Och du kommer att föreställa dig. Och du kommer inte att kunna motstå, du kommer verkligen göra vad du trodde.

Bilden nedan visar hur Test Case-skrivning förenklas:

Test Fall Writing Förenklad

Jag fyller i ett formulär och jag är klar med att fylla i det första fältet. Jag är för lat för att gå för musen för att flytta fokus till nästa fält. Jag trycker på 'tab' -tangenten. Jag är klar med att fylla i nästa och sista fält också, nu måste jag klicka på knappen Skicka, fokus är fortfarande på det sista fältet.

Oj, jag slog av misstag på Enter-tangenten. Låt mig kontrollera vad som hände. ELLER det finns en skicka-knapp, jag dubbelklickar på den. Inte tillfredsställd. Jag klickar på den flera gånger, för snabbt.

Märkte du? Det finns så många möjliga användaråtgärder, både avsedda och icke avsedda.

Du kommer inte att kunna skriva alla testfall som täcker din ansökan som testas 100%. Detta måste ske på ett utforskande sätt.

Du fortsätter att lägga till dina nya testfall när du testar applikationen. Dessa kommer att vara testfall för buggar som du stött på och som tidigare inte skrivits något testfall. Eller, medan du testar, utlöste något din tankeprocess och du har några fler testfall som du vill lägga till i din testfallssituation och utföra.

Även efter allt detta finns det ingen garanti för att det inte finns någon dolda buggar . Programvara med noll buggar är en myt. Du kan bara rikta dig mot att ta det nära Zero men det kan bara inte hända utan att ett mänskligt sinne kontinuerligt riktar in sig på samma, liknande men inte begränsat till exempelprocessen vi såg ovan.

Åtminstone idag finns det ingen programvara som kommer att tänka som ett mänskligt sinne, observera som ett mänskligt öga, ställa frågor och svara som en människa och sedan utföra avsedda och icke-avsedda handlingar. Även om sådant händer, vems sinne, tankar och öga kommer det att efterlikna? Din eller min? Vi människor är inte heller samma rätt. Vi är alla olika. Sedan?

Behov av manuell testning när automatisering är runt:

Automation Testing har sin egen andel av ära idag och kommer att ha ännu mer under de kommande åren, men det kan helt enkelt inte ersätta manuell QA-testning (läs mänsklig / utforskande testning).

Du måste ha hört förut- Du automatiserar inte testning utan du kontrollerar automatiskt ”. Denna mening talar mycket om var manuell QA-testning står med Automation-testning runt. Många stora namn över hela världen har skrivit och talat om detta ämne, så jag kommer inte att betona mycket på detta.

Automation kan inte ersätta mänsklig testning eftersom:

  • Det kräver runtime-bedömningar om allt som händer framför dina ögon (medan du testar) och i få fall också bakom kulisserna.
  • Det kräver tydlig och ständig observation.
  • Det kräver frågande.
  • Det kräver en utredning.
  • Det kräver resonemang.
  • Det kräver oplanerade åtgärder som krävs under testningen.

Testning kan ersättas med ett verktyg / maskin som kommer att kunna absorbera detaljerna, bearbeta dem, kommandot och utföra dem som ett mänskligt sinne och en människa, och allt detta vid körning och i alla möjliga sammanhang. Detta verktyg måste återigen vara som alla möjliga människor.

Så kort sagt, mänskliga tester kan inte ersättas. Kanske kommer någon Hollywood-sci-fi-film om några år att se nära den, men i verkligheten kan jag inte se att den kommer på några hundra år, som jag kan föreställa mig. Jag kommer inte att skriva av det för alltid eftersom jag tror på oändliga möjligheter.

På en separat anteckning, även om det verkligen händer efter några hundra år, kan jag föreställa mig bilden av en läskig värld. Age of Transformers. :)

= >> Rekommenderad läsning - Bästa företag för manuell testtjänst

Hur kompletterar automatisering manuell testning?

Jag sa tidigare och jag säger det igen att Automation inte längre kan ignoreras. I världen där kontinuerlig integration, kontinuerlig leverans och kontinuerlig distribution blir obligatoriska saker kan kontinuerlig testning inte sitta tomgång. Vi måste ta reda på hur vi kan göra det.

För det mesta hjälper det inte på lång sikt att använda mer och mer arbetskraft för den här uppgiften. Därför måste testaren (testledare / arkitekt / chef) besluta försiktigt om vad som ska automatiseras och vad som fortfarande ska göras manuellt.

Det blir oerhört viktigt att ha mycket exakta test / kontroller skrivna så att de kan automatiseras utan någon avvikelse från den ursprungliga förväntningen och kan användas samtidigt som produkten sänks tillbaka som en del av ”kontinuerlig testning”.

Notera: Ordet kontinuerligt från termen 'kontinuerlig testning' utsätts för villkorliga och logiska samtal som liknar de andra termer som vi använde ovan med samma prefix. Kontinuerlig i detta sammanhang betyder allt oftare, snabbare än igår. Medan det betyder kan det mycket väl betyda varje sekund eller Nano-sekund.

Utan att ha en perfekt matchning av mänskliga testare och automatiserade kontroller (test med exakta steg, förväntade resultat- och utgångskriterier för nämnda test dokumenterade) är det mycket svårt att uppnå kontinuerlig testning och detta kommer i sin tur att göra kontinuerlig integration, kontinuerlig leverans och kontinuerlig distribution svårare.

Jag använde medvetet termen utgångskriterier för ett test ovan. Våra automatiseringsdräkter kan inte likna de traditionella längre. Vi måste se till att om de misslyckas ska de misslyckas snabbt. Och för att få dem att misslyckas snabbt bör utgångskriterier också automatiseras.

Exempel:

Låt oss säga att det finns en blockeringsfel där jag inte kan logga in på Facebook.

Inloggningsfunktionaliteten måste då vara din första automatiska kontroll och din automatiseringspaket ska inte köra nästa kontroll där inloggning är en förutsättning, som att skicka en status. Du vet mycket väl att det kommer att misslyckas. Så få det att misslyckas snabbare, publicera resultaten snabbare så att felet kan lösas snabbare.

Nästa sak är igen något som du måste ha hört förut - Du kan inte och bör inte försöka automatisera allt.

Välj testfall som, om automatiserade, kommer att gynnas avsevärt till Human Testers och har en bra avkastning på investeringen. För den delen finns det en allmän regel som säger att du bör försöka automatisera alla dina Priority 1-testfall och om möjligt sedan Priority 2.

Automation är inte lätt att implementera och är tidskrävande, så det rekommenderas att undvika att automatisera fall med låg prioritet åtminstone till den tid du är klar med de höga. Att välja vad som ska automatiseras och fokusera på det förbättrar applikationskvaliteten när den används och underhålls kontinuerligt.

Slutsats

Jag hoppas att du nu måste ha förstått varför och hur dåligt manuell / mänsklig testning krävs för att leverera kvalitetsprodukter och hur Automation komplimangerar det.

Att acceptera vikten av QA manuell testning och veta varför det är speciellt är det allra första steget mot att vara en utmärkt manuell testare.

I våra kommande manuella testhandledningar kommer vi att täcka ett generiskt tillvägagångssätt för att göra manuell testning, hur det kommer att existera tillsammans med Automation och många andra viktiga aspekter också.

Jag är säker på att du kommer att få enorm kunskap om programvarutestning när du har gått igenom hela listan med självstudier i denna serie.

intervjufrågor om tvål och vila

Vi skulle gärna höra från dig. Uttryck gärna dina tankar / förslag i kommentarfältet nedan.

Rekommenderad läsning

^