Meni

Što klijenti DOISTA očekuju od softverskih testera?

what do clients really expect from software testers

Isprobajte Naš Instrument Za Uklanjanje Problema

U današnjem članku podijelit ću neke misli o onome što vjerujem da klijenti DOISTA očekuju od nas na temelju mog iskustva iz prve ruke radeći na klijentskim lokacijama uz svakodnevne interakcije licem u lice i suradnja u inozemstvu putem e-maila ili telefonskih poziva.

IT usluge važan su i sastavni dio softverske industrije, a zadovoljstvo kupaca važno je za uspjeh. Svaki klijent / organizacija može biti drugačiji u svom procesu, može slijediti drugačiji protokol i može se baviti različitim vrstama poduzeća.

Sljedeći su čimbenici zajednički i svima su važni.

klijenti za testiranje softvera

(slika src )

Što ćete naučiti:

5 stvari koje klijent očekuje od softverskih testera:

Očekivanje klijenta 1

# 1) Troškovna korist

Kad razmišljate o prodaji ili kupnji nečega, trošak igra glavnu ulogu i često je jedan od važnih odlučujućih čimbenika. Ne čekamo li svi s nestrpljenjem Crni petak, rasprodaju Flipkarta Billion Day ili sjajni Amazonov šoping festival? Postajemo ludi kupci za vrijeme prodaje. Jednostavno je ljudsko ponašanje očekivati ​​pravu ili dodatnu vrijednost za svoj novac.

Tvrtke i kupci se ne razlikuju. Troškovne koristi pojačavaju odnose s kupcima i uslugama, a nerijetko servisne tvrtke gube ponude zbog slabijeg citiranja konkurenata.

Troškovna korist

VELIKO je pitanje sada: Kako svojim kupcima možemo pokazati isplativost?

Ove točke mogu vam pomoći:

  • Pokažite im vrijednost njihovog novca . Opravdajte i pružite dodatne dokaze za svoje procjene .
  • Zamislite kreativne načine uštede na troškovima.
  • Prilagodite svoju ponudu. Umjesto da se pridržavate svog standardnog postupka koji košta X iznos novca, pružite jeftinije alternative. Na primjer : Predložite testiranje kritične staze umjesto cjelovitog testiranja sustava.
  • Upoznajte svoju konkurenciju . Brza provjera stvarnosti onoga što druge uslužne tvrtke nude svojim klijentima pod kojim troškovima je važno kako bi vaše tržište modela cijena bilo relevantno.

# 2) Kvaliteta rada

Kvaliteta i količina rada dvije su vrlo različite stvari.

Prošla su vremena kada se broj stvorenih testnih slučajeva ili prijavljenih nedostataka koristio u pokazateljima produktivnosti ili kvalitete. Ne više.

Situacija je sličnija donjoj slici:

Kvaliteta rada

Kvaliteta rada 2

A) Znati kada reći ‘NE’

Svi smo bili na mjestima gdje smo radili prekovremeno, dežurali preko vikenda, prisustvovali kasnim noćnim ili ranojutarnjim pozivima itd. Međutim, ono što ne shvaćamo jest da možemo reći NE ako se stvari nastave pogoršavati. Rekavši NE je jedini način na koji možemo zadržati kvalitetu rada i zdrav razum.

Pritom unaprijed podnesite svoju zabrinutost i zagovarajte kvalitetu.

Evo situacije u kojoj sam bio i ovo bi vam moglo dati bolju predodžbu o čemu govorim:

Moja je tvrtka osvojila novi logotip i kao dio migracije sa stare tvrtke na moju tvrtku planirane su sesije prijenosa znanja. Mi, tim od 6 članova putovali smo na web mjesto klijenta. Prvog dana nakon uvođenja podijelili smo KT plan. Otkrio sam da je moje ime označeno s više modula. Jedan od tih modula trebao je biti potpuno izvan mog opsega, jer nisam ni bio svjestan te tehnologije; to se nikako nije poklapalo s mojim vještinama.

Otišao sam do vodiča za prijelaz znanja i rekao mu situaciju -

  • Dodijeljeno mi je previše radnih predmeta, što će zauzvrat narušiti kvalitetu i moju sposobnost da 100% zabilježim u sesijama.
  • Planirani predmeti imali su područja na kojima se moje vještine ne podudaraju, a budući da nisam bio u formi, možda nisam razumio 100% tijekom tranzicije.

Put razumio problem i revidirao KT plan.

kako stvoriti popis objekata u javi

Nadam se da ovo pomaže u potvrđivanju sljedećeg: Ako je nešto na našem tanjuru, to ne znači da moramo sve to pojesti. Pogotovo ne ako to znači kompromitiranje kvalitete.

B) Kompletnost testnog slučaja

Koliko se vas sa mnom slaže ako to pokušamo poboljšati način pisanja test slučajeva , dovodi do bolje kvalitete?

Ispod su neke uobičajene pogreške koje su česte u većini testnih slučajeva:

Komponente testnog slučajaTrenutni problemRiješenje
Cilj Cilj je najvažniji dio svakog test slučaja, to je ono što sve test slučajeve čini različitim. Uobičajene pogreške u objektivu nedostaju jasnoća.

Kao i svi testni slučajevi stvoreni za jednu funkcionalnost imaju jedan cilj bez pokazivanja kako se svaki testni slučaj razlikuje.		 Cilj / svrha svakog test slučaja trebao bi biti jasan kako bi se objasnilo koja će se funkcionalnost i koji testni uvjeti testirati kao dio tog testnog slučaja.

Ista funkcionalnost može imati pozitivne i negativne test slučajeve, pa bi objektiv trebao biti dovoljno jasan da pokaže razliku. Dobra ideja je uputiti testni scenarij za definiranje cilja.
Preduvjeti Mnogi testeri potpuno propuste spomenuti preduvjet ili će mnogi jednostavno kopirati i zalijepiti. Lijepljenje kopija dovodi do pogrešaka jer se svaki testni slučaj može potpuno razlikovati od drugog.Izbjegavajte pogreške Copy-Paste i obratite pažnju na detalje.
Podaci o ispitivanju Ovo je vjerojatno područje koje se najviše previđa i u većini će testnih slučajeva biti prazno ili mu nedostaje precizna definicijaNavedite odgovarajuće podatke koje treba unijeti. Ponekad to ne mora biti točno.

Na primjer: Registracija korisnika može registrirati korisnika Anna ili John i to ne bi bilo važno. No definiranje da valjano ime koje ima sve znakove i treba biti duljine 4-10 može pomoći u razjašnjavanju mnogih stvari.
ID testnog slučaja Preko pojednostavljene konvencije imenovanja ili numeriranja. Recimo, testirate gumb za prijavu. ID-ovi su često:
TC_1_Login
TC_2_Login		Učinite ih opisnijima:
TC_1_Login_Invalid_User
TC_2_Login_Valid_User
Referentni dokumenti Nedosljedno kopiranje-lijepljenje iz referentnih dokumenata ili još gore, koristeći netočan dokument.Uvijek je poželjno spomenuti točan referentni dokument s točnim brojem verzije, recimo da bi se za neke ispitne slučajeve odnosili FRS i tehničke specifikacije, pa bi testni slučaj u referentnom odjeljku trebao spomenuti oba.
Koraci test primjera Koraci koji nedostaju, uglavnom testeri koji vrlo dobro poznaju aplikaciju. Mogli su pretpostaviti stvari i preskočiti spominjanje koraka. To uzrokuje probleme tvrtki, recenzentima i novim ispitivačima.Treba koristiti ispravne korake i redoslijed.

Da rezimiramo, ako se u fazi projektiranja uzmu u obzir mali detalji, kvaliteta izlaznog testa bit će mnogo superiornija.

# 3) Poslovno razumijevanje

Ovo je jedan od najvažnijih čimbenika koji kupci traže u testerima. Međutim, tužno je što neki testeri vjeruju da je njihov posao pisanje testnih slučajeva na temelju FRS-a i ne trude se razumjeti posao.

Pokušajte prvo upoznati tvrtku, a zatim potražite funkcionalnost; možeš zamislite potrebe svog klijenta više i u skladu s tim testirajte.

Evo primjera- FRS navodi 'Izvještaj XYZ treba generirati s 3 stupca kao datum, ime i status'. Slijede testni slučajevi s kojima ćete završiti kada ovaj zahtjev uzmete u nominalnu vrijednost:

  • Generira se potvrdno izvješće XYZ
  • Izvještaj o potvrdi ima 3 stupca kao Datum, Ime, Status
  • Potvrdite podatke u 3 stupca.

No, ako imate na umu poslovnu primjenjivost ovog izvješća, možda ćete morati testirati:

  • Koja je poslovna svrha ovog izvješća?
  • Generira li se ovo izvješće svaki dan?
  • Tko su poslovni korisnici koji gledaju ovo izvješće?
  • Koji je izvor podataka za ovo izvješće?
  • Treba li generirati izvješće ako podaci nisu dostupni?

Ovo je samo jedan primjer, ali pretpostavljam da se svi slažemo da se bolja testiranja mogu postići stjecanjem poslovne svijesti i stručnosti.

unos i izlaz datoteke c ++

# 4) Dostupnost

Bez obzira jeste li pojedinac koji podržava kupca ili tim, uvijek treba provjeriti vašu dostupnost ( Opseg poboljšanja).

Pod dostupnošću, to ne znači 24/7 podršku. To samo znači jasnu i neposrednu komunikaciju o slobodnim vremenima, alternativnim planovima i dostupnosti i odlasku u MUP.

Ispod su neki od modela koje industrija usluga slijedi:

  • Model povećanja osoblja - Ako radite na modelu za povećanje osoblja i jedini ste predstavnik vaše tvrtke, poželjno je da se kupac upozna s vašim vremenima rada i planiranim izostancima kako bi se mogli donijeti potrebni dogovori.
  • Model upravljanih projekata - U upravljanom projektnom modelu u kojem se formiraju veliki projektni timovi i kojima rukovode voditelji isporuka / projekata, stvaranje rezervnog plana resursa više nije odgovornost kupaca. PM-ova potreba upravljanja i planirano i neplanirano slobodno vrijeme. U ovom je modelu preporučljivo da premijer pokuša prije vremena prikupiti planirane podatke o odsutnosti od svog tima i upravljati u skladu s tim. Postoje slučajevi kada kupci zatraže potporu vikendom ili produženo radno vrijeme. Takve slučajeve također treba planirati izmjenom resursa. Tim bi se trebao sastojati od članova koji se mogu međusobno sigurnosno kopirati ako je potrebno. Planirane detalje treba podijeliti s kupcem.

# 5) Opseg poboljšanja

To nije poželjno samo u softverskoj industriji, već i svugdje. Donošenje poboljšanja nije jednodnevni posao. Na opsegu poboljšanja treba kontinuirano raditi i može se podijeliti na 3 koraka -

Također pročitajte=> Kako poboljšati svoje vještine testiranja i pobijediti konkurenciju

1. korak: Identificirajte

Temeljito proučite i utvrdite područja / opseg za poboljšanja. Recimo, kad se od vas zatraži da istu funkciju testirate nekoliko puta istim postupkom, doći će trenutak kada ćete osjetiti da ili želite napustiti projekt ili promijenite način na koji se testira. Tako se uvode poboljšanja kad nam dosade naše postojeće metode, mislimo mijenjati i poboljšavati .

Korak 2: Donesite poboljšanja

Da se stvari rade ručno, mogli biste pokušajte automatizirati nekoliko stvari . Kad kažem automatizacija, ne znači uvijek kupnju automatiziranog alata.

Citirat ću situaciju:

Bio sam dio tima za testiranje baze podataka. Naš svakodnevni rad uključivao je pokretanje istih SQL skripti više puta dnevno s različitim skupom parametara. Kad smo započeli projekt, bili smo u redu s ovim koracima, ali na kraju smo bolje razumjeli sustav i mislili smo da se iste SQL skripte mogu pokretati kao dio pohranjenih procedura umjesto da netko ručno ažurira parametre i izvršava.

3. korak: Procijenite poboljšanje

Kad god se primijeni novi postupak, morat ćete osigurati da funkcionira prema očekivanjima i da nema nuspojava. Proširujući raniji primjer, uvođenje pohranjenih procedura, provjerite jesu li izlazi iz novostvorenog automatiziranog načina i izlazi iz ručnog načina jednaki.

Drugi dio je praćenje blagodati tijekom određenog vremenskog razdoblja kako biste bili potpuno sigurni i predstavili rezultate svojim klijentima. U našem projektu pokazali smo klijentima smanjenje vremena izvođenja testa za 30% što je zauzvrat smanjilo troškove.

Zaključak

Za kraj, samo sam želio spomenuti da svatko od nas ima urođene talente i svi imamo svoje jedinstvene stilove rada, a to su bili samo neki savjeti za koje vjerujem da našim klijentima mogu ponuditi bolje uslužno iskustvo.

O autoru: Ovaj sjajni članak napisala je članica STH tima Priya R. Ako želite pisati za nas i podijeliti svoje iskustvo, molimo vas javite nam ovdje .

Nadam se da ste uživali čitajući ovaj članak i smatrali ga informativnim! Javite nam ako imate drugačije iskustvo za dijeljenje.

Preporučena literatura

^