Úvod do softwarového testeru
Jaká je první věc, která vás napadne, když přemýšlíte o práci na testování softwaru? Práce nekódující? Nebo povolání, které je velmi snadné, protože vám dává příležitost najít chyby v práci jiných (hledání chyb, když v jiných je pro nás nejsnadnější úkol)? Nebo si o tom myslíte jako o povolání, které se zabývá kontrolou správnosti produktu? Všechny tyto myšlenky jsou správné a jsou každodenní činností softwarového testeru. Testování softwaru se však neomezuje pouze na tyto činnosti.
Pochopení aplikace
Aplikace může být z libovolné oblasti - zdravotnictví, pojišťovnictví, finance atd. Učení aplikační domény je velmi důležité, aby jakákoli softwarová práce otevírala dveře k myšlení různým úhlům a různým perspektivám uživatelů při testování aplikace. Hlavním očekáváním je vždy odhalit a ověřit zjevné a ne tak zjevné cesty aplikace. Mít důkladnou znalost aplikace pomáhá efektivní validaci produktu ve stejnou dobu, kdy se tester může stát aktivem projektu, kde je považován za jeden z primárních zdrojů znalostí s ohledem na chování produktu.
Zatímco učení domény a funkčnosti je nepřetržitý proces pro jakýkoli další důležitý faktor má znalosti o procesu testování.
Proces testování
Proces testování se může u jednotlivých společností lišit nebo dokonce od jednoho projektu k druhému. Dnes máme různé modely vývoje softwaru, jako je V model, Prototyping model nebo úplně jiná metodologie, jako je Agilní přístup k vývoji softwaru. Se změnou ve vývojovém modelu se liší i testovací přístup, který je třeba dodržovat. Práce v modelu V bude mít dobře definované procesy, zatímco se očekává, že tato práce v agilní metodologii bude testovat v neustále se měnících podmínkách.
Úkol zatím není plynulý s přijatelnými znalostmi domény a porozuměním procesu testování. Další výzvou, která přichází se životem, je naučit se různé nástroje.
Nástroje
Nástroje zahrnují nástroje pro správu testů, nástroje pro protokolování defektů, nástroje pro správu databází atd.
S různým softwarem pro zaznamenávání vad, jejími vlastnostmi a nástroji, některými otevřenými zdrojovými kódy a některými licencovanými, je vždy výhodou mít znalosti o více než jednom nástroji. Pomáhá jí snadno převádět projekty nebo týmy pomocí různých nástrojů. S odpovídajícími znalostmi domény, procesu a nástrojů existuje více života softwaru Software Tester, což činí jeho pracovní dny náročnými a vzrušujícími. Spolupráce v týmech je jedním z důležitých faktorů úspěchu jakéhokoli projektu a pro efektivní spolupráci hraje komunikace velmi důležitou roli.
Doporučené kurzy
- Absolvujte komplexní kurz J2EE
- Online školení o programování R
- Jděte na kurz programování
- Online certifikační školení v programu Haskell
Sdělení
Komunikace hraje velmi důležitou roli pro software, který má kvality, od počátečních fází vývoje softwaru, členové testovacího týmu jsou (jako nejlepší praxe) zapojeni do diskuse o požadavcích, dotazování obchodních analytiků v případě jakýchkoli dotazů nebo mezer v požadavku. Tester s účinnými komunikačními schopnostmi dokáže efektivně komunikovat rizika, může efektivně komunikovat s vývojovým týmem a může efektivně komunikovat výsledky testů a zprávy o testování.
Plánování softwarových testerů
Jak již název napovídá, plánování testování je fáze, ve které se připravuje na testování. Příprava na tster bude zahrnovat různé typy činností, které tster provádí za účelem efektivní aplikace. Pomůže to při validaci aplikace a účinném odhalování vad aplikace. Aby bylo možné začít s plánováním, teste prochází požadavky, aby pochopilo očekávání.
1. Požadavky
Testovacímu týmu by mohly být kladeny požadavky ve formě drátěných rámů, scénářů, excelovských listů. Účelem všech těchto dokumentů je představit požadavky klienta efektivním a snadno pochopitelným způsobem. Drátový dokument není ničím jiným než dokumentem, který může být ve formě prezentace PowerPoint, která zobrazuje požadavky klienta. Na stejných řádcích storyboardy obvykle zobrazují požadovaný vzhled / design obrazovek. V současné době jsou na trhu k dispozici různé nástroje, které lze použít k přípravě požadovaných dokumentů. Vytvoření požadovaných dokumentů je hlavní odpovědností obchodního analytika. Očekává se, že požadavky důkladně pochopí. Aby teste i vývojáři porozuměli požadavkům správně, obchodní analytici udržují fórum otevřené pro všechny, aby mohli zvyšovat a dostávat odpovědi na všechny požadavky. Platforma pro diskusi a komunikaci otevřených otázek a dotazů se v jednotlivých projektech liší. Může to být řetěz e-mailů nebo konferenčních hovorů nebo dokonce sdílené úložiště pohonů udržované, aby bylo možné sledovat všechny otevřené otázky a jejich odpovědi poskytnuté obchodním analytikem.
Jasná komunikace a záznam komunikace hraje velmi důležitou roli při dokazování. Malý předpoklad v požadavku může někdy vést k hlavní vadě produktu. V každé fázi je doporučeno, aby kvalita testovacího softwaru udržovala komunikaci čistou. Software Tester Work komunikace může probíhat s obchodními analytiky nebo dokonce v rámci týmu. Jasná komunikace pomáhá udržet předpoklady daleko během plánování a provádění. Současně se doporučuje mít záznam o komunikaci (nejlépe e-mailovou komunikaci). Písemná komunikace o požadavcích v požadavcích pomáhá v pozdějších fázích provádění testu, kde by funkčnost nemohla být vyvinuta, jak bylo potvrzeno v zaznamenané komunikaci.
2. Scénář
Jakmile jsou požadavky pochopeny, tester začne dokumentovat scénáře v dokumentu Testovací scénář. Scénář, jak název napovídá, je tok funkcí, který uživatel sleduje, aby mohl provést úkol.
Příklady scénářů -
- Uživatel by měl být schopen se úspěšně přihlásit.
- Uživatel by měl mít možnost rezervovat si vstupenky v systému.
- Uživatel by měl mít možnost zrušit vstupenky v systému.
- Uživatel by měl mít možnost zobrazit / aktualizovat podrobnosti profilu.
Toto jsou logické úkoly, které uživatel provádí v systému. Tyto logické úkoly, když jsou seskupeny, pomáhají ověřovateli zaznamenat všechny možné scénáře, které má uživatel provést. Tyto scénáře jsou obvykle dokumentovány v listech Excelu nebo někdy pomocí některých nástrojů. Proverant se daří extrahovat všechny takové scénáře z dokumentů požadavků. Dokument obsahující takové scénáře se nazývá Testovací scénářový dokument (nebo někde jako dokument scénáře na vysoké úrovni). Tento dokument slouží jako vstupní dokument pro vypracování testovacích případů.
3. Případ
Tento případ je podrobnější verzí pracovního scénáře Software Tester, kde je scénář rozdělen do podrobnějších kroků, které uživatel skutečně provede při používání aplikace. Jednoduchý příklad založený na výše uvedených scénářích je:
Scénář - Uživatel by měl být schopen se úspěšně přihlásit.
Zkušební případy:
- Ověřte, zda je uživatel schopen zadat správné uživatelské jméno.
- Ověřte, zda je uživatel schopen zadat heslo.
- Po zadání správného uživatelského jména a hesla ověřte, že se uživatel může úspěšně přihlásit.
Takový seznam těchto případů může zahrnovat ověření platnosti každého pole, kontrolu negativních scénářů atd.
Níže uvádíme některé další příklady těchto případů -
- Ověřte, že uživatelské jméno, pokud není zadáno, systém vyvolá příslušnou chybu.
- Ověřte toto heslo, pokud není zadáno, systém vyvolá příslušnou chybu.
- Ověřte, že uživatelské jméno a heslo, pokud není zadáno, systém vyvolá příslušnou chybu.
- Zkontrolujte, zda zadáním nesprávného hesla systém vyvolá příslušnou chybovou zprávu.
- Zkontrolujte, zda zadáním nesprávného uživatelského jména systém vyvolá příslušnou chybovou zprávu.
4. Matice sledovatelnosti požadavků (RTM)
Matice sledovatelnosti požadavků, jak název napovídá, pomáhá prokázat kontrolu a začlenění pokrytí požadavků stanovených společností do testovacích dokumentů, jako jsou scénáře a testovací případy.
Jako nejlepší postup se jedná o samostatný dokument, který ukazuje mapování čísla požadavku na případy scénářů / případů, které tento požadavek zahrnují.
Tento dokument nemusí být používán všemi druhy projektů, ale při jeho použití pomáhá silně sledovat trasování scénářů na vysoké úrovni podle požadavků. Označuje pokrytí a může být použit ke kontrole přítomnosti alespoň jednoho z těchto případů proti každému požadavku. Vytváření a údržba dokumentu RTM je považováno za osvědčený postup, ale ne všechny druhy projektů (jako Agilní) využívají pracovní dokument Software proof. Pokud se požadavky mění velmi často, může být údržba tohoto dokumentu zaslechnuta. Abychom se vyhnuli této režii a současně měli způsob, jak sledovat požadavky, některé projekty začleňují část sledovatelnosti do pracovního případu Softwarového testeru nebo do jeho scénářového dokumentu samotného.
Důležitým aspektem je mít způsob, jak sledovat scénáře / případy podle požadavků a naopak. Dobře zdokumentované požadavky usnadňují poskytovateli úkol vytvořit a udržovat tyto dokumenty. Nejednoznačné požadavky, neustále se měnící požadavky zvyšují život proverátora náročnější a mohou vést k nekonzistentním doručitelným dokumentům, které mají za následek opomenutí některé validace a tím i vadu konečného produktu.
Cesta pro testera zatím byla plánování a přípravy na testování. Protože příprava na válku je součástí války, platí to i zde. Čím stručněji jsou tyto dokumenty vytvořeny, je snazší pro ověřovatele ověřit funkčnost a odhalit téměř všechny vady. Další fází cesty testera je Poprava.
Provádění testeru softwaru funguje
Toto je fáze, ve které se používají všechny výše uvedené dokumenty. Požadavky byly použity k vytvoření scénáře, scénář byl použit k vytvoření scénáře. tento Případový dokument je zde dokument Samostatný k zahájení validace aplikace. Poskytovatel zahájí ověření aplikace provedením kroků z tohoto případového dokumentu. K ověření jednoho scénáře by mohlo být použito více těchto případů nebo dokonce jediný testovací případ může odpovídat jedinému testovacímu scénáři. Vše záleží na složitosti scénářů nebo někdy na standardu dodržovaném v testovacím týmu. Jeden dokument o testovacím případu proto může obsahovat 20–50 testovacích případů nebo může mít 100-120 testovacích případů. Tato čísla slouží pouze pro vysvětlení, mohou se v jednotlivých projektech lišit. Výsledkem této fáze jsou testovací vady. Počet platných defektů vyvolaných v této fázi dává dobrou představu o stabilitě aplikace, kvalitě testování, kvalitě sestavení a mnoha takových faktorech, které mají přímý dopad na produkt. Tato fáze je nejdůležitější fází, protože se testerovi daří pokrýt všechny testovací případy (ověření téměř všech požadovaných cest uživatele) a současně zvýšit co nejvíce platných defektů. V této fázi testování přichází veškerá příprava, komunikační dovednosti, dotazy týkající se podnikání.
Vady softwaru testeru funguje
Při provádění těchto případů je jakékoli chování, které se nerovná očekávanému výsledku, vyvoláno jako chyba. Každý testovací případ má popis, očekávaný výsledek a sloupec pro skutečný výsledek. Zatímco tento plánovací dokument Software Tester Work má popis a očekávané výsledky a prázdný sloupec pro skutečné výsledky. Při provádění testovacích případů by měl tester vyplnit sloupec skutečného výsledku. Současně, pokud se skutečná hodnota nerovná očekávanému výsledku, je vada zaznamenána. Protokolování vady prostě neznamená informovat vývojáře o problému. Je to opět formální proces, který se obvykle provádí pomocí nástroje. V současné době existují na trhu různé nástroje, některé open source a jiné licencované. Každý nástroj pro protokolování vad má následující pole -
- Název projektu / vydání
- Shrnutí vady
- Popis vady
- Vada závažnosti
- Priorita vady
- Fáze byla nalezena vada
- Přiřazen
- Přílohy
Jak vidíme, účel všech těchto polí je, aby formální proces moudré podrobnosti o problému našel. To vývojářům pomáhá reprodukovat vadu v jejich prostředí a opravit ji. Níže je uveden stručný popis všech těchto polí -
- Název projektu / vydání - Název vydání, kde byla nalezena vada, obvykle má projekt více vydání a stejný projekt může mít více dílčích projektů. Toto pole pomáhá upozornit na problém s konkrétním vydáním.
- Souhrn defektů - Krátký popis nalezené vady na jedné linii.
- Podrobný popis defektu - Jedná se o podrobný popis defektu, měl by zahrnovat podrobnosti, jako je prostředí, kde byla defekt nalezena, a použité testovací údaje, skutečné výsledky očekávané, že výsledek, a jakékoli další informace, které přidávají cennější informace pro zúčastněné strany, aby porozuměly přeběhnout.
- Závažnost vady - to znamená, jak závažná je vada. Obvykle má hodnoty podobné kritickým, vysokým, středním, nízkým nebo číselným hodnotám, jako je 4, 3, 2, 1.
- Defect Priority - Označuje, jak naléhavě je třeba vadu opravit.
- Fáze byla nalezena vada - Protože existuje mnoho fází, kdy lze závadu zaznamenat, fázi testování jednotky, SIT (testování systémové integrace), UAT (testování akceptace uživatelem) nebo dokonce fázi výroby.
- Přiřazeno k - jméno vývojáře nebo vedoucí vývoje.
- Přílohy - To poskytlo testerovi možnost připojit snímek obrazovky, kde došlo k problému.
Provedení testu a protokolování defektů je fáze, ve které může tester čelit mnoha výzvám. Některé z nich komunikují efektivně s vývojáři. Můžeme tvrdit, že protokolování vady se všemi nezbytnými informacemi nestačí, aby vývojáři pochopili vadu?
Je to av některých případech vyžaduje další vysvětlení / diskusi s vývojáři. Existují případy, kdy tester narazí na neočekávané chování, které si nemusí být jistý, zda se jedná o vadu. Těmto okolnostem obvykle čelí zkoušející, kteří jsou v týmu noví, mají omezené znalosti domény nebo mají nejasnosti ohledně požadavků. Testerovi by se nemělo obviňovat, jsou-li stanoveny pevné lhůty a existují neustále se měnící požadavky a ve většině případů se ověřující dozví o doméně při plánování a provádění testovacích případů. Jak vidíme, cesta testera není tak snadná, jak je vnímána. Vyžaduje si neustálý přístup k učení, dobré komunikační dovednosti, dobré schopnosti spolupracovat a dychtivost přizpůsobit se podmínkám, ve kterých dochází ke změnám v doménách, nástrojích, použitých procesech. Zatímco jsme hovořili o cestě ručních testerů, celkový proces platí také pro automatizační testery. Na druhou stranu automatizace má v procesu významné změny, protože rozsah testování a plánování, provádění se výrazně liší.
Pokud vezmeme v úvahu cestu provizorů, jak je uvedeno výše, můžeme stále říci, že úloha vlastností testerů softwaru je jednodušší než práce vývojářů?
Lze říci, že více než porovnání vývojových rolí testerů v / s bude užitečnější diskutovat o tom, jak může spolupráce dvou vést k velkému úspěchu produktu jako celku. Někdy zapomínáme, že úkolem testera je hledat problémy v aplikaci a ne poukazovat na chyby vývojářů. Když zapomeneme na samotnou myšlenku naší práce, někdy to vede k zbytečné diskusi. Bylo však pozorováno, že existují stejně dobré testovací vývojové týmy, kde každý chápe, že konečným účelem je zajistit, aby aplikace fungovala podle očekávání. Doufejme, že se všichni podívají na pozitivní stránku testovací práce jako na roli, která pomáhá při čištění produktu, a nikoli jako na osobu, která právě najde chyby!
Doporučené články
Toto byl průvodce, jak odhalit a ověřit zjevné a ne tak zjevné cesty aplikace, je vždy hlavním očekáváním od práce softwarového testera. Toto je následující externí odkaz související s prací softwarového testeru.
- Životní cyklus vad při testování softwaru
- 6 nejúžasnějších dotazů na testování softwaru
- Kariéra v testování softwaru