Meny

Hva forventer klienter virkelig av programvaretesterne?

what do clients really expect from software testers

Prøv Instrumentet Vårt For Å Eliminere Problemer

I dagens artikkel skal jeg dele noen tanker om hva jeg tror klientene virkelig forventer av oss basert på min førstehånds erfaring med å jobbe på klientsteder med daglige interaksjoner og samarbeide offshore via e-post eller telefonsamtaler.

IT-tjenester er en viktig og integrert del av programvareindustrien, og kundetilfredshet er viktig for å lykkes. Hver klient / organisasjon kan være forskjellig i prosessen, kan følge forskjellige protokoller, og kan håndtere forskjellige typer virksomheter.

Men følgende faktorer er vanlige og har betydning for alle generelt.

programvaretesting av klienter

(bilde src )

Hva du vil lære:

5 ting som klienten forventer av programvaretestere:

Kundens forventning 1

# 1) Kostnadsfordel

Når du tenker på å selge eller kjøpe noe, spiller kostnadene en viktig rolle, og det er ofte en av de viktigste avgjørende faktorene. Venter vi ikke alle ivrig på Black Friday, Flipkart Billion Day-salg eller Amazons store shoppingfestival? Vi blir sprø kjøpere i løpet av salgstiden. Det er en enkel menneskelig oppførsel å forvente den rette eller ekstra verdien for pengene våre.

Bedrifter og kunder er ikke forskjellige. Kostnadsfordeler øker forholdet mellom kundeservice og det er ikke uvanlig at serviceselskaper mister bud på grunn av lavere konkurrenter.

Kostnadsfordeler

BIG-spørsmålet er nå: Hvordan kan vi vise kostnadsfordeler for kundene våre?

Disse punktene kan hjelpe:

  • Vis dem pengene sine . Begrunn og gi støttende bevis for din estimater .
  • Tenk på kreative måter å spare på utgiftene.
  • Skreddersy tilbudet ditt. I stedet for å holde deg til standardprosessen din som koster X mengde penger, kan du tilby billigere alternativer. For eksempel : Foreslå kritisk banetesting i stedet for fullstendig systemtesting.
  • Kjenn din konkurranse . En rask reality-sjekk av hvilke andre tjenesteselskaper som tilbyr sine kunder til hvilke kostnader som er viktig for å holde prismodellmarkedet relevant.

# 2) Arbeidskvalitet

Kvalitet og mengde arbeid er to veldig forskjellige ting.

Borte er dagene da antall testtilfeller opprettet eller rapporterte mangler brukt til produktivitets- eller kvalitetsindikatorer. Ikke nå lenger.

Situasjonen er mer som bildet nedenfor:

Arbeidskvalitet

Arbeidskvalitet 2

A) Vet når du skal si 'NEI'

Vi har alle vært på steder hvor vi jobbet overtid, vært på vakt i helgene, deltatt sent på kvelden eller tidlig på morgenen samtaler osv. Det vi ikke vet er imidlertid at vi kan si NEI hvis ting fortsetter å bli verre. Sier NEI er den eneste måten vi kan holde kvaliteten på arbeidet og sunn fornuft intakt.

Når du gjør det, må du bekymre deg på forhånd og gå inn for kvalitet.

Her er en situasjon jeg var i, og dette kan gi deg en bedre ide om hva jeg snakker om:

Mitt firma vant en ny logo, og som en del av migrasjonen fra et gammelt selskap til mitt firma ble det planlagt økte kunnskapsoverføringer. Vi, et team på 6 medlemmer reiste til klientstedet. Den aller første dagen etter introduksjonen ble vi delt med KT-planen. Jeg fant navnet mitt ble merket mot flere moduler. En av disse modulene burde ha vært helt utenfor omfanget mitt fordi jeg ikke engang var klar over den teknologien; det passet ikke til mine ferdigheter.

Jeg gikk til kundeovergangsledelsen og fortalte ham situasjonen -

  • For mange arbeidsartikler ble tildelt meg, noe som igjen vil hemme kvaliteten og min evne til å fange 100% i øktene.
  • De planlagte varene hadde områder der ferdighetene mine ikke stemte overens, og siden jeg ikke passet riktig, forsto jeg kanskje ikke 100% under overgangen.

Ledelsen forstått problemet og revidert KT-planen.

falsk Gmail-konto generator og passord

Jeg håper dette hjelper til med å bekrefte at: Hvis noe er på tallerkenen vår, betyr det ikke at vi må spise alt. Spesielt ikke hvis det betyr å gå på kompromiss med kvaliteten.

B) Fullstendighet i testtilfelle

Hvor mange av dere er enige med meg hvis vi prøver forbedre måten vi skriver prøvesaker på , fører det til bedre kvalitet?

Nedenfor er noen vanlige feil som er vanlige i de fleste testsaker:

TestkofferkomponenterNåværende problemLøsning
Objektiv Mål er den viktigste delen av en testsak, det er det som gjør alle testsaker forskjellige. Vanlige feil med Objective mangler klarhet.

Som alle testtilfeller opprettet for en funksjonalitet har ett mål uten å vise hvordan hver testtilfelle er forskjellig.		 Mål / formål med hver testtilfelle skal være tydelig for å forklare hvilken funksjonalitet og hvilken testtilstand som skal testes som en del av det testtilfellet.

Samme funksjonalitet kan ha positive og negative testtilfeller, så objektivt bør være tydelig nok til å vise forskjellen. En god idé er å henvise testscenariet for å definere mål.
Forutsetninger Mange testere går glipp av å nevne forutsetningen, ellers vil mange bare kopiere og lime inn. Kopiering og liming fører til feil siden hver testtilfelle kan være helt forskjellig fra en annen.Unngå feil i kopi-lim inn og vær oppmerksom på detaljer.
Testdata Dette er sannsynligvis det mest oversettte feltet, og de fleste testtilfeller vil ha det tomt eller mangler presis definisjonNevn de aktuelle dataene som skal legges inn. Noen ganger trenger det ikke å være nøyaktig.

For eksempel: Brukerregistrering kan registrere en bruker Anna eller John, og det spiller ingen rolle. Men å definere at et gyldig navn som har alle tegn og skal være 4-10 i lengde, kan bidra til å avklare mange ting.
Test saks-ID Over forenklet navngivning eller nummereringskonvensjon. Si, du tester en påloggingsknapp. Ofte er ID-ene:
TC_1_Logg på
TC_2_Logg på		Gjør dem mer beskrivende:
TC_1_Login_Invalid_User
TC_2_Login_Valid_User
Referansedokumenter Inkonsekvent kopi-lim inn fra referansedokumenter eller verre, ved å bruke en feil.Det er alltid tilrådelig å nevne riktig referansedokument med riktig versjonsnummer, si for noen testtilfeller FRS og tekniske spesifikasjoner begge ville ha blitt henvist, så testtilfellet i referansedelen bør nevne begge deler.
Test Case Steps Manglende trinn, mest av testere som kjenner applikasjonen veldig godt. De kunne anta ting og hoppe over å nevne trinnene. Dette forårsaker problemer for virksomheten, anmeldere og nye testere.Riktige trinn og sekvens bør brukes.

For å oppsummere, hvis små detaljer tas i betraktning i designfasen, vil testutgangskvaliteten være mye bedre.

# 3) Forretningsforståelse

Dette er en av de viktigste faktorene som kundene ser etter i testere. Imidlertid er det trist at noen testere mener at deres jobb er å skrive testsaker basert på FRS og ikke anstrenger seg for å forstå virksomheten.

Prøv å kjenne virksomheten først, og se deretter på funksjonalitet; du kan se for deg kundens behov mer og test deretter.

Her er et eksempel- FRS sier 'XYZ-rapporten skal genereres med tre kolonner som dato, navn og status'. Følgende er testsaker du vil ende opp med når du tar dette kravet til pålydende:

  • Bekreft rapporten XYZ genereres
  • Bekreft rapporten har tre kolonner som Dato, Navn, Status
  • Valider dataene i tre kolonner.

Men når du holder forretningens anvendbarhet i tankene, må du kanskje teste:

  • Hva er forretningsformålet med denne rapporten?
  • Blir denne rapporten generert hver dag?
  • Hvem er forretningsbrukerne som ser på denne rapporten?
  • Hva er datakilden for denne rapporten?
  • Bør rapporten genereres hvis ingen data er tilgjengelige?

Dette er bare et eksempel, men jeg antar at vi alle er enige om at bedre testing kan oppnås ved å få forretningsbevissthet og ekspertise.

# 4) Tilgjengelighet

Enten du er en enkeltperson som støtter kunden eller et team, bør tilgjengeligheten din alltid kontrolleres ( Omfanget av forbedring).

Av tilgjengelighet betyr det ikke 24/7 support. Det betyr bare klar og forhåndskommunikasjon om ledig tid, alternative planer og å være tilgjengelig og ikke gå MIA.

Nedenfor er noen av modellene som tjenestebransjen følger:

  • Utvidelsesmodell for ansatte - Hvis du arbeider i en personalforsterkningsmodell og er enerepresentant fra firmaet ditt, anbefales det at kunden blir gjort oppmerksom på arbeidstider og planlagt fravær, slik at nødvendige ordninger kan gjøres.
  • Managed Projects Model - I en styrt prosjektmodell der store prosjektgrupper er dannet og ledet av leverans / prosjektledere, er det ikke lenger kundenes ansvar å ha en reserveresursplan. Statsministerens behov for å klare seg både planlagte og ikke-planlagte fri. I denne modellen er det tilrådelig at statsrådene prøver å samle de planlagte fraværsdataene fra teamet på forhånd og klare seg deretter. Det er tilfeller der kunder ber om helgestøtte eller utvidet arbeidstid. Slike saker bør også planlegges ved roterende ressurser. Et team skal bestå av medlemmer som kan sikkerhetskopiere hverandre om nødvendig. De planlagte detaljene bør deles med kunden.

# 5) Forbedringsomfang

Dette er ikke bare ønskelig i programvareindustrien, men overalt. Å bringe forbedring er ikke en dags jobb. Omfanget av forbedringer må jobbes kontinuerlig med og kan deles inn i 3 trinn -

Les også=> Hvordan du kan forbedre testferdighetene dine og slå konkurransen

Trinn 1: Identifiser

Gjør en grundig studie og identifiser områdene / muligheten for forbedringer. Si at når du blir bedt om å teste den samme funksjonaliteten flere ganger ved hjelp av samme prosess, vil det komme en tid da du vil føle at du enten vil flytte ut av prosjektet, eller du endrer måten det testes på. Slik får vi forbedringer når vi kjeder oss over våre eksisterende metoder, vi tenker på å endre og forbedre .

selen intervju spørsmål og svar pdf

Steg 2: Ta med forbedringer

Hvis ting ble gjort manuelt, kunne du prøv å automatisere noen få ting . Når jeg sier automatisering, betyr det ikke alltid å kjøpe et automatisert verktøy.

Jeg vil sitere en situasjon:

Jeg var en del av et team for databasetesting. Vårt daglige arbeid innebar å kjøre de samme SQL-skriptene flere ganger på en dag med et annet sett med parametere. Da vi startet prosjektet, var vi fine med disse trinnene, men til slutt forsto vi systemet bedre, og vi trodde de samme SQL-skriptene kan kjøres som en del av lagrede prosedyrer i stedet for at noen manuelt oppdaterer parametere og utfører.

Trinn 3: Evaluer forbedringen

Når en ny prosess er implementert, må du sørge for at den fungerer som forventet og ikke har noen bivirkninger. Utvid det tidligere eksemplet, en introduksjon av lagrede prosedyrer, sjekk om utdataene fra den nyopprettede automatiserte måten og utdataene fra manuell måte er de samme.

Den andre delen er å overvåke fordelene over en periode for å være helt sikker og presentere resultatene for kundene dine. I prosjektet vårt viste vi kundene en reduksjon i testutførelsestiden med 30%, som igjen reduserte kostnadene.

Konklusjon

Avslutningsvis ville jeg bare nevne at hver og en av oss har medfødte talenter, og vi har alle våre egne unike arbeidsstiler, og dette var bare noen tips som jeg tror kan tilby våre kunder en bedre serviceopplevelse.

Om forfatteren: Denne fantastiske artikkelen er skrevet av STH-teammedlem Priya R. Hvis du vil skrive for oss og dele din erfaring, vær så snill gi oss beskjed her .

Håper du har likt å lese denne artikkelen og funnet den informativ! Gi oss beskjed hvis du har en annen opplevelse å dele.

Anbefalt lesing

^