Hvad er softwaretestning? 100+ Gratis vejledninger i manuel testning

En komplet vejledning i softwaretestning med 100+ vejledninger i manuel testning med definition af testning, typer, metoder og procesdetaljer:

Hvad er softwaretestning?

Softwaretestning er en proces, hvor man verificerer og validerer funktionaliteten af en applikation for at finde ud af, om den opfylder de specificerede krav. Det er processen med at finde fejl i en applikation og kontrollere, hvor applikationen fungerer i overensstemmelse med slutbrugerens krav.

Hvad er manuel testning?

Manuel testning er en proces, hvor du sammenligner opførslen af et udviklet stykke kode (software, modul, API, funktion osv.) med den forventede opførsel (krav).

Liste over tutorials om manuel softwaretestning

Dette er den mest dybdegående serie af tutorials om softwaretestning. Gennemgå de emner, der er nævnt i denne serie, omhyggeligt for at lære de grundlæggende og avancerede testteknikker.

Denne serie af tutorials vil berige din viden og vil til gengæld forbedre dine testfærdigheder.

Praktiser end-to-end manuel testning Gratis træning på et liveprojekt:

Tutorial #1: Grundlæggende om manuel softwaretestning
Tutorial #2: Introduktion til liveprojektet
Tutorial #3: Skrivning af testscenarier
Tutorial #4: Skriv et testplansdokument fra bunden
Tutorial #5: Skriv testtilfælde fra SRS-dokument
Tutorial #6: Testudførelse
Tutorial #7: Bug Tracking and Test Sign off
Tutorial #8: Kursus i softwaretestning

Software Testing Life-Cycle:

Tutorial #1: STLC

Webtestning:

Tutorial #1: Web Application Testing
Tutorial #2: Cross Browser Testing

Test Case Management:

Tutorial #1: Test Cases
Tutorial #2: Eksempel på skabelon til testtilfælde
Tutorial #3: Matrix for sporbarhed af krav (RTM)
Tutorial #4: Testdækning
Tutorial #5: Testdatahåndtering

Testhåndtering:

Tutorial #1: Teststrategi
Tutorial #2: Testplan-skabelon
Tutorial #3: Test Estimation
Tutorial #4: Test Management Tools
Tutorial #5: HP ALM Tutorial
Tutorial #6: HP ALM Tutorial
Tutorial #6: Jira
Tutorial #7: TestLink Tutorial

Testteknikker:

Tutorial #1: Use Case Testing
Tutorial #2: State Transition Testing
Tutorial #3: Boundary Value Analysis
Tutorial #4: Equivalence Partitioning
Tutorial #5: Software Testing Methodologies
Tutorial #6: Agile Methodology

Defect Management:

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

Funktionel testning

Tutorial #1: Unit Testing
Tutorial #2: Sanity og Smoke Testing
Tutorial #3: Regression Testing
Tutorial #4: System Testing
Tutorial #5: Acceptance Testing
Tutorial #6: Integration Testing
Tutorial #7: UAT User Acceptance Testing

Non-Functional Testing:

Tutorial #1: Non-Functional Testing
Tutorial #2: Performance Testing
Tutorial #3: Security Testing
Tutorial #4: Web Application Security Testing
Tutorial #5: Usability Testing
Tutorial #6: Kompatibilitetstest
Tutorial #7: Installationstest
Tutorial #8: Dokumentationstest

Software-testtyper:

Tutorial #1: Testtyper
Tutorial #2: Testtyper
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: Tilgængelighedstest
Tutorial #8: Negativ testning
Tutorial #9: Backend-testning
Tutorial #10: Alpha-testning
Tutorial #11: Betatestning
Tutorial #12: Alpha vs Beta Testing
Tutorial #13: Gamma Testing
Tutorial #14: ERP Testing
Tutorial #15: Statisk og dynamisk testning
Tutorial #16: Adhoc testing
Tutorial #17: Lokaliserings- og internationaliseringstest
Tutorial #18: Automatiseringstest
Tutorial #19: White box testing

Software Testing Career:

Tutorial #1: Choosing a Software Testing Career
Tutorial #2: How to Get QA Testing Job – Complete Guide
Tutorial #3: Career options for Testers
Tutorial #4: Career options for Testers
Tutorial #4: Skift fra ikke-IT til softwaretestning
Tutorial #5: Kick Start Your Manual Testing Career
Tutorial #6: Lessons Learned from 10 Years in Testing
Tutorial #7: Survive and Progress in Testing Field

Interview Preparation:

Tutorial #1: Overlev og gør fremskridt inden for testområdet

Tutorial #1: 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: Test af bankapplikation
Tutorial #2: Test af sundhedsplejeapplikation
Tutorial #3: Test af betalingsgateway
Tutorial #4: Test af POS-system
Tutorial #5: Test af e-handelswebsted

Test af QA-certificering:

Test af QA-certificering:

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

Advanced Manual Testing Topics:

Tutorial #1: Cyclomatic Complexity
Tutorial #2: Migration Testing
Tutorial #3: Cloud Testing
Tutorial #4: ETL Testing
Tutorial #5: Software Testing Metrics
Tutorial #6: Web Services

Gør dig klar til at tage et kig på den 1. tutorial i denne Manual Testing serie !!!!

Indledning til manuel softwaretestning

Manuel testning er en proces, hvor du sammenligner opførslen af et udviklet stykke kode (software, modul, API, funktion osv.) med den forventede opførsel (krav).

Og hvordan ved du, hvad der er den forventede opførsel?

Du ved det ved at læse eller lytte nøje til kravene og forstå dem fuldstændigt. Husk, at det er meget meget vigtigt at forstå kravene fuldstændigt.

Tænk dig selv som slutbruger af det, du skal teste. Herefter er du ikke længere bundet, til softwarekravdokumentet eller ordene i det. Du kan så forstå kernekravet og ikke kun kontrollere systemets adfærd i forhold til det, der er skrevet eller fortalt, men også i forhold til din egen forståelse og i forhold til ting, der ikke er skrevet eller fortalt.

Der kan til tider være et overset krav (ufuldstændigt krav) eller et implicit krav (noget, der ikke behøver at blive nævnt særskilt, men som bør opfyldes), og du skal også teste for dette.

Et krav behøver desuden ikke nødvendigvis at være et dokumenteret krav. Du kan meget vel have kendskab til softwarens funktionalitet, eller du kan endda gætte og derefter teste et trin ad gangen. Vi kalder det generelt ad hoc-testning eller udforskende testning.

Lad os se nærmere på det:

Først skal vi forstå det faktum – uanset om du sammenligner test af et softwareprogram eller noget andet (lad os sige et køretøj), er konceptet det samme. Tilgang, værktøjer og prioriteter kan være forskellige, men det centrale mål forbliver det SAMME, og det er SIMPELT, dvs. at sammenligne den faktiske adfærd med den forventede adfærd.

For det andet – Testning er som en holdning eller et mindset, der bør komme indefra. Færdigheder kan læres, men du vil kun blive en succesfuld tester, når du har nogle få kvaliteter i dig som standard. Når jeg siger, at testfærdigheder kan læres, mener jeg fokuseret og formel uddannelse omkring softwaretestprocessen.

Men hvad er kvaliteterne hos en succesfuld tester? Du kan læse om dem på nedenstående link:

Læs den her =>Qualities of Highly Effective Testers

Jeg anbefaler på det kraftigste, at du gennemgår ovenstående artikel, før du fortsætter med denne tutorial. Det vil hjælpe dig med at sammenligne dine egenskaber med dem, der forventes i softwaretesterens rolle.

For dem, der ikke har tid til at gennemgå artiklen, er her et resumé:

“Din nysgerrighed, opmærksomhed, disciplin, logiske tænkning, passion for arbejdet og evne til at dissekere ting betyder meget for at være en destruktiv og succesfuld tester. Det virkede for mig, og jeg er overbevist om, at det også vil virke for dig. Hvis du har disse kvaliteter i forvejen, så skal det også fungere for dig.”

Vi har talt om de centrale forudsætninger for at blive softwaretester. Lad os nu forstå, hvorfor manuel testning har og altid vil have sin selvstændige eksistens med eller uden vækst i automatiseringstestning.

Hvorfor manuel testning er nødvendig?

Ved du, hvad der er det bedste ved at være tester, også en manuel tester?

Det er det faktum, at du ikke kun kan stole på dine færdigheder her. Du er nødt til at have/udvikle og forbedre din tankeproces. Det er noget, du ikke rigtig kan købe for få penge. Du skal selv arbejde på det.

Du skal udvikle en vane med at stille spørgsmål, og du skal stille dem hvert minut, når du tester. For det meste bør du stille disse spørgsmål til dig selv frem for til andre.

Jeg håber, at du har gennemgået den artikel, som jeg anbefalede i det foregående afsnit (dvs. kvaliteterne hos meget effektive testere). Hvis ja, så ville du vide, at testning betragtes som en tankeproces, og hvor succesfuld du vil være som tester afhænger helt af de kvaliteter, du besidder som person.

Lad os se dette enkle flow:

• Du gør noget (udfører handlinger), mens du observerer det med en vis hensigt (sammenligner med det forventede). Nu kommer dine observationsevner og din disciplin til at udføre ting ind i billedet her.
• Voila! Hvad var det? Du lagde mærke til noget. Du bemærkede det, fordi du gav perfekt opmærksomhed til detaljerne foran dig. Du vil ikke lade det gå, fordi du er nysgerrig. Det var ikke i din plan, at der skulle ske noget uventet/underligt, du lægger mærke til det, og du vil undersøge det nærmere. Men nu gør du det. Du kan lade det gå. Men Du bør ikke lade det gå.
• Du er glad, du har fundet ud af årsagen, trinene og scenariet. Nu vil du kommunikere dette korrekt og konstruktivt til udviklingsteamet og de andre interessenter i dit team. Du kan gøre det via et fejlsporingsværktøj eller mundtligt, men du skal sørge for, at du kommunikerer det konstruktivt.
• Ops! Hvad hvis jeg gør det på den måde? Hvad hvis jeg indtaster rigtige heltal som input, men med ledende hvide mellemrum? Hvad nu hvis… Hvad nu hvis… Hvad nu hvis… Hvad nu hvis… Det slutter ikke let, det burde ikke slutte let. Du vil forestille dig en masse situationer & scenarier, og du vil faktisk også blive fristet til at udføre dem.

Diagrammet nedenfor repræsenterer en testers liv:

Læs de fire bullet points, der er nævnt ovenfor, en gang til. Lagde du mærke til, at jeg holdt det meget kort, men alligevel fremhævede den rigeste del af det at være en manuel tester? Og lagde du mærke til den fede fremhævning over et par ord? Det er netop de vigtigste kvaliteter, som en manuel tester har brug for.

Tænker du nu virkelig, at disse handlinger kan erstattes fuldstændigt af noget andet? Og den hotte trend i dag – kan de nogensinde blive erstattet af automatisering?

I SDLC med enhver udviklingsmetodologi er der få ting, der altid forbliver konstante. Som tester vil du forbruge kravene, konvertere dem til testscenarier/testcases. Du vil derefter udføre disse testcases eller direkte automatisere dem (jeg ved, at nogle få virksomheder gør det).

Når du automatiserer det, er dit fokus stabilt, hvilket er at automatisere de skrevne trin.

Lad os gå tilbage til den formelle del, dvs. at udføre de testcases, der er skrevet manuelt.

Her fokuserer du ikke kun på at udføre de skrevne testcases, men du udfører også en masse udforskende test, mens du gør det. Husker du, at du er nysgerrig? Og du vil forestille dig. Og du vil ikke kunne modstå, du vil faktisk gøre det, du forestillede dig.

Det nedenstående billede viser, hvordan det er forenklet at skrive testcases:

Jeg udfylder en formular, og jeg er færdig med at udfylde det første felt. Jeg er for doven til at gå efter musen for at skifte fokus til det næste felt. Jeg trykker på “tabulator”-tasten. Jeg er færdig med at udfylde det næste og sidste felt også, nu skal jeg klikke på Submit-knappen, fokus er stadig på det sidste felt.

Ops, jeg ramte ved et uheld ‘Enter’-tasten. Lad mig lige tjekke, hvad der er sket. ELLER der er en submit-knap, jeg vil dobbeltklikke på den. Jeg er ikke tilfreds. Jeg klikker på den flere gange, for hurtigt.

Har du bemærket det? Der er så mange mulige brugerhandlinger, både tilsigtede og ikke tilsigtede.

Det vil ikke lykkes dig at skrive alle testcases, der dækker din applikation under test 100 %. Det skal ske på en udforskende måde.

Du vil blive ved med at tilføje dine nye testcases, efterhånden som du tester applikationen. Det vil være testcases for fejl, som du er stødt på, og som der ikke tidligere var skrevet testcases for. Eller, mens du tester, udløste noget din tankeproces, og du fik et par testcases mere, som du gerne vil tilføje til din testcase suite og udføre.

Selv efter alt dette er der ingen garanti for, at der ikke er skjulte fejl. Software med nul fejl er en myte. Du kan kun sigte mod at bringe det tæt på nul, men det kan bare ikke ske uden en menneskelig hjerne, der hele tiden sigter mod det samme, svarende til, men ikke begrænset til, den eksempelproces, vi så ovenfor.

Der findes i hvert fald i dag ingen software, der vil tænke som en menneskelig hjerne, observere som et menneskeligt øje, stille spørgsmål og svare som et menneske og derefter udføre tilsigtede og ikke tilsigtede handlinger. Selv hvis en sådan ting sker, hvis sind, tanker og øjne vil den så efterligne? Dit eller mit? Vi mennesker er heller ikke den samme ret. Vi er alle forskellige. Så?

Nødvendigheden af manuel testning, når der er automatisering:

Automatiseringstestning har sin egen andel af ære i disse dage og vil få endnu mere i de kommende år, men den kan simpelthen ikke erstatte manuel QA-testning (læs menneskelig/udforskende testning).

Du har sikkert hørt før- “Man automatiserer ikke testning, man automatiserer kontrol”. Denne sætning siger meget om, hvor manuel QA-testning står med Automation testing omkring. Mange store navne over hele kloden har skrevet og talt om dette emne, så jeg vil ikke understrege meget på dette.

Automatisering kan ikke erstatte menneskelig testning fordi:

• Det kræver runtime-domme om alt, hvad der sker foran dine øjne (mens du tester) og i få tilfælde også bag kulisserne.
• Det kræver klar og konstant observation.
• Det kræver spørgsmålstegn.
• Det kræver en undersøgelse.
• Det kræver ræsonnement.
• Det kræver uplanlagte handlinger, som det er nødvendigt under testningen.

Testning kan erstattes af et værktøj/maskine, som vil være i stand til at absorbere detaljerne, behandle dem, kommandere handlinger og udføre dem som en menneskelig hjerne og et menneske, og alt dette på køretid og i alle mulige sammenhænge. Dette værktøj skal igen være som alle mulige mennesker.

Så kort sagt kan menneskelig testning ikke erstattes. Måske vil en Hollywood sci-fi film om nogle få år se tæt på det, men i det virkelige liv kan jeg ikke se det komme før om et par hundrede år, som jeg kan forestille mig. Jeg vil ikke afskrive det for evigt, da jeg tror på uendelige muligheder.

Selv om det virkelig sker efter et par hundrede år, er det billede, jeg kan forestille mig, helt sikkert en skræmmende verden. Age of Transformers. 🙂

=>> Anbefalet læsning – Best Manual Testing Service Companies

Hvordan Automation komplimenterer Manual Testing?

Jeg har sagt før og jeg siger det igen, at Automation ikke kan ignoreres længere. I en verden, hvor kontinuerlig integration, kontinuerlig levering og kontinuerlig implementering er ved at blive obligatoriske ting, kan kontinuerlig testning ikke sidde ubenyttet hen. Vi er nødt til at finde ud af måder at gøre det på.

De fleste gange hjælper det ikke i det lange løb at implementere mere og mere arbejdskraft til denne opgave. Derfor må testeren (testleder/arkitekt/manager) beslutte med forsigtighed, hvad der skal automatiseres, og hvad der stadig skal gøres manuelt.

Det bliver ekstremt vigtigt at have meget præcise tests/kontroller skrevet, så de kan automatiseres uden afvigelse fra den oprindelige forventning og kan bruges, mens man regresserer produktet som en del af ‘Continuous Testing’.

Bemærk: Ordet kontinuerlig fra udtrykket ‘Continuous Testing’ er underlagt betingede og logiske opfordringer i lighed med de andre udtryk, som vi har brugt ovenfor med samme præfiks. Kontinuerlig betyder i denne sammenhæng mere og oftere, hurtigere end i går. Mens det i betydningen meget vel kan betyde hvert sekund eller Nano-sekund.

Og uden at have et perfekt match mellem menneskelige testere og automatiserede kontroller (tests med præcise trin, forventet resultat og exitkriterier for den pågældende test dokumenteret) er det meget svært at opnå Continuous Testing, og det vil igen gøre Continuous Integration, Continuous Delivery og Continuous Deployment vanskeligere.

Jeg brugte bevidst udtrykket exitkriterier for en test ovenfor. Vores automatiseringsdragter kan ikke længere ligne de traditionelle dragter. Vi er nødt til at sikre, at hvis de fejler, skal de fejle hurtigt. Og for at få dem til at fejle hurtigt skal exitkriterierne også automatiseres.

Eksempel:

Lad os sige, der er en blockeringsfejl, hvor jeg ikke kan logge ind på Facebook.

Login-funktionalitet skal så være din første automatiserede kontrol, og din automatiseringssuite skal ikke køre den næste kontrol, hvor login er en forudsætning, som f.eks. at skrive en status. Du ved udmærket godt, at det er dømt til at mislykkes. Så få den til at fejle hurtigere, offentliggør resultaterne hurtigere, så fejlen kan blive løst hurtigere.

Næste ting er igen noget, som du må have hørt før – Du kan og bør ikke forsøge at automatisere alt.

Vælg testcases, som hvis de automatiseres, vil gavne de menneskelige testere betydeligt og har et godt afkast af investeringen. I den forbindelse er der en generel regel, der siger, at du bør forsøge at automatisere alle dine testcases med prioritet 1 og om muligt derefter prioritet 2.

Automatisering er ikke let at implementere og er tidskrævende, så det anbefales at undgå at automatisere cases med lav prioritet, i det mindste indtil du er færdig med de højprioriterede. At vælge, hvad der skal automatiseres og fokusere på det, forbedrer applikationskvaliteten, når det bruges og vedligeholdes kontinuerligt.

Slutning

Jeg håber, at du nu må have forstået, hvorfor og hvor meget manuel/menneskelig testning er nødvendig for at levere kvalitetsprodukter, og hvordan automatisering komplimenterer det.

Acceptere vigtigheden af QA manuel testning og vide, hvorfor den er speciel, er det allerførste skridt mod at blive en fremragende manuel tester.

I vores kommende tutorials om manuel testning vil vi dække en generisk tilgang til at udføre manuel testning, hvordan det vil eksistere sammen med automatisering og mange andre vigtige aspekter.

Jeg er sikker på, at du vil få enorm viden om softwaretestning, når du går igennem hele listen over tutorials i denne serie.