Úvod do práce softvéru Tester
Čo je prvá vec, ktorá vám príde na myseľ, keď uvažujete o úlohe testovania softvéru? Práca nekódujúca? Alebo povolanie, ktoré je veľmi ľahké, pretože vám dáva príležitosť nájsť chyby v práci iných (hľadanie chýb, keď je v iných najjednoduchšia úloha pre nás všetkých)? Alebo to považujete za povolanie, ktoré sa zaoberá kontrolou správnosti výrobku? Všetky tieto myšlienky sú správne a sú každodennou činnosťou pre prácu testera softvéru. Testovanie softvéru sa však neobmedzuje iba na tieto činnosti.
Porozumenie žiadosti
Aplikácia môže byť z ľubovoľnej oblasti - zdravotníctvo, poisťovníctvo, financie atď. Naučenie sa aplikačnej oblasti je veľmi dôležité pre akúkoľvek softvérovú prácu, ktorá pri testovaní aplikácie otvára dvere mysleniu z rôznych uhlov a rôznych perspektív užívateľa. Hlavným očakávaním je vždy odhaliť a potvrdiť zrejmé a nie také zrejmé cesty aplikácie. Dôkladné znalosti aplikácie pomáhajú pri účinnej validácii výrobku v rovnakom čase, keď sa tester môže stať prínosom pre projekt, v ktorom sa považuje za jeden z primárnych zdrojov vedomostí týkajúcich sa správania produktu.
Zatiaľ čo učenie sa domény a funkčnosti je proces prebiehajúci, ďalším dôležitým faktorom je znalosť testovacieho procesu.
Proces testovania
Proces testovania sa môže v jednotlivých spoločnostiach líšiť alebo dokonca od jedného projektu k druhému. Dnes máme rôzne modely vývoja softvéru, ako je napríklad model V, model prototypovania alebo úplne iná metodika, ako je agilný prístup k vývoju softvéru. So zmenou vývojového modelu sa líši aj prístup, ktorý treba dodržiavať pri testovaní. Práca v modeli V bude mať dobre definované procesy, zatiaľ čo sa očakáva, že táto práca v agilnej metodike sa bude testovať v neustále sa meniacich podmienkach.
Úloha ešte nie je plynulá, pretože má prijateľné znalosti domény a porozumenie procesu testovania. Ďalšou výzvou, ktorá prichádza so životom, je naučiť sa rôzne nástroje.
náradie
Nástroje zahŕňajú nástroje na správu testov, nástroje na zaznamenávanie chýb, nástroje na správu databáz atď.
S rôznymi programami na zaznamenávanie chýb, ich kvalitami a nástrojmi, niektorými otvorenými zdrojmi a niektorými licencovanými, je vždy výhodou poznať viac ako jeden nástroj. Pomáha to ľahko previesť projekty alebo tímy pomocou rôznych nástrojov. S primeranými znalosťami o doméne, procese a nástrojoch je viac k životu práca softvéru Tester, čo robí jeho pracovné dni náročnými a vzrušujúcimi. Spolupráca v tímoch je jedným z dôležitých faktorov úspechu každého projektu a pre efektívnu spoluprácu hrá komunikácia veľmi dôležitú úlohu.
Odporúčané kurzy
- Kompletný komplexný kurz J2EE
- Online školenie o programovaní R
- Choďte na kurz programovania
- Online certifikačné školenie v programe Haskell
komunikácia
Komunikácia hrá veľmi dôležitú úlohu pre softvér, ktorý má kvalitné, od počiatočných fáz vývoja softvéru, členovia testovacieho tímu sú (ako najlepší postup) zapojení do diskusie o požiadavkách, kladú otázky obchodným analytikom v prípade akýchkoľvek otázok alebo medzier v požiadavke. Tester s účinnými komunikačnými schopnosťami môže efektívne komunikovať riziká, môže efektívne komunikovať s vývojovým tímom a môže efektívne komunikovať výsledky testov a správy o testoch.
Plánovanie softvérových testerov
Ako už názov napovedá, plánovanie testov je fáza, v ktorej sa pripravuje testovanie. Príprava na testera bude zahŕňať rôzne typy aktivít, ktoré tester vykonáva na účely efektívnej aplikácie. Pomôže to pri validácii žiadosti a účinnom odhaľovaní chýb v aplikácii. Aby bolo možné začať s plánovaním, teste prechádza požiadavkami, aby pochopila očakávania.
1. Požiadavky
Skúšobnému tímu by sa mohli dať požiadavky vo forme drôtových rámov, storyboardov, excelovských listov. Účelom všetkých týchto dokumentov je prezentovať požiadavky klienta efektívnym a ľahko zrozumiteľným spôsobom. Drátový model nie je nič iné ako dokument, ktorý môže byť vo forme prezentácie programu PowerPoint, ktorý zobrazuje požiadavky klienta. Na rovnakých riadkoch storyboardy zvyčajne zobrazujú požadovaný vzhľad / vzhľad obrazoviek. V súčasnosti sú na trhu k dispozícii rôzne nástroje, ktoré je možné použiť na prípravu požadovaných dokumentov. Tvorba požadovaných dokumentov je primárnou zodpovednosťou obchodného analytika. Očakáva sa, že chuť dôkladne porozumie požiadavkám. Aby teste aj vývojári správne porozumeli požiadavkám, obchodní analytici udržujú fórum otvorené pre všetkých, aby mohli vzniesť otázky a odpovedať na všetky požiadavky. Platforma na diskusiu a komunikáciu otvorených otázok a otázok sa v jednotlivých projektoch líši. Môže to byť reťazec e-mailov alebo konferenčných hovorov alebo dokonca zdieľaný archív jednotiek, ktorý sleduje všetky otvorené otázky a ich odpovede poskytnuté obchodným analytikom.
Jasná komunikácia a záznam komunikácie zohrávajú pri dokazovaní veľmi dôležitú úlohu. Malý predpoklad v požiadavke by niekedy mohol viesť k veľkej chybe produktu. V každej fáze sa odporúča, aby kvalita testovacieho softvéru udržovala komunikáciu čistú. Softvérový tester Pracovná komunikácia môže prebiehať s obchodnými analytikmi alebo dokonca v rámci tímu. Jasná komunikácia pomáha zabrániť predpokladom počas plánovania a vykonávania. Zároveň sa odporúča mať záznam o komunikácii (najlepšie e-mailovú komunikáciu). Písomná komunikácia o požiadavkách v požiadavkách pomáha v neskorších fázach vykonávania testu, keď sa funkčnosť pravdepodobne nevyvinula, ako sa potvrdilo v zaznamenanej komunikácii.
2. Scenár
Po pochopení požiadaviek tester začne dokumentovať scenáre v dokumente Testovací scenár. Scenár, ako názov napovedá, je tokom funkcií, ktoré užívateľ sleduje, aby mohol vykonať úlohu.
Príklady scenárov -
- Užívateľ by mal byť schopný úspešne sa prihlásiť.
- Užívateľ by mal mať možnosť rezervovať si lístky v systéme.
- Užívateľ by mal mať možnosť zrušiť lístky v systéme.
- Užívateľ by mal mať možnosť zobraziť / aktualizovať podrobnosti profilu.
Toto sú logické úlohy, ktoré používateľ vykonáva v systéme. Tieto logické úlohy, keď sú zoskupené, dokazujú, že si môžu všimnúť všetky možné scenáre, ktoré má používateľ vykonať. Tieto scenáre sú zvyčajne zdokumentované v hárkoch programu Excel alebo niekedy používajú niektoré nástroje. Poskytovateľ sa usiluje získať všetky takéto scenáre z dokumentov požiadaviek. Dokument obsahujúci takéto scenáre sa nazýva Dokument skúšobného scenára (alebo niekde ako Dokument scenára na vysokej úrovni). Tento dokument slúži ako vstupný dokument pre vypracovanie testovacích prípadov.
3. Prípad
Tento prípad predstavuje podrobnejšiu verziu pracovného scenára softvéru Tester, kde je scenár rozdelený na podrobnejšie kroky, ktoré používateľ skutočne vykoná počas používania aplikácie. Jednoduchý príklad založený na vyššie uvedených scenároch je:
Scenár - Používateľ by sa mal úspešne prihlásiť.
Skúšobné prípady:
- Overte, či je používateľ schopný zadať správne používateľské meno.
- Overte, či je používateľ schopný zadať heslo.
- Po zadaní správneho používateľského mena a hesla overte, že sa používateľ môže úspešne prihlásiť.
Takýto zoznam týchto prípadov môže ďalej zahŕňať kontrolu platnosti každého poľa, kontrolu negatívnych scenárov atď.
Ďalej uvádzame niektoré z ďalších príkladov týchto prípadov -
- Ak zadané používateľské meno nie je zadané, systém vyvolá príslušnú chybu.
- Ak heslo nezadáte, overte, či systém vyvolá príslušnú chybu.
- Ak zadané používateľské meno a heslo nie je zadané, systém vyvolá príslušnú chybu.
- Skontrolujte, či zadaním nesprávneho hesla systém zobrazí príslušné chybové hlásenie.
- Skontrolujte, či zadaním nesprávneho používateľského mena systém zobrazí príslušné chybové hlásenie.
4. Matica sledovateľnosti požiadaviek (RTM)
Matica sledovateľnosti požiadaviek, ako už názov napovedá, pomáha dokázať overiť a začleniť pokrytie požiadaviek, ktoré poskytuje podnik, do testovacích dokumentov, ako sú scenáre a testovacie prípady.
Ako najlepšia prax sa jedná o samostatný dokument, ktorý ukazuje mapovanie čísla požiadavky s prípadom scenárov / prípadov zahŕňajúcich túto požiadavku.
Tento dokument nemusia byť použité pre všetky druhy projektov, ale keď sa použije, pomáha to silne sledovať trasovanie scenárov na vysokej úrovni podľa požiadaviek. Označuje pokrytie a môže sa použiť na overenie prítomnosti aspoň jedného z týchto prípadov proti každej požiadavke. Vytváranie a udržiavanie dokumentu RTM sa považuje za najlepší postup, avšak nie všetky druhy projektov (napríklad agilné) používajú dokument Pracovný dokument overený softvérom. Ak sa požiadavky menia veľmi často, mohlo by sa zachovať zachovanie tohto dokumentu. Aby sa predišlo tejto režijnej záťaži a zároveň existovali spôsoby, ako sledovať požiadavky, niektoré projekty začleňujú časť sledovateľnosti do pracovného prípadu softvéru Tester alebo samotného svojho scenára.
Dôležitým aspektom je mať spôsob, ako vysledovať scenáre / prípady podľa požiadaviek a naopak. Dobre zdokumentované požiadavky uľahčujú poskytovateľovi vytváranie a udržiavanie týchto dokumentov. Nejednoznačné požiadavky, neustále sa meniace požiadavky, zvyšujú životnosť overovateľa a môžu viesť k nejednotným dokumentom, ktoré sa dajú dodať, čo má za následok stratu určitej validácie, a teda aj chyby konečného produktu.
Cesta pre testera doteraz bola plánovaním a prípravou na testovanie. Keďže príprava na vojnu je súčasťou vojny, platí to aj tu. Čím stručnejšie sú tieto dokumenty vytvorené, pre kontrolór je ľahšie overiť ich funkčnosť a odhaliť takmer všetky chyby. Ďalšou fázou cesty testera je Poprava.
Vykonávanie testerov softvéru funguje
Toto je fáza, v ktorej sa používajú všetky uvedené dokumenty. Požiadavky sa použili na vytvorenie scenára, scenár sa použil na vytvorenie scenára. tento Prípadový dokument je tu sebestačným dokumentom na začatie overovania žiadosti. Poskytovateľ začne overovať aplikáciu vykonaním krokov z tohto prípadového dokumentu. Viaceré tieto prípady by sa mohli použiť na validáciu jedného scenára, alebo dokonca jediný testovací prípad môže korešpondovať s jediným testovacím scenárom. Všetko záleží na zložitosti scenárov alebo niekedy na štandarde, ktorý sa dodržiava v testovacom tíme. Jeden dokument z testovacieho prípadu preto môže obsahovať 20-50 testovacích prípadov alebo môže mať 100-120 testovacích prípadov. Tieto čísla slúžia iba na vysvetlenie a môžu sa v jednotlivých projektoch líšiť. Výsledkom tejto fázy sú testovacie chyby. Počet platných nedostatkov zistených v tejto fáze poskytuje dobrý prehľad o stabilite aplikácie, kvalite testovania, kvalite zostavenia a mnohých takých faktoroch, ktoré majú priamy vplyv na výrobok. Táto fáza je najdôležitejšou fázou, keď sa testerovi darí pokryť všetky testovacie prípady (overenie takmer všetkých požadovaných užívateľských trás) a súčasne zvýšiť čo najviac platných chýb. V tejto fáze testovania prichádza všetka príprava, komunikačné zručnosti, otázky požadované pre podnikanie.
Poruchy softvéru testera funguje
Pri vykonávaní tohto prípadu sa za chybu považuje každé správanie, ktoré sa nerovná očakávanému výsledku. Každý testovací prípad má popis, očakávaný výsledok a stĺpec pre skutočný výsledok. Zatiaľ čo tento plánovací dokument Software Tester Work má popis a očakávané výsledky a prázdny stĺpec pre skutočné výsledky. Počas vykonávania testovacích prípadov má tester vyplniť stĺpec skutočných výsledkov. Súčasne, ak skutočná hodnota nie je rovná očakávanému výsledku, sa zaznamená chyba. Logovanie chyby jednoducho neznamená informovanie vývojára o probléme. Je to opäť formálny proces, ktorý sa zvyčajne vykonáva pomocou nástroja. V súčasnosti existujú rôzne nástroje na trhu, niektoré otvorené zdroje a iné licencované. Každý nástroj na zaznamenávanie chýb má nasledujúce polia -
- Názov projektu / vydania
- Zhrnutie chýb
- Popis chyby
- Závažnosť chyby
- Priorita chyby
- Fáza bola zistená
- Priradený
- prílohy
Ako vidíme, účel všetkých týchto oblastí je mať formálny proces múdre podrobnosti o nájdenej otázke. Pomáha to vývojárom reprodukovať chybu v ich prostredí a opraviť ju. Nižšie je uvedený krátky popis všetkých týchto polí -
- Názov projektu / vydania - Názov vydania, v ktorom bola chyba nájdená, zvyčajne má projekt viac vydaní a ten istý projekt môže mať viacero čiastkových projektov. Toto pole pomáha upozorniť na problém s konkrétnym vydaním.
- Súhrn defektov - Krátky opis zistenej chyby, ktorý sa nachádza na jednej linke.
- Podrobný popis defektu - Jedná sa o podrobný popis defektu, mal by obsahovať podrobnosti, ako je prostredie, v ktorom sa defekt našiel, a použité testovacie údaje, skutočné výsledky, ktoré očakávajú výsledok, a akékoľvek ďalšie informácie, ktoré zainteresovaným stranám pridávajú hodnotnejšie informácie, aby porozumeli prebehnúť.
- Závažnosť chyby - Označuje závažnosť chyby. Zvyčajne má hodnoty podobné kritickým, vysokým, stredným, nízkym alebo číselným hodnotám ako 4, 3, 2, 1.
- Defect Priority (Priorita defektu) - Znamená to, aké naliehavé je odstránenie chyby.
- Fáza, ktorá sa vyskytla, bola zistená - keďže existuje mnoho fáz, keď je možné chybu zaznamenať, fázu testovania jednotky, SIT (testovanie systémovej integrácie), UAT (testovanie akceptácie používateľa) alebo dokonca výrobnú fázu.
- Priradené - Meno vývojára alebo vedúceho vývoja.
- Prílohy - testerovi bola poskytnutá možnosť pripojiť snímku obrazovky, na ktorej sa vyskytol problém.
Vykonanie testu a zaznamenávanie chýb sú fázou, v ktorej môže tester čeliť mnohým výzvam. Niektoré z nich komunikujú efektívne s vývojármi. Môžeme tvrdiť, že zaznamenáva chyba so všetkými potrebnými informáciami, ktoré vývojári nepostačujú na to, aby pochopili chybu?
Je to av niektorých prípadoch si vyžaduje ďalšie vysvetlenie / diskusiu s vývojármi. Existujú prípady, keď sa tester stretne s neočakávaným správaním, ktoré si nemusí byť istý, či ide o chybu. Týmto okolnostiam zvyčajne čelí pracovník, ktorý je v tíme nový, ktorý má obmedzené znalosti domény alebo nejednoznačnosť požiadaviek. Teda testerovi by sa nemalo obviňovať, ak existujú prísne termíny a existujú neustále sa meniace požiadavky a vo väčšine prípadov sa overujúci dozvie o doméne pri skutočnom plánovaní a vykonávaní testovacích prípadov. Ako vidíme, cesta testera nie je taká jednoduchá, ako sa vníma. Vyžaduje si to neustále učenie, dobré komunikačné schopnosti, dobré zručnosti v oblasti spolupráce a horlivosť, aby sa prispôsobili podmienkam, v ktorých dochádza k zmenám v doménach, nástrojoch, použitých procesoch. Aj keď sme hovorili o ceste manuálnych testerov, celkový proces sa vzťahuje aj na automatických testerov. Na druhej strane automatizácia má v procese významné zmeny, pretože rozsah testovania a plánovania, vykonávanie sa výrazne líšia.
Ak vezmeme do úvahy cestu overiteľa, ako je uvedené vyššie, môžeme stále tvrdiť, že úloha testerov softvéru je jednoduchšia ako práca vývojárov?
Dá sa povedať, že viac ako porovnanie vývojových úloh testera v / s bude užitočnejšie viesť diskusiu o tom, ako môže spolupráca dvoch viesť k veľkému úspechu produktu ako celku. Niekedy zabúdame, že úlohou testera je nájsť problémy v aplikácii a nie upozorňovať na chyby vývojárov. Keď zabudneme na samotnú myšlienku našej práce, niekedy to vedie k zbytočnej diskusii. Zistilo sa však, že existujú rovnako dobré tímy na vývoj a testovanie, kde každý chápe, že konečným cieľom je zabezpečiť, aby aplikácia pracovala tak, ako sa očakávalo. Dúfajme, že sa všetci pozrú na pozitívnu stránku testovacej práce ako na úlohu, ktorá pomáha pri čistení produktu, a nie ako na tú, ktorá len zistí chyby!
Odporúčané články
Toto bol návod na odhalenie a potvrdenie zrejmých a nie tak zrejmých ciest aplikácie je vždy primárnym očakávaním od práce testera softvéru. Toto je nasledujúci externý odkaz súvisiaci s prácou testera softvéru.
- Životný cyklus defektov pri testovaní softvéru
- 6 najzaujímavejších otázok týkajúcich sa testovania softvéru
- Kariéra v testovaní softvéru