what is software testing
En komplett programvaretestguide med 100+ manuelle testveiledninger med testdefinisjon, typer, metoder og prosessdetaljer:
Hva er programvaretesting?
Programvaretesting er en prosess for å verifisere og validere funksjonaliteten til et program for å finne ut om det oppfyller de spesifiserte kravene. Det er prosessen med å finne feil i en applikasjon og sjekke hvor applikasjonen fungerer i henhold til sluttbrukerens krav.
Hva er manuell testing?
Manuell testing er en prosess der du sammenligner oppførselen til en utviklet kode (programvare, modul, API, funksjon osv.) Mot forventet oppførsel (Krav).
Hva du vil lære:
Liste over manuelle programvaretester
Dette er den mest grundige opplæringsserien om programvaretesting. Gå nøye gjennom emnene nevnt i denne serien for å lære de grunnleggende og avanserte testteknikkene.
Denne opplæringsserien vil berike din kunnskap og vil i sin tur forbedre testferdighetene dine.
Øv på Manuell testing fra end-to-end gratis trening på et live-prosjekt:
Opplæring # 1: Grunnleggende om manuell programvaretesting
Opplæring nr. 2: Live Project introduksjon
Opplæring # 3: Test Scenario Writing
Opplæring # 4: Skriv et testplan-dokument fra Scratch
Opplæring # 5: Skrive testtilfeller fra SRS-dokument
Opplæring # 6: Testutførelse
Opplæring # 7: Feilsøking og testavmelding
Opplæring # 8: Programvare Testing Course
Programvare Testing livssyklus:
Opplæring # 1: STLC
Nettprøving:
Opplæring # 1: Testing av webapplikasjon
Opplæring nr. 2: Cross Browser Testing
Test saksbehandling:
hvordan du kjører .jar filer
Opplæring # 1: Test tilfeller
Opplæring nr. 2: Eksempel på mal for prøvesaker
Opplæring # 3: Krav Sporbarhetsmatrise (RTM)
Opplæring # 4: Test dekning
Opplæring # 5: Test datahåndtering
Testledelse:
Opplæring # 1: Teststrategi
Opplæring nr. 2: Testplanmal
Opplæring # 3: Testestimering
Opplæring # 4: Test Management Tools
Opplæring # 5: HP ALM-opplæring
Opplæring # 6: Jira
Opplæring # 7: TestLink opplæring
Tekniske tester:
Opplæring # 1: Bruk saksprøving
Opplæring nr. 2: Testing av statlig overgang
Opplæring # 3: Grenseverdianalyse
Opplæring # 4: Ekvivalenspartisjonering
Opplæring # 5: Testmetoder for programvare
Opplæring # 6: Agil metodikk
Feilbehandling:
Opplæring # 1: Feil livssyklus
Opplæring nr. 2: Feilrapportering
Opplæring # 3: Defektprioritet
Opplæring # 4: Bugzilla Tutorial
Funksjonell testing
Opplæring # 1: Enhetstesting
Opplæring nr. 2: Sanity and Smoke Testing
Opplæring # 3: Regresjonstesting
Opplæring # 4: Systemtesting
Opplæring # 5: Akseptprøving
Opplæring # 6: Integrasjonstesting
Opplæring # 7: UAT-testing av brukeraksept
Ikke-funksjonell testing:
Opplæring # 1: Ikke-funksjonell testing
Opplæring nr. 2: Ytelsestesting
Opplæring # 3: Sikkerhetstesting
Opplæring # 4: Sikkerhetstesting av webapplikasjoner
Opplæring # 5: Brukervennlighetstesting
Opplæring # 6: Kompatibilitetstesting
Opplæring # 7: Installasjonstesting
Opplæring # 8: Dokumentasjonstesting
Programvaretesttyper:
Opplæring # 1: Typer testing
Opplæring # 2 : Black box Testing
Opplæring # 3: Databasetesting
Opplæring # 4: Test til slutt til slutt
Opplæring # 5: Utforskende testing
Opplæring # 6: Inkrementell testing
Opplæring # 7: Tilgjengelighetstesting
Opplæring # 8: Negativ testing
Opplæring 9: Backend Testing
Opplæring # 10: Alpha Testing
Opplæring # 11: Betatesting
Opplæring # 12: Alpha vs Beta Testing
Opplæring # 13: Gamma Testing
Opplæring # 14: ERP-testing
Opplæring # 15: Statisk og dynamisk testing
Opplæring nr. 16: Adhoc testing
Opplæring nr. 17: Testing av lokalisering og internasjonalisering
Opplæring # 18: Automatiseringstesting
Opplæring # 19: Testing av hvit boks
Programvare Testing Karriere:
Opplæring # 1: Velge en programvaretestekarriere
Opplæring nr. 2: Hvordan få QA-testjobb - Komplett guide
Opplæring # 3: Karrieremuligheter for testere
Opplæring # 4: Ikke-IT til programvaretestebryter
Opplæring # 5: Start din manuelle testkarriere
Opplæring # 6: Leksjoner fra 10 år i testing
Opplæring # 7: Overlev og fremgang i testfeltet
Intervjuforberedelse:
Opplæring # 1: Forberedelse av CV-CV
Opplæring nr. 2: Manual Testing Interview Questions
Opplæring # 3: Intervju spørsmål om automatiseringstesting
Opplæring # 4: QA intervju spørsmål
Opplæring # 5: Håndter ethvert jobbintervju
Opplæring # 6: Få testjobb som ferskere
Testing av forskjellige domeneapplikasjoner:
Opplæring # 1 : Testing av banksøknader
Opplæring nr. 2: Testing av helsevesen
Opplæring # 3: Payment Gateway Testing
Opplæring # 4: Test-salgssted (POS) -system
Opplæring # 5: Testing av netthandelsnettsted
Testing av kvalitetssertifisering:
Opplæring # 1: Programvaretestingsertifiseringsveiledning
Opplæring nr. 2: CSTE-sertifiseringsguide
Opplæring # 3: CSQA-sertifiseringsveiledning
Opplæring # 4: ISTQB Guide
Opplæring # 5: ISTQB Advanced
Avanserte emner for manuell testing:
Opplæring # 1: Syklomatisk kompleksitet
Opplæring nr. 2: Migrasjonstesting
Opplæring # 3: Cloud Testing
Opplæring # 4: ETL-testing
Opplæring # 5: Programvare Testing Metrics
Opplæring # 6: Nettjenester
Gjør deg klar til å ta en titt på den første veiledningen i denne Manual Testing-serien !!!
Introduksjon til manuell programvaretesting
Manuell testing er en prosess der du sammenligner oppførselen til en utviklet kode (programvare, modul, API, funksjon osv.) Mot forventet oppførsel (Krav).
Og hvordan vil du vite hva som er forventet oppførsel?
Du vil vite det ved å lese eller lytte til kravene nøye og forstå det fullstendig. Husk at det å forstå kravene er veldig veldig viktig.
hvordan du legger til elementer i en array-java
Tenk deg selv som sluttbruker av det du skal teste. Etter det er du ikke bundet til programvarekravdokumentet eller ordene i det lenger. Du kan da forstå kjernekravet og ikke bare kontrollere systemets oppførsel mot det som er skrevet eller fortalt, men også mot din egen forståelse og mot ting som ikke er skrevet eller fortalt.
Noen ganger kan det være et savnet krav (ufullstendig krav) eller implisitt krav (noe som ikke trenger særskilt omtale, men som skal oppfylles), og du må også teste for dette.
Videre trenger et krav ikke nødvendigvis være dokumentert. Du kan veldig godt ha kunnskap om programvarefunksjonaliteten, eller du kan til og med gjette og deretter teste ett trinn av gangen. Vi kaller det generelt ad hoc-testing eller utforskende testing.
La oss se nærmere på:
La oss først forstå fakta - Enten du sammenligner testing av et program eller noe annet (la oss si et kjøretøy), forblir konseptet det samme. Tilnærming, verktøy og prioriteringer kan variere, men kjernemålet forblir SAMME og det er ENKEL, dvs. å sammenligne den faktiske atferden med den forventede atferden.
For det andre - Testing er som en holdning eller tankesett som skal komme innenfra. Ferdigheter kan læres, men du vil bare bli en vellykket tester når du har noen få kvaliteter i deg som standard. Når jeg sier at testferdigheter kan læres, mener jeg fokusert og formell utdanning rundt programvaretestprosessen.
Men hva er egenskapene til en vellykket tester? Du kan lese om dem på lenken nedenfor:
Les det her => Kvaliteter av svært effektive testere
Jeg anbefaler på det sterkeste å gå gjennom artikkelen ovenfor før du fortsetter med denne veiledningen. Det vil hjelpe deg med å sammenligne egenskapene dine mot de som forventes i Software Tester's rolle.
For de som ikke har tid til å gå gjennom artikkelen, er det en sammendrag:
“Din nysgjerrighet, oppmerksomhet, disiplin, logiske tenkning, lidenskap for arbeid og evne til å dissekere ting, betyr mye for å være en destruktiv og vellykket tester. Det fungerte for meg, og jeg tror sterkt at det også vil fungere for deg. Hvis du allerede har disse egenskapene, så må det faktisk fungere for deg også. '
Vi har snakket om de viktigste forutsetningene for blir en programvaretester. La oss nå forstå hvorfor manuell testing har og alltid vil ha sin uavhengige eksistens med eller uten automatiseringstesting.
Hvorfor er manuell testing påkrevd?
Vet du hva som er det beste med å være en tester, også en manuell tester?
Det er det faktum at du ikke bare kan stole på ferdighetssettet her. Du må ha / utvikle og forbedre tankeprosessen. Dette er noe du egentlig ikke kan kjøpe for noen få dollar. Du må selv jobbe med det.
Du må utvikle vanen med å stille spørsmål og du må spørre dem hvert minutt når du tester. De fleste ganger bør du stille disse spørsmålene til deg selv enn til andre.
Jeg håper at du har gått gjennom artikkelen som jeg anbefalte i forrige avsnitt (dvs. egenskapene til svært effektive testere). Hvis ja, ville du vite at testing betraktes som en tankeprosess og hvor vellykket du vil være som tester, avhenger helt av hvilke egenskaper du har som person.
La oss se denne enkle strømmen:
- Du gjør noe ( utføre handlinger ) mens du observerer det med en viss hensikt (sammenligner med forventet). Nå din observasjon ferdigheter og disiplin å utføre ting kommer inn i bildet her.
- Voila! Hva var det? Du la merke til noe. Du la merke til det fordi du ga perfekt oppmerksomhet på detaljene foran deg. Du vil ikke la det gå fordi du er det nysgjerrig . Dette var ikke i planen din at noe uventet / rart vil skje, du vil legge merke til det og du vil undersøke det nærmere. Men nå gjør du det. Du kan la det gå. Men du skal ikke la det gå.
- Du er lykkelig, du fant ut årsaken, trinnene og scenariet. Nå vil du kommunisere dette riktig og konstruktivt til utviklingsteamet og de andre interessentene i teamet ditt. Du kan gjøre det via et sporingsverktøy eller muntlig, men du må sørge for at du er det kommunisere det konstruktivt .
- Beklager! Hva om jeg gjør det på den måten? Hva om jeg skriver inn riktig heltall som inndata, men med ledende hvite mellomrom? Hva om? … Hva om? … Hva om? Det ender ikke lett, det skal ikke ende lett. Du vil Forestill deg mange situasjoner og scenarier, og faktisk vil du bli fristet til å utføre dem også.
Diagrammet nedenfor representerer livet til en tester:
Les de fire punktene som er nevnt ovenfor igjen. La du merke til at jeg holdt det veldig kort, men fremdeles fremhevet den rikeste delen av å være en manuell tester? Og la du merke til den dristige uthevingen over noen få ord? Det er nettopp de viktigste egenskapene som en manuell tester trenger.
Tror du virkelig at disse handlingene kan erstattes helt av noe annet? Og den hete trenden i dag - kan den noen gang erstattes med automatisering?
I SDLC med noen utviklingsmetoder forblir få ting alltid konstante. Som tester vil du konsumere kravene, konvertere dem til testscenarier / testsaker. Du vil deretter utføre disse testtilfellene eller automatisere dem direkte (jeg vet at noen få selskaper gjør det).
Når du automatiserer det, er fokuset ditt jevnt, som automatiserer trinnene som er skrevet.
La oss gå tilbake til den formelle delen, dvs. utføre testsakene skrevet manuelt.
Her fokuserer du ikke bare på å utføre de skriftlige prøvesakene, men du utfører også mye utforskende testing mens du gjør det. Husk at du er nysgjerrig? Og du vil forestille deg. Og du vil ikke være i stand til å motstå, du vil virkelig gjøre det du forestilte deg.
Bildet som er gitt nedenfor viser hvordan skriving av testsaker er forenklet:
Jeg fyller ut et skjema, og jeg er ferdig med å fylle ut det første feltet. Jeg er for lat til å gå for musen til å skifte fokus til neste felt. Jeg trykket på “tab” -tasten. Jeg er ferdig med å fylle opp neste og siste felt også, nå må jeg klikke på Send-knappen, fokuset er fortsatt på det siste feltet.
Ups, jeg traff ved et uhell ‘Enter’ -tasten. La meg sjekke hva som skjedde. ELLER det er en sendeknapp, jeg dobbeltklikker på den. Ikke tilfredsstilt. Jeg klikker på den flere ganger, for fort.
La du merke til? Det er så mange mulige brukerhandlinger, både tiltenkte og ikke-tiltenkte.
Du vil ikke lykkes med å skrive alle testtilfellene som dekker søknaden din under test 100%. Dette må skje på en utforskende måte.
Du vil fortsette å legge til dine nye testtilfeller mens du tester applikasjonen. Dette vil være testtilfeller for feil som du har opplevd, som det tidligere ikke var skrevet noen testsak. Eller mens du tester, utløste noe tankeprosessen din, og du fikk noen flere testtilfeller som du vil legge til i testsaken din og utføre.
Selv etter alt dette er det ingen garanti for at det ikke er noe skjulte feil . Programvare med null feil er en myte. Du kan bare målrette mot å ta det nær Zero, men det kan bare ikke skje uten at et menneskesinn kontinuerlig retter seg mot det samme, lik men ikke begrenset til eksempelprosessen vi så ovenfor.
I det minste i dag er det ingen programvare som vil tenke som et menneskesinn, observere som et menneskelig øye, stille spørsmål og svare som et menneske og deretter utføre tiltenkte og ikke-tiltenkte handlinger. Selv om noe slikt skjer, hvis sinn, tanker og øye vil det etterligne? Din eller min? Vi, mennesker, har heller ikke samme rett. Vi er alle forskjellige. Deretter?
Behov for manuell testing når automatisering er rundt:
Automatiseringstesting har sin egen andel av ære i disse dager og vil ha enda mer i de kommende årene, men den kan ganske enkelt ikke erstatte manuell QA-testing (les menneskelig / utforskende testing).
Du må ha hørt før- ‘ Du automatiserer ikke testing, du automatiserer sjekker '. Denne setningen snakker mye om hvor manuell QA-testing står med automatiseringstesting rundt. Mange store navn over hele verden har skrevet og snakket om dette emnet, så jeg vil ikke stresse mye med dette.
Automatisering kan ikke erstatte menneskelig testing fordi:
- Det krever kjøretidsdommer om alt som skjer foran øynene dine (mens du tester) og i få tilfeller bak kulissene også.
- Det krever klar og konstant observasjon.
- Det krever avhør.
- Det krever etterforskning.
- Det krever resonnement.
- Det krever ikke planlagte handlinger etter behov.
Testing kan erstattes av et verktøy / maskin som vil være i stand til å absorbere detaljene, behandle dem, kommandere handlinger og utføre dem som et menneskelig sinn og menneske, og alt dette ved kjøretid og i alle mulige sammenhenger. Dette verktøyet må igjen være som alle mulige mennesker.
Så kort sagt, menneskelig testing kan ikke erstattes. Kanskje noen Hollywood-sci-fi-flikker om noen år vil se nærmere på det, men i det virkelige liv kan jeg ikke se det komme på noen hundre år, det kan jeg forestille meg. Jeg vil ikke avskrive det for alltid, da jeg tror på uendelige muligheter.
På et eget notat, selv om det virkelig skjer etter noen hundre år, er bildet jeg kan forestille meg helt sikkert det av en skummel verden. Age of Transformers. :)
= >> Anbefalt lesing - Beste bedrifter for manuell testing
Hvordan automatisering komplimenterer manuell testing?
Jeg sa før, og jeg sier det igjen at automatisering ikke lenger kan ignoreres. I verden der kontinuerlig integrering, kontinuerlig levering og kontinuerlig distribusjon blir obligatoriske ting, kan kontinuerlig testing ikke sitte inaktiv. Vi må finne ut måter å gjøre det på.
Å hjelpe med å distribuere mer og mer arbeidskraft hjelper ikke i det lange løp for denne oppgaven. Derfor må testeren (testleder / arkitekt / leder) bestemme forsiktig om hva som skal automatiseres og hva som fortsatt skal gjøres manuelt.
Det blir ekstremt viktig å ha skrevet veldig nøyaktige tester / sjekker slik at de kan automatiseres uten noe avvik fra den opprinnelige forventningen, og kan brukes mens du trekker tilbake produktet som en del av 'Kontinuerlig testing'.
Merk: Ordet kontinuerlig fra begrepet ‘Kontinuerlig testing’ er utsatt for betingede og logiske anrop som ligner på de andre begrepene vi brukte ovenfor med samme prefiks. Kontinuerlig i denne sammenheng betyr oftere og oftere, raskere enn i går. Mens det betyr, kan det veldig bra bety hvert sekund eller Nano-sekund.
Uten å ha en perfekt match av menneskelige testere og automatiserte kontroller (tester med nøyaktige trinn, forventede resultat- og utgangskriterier for nevnte test dokumentert), er det veldig vanskelig å oppnå kontinuerlig testing, og dette vil igjen gjøre kontinuerlig integrering, kontinuerlig levering og kontinuerlig distribusjon vanskeligere.
Jeg brukte bevisst begrepet utgangskriterier for en test ovenfor. Våre automatiseringsdrakter kan ikke likne de tradisjonelle lenger. Vi må sørge for at hvis de mislykkes, skal de mislykkes raskt. Og for å få dem til å mislykkes raskt, bør også utgangskriteriene automatiseres.
Eksempel:
La oss si at det er en blokkeringsfeil der jeg ikke klarer å logge inn på Facebook.
Innloggingsfunksjonalitet må da være din første automatiserte sjekk, og automatiseringsserien din skal ikke kjøre neste sjekk der pålogging er en forutsetning, som å legge ut en status. Du vet veldig godt at det vil mislykkes. Så få det til å mislykkes raskere, publiser resultatene raskere slik at feilen kan løses raskere.
Neste ting er igjen noe du må ha hørt før - Du kan ikke og bør ikke prøve å automatisere alt.
Velg testtilfeller som hvis automatiserte vil ha stor fordel til Human Testers og har god avkastning. For den saks skyld er det en generell regel som sier at du bør prøve å automatisere alle dine Priority 1-testtilfeller og om mulig deretter Priority 2.
Automatisering er ikke lett å implementere og er tidkrevende, så det anbefales å unngå å automatisere saker med lav prioritet minst til den tiden du er ferdig med de høye. Å velge hva som skal automatiseres og fokusere på det forbedrer applikasjonskvaliteten når den brukes og vedlikeholdes kontinuerlig.
Konklusjon
Jeg håper du nå må ha forstått hvorfor og hvor dårlig manuell / menneskelig testing kreves for å levere kvalitetsprodukter og hvordan automatisering komplimenterer det.
Å akseptere viktigheten av QA manuell testing og vite hvorfor det er spesielt, er det aller første skrittet mot å være en utmerket manuell tester.
I våre kommende opplæringsprogrammer for manuell testing vil vi dekke en generisk tilnærming for å utføre Manuell testing, hvordan den vil eksistere samtidig med Automation og mange andre viktige aspekter.
Jeg er sikker på at du vil få enorm kunnskap om programvaretesting når du har gått gjennom hele listen over opplæringsprogrammer i denne serien.
hvordan man skriver testsaker i programvaretesting med eksempel
Vi vil gjerne høre fra deg. Uttrykk gjerne dine tanker / forslag i kommentarfeltet nedenfor.
Anbefalt lesing
- Beste verktøy for testing av programvare 2021 [QA Test Automation Tools]
- Programvaretesting QA Assistant Job
- Alpha Testing og Beta Testing (En komplett guide)
- Funksjonstesting mot ikke-funksjonell testing
- Beste QA Software Testing Services fra SoftwareTestingHelp
- Programvare Testing Course: Hvilket programvare Testing Institute skal jeg delta?
- Typer programvaretesting: Ulike testtyper med detaljer
- Velge programvaretesting som din karriere