Meny

Programvare Testing Training: End to End Training på et live prosjekt - Gratis online kvalitetsopplæring del 1

software testing training

Prøv Instrumentet Vårt For Å Eliminere Problemer

GratisProgramvare Testing TrainingPå et sanntids live-prosjekt:

Vi er veldig glade for å presentere dette neste serie programvaretesting gratis opplæringsprogrammer. Vi skal simulere et slutt-til-slutt-sanntids programvareprosjekt som går over hver eneste fase i detalj med spesiell vekt på QA-opplæringsprosesser, faser, roller og ansvar, leveranser osv.

Kort sagt, vær klar for et kort online Software Testing-kurs.

_Slutt for å avslutte trening på et live-prosjekt

Viktig notat : Gratis tutorials nedenfor er nyttige for å komme i gang, men hvis du er interessert i det beste online LIVE Software Testing-kurset fra ekspertene, vennligst sjekk denne siden.

Testing av kvalitetsopplæring

=> Her erliste over alle opplæringenei denne gratis Live Project QA-treningsserien:

youtube til mp3 lenger enn 90 minutter

Hvorfor denne gratis kvalitetsopplæringen?

Vi får mange spørsmål fra leserne våre for å dele vår erfaring med nøyaktig programvaretestprosess etterfulgt av programvaretestteamene. Så vi bestemte oss for å dokumentere denne komplette STLC ved hjelp av et eksempel på en live applikasjon som er tilgjengelig for testing på Internett.

Vi vil bruke dette live-prosjektet for vår programvaretestopplæringsserie. Vi anbefaler deg på det sterkeste å følge denne serien nøye, da det kommer til å bli et kollisjonskurs å lære og implementere testpraksis på en live applikasjon.

Hva du vil lære:

Programvare Testing Training på Live Project - Hva er det?

Før jeg går videre, la meg ta et øyeblikk til å forklare hva denne kursserien om programvaretesting handler om og hvordan den kommer til å ta form når vi går videre.

Vi valgte en direktesendt applikasjon (hvis detaljer er nedenfor) og starter med:

- I utgangspunktet alt vi vanligvis gjør i et sanntids programvaretestprosjekt - med sanntidseksempler, gjenstander og leveranser, alt opprettet i prosessen.

Hvordan følge denne programvaretestekursen?

Trinn 1) Introduksjon og SRS Walkthrough - Vi starter dette mini-programvaretestekurset med SRS walkthrough. Vi har opprettet og delt et SRS-dokument. Gå gjennom det ettersom alle ytterligere trinn avhenger av din forståelse av dette programmet.

Steg 2) SRS gjennomgang og testscenario forberedelse.

Trinn 3) Testplan - fullfør prosessen med å lage en testplan fra bunnen av. Den endelige testplanversjonen vil bli delt med deg som referanse.

Trinn 4) Test tilfeller - fullfør skriveprosessen med noen eksempler på test tilfeller. Vi kan bruke hvilket som helst testadministrasjonsverktøy eller regneark til å skrive testsaker.

Trinn 5) Gjennomgang av applikasjoner og testutførelse - Hvordan utføre testsaker og registrere testresultatene?

Trinn 6) Feilrapportering

Trinn 7) Defektverifisering, regressing testprosess

Trinn 8) QA-pålogging

Hensikten er å gi dere alle en følelse av sanntids prosjektopplevelse og ekspertise. Vi håper du synes denne serien er nyttig.

Søknad som vi skal bruke videre

Introduksjon

Klient: oransje
Applikasjon: OrangeHRM demo .
Tjenesteleverandør: SoftwareTestingHelp.com

Prosjektbeskrivelse

Orange ønsker å skape et kommersielt menneskelig ressursadministrasjonsprodukt som kan konsumeres og tilpasses av mellomstore bedrifter i et enkelt land og globalt.

kvalitetsanalytiker intervju spørsmål og svar

Den har to versjoner: Profesjonell og Enterprise.

Funksjonene inkluderer

  • Administrasjon av personlig informasjon
  • Avansert permisjonsledelse
  • Tid og fremmøte sporing
  • Ledelse av ansattes ytelse
  • Rekruttering
  • Avansert rapportering
  • Land / Stedsbasert ansattes ledelse
  • Lokaliserte permisjonsregler
  • Konfigurerbare arbeidsflyter
  • Platinum Support
  • Land / stedsbasert rapportering
  • Tilpasset rapportering

Merk : For enkelhets skyld og for å begrense omfanget, la oss vurdere medarbeidermodulen i denne HRM-portalen, der brukeren har mulighet til å legge inn personlig informasjon.

Når en kunde eller en bedriftseier har behov for å våge seg inn i den elektroniske verdenen eller gjøre oppdateringer på det allerede eksisterende nettstedet eller applikasjonen, er behovet et forretningsproblem, og programvaren er et stykke kode som er designet for å løse dette forretningsproblemet.

En kunde henvender seg deretter til en leverandør av programvaretjenester for å gjøre denne programvaren til en realitet for dem. Det er da programvareprosjektets begynnelse begynner.

En tradisjonell Waterfall Project (SDLC) har følgende faser:

Programvareutviklingsprosess

  • Som QA-er vet vi alle at selv om 'Test' er trinn 5 i denne strømmen, er det ikke det eneste stedet vi testere spiller en fremtredende rolle.
  • Testing er også en reaktiv jobb. Uten kode / applikasjon klar til å teste kan vi egentlig ikke 'teste' noe. For å være klar og reagere på en mest mulig effektiv måte prøver vi så mye vi kan å planlegge og forberede oss fremover. Så selv om fase 5 er for testing, starter aktivitetene våre langt fremover.

I et nøtteskall er dette det som skjer i hver fase !!

Sette i gang:

Når produsenten og kunden er enige om vilkår - begynner programvareproduksjonen.

  • I denne fasen blir forretningskrav samlet og analysert. Analysen vil involvere beslutningene om teknologiske hensyn, maskinvare- og programvarespesifikasjoner, mennesker, krefter, tid, relevans og forbedringer blant andre.
  • Forretningsanalytikere, prosjektledere og klientrepresentanter er involvert i dette trinnet.
  • På slutten av dette trinnet og grunnprosjektet blir planen utarbeidet.
  • Prosjektspesifikke dokumenter som omfangsdokument og / eller forretningskrav blir laget.
  • QA-involvering på dette stadiet er vanligvis ikke å forvente. (Dette er et lite avvik fra hva det skal være, for å identifisere problemer tidlig i utviklingsfasene, er det best å involvere QA helt fra begynnelsen.)

Definere:

De endelige forretningskravene er inngangene for dette trinnet.

  • Denne fasen innebærer oversettelse av forretningskrav til funksjonelle krav til programvaren. For eksempel , hvis forretningskravet er å tillate en bruker å kjøpe noe fra et nettsted. Funksjonskravet vil ha detaljer som Nettstedsformat-> Menyalternativnavn og plassering-> Søk produkt-> Handlekurv-> Kasse (registrering eller ikke) -> Betalingsalternativer-> Bekreftelse av salg.
  • Utviklere, forretningsanalytikere, prosjektledere er involvert i denne fasen
  • Resultatet av denne fasen er et detaljert dokument som inneholder programvarens funksjonelle krav. Dette dokumentet er referert til av mange navn - Software Requirement Specification (SRS), Functional Requirements Document (FRD) eller Functional Requirements Specification (FRS).
  • Dette er hvor QA-teamet blir involvert - etter fullføring av SRS-dokumentasjon.
  • Mens ferdigstillelse av funksjonelle krav og dokumentasjon av SRS pågår, er QA-leder / leder involvert i å utarbeide en den første versjonen av testplanen og danne et QA-team.
  • QA-teamets engasjement vil være når SRS er dokumentert.
  • På dette stadiet vil enten utviklingsteamet eller forretningsanalytikeren eller noen ganger til og med QA-teamledelsen gi en gjennomgang av SRS til QA-teamet.
  • I tilfelle et nytt prosjekt fungerer en grundig gjennomgang i form av en konferanse eller et møte best
  • Ved senere utgivelser for et eksisterende prosjekt, sendes et dokument via e-post eller plassering i et felles arkiv til QA-teamet. QA-team vil på dette punktet lese / gjennomgå det offline og forstå systemet grundig.
  • Siden den primære målgruppen for SRS-dokumentet ikke bare er testere, er ikke alt nyttig for oss. Vi testere bør være flittige når vi gjennomgår dette dokumentet for å bestemme hvilke deler av det som er nyttige for oss og hvilke deler av det ikke.

SRS-dokument for dette live-prosjektet

Et eksempel på SRS-dokument er vedlagt dette innlegget for å gi deg en ide om hvordan dette dokumentet ser ut, formatet det er skrevet i, hva slags informasjon det inneholder osv. I neste artikkel vil vi komme inn på hvordan dette dokumentet konsumeres av QA-teamet for å gå videre i testprosjektene våre.

==> Last ned live prosjekteksempel på SRS-dokument .

Konklusjon

I denne artikkelen introduserte vi deg for programvareutvikling og testing. Vi delte også et eksempel på SRS-dokument for live-prosjektet som vi skal teste.

=> Den kommende artikkelen i denne programvaretestingen vil være - SRS gjennomgang og prosessen med å lage testscenarier .

Merk: Mens den neste artikkelen i denne QA-opplæringsserien skrives, jobber du parallelt med oss ​​her for mest live opplevelse . Prøv å gi SRS-dokumentet en god lesing, og så fortsetter vi med de neste trinnene når vi møtes igjen.

God test, til da!

Om forfatteren: STH-teammedlem Swati Seela hjelper oss med å presentere denne live-prosjektet QA-treningsserien.

Anbefalt lesing

^