what do clients really expect from software testers
I dagens artikel kommer jag att dela några tankar om vad jag tror att klienterna verkligen förväntar sig av oss baserat på min första hand erfarenhet av att arbeta på kundplatser med dagliga ansikte mot ansikte interaktioner och samarbetar offshore via e-post eller telefonsamtal.
IT-tjänster är en viktig och integrerad del av programvaruindustrin och kundtillfredsställelse är viktigt för att lyckas. Varje klient / organisation kan vara olika i sin process kan följa olika protokoll och kan hantera olika typer av företag.
Men följande faktorer är vanliga och spelar roll för alla i allmänhet.
(bild src )
Vad du kommer att lära dig:
- 5 saker som kunden förväntar sig av programvarutestare:
- # 1) Kostnadsfördel
- # 2) Arbets kvalitet
- # 3) Affärsförståelse
- # 4) Tillgänglighet
- # 5) Förbättringsomfång
- Slutsats
- Rekommenderad läsning
5 saker som kunden förväntar sig av programvarutestare:
# 1) Kostnadsfördel
När du tänker sälja eller köpa något spelar kostnad en viktig roll och det är ofta en av de viktigaste avgörande faktorerna. Väntar vi inte alla ivrigt på Black Friday, Flipkart Billion Day-försäljningen eller Amazons fantastiska shoppingfestival? Vi blir galna köpare under försäljningstiden. Det är ett enkelt mänskligt beteende att förvänta sig rätt eller extra värde för pengarna.
Företag och kunder är inte olika. Kostnadsfördelar ökar kund-service-relationerna och det är inte ovanligt att serviceföretag tappar bud på grund av lägre prisnoterade konkurrenter.
STORA frågan är nu: Hur kan vi visa kostnadsfördelar för våra kunder?
Dessa punkter kan hjälpa:
- Visa dem deras pengar . Motivera och tillhandahålla stödjande bevis för din uppskattningar .
- Tänk på kreativa sätt att spara på utgifterna.
- Skräddarsy din offert. Istället för att hålla fast vid din standardprocess som kostar X summa pengar, ge billigare alternativ. Till exempel : Föreslå kritisk vägtestning istället för fullständig systemtestning.
- Känn din tävling . En snabb verklighetskontroll av vad andra tjänsteföretag erbjuder sina kunder till vilka kostnader är viktigt för att hålla din prissättningsmodell relevant.
# 2) Arbets kvalitet
Arbetets kvalitet och kvantitet är två mycket olika saker.
Borta är de dagar då antalet testfall som skapats eller rapporterade defekter används för produktivitets- eller kvalitetsindikatorer. Inte längre.
Situationen är mer som bilden nedan:
A) Vet när du ska säga ”NEJ”
Vi har alla varit på platser där vi arbetat övertid, varit i beredskap under helgerna, närvarat sent på kvällen eller tidigt på morgonen samtal, etc. Vad vi inte inser är dock att vi kan säga NEJ om saker och ting blir värre. Säger NEJ är det enda sättet vi kan hålla kvaliteten på arbetet och vår förnuft intakt.
När du gör det, ta upp din oro i förväg och förespråka kvalitet.
Här är en situation jag befann mig i och detta kan ge dig en bättre uppfattning om vad jag pratar om:
Mitt företag vann en ny logotyp och som en del av migrationen från ett gammalt företag till mitt företag planerades kunskapsöverföringssessioner. Vi, ett team på 6 medlemmar reste till klientens webbplats. Den första dagen efter introduktionen delades vi KT-planen. Jag hittade att mitt namn var taggat mot flera moduler. En av dessa moduler borde ha varit helt utanför mitt omfång eftersom jag inte ens var medveten om den tekniken; det matchade inte på något sätt mina färdigheter.
Jag gick till kunskapsövergångsledningen och berättade för honom situationen -
- För många arbetsobjekt tilldelades mig, vilket i sin tur kommer att hämma kvaliteten och min förmåga att fånga 100% i sessionerna.
- De planerade föremålen hade områden där mina färdigheter inte skulle matcha och eftersom jag inte passade rätt förstod jag kanske inte 100% under övergången.
Ledningen förstod problemet och reviderade KT-planen.
hur man testar privata metoder med mockito
Jag hoppas att detta hjälper till att bekräfta att: om något finns på vår tallrik betyder det inte att vi måste äta allt. Speciellt inte om det innebär att kompromissa med kvaliteten.
B) Testfallets fullständighet
Hur många av er håller med mig om det om vi försöker förbättra sättet vi skriver testfall , leder det till bättre kvalitet?
Nedan följer några vanliga misstag som är vanliga i de flesta testfall:
Testfallskomponenter | Nuvarande problem | Lösning |
---|---|---|
Mål | Mål är den viktigaste delen av alla testfall, det är det som gör alla testfall olika. Vanliga misstag med Object saknar tydlighet. Som alla testfall som skapats för en funktion har ett mål utan att visa hur varje testfall skiljer sig. | Mål / syfte med varje testfall ska vara tydligt för att förklara vilken funktionalitet och vilket testförhållande som ska testas som en del av testfallet. Samma funktionalitet kan ha positiva och negativa testfall, så målet bör vara tillräckligt tydligt för att visa skillnaden. En bra idé är att hänvisa testscenariot för att definiera mål. |
Förutsättningar | Många testare missar helt att nämna förutsättningen eller många kopierar och klistrar helt enkelt. Kopiera klistra in leder till fel eftersom varje testfall kan vara helt annorlunda. | Undvik Copy-Paste-fel och var uppmärksam på detaljer. |
Testdata | Detta är förmodligen det mest förbises fältet och de flesta testfall kommer att ha det tomt eller saknar exakt definition | Nämn lämpliga uppgifter som ska anges. Ibland behöver det inte vara korrekt. Till exempel: Användarregistrering kan registrera en användare Anna eller John och det spelar ingen roll. Men att definiera att ett giltigt namn som har alla tecken och ska vara 4-10 i längd kan hjälpa till att klargöra många saker. |
Testfall ID | Över förenklad namngivning eller numreringskonvention. Säg, du testar en inloggningsknapp. Ofta är ID: n: TC_1_Login TC_2_Login | Gör dem mer beskrivande: TC_1_Login_Invalid_User TC_2_Login_Valid_User |
Referensdokument | Inkonsekvent kopia-klistra in från referensdokument eller värre, med felaktig. | Det är alltid tillrådligt att nämna rätt referensdokument med rätt versionsnummer, säg för vissa testfall FRS och tekniska specifikationer båda skulle ha hänvisats, så testfallet i referensavsnittet bör nämna båda. |
Steg för testfall | Saknade steg, mestadels av testare som känner till applikationen mycket väl. De kunde anta saker och hoppa över att nämna stegen. Detta orsakar problem för verksamheten, granskare och nya testare. | Korrekt steg och sekvens bör användas. |
Sammanfattningsvis, om små detaljer tas med i beräkningen i designfasen kommer testutgångskvaliteten att vara mycket bättre.
# 3) Affärsförståelse
Detta är en av de viktigaste faktorerna som kunderna letar efter i testare. Det är dock tråkigt att vissa testare tror att deras jobb är att skriva testfall baserade på FRS och inte anstränger sig för att förstå verksamheten.
Försök att känna till verksamheten först och undersök sedan funktionaliteten; du kan se dina kunders behov mer och testa därefter.
Här är ett exempel- FRS säger att ”XYZ-rapporten ska genereras med tre kolumner som datum, namn och status”. Följande är de testfall du kommer att sluta med när du tar detta krav till dess nominella värde:
- Validera rapport XYZ genereras
- Validera rapporten har tre kolumner som Datum, Namn, Status
- Validera data i tre kolumner.
Men när du tänker på affärsapplikationen för denna rapport kan du behöva testa:
- Vad är affärsmålet med denna rapport?
- Blir den här rapporten genererad varje dag?
- Vem är affärsanvändarna som tittar på den här rapporten?
- Vad är datakällan för denna rapport?
- Bör rapporten genereras om ingen data finns tillgänglig?
Detta är bara ett exempel, men jag antar att vi alla är överens om att bättre testning kan uppnås genom att få affärsmedvetenhet och expertis.
# 4) Tillgänglighet
Oavsett om du är en enskild person som stöder kunden eller ett team, bör din tillgänglighet alltid kontrolleras ( ).
Efter tillgänglighet betyder det inte support dygnet runt. Det betyder bara tydlig och förhandskommunikation om ledighet, alternativa planer och att nås och inte gå MIA.
Nedan följer några av de modeller som tjänstebranschen följer:
- Modell för personalförstoring - Om du arbetar i en personalförstärkningsmodell och är ensamrepresentant från ditt företag är det tillrådligt att kunden görs medveten om dina arbetstider och planerade frånvaro så att nödvändiga arrangemang kan göras.
- Hanterade projektmodell - I en hanterad projektmodell där stora projektgrupper bildas och leds av leverans / projektledare förblir det inte längre kundernas ansvar att ha en reservresursplan. PM: s behov av att hantera både planerade och oplanerade lediga dagar. I den här modellen rekommenderas det att premiärministerna försöker samla in de planerade frånvarodata från sitt team i förväg och hantera därefter. Det finns fall där kunderna begär helgstöd eller utökad arbetstid. Sådana fall bör också planeras med roterande resurser. Ett team ska bestå av medlemmar som kan säkerhetskopiera varandra vid behov. De planerade detaljerna ska delas med kunden.
# 5) Förbättringsomfång
Detta är inte bara önskvärt i mjukvaruindustrin utan överallt. Att få förbättring är inte ett dagsjobb. Omfattningen av förbättringar måste arbetas kontinuerligt och kan delas in i 3 steg -
Läs också=> Hur du kan förbättra dina testfärdigheter och slå tävlingen
Steg 1: Identifiera
Gör en grundlig studie och identifiera områden / utrymmen för förbättringar. Säg att när du blir ombedd att testa samma funktion flera gånger med samma process kommer det att komma en tid då du kommer att känna att du antingen vill flytta ut ur projektet eller att du ändrar hur det testas. Så här förbättras vi när vi tröttnar på våra befintliga metoder, vi tänker på att förändra och förbättra .
Steg 2: Ta med förbättringar
Om saker gjordes manuellt kan du försök att automatisera några saker . När jag säger automatisering betyder det inte alltid att köpa ett automatiserat verktyg.
Jag kommer att citera en situation:
jämför två filer i linux och hitta skillnaderna
Jag var en del av ett testteam för databaser. Vårt dagliga arbete innebar att köra samma SQL-skript flera gånger på en dag med en annan uppsättning parametrar. När vi startade projektet gick det bra med dessa steg men så småningom förstod vi systemet bättre och vi trodde att samma SQL-skript kan köras som en del av lagrade procedurer istället för att någon manuellt uppdaterar parametrar och kör.
Steg 3: Utvärdera förbättringen
När en ny process implementeras måste du se till att den fungerar som förväntat och inte har några biverkningar. Utöka det tidigare exemplet, en introduktion av lagrade procedurer, kontrollera om utdata från det nyskapade automatiserade sättet och utdata från manuellt sätt är desamma.
Den andra delen är att övervaka fördelarna under en tidsperiod för att vara helt säker och presentera resultaten för dina kunder. I vårt projekt visade vi kunderna en minskning av testkörningstiden med 30% vilket i sin tur minskade kostnaden.
Slutsats
Sammanfattningsvis ville jag bara nämna att var och en av oss har medfödda talanger och att vi alla har våra egna unika arbetsstilar och det var bara några tips som jag tror kan erbjuda våra kunder en bättre serviceupplevelse.
Om författaren: Den här fantastiska artikeln är skriven av STH-teammedlem Priya R. Om du vill skriva för oss och dela med dig av din erfarenhet tack låt oss veta här .
Hoppas du gillat att läsa den här artikeln och tyckte att den var informativ! Låt oss veta om du har en annan upplevelse att dela.
Rekommenderad läsning
- Bästa verktyg för testning av programvara 2021 (QA Test Automation Tools)
- Global mjukvarutestning kommer snart att nå 28,8 miljarder dollar
- Råd om programvarutestning för nybörjare
- Programvarutestning QA-assistentjobb
- Hur håller jag motivationen levande i programvarutestare?
- Zen and the Art of Software Testing
- Kurs för programvarutestning: Vilket program för testning av programvara ska jag gå med?
- Välja programvarutestning som din karriär