Vad är mjukvarutestning? 100+ gratis handledning i manuell testning

En komplett guide för mjukvarutestning med 100+ handledning i manuell testning med definition av testning, typer, metoder och processdetaljer:

Vad är mjukvarutestning?

Mjukvarutestning är en process där man verifierar och validerar funktionaliteten hos en applikation för att ta reda på om den uppfyller de angivna kraven. Det är processen för att hitta defekter 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 ett utvecklat stycke kod (programvara, modul, API, funktion, etc.) mot det förväntade beteendet (kraven).

Lista över handledningar för manuell programvarutestning

Detta är den mest djupgående serien av handledningar om programvarutestning. Gå igenom de ämnen som nämns i denna serie noggrant för att lära dig grundläggande och avancerade testtekniker.

Denna serie handledningar kommer att berika dina kunskaper och kommer i sin tur att förbättra dina testkunskaper.

Praktisera manuell testning från början till slut gratis utbildning i ett levande projekt:

Tutorial #1: Grunderna i manuell programvarutestning
Tutorial #2: Introduktion till ett levande projekt
Tutorial #3: Skrivning av testscenarion
Tutorial #4: Skriv ett testplanedokument från början
Tutorial #5: Skrivning av testfall från SRS-dokument
Tutorial #6: Testutförande
Tutorial #7: Bug Tracking and Test Sign off
Tutorial #8: Kurs i programvarutestning

Livscykel för programvarutestning:

Tutorial #1: STLC

Webbtestning:

Tutorial #1: Testning av webbapplikationer
Tutorial #2: Cross Browser Testing

Test Case Management:

Tutorial #1: Test Cases
Tutorial #2: Test Cases
Tutorial #2: Test Case Management: Mall för exempel på testfall
Talare 3: Matris för spårbarhet av krav (RTM)
Talare 4: Testtäckning
Talare 5: Hantering av testdata

Testhantering: Testhantering: Det är viktigt att veta hur man hanterar testfall:

Tutorial #1: Teststrategi
Tutorial #2: Mall för testplan
Tutorial #3: Testskattning
Tutorial #4: Testhanteringsverktyg
Tutorial #5: HP ALM Tutorial
Tutorial #6: Jira
Tutorial #7: TestLink Tutorial

Testtekniker:

Tutorial #1: Testning av användningsfall
Tutorial #2: Testning av tillståndsövergångar
Tutorial #3: Analys av gränsvärden
Tutorial #4: Equivalenspartitionering
Tutorial #5: Metodik för testning av mjukvara
Tutorial #6: Agil metodik

Felhanteringsmetoder:

Tutorial #1: Bug Life Cycle
Tutorial #2: Bug Reporting
Tutorial #3: Defect Priority
Tutorial #4: Bugzilla Tutorial

Funktionell testning

Tutorial #1: Unit Testing
Tutorial #2: Sanity and Smoke Testing
Tutorial #3: Regression Testing
Tutorial #4: System Testing
Tutorial #5: Acceptanstestning
Tutorial #6: Integrationstestning
Tutorial #7: UAT Användaracceptanstestning

Non-funktionell testning:

Tutorial #1: Icke-funktionell testning
Tutorial #2: Prestandatestning
Tutorial #3: Säkerhetstestning
Tutorial #4: Testning av webbapplikationssäkerheten
Tutorial #5: Testning av användbarhet
Tutorial #6: Kompatibilitetstestning
Tutorial #7: Installationstestning
Tutorial #8: Dokumentationstestning

Mjukvarutestningstyper:

Tutorial #1: Testningstyper
Tutorial #2: Black box Testing
Tutorial #3: Database Testing
Tutorial #4: End to end Testing
Tutorial #5: Exploratory Testing
Tutorial #6: Incremental Testing
Tutorial #7: Tillgänglighetstestning
Tutorial #8: Negativ testning
Tutorial #9: Backend-testning
Tutorial #10: Alfa-testning
Tutorial #11: Betatestning
Tutorial #12: Alpha vs Beta Testing
Tutorial #13: Gamma Testing
Tutorial #14: ERP Testing
Tutorial #15: Static and Dynamic Testing
Tutorial #16: Adhoc Testing
Tutorial #17: Testning av lokalisering och internationalisering
Tutorial #18: Automatiseringstestning
Tutorial #19: White box testing

Mjukvarutestningskarriär:

Tutorial #1: Att välja en mjukvarutestningskarriär
Tutorial #2: Hur man får ett jobb som QA-testare – komplett guide
Tutorial #3: Karriäralternativ för testare
Tutorial #4: Hur man får ett jobb som QA-testare
Tutorial #3: Karriäralternativ för testare
Tutorial #4: Omställning från icke-IT till mjukvarutestning
Tutorial #5: Starta din karriär inom manuell testning
Tutorial #6: Lärdomar från 10 år inom testning
Tutorial #7: Överleva och göra framsteg inom testning

Förberedelser för intervjuer:

Tutorial #1: Förberedelser för intervjuer: Förberedelser för intervjuer:

Tutorial #1: Förberedelser för intervjuer: QA Resume Preparation
Tutorial #2: Manual Testing Interview Questions
Tutorial #3: Automation Testing Interview Questions
Tutorial #4: QA Interview Questions
Tutorial #5: Handle Any Job Interview
Tutorial #6: Get Testing Job as a Fresher

Testing Different Domain Application:

Tutorial #1: Testning av banktillämpningar
Tutorial #2: Testning av hälsovårdstillämpningar
Tutorial #3: Testning av betalningsgateway
Tutorial #4: Testning av POS-system
Tutorial #5: Testning av e-handelswebbplatser

Testning av QA-certifiering:

Testning av QA-certifiering:

Tutorial #1: Software Testing Certification Guide
Tutorial #2: CSTE Certification Guide
Tutorial #3: CSQA Certification Guide
Tutorial #4: ISTQB Guide
Tutorial #5: ISTQB Advanced

Temanuella testningsämnen för avancerade testningar:

Tutorial #1: Tema nr 2: Migrationstestning
Tema nr 3: Molntestning
Tema nr 4: ETL-testning
Tema nr 5: Mätetal för programvarutestning
Tema nr 6: Webbtjänster

Var beredd att ta en titt på den första handledningen i denna serie om manuell testning!!!

Introduktion till manuell programvarutestning

Manuell testning är en process där du jämför beteendet hos ett utvecklat kodstycke (programvara, modul, API, funktion, etc.) mot det förväntade beteendet (krav).

Och hur vet du vad som är det förväntade beteendet?

Det vet du genom att läsa eller lyssna på kraven noggrant och förstå dem helt och hållet. Kom ihåg att det är mycket viktigt att förstå kraven helt och hållet.

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

I vissa fall kan det vara ett missat krav (ofullständigt krav) eller ett underförstått krav (något som inte behöver nämnas separat men som bör uppfyllas), och du måste testa för detta också.

För övrigt behöver ett krav inte nödvändigtvis vara ett dokumenterat krav. 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 brukar kalla det för ad hoc-testning eller explorativ testning.

Låt oss titta på djupet:

Först ska vi förstå faktumet – oavsett om du jämför testning av en programvaruapplikation eller något annat (låt oss säga ett fordon), så förblir konceptet detsamma. Tillvägagångssätt, verktyg och prioriteringar kan skilja sig åt, men kärnmålet förblir detsamma och det är ENKELT, dvs. att jämföra det faktiska beteendet med det förväntade beteendet.

För det andra – Testning är som en attityd eller ett tankesätt som bör komma inifrån. Färdigheter kan man lära sig, men du blir en framgångsrik testare först när du har några egenskaper inom dig som standard. När jag säger att man kan lära sig testkunskaper menar jag fokuserad och formell utbildning kring mjukvarutestningsprocessen.

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

Läs den här =>Qualities of Highly Effective Testers

Jag rekommenderar starkt att du går igenom ovanstående artikel innan du fortsätter med denna handledning. Den kommer att hjälpa dig att jämföra dina egenskaper med dem som förväntas i rollen som mjukvarutestare.

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

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

Vi har talat om de viktigaste förutsättningarna för att bli mjukvarutestare. Nu ska vi förstå varför manuell testning har och alltid kommer att ha sin självständiga existens, med eller utan tillväxt av automatiseringstestning.

Varför manuell testning krävs?

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

Det är det faktum att du inte bara kan förlita dig på dina färdigheter. Du måste ha/utveckla och förbättra din tankeprocess. Detta är något man 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 ställa dem varje minut när du testar. Oftast bör du ställa dessa frågor till dig själv snarare än till andra.

Jag hoppas att du har gått igenom den artikel som jag rekommenderade i det föregående avsnittet (dvs. egenskaperna hos mycket effektiva testare). Om ja, då vet du att testning anses vara en tankeprocess och hur framgångsrik du blir som testare beror helt och hållet på de egenskaper som du besitter som person.

Låt oss se det här enkla flödet:

• Du gör något (utför handlingar) samtidigt som du observerar det med en viss avsikt (jämför mot det förväntade). Nu kommer din observationsförmåga och disciplin att utföra saker in i bilden här.
• Voila! Vad var det där? Du lade märke till något. Du märkte det eftersom du gav perfekt uppmärksamhet åt detaljerna framför dig. Du släpper det inte för att du är nyfiken. Detta fanns inte med i din plan att något oväntat/konstigt skulle hända, du kommer att lägga märke till det och du kommer att undersöka det vidare. Men nu gör du det. Du kan släppa det. Men Du bör inte låta det gå.
• Du är nöjd, du har tagit reda på orsaken, stegen och scenariot. Nu kommer du att kommunicera detta på ett korrekt och konstruktivt sätt till utvecklingsteamet och de andra intressenterna i ditt team. Du kanske gör det via något felspårningsverktyg eller muntligt, men du måste se till att du kommunicerar det på ett konstruktivt sätt.
• Oj! Vad händer om jag gör det på det sättet? Vad händer om jag skriver in rätt heltal som indata men med inledande vitrymder? Tänk om? … Tänk om? … Tänk om? Det slutar inte lätt, det borde inte sluta lätt. Du kommer att föreställa dig många situationer & scenarier och du kommer faktiskt att frestas att utföra dem också.

Diagrammet nedan representerar en testares liv:

Läs de fyra punkter som nämns ovan en gång till. Märkte du att jag höll det väldigt kort men ändå lyfte fram den rikaste delen av att vara en manuell testare? Och lade du märke till den feta 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 av något annat? Och den heta trenden idag – kan de någonsin ersättas med automatisering?

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

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

Låt oss gå tillbaka till den formella delen, dvs. att utföra de testfall som skrivits manuellt.

Här fokuserar du inte bara på att utföra de skrivna testfallen, utan du utför också en hel del utforskande testning medan du gör det. Minns du att du är nyfiken? Och du kommer att föreställa dig. Och du kommer inte att kunna motstå, du kommer faktiskt att göra det du föreställde dig.

Bilden nedan visar hur skrivandet av testfall förenklas:

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

Oj, jag råkade trycka på ”Enter”-tangenten. Låt mig kontrollera vad som hände. ELLER det finns en submit-knapp, jag dubbelklickar på den. Jag är inte nöjd. Jag klickar på den flera gånger, för snabbt.

Har du märkt det? Det finns så många möjliga användarhandlingar, både avsedda och icke avsedda.

Du kommer inte att lyckas skriva alla testfall som täcker din applikation under test till 100 %. Detta måste ske på ett utforskande sätt.

Du kommer att fortsätta 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 för vilka det tidigare inte fanns något testfall skrivet. Eller så är det något som under testningen har satt igång din tankeprocess och du har fått fram ytterligare några testfall som du vill lägga till i din testfallssvit och utföra.

Även efter allt detta finns det ingen garanti för att det inte finns några dolda buggar. Mjukvara med noll fel är en myt. Du kan bara sikta på att få den nära noll, men det kan inte ske utan ett mänskligt sinne som kontinuerligt siktar på samma sak, i likhet med, men inte begränsat till, den exempelprocess som vi såg ovan.

Tillminstone i dagsläget finns det ingen programvara som tänker som ett mänskligt sinne, observerar som ett mänskligt öga, ställer frågor och svarar som en människa och sedan utför avsedda och icke avsedda åtgärder. Även om något sådant skulle hända, vems sinne, tankar och öga kommer det att efterlikna? Din eller min? Vi människor har inte heller samma rätt. Vi är alla olika. Då?

Nödvändigheten av manuell testning när det finns automatisering:

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

Du måste ha hört förut – ”Man automatiserar inte testning, man automatiserar kontroll”. Denna mening säger en hel del om var den manuella QA-testningen står i förhållande till automatiserad testning. 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-domar om allt som händer framför ögonen på dig (medan du testar) och i några få fall bakom kulisserna också.
• Det kräver tydlig och ständig observation.
• Det kräver ifrågasättande.
• Det kräver en utredning.
• Det kräver resonemang.
• Det kräver oplanerade åtgärder som krävs under testningen.

Testning kan ersättas av ett verktyg/maskin som kommer att kunna ta till sig detaljerna, bearbeta dem, beordra åtgärder 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änsklig testning kan inte ersättas. Kanske någon Hollywood sci-fi-film om några år kommer att se nära på det, men i verkligheten kan jag inte se det komma på några hundra år, som jag kan föreställa mig. Jag kommer inte att avskriva det för alltid eftersom jag tror på oändliga möjligheter.

En annan sak, även om det verkligen sker efter några hundra år, är den bild jag kan föreställa mig en skrämmande värld förvisso. Age of Transformers. 🙂

=>> Rekommenderad läsning – Best Manual Testing Service Companies

Hur automatisering kompletterar manuell testning?

Jag har sagt tidigare och jag säger det igen att automatisering inte kan ignoreras längre. I en värld där kontinuerlig integration, kontinuerlig leverans och kontinuerlig driftsättning blir obligatoriska saker, kan kontinuerlig testning inte sitta still. Vi måste ta reda på hur vi ska göra det.

För det mesta hjälper det inte i längden att distribuera mer och mer arbetskraft för den här uppgiften. Därför måste testaren (testledare/arkitekt/chef) försiktigt avgöra vad som ska automatiseras och vad som fortfarande ska göras manuellt.

Det blir allt viktigare att ha mycket exakta tester/kontroller skrivna så att de kan automatiseras utan någon avvikelse från de ursprungliga förväntningarna och kan användas när produkten utvecklas som en del av ”kontinuerlig testning”.

Notera: Ordet ”continuous” i termen ”Continuous Testing” är föremål för villkorliga och logiska uppmaningar som liknar de andra termer som vi använde ovan med samma prefix. Kontinuerlig betyder i detta sammanhang mer och oftare, snabbare än igår. Medan det i betydelsen mycket väl kan betyda varje sekund eller nanosekund.

Om man inte har en perfekt matchning av mänskliga testare och automatiserade kontroller (tester med exakta steg, förväntat resultat och utträdeskriterier för det nämnda testet dokumenterade), är det mycket svårt att uppnå kontinuerlig testning och detta kommer i sin tur att försvåra kontinuerlig integrering, kontinuerlig leverans och kontinuerlig driftsättning.

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

Exempel:

Säg att det finns ett blockeringsfel där jag inte kan logga in på Facebook.

Inloggningsfunktionaliteten måste då vara din första automatiserade kontroll och din automatiseringsföljd bör inte köra nästa kontroll där inloggning är en förutsättning, t.ex. att publicera en status. Du vet mycket väl att det är dömt att misslyckas. Så få den att misslyckas snabbare, publicera resultaten snabbare så att felet kan lösas snabbare.

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

Välj testfall som, om de automatiseras, kommer att vara till stor nytta för de mänskliga testarna och som har en god avkastning på investeringen. Det finns en allmän regel som säger att du bör försöka automatisera alla dina testfall med prioritet 1 och om möjligt sedan prioritet 2.

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

Slutsats

Jag hoppas att du vid det här laget måste ha förstått varför och hur mycket manuell/mänsklig testning krävs för att leverera kvalitetsprodukter och hur automatiseringen komplimenterar den.

Acceptera betydelsen av manuell testning av kvalitetssäkring och veta varför den är speciell, är det allra första steget mot att bli en utmärkt manuell testare.

I våra kommande handledningar om manuell testning kommer vi att täcka ett generiskt tillvägagångssätt för att göra manuell testning, hur det kommer att samexistera med automatisering och många andra viktiga aspekter också.

Jag är säker på att du kommer att få enorma kunskaper om mjukvarutestning när du går igenom hela listan med handledningar i denna serie.