what do clients really expect from software testers
V dnešnom článku sa chystám podeliť o niekoľko myšlienok o tom, čo verím, že klienti od nás NAOZAJ očakávajú na základe mojich skúseností z prvej ruky pracujúcich v miestach klientov s každodennými osobnými interakciami a spolupracujúci na mori prostredníctvom e-mailov alebo telefonických hovorov.
Služby IT sú dôležitou a neoddeliteľnou súčasťou softvérového priemyslu a spokojnosť zákazníka je dôležitá pre úspech. Každý klient / organizácia sa môže líšiť v procese, ktorý sa môže riadiť iným protokolom, a môže rokovať s iným typom podnikania.
Nasledujúce faktory sú však bežné a sú dôležité pre všetkých všeobecne.
[obrázok src ]
Čo sa dozviete:
- 5 vecí, ktoré klient očakáva od softvérových testerov:
- # 1) Úžitok z nákladov
- # 2) Kvalita práce
- # 3) Obchodné porozumenie
- # 4) Dostupnosť
- # 5) Rozsah zlepšenia
- Záver
- Odporúčané čítanie
5 vecí, ktoré klient očakáva od softvérových testerov:
# 1) Úžitok z nákladov
Keď uvažujete o predaji alebo kúpe niečoho, zohrávajú hlavnú úlohu náklady a často sú jedným z dôležitých rozhodujúcich faktorov. Nečakáme všetci nedočkavo na Black Friday, výpredaj Flipkart Billion Day alebo skvelý nákupný festival Amazon? Počas doby predaja sa stávame bláznivými kupujúcimi. Je to jednoduché ľudské správanie, keď očakávame správnu alebo mimoriadnu hodnotu za naše peniaze.
Spoločnosti a zákazníci sa nelíšia. Nákladové výhody posilňujú vzťahy medzi zákazníkmi a službami a nie je nezvyčajné, že spoločnosti poskytujúce služby stratia ponuky z dôvodu nižšej ponuky konkurencie.
Veľká otázka teraz znie: Ako môžeme zákazníkom ukázať výhody v oblasti nákladov?
Tieto body môžu pomôcť:
- Ukážte im ich hodnotu peňazí . Zdôvodnite a poskytnite podporné dôkazy pre svoje odhady .
- Vymyslite kreatívne spôsoby, ako ušetriť na výdavkoch.
- Prispôsobte svoju ponuku. Namiesto toho, aby ste sa držali štandardného procesu, ktorý stojí X peňazí, poskytnite lacnejšie alternatívy. Napríklad : Namiesto úplného testovania systému navrhnite testovanie kritických ciest.
- Poznajte svoju konkurenciu . Rýchla kontrola reality toho, čo iné spoločnosti poskytujúce služby ponúkajú svojim klientom za aké náklady, je dôležitá, aby bol váš model cenového modelu relevantný pre trh.
# 2) Kvalita práce
Kvalita a množstvo práce sú dve veľmi odlišné veci.
Časy, keď sa počet vytvorených testovacích prípadov alebo hlásených chýb používali na ukazovatele produktivity alebo kvality, sú preč. Už nie.
Situácia sa viac podobá obrázku nižšie:
A) Vedieť, kedy povedať „NIE“
Všetci sme boli na miestach, kde sme pracovali nadčas, boli sme v pohotovosti cez víkendy, zúčastňovali sme sa hovorov neskoro večer alebo skoro ráno atď. Neuvedomujeme si však, že môžeme povedať NIE, ak sa veci budú zhoršovať. Povedať NIE je jediný spôsob, ako môžeme udržať kvalitu práce a náš zdravý rozum nedotknutý.
Ak tak urobíte, vopred upozornite na svoje obavy a obhajujte kvalitu.
Tu je situácia, v ktorej som sa nachádzal, a to vám môže poskytnúť lepšiu predstavu o tom, o čom hovorím:
Moja spoločnosť získala nové logo a ako súčasť prechodu zo starej spoločnosti na moju spoločnosť boli naplánované stretnutia prenosu znalostí. My, tím 6 členov, sme cestovali na stránku klienta. Hneď prvý deň po zavedení sme boli oboznámení s plánom KT. Zistil som, že moje meno bolo označené na viacerých moduloch. Jeden z týchto modulov mal byť úplne mimo môjho rozsahu, pretože som o tejto technológii ani nevedel; nijako sa to nezhodovalo s mojimi schopnosťami.
Išiel som k vedúcemu prechodu znalostí a povedal som mu situáciu -
- Bolo mi pridelených príliš veľa pracovných položiek, čo zase bude brzdiť kvalitu a moju schopnosť zachytávať 100% v reláciách.
- Naplánované položky mali oblasti, kde by sa moje schopnosti nezhodovali, a keďže som nebol v tej správnej forme, nemusel som počas prechodu rozumieť stopercentne.
Olovo pochopil problém a zrevidoval plán KT.
ako vytvoriť zoznam objektov v jave
Dúfam, že to pomôže potvrdiť, že: Ak je niečo na našom tanieri, neznamená to, že to musíme všetko zjesť. Najmä nie, ak to znamená robiť kompromisy v kvalite.
B) Úplnosť testovacieho prípadu
Koľkí z vás so mnou súhlasia, ak sa o to pokúsime vylepšiť spôsob, akým píšeme testovacie prípady , vedie to k lepšej kvalite?
Ďalej uvádzame niektoré bežné chyby, ktoré sú bežné vo väčšine testovacích prípadov:
Súčasti testovacieho prípadu | Aktuálny problém | Riešenie |
---|---|---|
Cieľ | Cieľ je najdôležitejšou súčasťou každého testovacieho prípadu, vďaka čomu sa všetky testovacie prípady líšia. Bežným chybám v rámci cieľa chýba jasnosť. Rovnako ako všetky testovacie prípady vytvorené pre jednu funkcionalitu má jeden cieľ bez toho, aby ukazoval, v čom sa jednotlivé testovacie prípady líšia. | Cieľ / účel každého testovacieho prípadu by mal byť jasný a vysvetľujúci, aká funkčnosť a aké testovacie podmienky sa budú testovať v rámci daného testovacieho prípadu. Rovnaká funkčnosť môže mať pozitívne aj negatívne testovacie prípady, takže objektívny by mal byť dostatočne jasný, aby ukázal rozdiel. Dobrým nápadom je odkázať na definíciu cieľa testovacím scenárom. |
Predbežné podmienky | Mnoho testerov úplne vynechá zmienku o predpokladoch alebo mnohí jednoducho skopírujú a prilepia. Prilepenie kopírovania vedie k chybám, pretože každý testovací prípad sa môže úplne líšiť od iného. | Vyvarujte sa chýb kopírovania a vkladania a dávajte pozor na detaily. |
Skúšobné údaje | Toto je pravdepodobne najviac prehliadané pole a väčšina testovacích prípadov ho bude mať prázdne alebo nebude mať presnú definíciu | Uveďte príslušné údaje, ktoré sa majú zadať. Niekedy to nemusí byť presné. Napríklad: Registrácia používateľa môže zaregistrovať používateľa Annu alebo Johna a to by nevadilo. Definovanie platného názvu, ktorý má všetky znaky a mal by mať dĺžku 4 až 10, vám však môže pomôcť objasniť veľa vecí. |
ID testovacieho prípadu | Cez zjednodušené pomenovanie alebo číslovanie. Povedzme, že testujete prihlasovacie tlačidlo. Identifikátory sú často: TC_1_Prihlásenie TC_2_Prihlásenie | Zlepšite ich popis: TC_1_Login_Invalid_User TC_2_Login_Valid_User |
Referenčné dokumenty | Nekonzistentné kopírovanie a vkladanie z referenčných dokumentov alebo ešte horšie, použitie nesprávneho. | Vždy je vhodné uviesť správny referenčný dokument so správnym číslom verzie, napríklad pri niektorých testovacích prípadoch by sa odporúčali FRS aj Tech Specs, takže v testovacom prípade v referenčnej časti by mali byť uvedené obidve. |
Kroky testovacieho prípadu | Chýbajúce kroky, väčšinou od testerov, ktorí aplikáciu veľmi dobre poznajú. Mohli veci predpokladať a vynechať zmienku o krokoch. To spôsobuje problémy podnikateľom, recenzentom a novým testerom. | Mali by sa použiť správne kroky a postupnosť. |
Ak to zhrnieme, ak sa vo fáze návrhu vezmú do úvahy malé detaily, bude kvalita výstupného testu oveľa lepšia.
# 3) Obchodné porozumenie
Toto je jeden z najdôležitejších faktorov, ktoré zákazníci pri testeroch hľadajú. Je však smutné, že niektorí testéri sa domnievajú, že ich úlohou je písať testovacie prípady založené na FRS, a nevynaložia nijaké úsilie na pochopenie predmetu podnikania.
Skúste najskôr poznať podnikanie a potom sa pozrite na funkčnosť; môžeš predstavte si potreby svojho klienta viac a podľa toho testovať.
Tu je príklad- FRS uvádza „Správa XYZ by sa mala generovať s 3 stĺpcami ako Dátum, Meno a Stav“. Nasledujú testovacie prípady, ktoré skončia, keď vezmete túto požiadavku v nominálnej hodnote:
- Vygeneruje sa overovací prehľad XYZ
- Overiť prehľad má 3 stĺpce ako Dátum, Meno, Stav
- Overte údaje v 3 stĺpcoch.
Ak však budete mať na pamäti obchodnú použiteľnosť tohto prehľadu, bude možno potrebné otestovať:
- Aký je podnikateľský účel tejto správy?
- Generuje sa tento prehľad každý deň?
- Kto sú obchodní používatelia, ktorí sa dívajú na tento prehľad?
- Aký je zdroj údajov pre tento prehľad?
- Mal by sa prehľad generovať, ak nie sú k dispozícii žiadne údaje?
Toto je iba jeden príklad, ale myslím si, že všetci súhlasíme s tým, že lepšie testovanie je možné dosiahnuť získaním obchodného povedomia a odborných znalostí.
# 4) Dostupnosť
Či už ste jednotlivec podporujúci zákazníka alebo tím, mala by sa vždy skontrolovať vaša dostupnosť ( ).
Dostupnosťou to neznamená podporu nepretržite. Znamená to iba jasnú a predbežnú komunikáciu o voľnom čase, alternatívnych plánoch, dosiahnuteľnosti a neabsolvovaní MIA.
Ďalej uvádzame niektoré z modelov, ktorými sa riadi odvetvie služieb:
- Model rozšírenia personálu - Ak pracujete v modeli rozšírenia personálu a ste výhradným zástupcom svojej spoločnosti, je vhodné, aby bol zákazník informovaný o vašich časových harmonogramoch práce a plánovaných absenciách, aby bolo možné urobiť potrebné opatrenia.
- Model riadených projektov - V modeli riadeného projektu, v ktorom sa formujú veľké projektové tímy a vedú ich dodávatelia / projektoví manažéri, už plán zálohovania zdrojov nezodpovedá zákazníkom. PM potrebuje správu plánované aj neplánované voľno. V tomto modeli je vhodné, aby sa PM pokúsili vopred zhromaždiť údaje o plánovanej neprítomnosti od svojho tímu a zodpovedajúcim spôsobom s nimi nakladať. Existujú prípady, keď zákazníci požadujú víkendovú podporu alebo predĺženie pracovnej doby. Takéto prípady by sa mali plánovať aj na základe striedania zdrojov. Tím by mal pozostávať z členov, ktorí si môžu v prípade potreby navzájom pomáhať. Plánované podrobnosti by mali byť zdieľané so zákazníkom.
# 5) Rozsah zlepšenia
To je žiaduce nielen v softvérovom priemysle, ale všade. Prinášať zlepšenie nie je jednodňová práca. Na rozsahu vylepšenia je potrebné neustále pracovať a je možné ho rozdeliť na 3 kroky -
c ++ výberový algoritmus triedenia
Prečítajte si tiež=> Ako vylepšiť svoje testovacie schopnosti a poraziť konkurenciu
Krok 1: Identifikujte
Urobte dôkladnú štúdiu a identifikujte oblasti / možnosti zlepšenia. Povedzme, že keď budete požiadaní o niekoľkokrát otestovanie rovnakej funkčnosti pomocou toho istého procesu, príde čas, keď budete mať pocit, že sa chcete z projektu buď vysťahovať, alebo zmeníte spôsob jeho testovania. Takto sa prinášajú zlepšenia, keď sa nudíme našimi existujúcimi metódami, myslíme na zmeny a vylepšenia .
Krok 2: Prineste vylepšenia
Keby sa veci robili ručne, dalo by sa skus zautomatizovat par veci . Keď poviem automatizáciu, nemusí to vždy znamenať nákup automatizovaného nástroja.
Citujem situáciu:
Bol som súčasťou tímu na testovanie databázy. Naša každodenná práca zahŕňala spustenie rovnakých skriptov SQL niekoľkokrát za deň s rôznymi súbormi parametrov. Keď sme začali projekt, boli sme s týmito krokmi v poriadku, ale nakoniec sme systému porozumeli lepšie a mysleli sme si, že rovnaké SQL skripty je možné spúšťať ako súčasť uložených procedúr namiesto toho, aby niekto manuálne aktualizoval parametre a vykonával ich.
Krok č. 3: Vyhodnoťte zlepšenie
Kedykoľvek sa implementuje nový proces, budete sa musieť ubezpečiť, že funguje podľa očakávaní a nemá žiadne vedľajšie účinky. Rozšírením predchádzajúceho príkladu, zavedenia uložených procedúr, skontrolujte, či sú výstup z novovytvoreného automatizovaného spôsobu a výstup z manuálneho spôsobu rovnaké.
Druhou časťou je sledovanie výhod za určité časové obdobie, aby ste si boli úplne istí, a prezentujte výsledky svojim klientom. V našom projekte sme ukázali klientom zníženie času vykonania testu o 30%, čo následne znížilo náklady.
Záver
Na záver by som chcel spomenúť len to, že každý z nás má vrodené vlohy a každý má svoje vlastné jedinečné pracovné štýly. To bolo iba niekoľko rád, ktoré podľa môjho názoru môžu našim zákazníkom ponúknuť lepší zážitok zo služieb.
O autorovi: Tento úžasný článok napísal člen tímu STH Priya R. Ak nám chcete napísať a podeliť sa o svoje skúsenosti, prosím dajte nám vedieť tu .
Dúfam, že ste si tento článok užili radi a považovali ste ho za poučný! Dajte nám vedieť, ak máte inú skúsenosť na zdieľanie.
Odporúčané čítanie
- Najlepšie nástroje na testovanie softvéru 2021 [QA Test Automation Tools]
- Globálne podnikanie v oblasti testovania softvéru čoskoro dosiahne 28,8 miliárd dolárov
- Poradenstvo pri testovaní softvéru pre začínajúcich testerov
- Úloha pomocníka QA pri testovaní softvéru
- Ako udržať motiváciu v softvérových testeroch nažive?
- Zen a umenie testovania softvéru
- Kurz testovania softvéru: Do ktorého inštitútu pre testovanie softvéru by som sa mal pripojiť?
- Ako svoju kariéru si zvolíte testovanie softvéru