what do clients really expect from software testers
I dagens artikel vil jeg dele nogle tanker om, hvad jeg mener, at klienterne virkelig forventer af os baseret på min førstehånds erfaring med at arbejde på klientlokationer med daglige ansigt til ansigt interaktioner og samarbejde offshore via e-mails eller telefonopkald.
IT-tjenester er en vigtig og integreret del af softwareindustrien, og kundetilfredshed er vigtigt for at få succes. Hver klient / organisation kan være forskellig i deres proces kan følge forskellige protokoller og kan beskæftige sig med forskellige typer virksomheder.
Men følgende faktorer er fælles og betyder noget for alle generelt.
[billede src ]
Hvad du lærer:
- 5 ting, som klienten forventer af softwaretestere:
- # 1) Omkostningsfordel
- # 2) Arbejdskvalitet
- # 3) Forretningsforståelse
- # 4) Tilgængelighed
- # 5) Forbedringsomfang
- Konklusion
- Anbefalet læsning
5 ting, som klienten forventer af softwaretestere:
# 1) Omkostningsfordel
Når du tænker på at sælge eller købe noget, spiller omkostninger en vigtig rolle, og det er ofte en af de vigtige afgørende faktorer. Venter vi ikke alle ivrigt på Black Friday, Flipkart Billion Day-salg eller Amazons store shoppingfestival? Vi bliver skøre købere i løbet af salgstiden. Det er en simpel menneskelig opførsel at forvente den rigtige eller ekstra værdi for vores penge.
Virksomheder og kunder er ikke forskellige. Omkostningsfordele øger kundeserviceforholdet, og det er ikke ualmindeligt, at servicevirksomheder mister bud på grund af lavere konkurrenter.
BIG-spørgsmålet er nu: Hvordan kan vi vise omkostningsfordele for vores kunder?
Disse punkter kan hjælpe:
- Vis dem deres penge . Retfærdiggør og frembring støttebeviser for din skøn .
- Tænk på kreative måder at spare på udgifterne på.
- Skræddersy dit tilbud. I stedet for at holde fast ved din standardproces, der koster X beløb, skal du give billigere alternativer. For eksempel : Foreslå test af kritisk sti i stedet for komplet systemtest.
- Kend din konkurrence . En hurtig reality-kontrol af, hvad andre servicevirksomheder tilbyder deres kunder til hvilke omkostninger, der er vigtige for at holde din prismodel relevant.
# 2) Arbejdskvalitet
Arbejdets kvalitet og mængde er to meget forskellige ting.
Borte er de dage, hvor antallet af oprettede testsager eller rapporterede mangler brugt til produktivitets- eller kvalitetsindikatorer. Ikke mere.
Situationen er mere som nedenstående billede:
A) Ved hvornår du skal sige 'NEJ'
Vi har alle været på steder, hvor vi har arbejdet overarbejde, været på vagt i weekenden, deltaget sent på aftenen eller tidligt om morgenen, osv. Men hvad vi ikke er klar over er, at vi kan sige NEJ, hvis tingene fortsætter med at blive værre. At sige nej er den eneste måde, hvorpå vi kan holde arbejdskvaliteten og vores fornuft intakte.
Når du gør det, skal du oplyse din bekymring på forhånd og gå ind for kvalitet.
Her er en situation, jeg var i, og dette kan give dig en bedre idé om, hvad jeg taler om:
Mit firma vandt et nyt logo, og som en del af migrationen fra et gammelt firma til mit firma var der planlagt videnoverførselssessioner. Vi, et team på 6 medlemmer rejste til klientwebstedet. Den første dag efter introduktion blev vi delt med KT-planen. Jeg fandt ud af, at mit navn var mærket mod flere moduler. Et af disse moduler burde have været helt uden for min rækkevidde, fordi jeg ikke engang var opmærksom på den teknologi; det matchede på ingen måde mine færdigheder.
Jeg gik til kundeovergangsledningen og fortalte ham situationen -
- For mange arbejdsgenstande blev tildelt mig, hvilket igen vil hæmme kvaliteten og min evne til at fange 100% i sessionerne.
- De planlagte genstande havde områder, hvor mine færdigheder ikke ville matche, og da jeg ikke passede rigtigt, forstod jeg muligvis ikke 100% under overgangen.
Føringen forstået problemet og revideret KT-planen.
hvad er den bedste databasesoftware
Jeg håber, det hjælper med at bekræfte, at: Hvis der er noget på vores tallerken, betyder det ikke, at vi skal spise det hele. Især ikke hvis det betyder at gå på kompromis med kvaliteten.
B) Testcases fuldstændighed
Hvor mange af jer er enige med mig i det, hvis vi prøver forbedre den måde, vi skriver testsager på , det fører til bedre kvalitet?
Nedenfor er nogle almindelige fejl, der er almindelige i de fleste testsager:
Testkassekomponenter | Nuværende problem | Opløsning |
---|---|---|
Objektiv | Mål er den vigtigste del af enhver testsag, det er det, der gør alle testsager forskellige. Almindelige fejl med mål mangler klarhed. Som alle testsager, der er oprettet for en funktionalitet, har det et mål uden at vise, hvordan hver testcase adskiller sig. | Målsætningen / formålet med hver testtilfælde skal være tydelig for at forklare, hvilken funktionalitet og hvilken testtilstand der skal testes som en del af denne testtilfælde. Samme funktionalitet kan have positive og negative testtilfælde, så objektivt skal være klart nok til at vise forskellen. En god idé er at henvise testscenariet til definition af mål. |
Forudsætninger | Mange testere går helt glip af at nævne forudsætningen, ellers vil mange simpelthen kopiere og indsætte. Kopiering indsætter fører til fejl, da hver testtilfælde kan være helt forskellig fra en anden. | Undgå Copy-Paste-fejl og vær opmærksom på detaljer. |
Testdata | Dette er sandsynligvis det mest overset felt, og i de fleste testsager vil det være tomt eller mangler en præcis definition | Nævn de relevante data, der skal indtastes. Nogle gange behøver det ikke være nøjagtigt. For eksempel: Brugerregistrering kan registrere en bruger Anna eller John, og det betyder ikke noget. Men at definere, at et gyldigt navn, der har alle tegn og skal være 4-10 i længden, kan hjælpe med at afklare mange ting. |
Test sag-id | Over forenklet navngivning eller nummereringskonvention. Sig, du tester en loginknap. Ofte er ID'erne: TC_1_Login TC_2_Login | Gør dem mere beskrivende: TC_1_Login_Invalid_User TC_2_Login_Valid_User |
Reference dokumenter | Inkonsekvent kopipasta fra referencedokumenter eller værre ved hjælp af en forkert. | Det tilrådes altid at nævne det korrekte referencedokument med det korrekte versionsnummer, f.eks. For nogle testtilfælde ville FRS og tekniske specifikationer begge være henvist, så testtilfælde i referenceafsnittet bør nævne begge dele. |
Test sag trin | Manglende trin, hovedsagelig af testere, der kender applikationen meget godt. De kunne antage tingene og springe over at nævne trinnene. Dette medfører problemer for virksomheden, korrekturlæsere og nye testere. | Korrekte trin og rækkefølge skal anvendes. |
For at opsummere, hvis der tages hensyn til små detaljer i designfasen, vil testoutputkvaliteten være meget bedre.
# 3) Forretningsforståelse
Dette er en af de vigtigste faktorer, som kunderne ser efter i testere. Det er dog trist, at nogle testere mener, at deres job er at skrive testsager baseret på FRS og ikke gør en indsats for at forstå forretningen.
char til heltal c ++
Prøv først at kende virksomheden og se derefter på funktionalitet; du kan forestil dig din klients behov mere og test i overensstemmelse hermed.
Her er et eksempel- FRS siger 'XYZ-rapport skal genereres med 3 kolonner som dato, navn og status'. Følgende er de testsager, du ender med, når du tager dette krav til pålydende værdi:
- Bekræft rapport XYZ genereres
- Valideringsrapport har 3 kolonner som dato, navn, status
- Valider dataene i 3 kolonner.
Men når du holder forretningsrapportens anvendelighed i tankerne, skal du muligvis teste:
- Hvad er forretningsformålet med denne rapport?
- Bliver denne rapport genereret hver dag?
- Hvem ser forretningsbrugere på denne rapport?
- Hvad er datakilden til denne rapport?
- Bør rapporten genereres, hvis der ikke er data tilgængelige?
Dette er kun et eksempel, men jeg antager, at vi alle er enige om, at bedre test kan opnås ved at få forretningsbevidsthed og ekspertise.
# 4) Tilgængelighed
Uanset om du er en enkelt person, der støtter kunden eller et team, skal din tilgængelighed altid kontrolleres ( ).
Efter tilgængelighed betyder det ikke support døgnet rundt. Det betyder bare klar og forudgående kommunikation om ledighed, alternative planer og at være tilgængelig og ikke gå MIA.
Nedenfor er nogle af de modeller, som serviceindustrien følger:
- Model til personaleforøgelse - Hvis du arbejder i en personaleforøgelsesmodel og er enerepræsentant fra din virksomhed, tilrådes det, at kunden gøres opmærksom på dine arbejdstider og planlagte fravær, så de nødvendige arrangementer kan træffes.
- Managed Projects Model - I en styret projektmodel, hvor store projektteams dannes og ledes af leverings- / projektledere, er det ikke længere kundernes ansvar at have en backup-ressourceplan. PM's behov for at styre både planlagte og ikke-planlagte fridage. I denne model tilrådes det, at premierministeren prøver at indsamle de planlagte fraværsdata fra deres team på forhånd og klare sig i overensstemmelse hermed. Der er tilfælde, hvor kunder beder om support i weekenden eller forlænget arbejdstid. Sådanne sager bør også planlægges ved hjælp af roterende ressourcer. Et team skal bestå af medlemmer, der kan sikkerhedskopiere hinanden, hvis det kræves. De planlagte detaljer skal deles med kunden.
# 5) Forbedringsomfang
Dette er ikke kun ønskeligt i softwareindustrien men overalt. At bringe forbedring er ikke et engangsjob. Omfanget af forbedringer skal arbejdes kontinuerligt med og kan opdeles i 3 trin -
Læs også=> Sådan forbedres dine testfærdigheder og vinder konkurrencen
Trin # 1: Identificer
Lav en grundig undersøgelse og identificer områder / muligheder for forbedringer. Sig, når du bliver bedt om at teste den samme funktionalitet flere gange ved hjælp af den samme proces, vil der komme et tidspunkt, hvor du vil føle, at du enten vil flytte ud af projektet eller ændre den måde, det testes på. Sådan bringes forbedringer ind, når vi keder os vores eksisterende metoder, vi tænker på at ændre og forbedre .
Trin # 2: Bring forbedringer
Hvis tingene blev gjort manuelt, kunne du prøv at automatisere nogle få ting . Når jeg siger automatisering, betyder det ikke altid at købe et automatiseret værktøj.
Jeg vil citere en situation:
Jeg var en del af et databasetestteam. Vores daglige arbejde involverede at køre de samme SQL-scripts flere gange på en dag med et andet sæt parametre. Da vi startede projektet, var det fint med disse trin, men til sidst forstod vi systemet bedre, og vi troede, at de samme SQL-scripts kan køres som en del af lagrede procedurer i stedet for, at nogen manuelt opdaterer parametre og udfører.
Trin # 3: Evaluer forbedringen
Hver gang en ny proces implementeres, skal du sikre dig, at den fungerer som forventet og ikke har nogen bivirkninger. Ved at udvide det tidligere eksempel, en introduktion af lagrede procedurer, skal du kontrollere, om output fra den nyoprettede automatiserede måde og output fra manuel måde er de samme.
Den anden del er at overvåge fordelene over en periode for at være helt sikker og præsentere resultaterne for dine kunder. I vores projekt viste vi kunderne en reduktion i testudførelsestiden med 30%, hvilket igen reducerede omkostningerne.
Konklusion
Afslutningsvis ville jeg bare nævne, at hver enkelt af os har medfødte talenter, og at vi alle har vores egne unikke arbejdsformer, og dette var blot nogle tip, som jeg tror kan tilbyde vores kunder en bedre serviceoplevelse.
Om forfatteren: Denne fantastiske artikel er skrevet af STH-teammedlem Priya R. Hvis du vil skrive for os og dele din oplevelse, bedes du lad os vide det her .
Håber du har nydt at læse denne artikel og fundet den informativ! Fortæl os, hvis du har en anden oplevelse at dele.
Anbefalet læsning
- Bedste softwaretestværktøjer 2021 [QA Test Automation Tools]
- Global softwaretestvirksomhed når snart $ 28,8 milliarder
- Råd om softwaretest til nybegyndere
- Software Testning QA Assistant Job
- Hvordan holder jeg motivationen levende i softwaretestere?
- Zen and the Art of Software Testing
- Software Testing Course: Hvilket Software Testing Institute skal jeg tilmelde mig?
- Valg af softwaretest som din karriere