Menu

6 základních dovedností, které by měl mít každý tester (hlavně čerstvější)

6 basic skills that every tester should have

Vyzkoušejte Náš Nástroj Pro Odstranění Problémů

otázky a odpovědi na otázky týkající se testování databází pro zkušené

Testování softwaru nebo QA je nejlepší platformou pro začátečníky pro vstup do IT průmyslu navzdory mylným představám, že se jedná o méně či méně placenou práci.

Nejdůležitější dovedností, kterou tester potřebuje, je schopnost najít chyby . A pokud jste typ člověka, který miluje hledání brouků, budete v této oblasti milovat a růst.

Přesto existuje několik dalších dovedností, které vám pomohou najít chyby a lépe pracovat s procesy QA.

Toto je článek, který ukáže proces QA, jak je sledován ve většině společností, a poskytne novým testerům vysvětlení ohledně testování.

Podrobně se naučíte proces dokumentace a standardy, předběžné práce testeru, testování založené na omezeních, testování během částečného vývoje a nakonec proces odhlášení.

základní testovací dovednosti

Pojďme začít.

Co se naučíte:

# 1. Dokumentace

Dokumentace je pro testování nezbytná. Většina společností přiděluje tento úkol nově příchozím. Abyste uspěli, měli byste mít dobrá slovní zásoba protože zbytek věcí, jako jsou dokumentační standardy atd., nemáte pod kontrolou a závisí na procesech týmu a společnosti.

Také se ujistěte, že vidíte hodnotu procesu dokumentace. Těch výhod je mnoho - pomáhají vám sledovat změny požadavků, sledovat vaše testovací kroky, zaznamenávat práci atd.

Doporučené čtení=> Proč je dokumentace důležitá při testování softwaru

# 2. Příprava na zkoušku

Ze všech dostupných dokumentů nelze opomenout následující. Tito jsou také nazýváni jako doručitelné dokumenty a překlenují porozumění klientům, vývojářům a testerům.

a) Testovací plán: Mapuje průběh testování od začátku do konce .

Testovací plán zobrazuje rozsah a aktivity testovací fáze. Tým, který vytvořil vedoucí QA, musí přispívat a být informován o všem, co je napsáno v plánu testu.

Některé týmy mají několik úrovní testovacích plánů: hlavní plán a fázové plány.

Plán zkoušek musí mít:

  • Název a verze projektu
  • Identifikátory testovacího plánu - tvůrce, číslo konceptu, datum vytvoření atd.
  • Úvod - Přehled projektu, cíl a omezení
  • Odkazy - Seznam referencí použitých jako vstup. (Ujistěte se, že používáte přesnou a nejnovější verzi)
  • Testované položky - moduly, verze, rozsah, mimo rozsah atd.
  • Celkový přístup k testování / strategie testování - nástroje k použití, proces sledování defektů, úrovně testování, které je třeba provést atd.
  • Kritéria položky Pass / Fail - Pokyny k provedení testu
  • Kritéria pozastavení a obnovení
  • Výsledky testování - testovací případ, protokoly o testu, hlášení o chybě, metriky testu atd.
  • Podrobnosti o testovacím prostředí
  • Týmový soupis s kontaktními údaji. pro každý modul nebo typ testování
  • Odhady testu - čas a úsilí. Podrobnosti o rozpočtu jsou důvěrné a nenajdete je zde
  • Rizika a plány zmírnění
  • Schválení
  • Další pokyny

Přečtěte si také=>

b) Testovací scénáře:

Jeden řádek ukazuje na „co testovat“ na základě každého požadavku a je obvykle dokumentován a sledován pomocí tabulek.

Většina z nich obsahuje:

  • Název modulu / komponenty / funkce (přihlášení, administrátor, registrace atd.)
  • ID scénáře slouží jako reference (např. TS_Login_001)
  • Popis scénáře - „Co otestovat“ Např .: Ověřte, zda přihlášení umožňuje uživatelům s platnými pověřeními úspěšné přihlášení
  • Důležitost scénáře - Stanovit priority v případě nedostatečného času - Vysoká / Střední / Nízká
  • ID požadavku - pro sledovatelnost

Další čtení=>

c) Testovací případy:

Přesné testovací případy poskytují přesné výsledky testů. Tabulky jsou stále oblíbeným prostředkem pro psaní testovacích případů, zejména pro začátečníky, i když některé společnosti přizpůsobují nástroje pro správu testů. Základem pro psaní testovacích případů je dokument SRS / FRD / Req. Ale to často nestačí, takže budete muset použít hodně předpokladů a diskusí s týmy BA / Dev.

Psaní efektivních testovacích případů je nejdůležitější kvalifikace, kterou tester musí mít. Všechny testovací případy jsou obvykle kategorizovány jako pozitivní / negativní. Pozitivní testovací případ dává platné vstupy a získává pozitivní výsledky. Negativní testovací případ dává neplatné vstupy a dostává přesnou chybovou zprávu.

jak napsat testovací případy pro webovou aplikaci s příkladem

Další informace o nich najdete na:

Některé běžné atributy, které mají všechny testovací případy, jsou:

  • ID scénáře - převzato z dokumentu testovacího scénáře
  • ID testovacího případu - pro jedinečnou identifikaci a sledování. Např .: TC_login_001
  • Popis testu - Stručné vysvětlení testovaných podmínek testu
  • Kroky k provedení - Podrobný návod, jak testovat krok za krokem
  • Test data - Data dodaná do testovacích kroků
  • Očekávaný výsledek - Výsledek podle očekávání
  • Skutečný výsledek - reakce AUT při spuštění testu
  • Status - Pass / Fail / No Run / Incomplete / Blocked - Popisuje výsledek testu
  • Komentáře - k dalším podrobnostem
  • Provedeno - jméno testera
  • Datum provedení - Datum, kdy je test spuštěn
  • Defekt ID - Defekt zaznamenaný proti testovacímu případu v případě selhání testu
  • Podrobnosti o konfiguraci - OS, prohlížeč, platforma, informace o zařízení (volitelně)

Doporučené čtení=>

# 3. Testovací proces - Jaké testy provést?

Existuje obrovské množství typů testování, ale ne všechny je možné na tomto AUT provést. Čas, rozpočet, povaha podnikání, povaha aplikace a zájem klienta jsou klíčovými hráči při výběru testů, které se mají při žádosti provést.

Například: Pokud se jedná o online obchodní portál, pak jsou zátěžové testy a zátěžové testy povinné. Některé typy testů, které byste si neměli nechat ujít, jsou:

# 4. Testování ve fázi částečného vývoje

Obecně platí, že u středních a začínajících společností je čas a zdroje omezené. Testeri zde mohou zahájit proces testování před integrací modulů, což znamená, že můžeme provádět testy integrace jednotek a zprostředkovatelů.

Je důležité si uvědomit, že výsledky z těchto fází nelze počítat jako přesné, takže možná budete muset naplánovat celkový test černé skříňky, jakmile bude vše připraveno. Přehlížení této části se může ukázat jako nákladné a testování, neúčinné.

# 5. Dokument o hlášení chyby

Ruce, toto je nejdůležitější dokument QA, který kdy vytvoříte.

Toto jsou pole, která musí mít dobré hlášení o chybě:

  • Defekt ID - obvykle sériové číslo
  • Popis defektu - vysvětlení problému v jednom řádku
  • Location - Modul / oblast AUT, kde je problém nalezen
  • Číslo sestavení - číslo verze a kódu.
  • Kroky k reprodukci - Seznam kroků, které vás dovedou k problému
  • Závažnost - Nastavte úroveň popisující závažnost problému - Nízká, Střední, Vysoká, Blokování atd.
  • Priorita - Stanoveno vývojáři k určení pořadí, ve kterém bude chyba odstraněna (P1, P2, P3 atd. P1 - nejvyšší)
  • Přiřazeno - Vlastníkovi vady v daném okamžiku
  • Hlášeno - jméno testera
  • Stav - Jiný stav, který představuje fázi životního cyklu chyby
    • Nový - Chyba je nalezena a je právě nahlášena
    • Otevřeno - ověřeno vedením QA
    • Přiřazeno - Odesláno vedoucímu vývojáře k přiřazení k příslušnému vývojáři
    • Probíhá / Probíhá - Dev na tom začal pracovat
    • Opraveno / Vyřešeno - vývojář na tom pracuje
    • Ověřeno / Uzavřeno - Tým QA znovu otestoval a našel chybu opravenou
    • Retest - tým QA nesouhlasí s řešením od Dev a dále postupuje v chybě pro přepracování
    • Duplikát - Podobná chyba již existuje
    • Odloženo - platná chyba, ale bude opravena v pozdějších verzích
    • Neplatné - nejedná se o chybu, není reprodukovatelná nebo není k dispozici dostatek informací

Další čtení=>

# 6. Proces odhlášení

Odhlásit se a zasílání finální dokumentace je úkolem vedoucího / manažera QA. Tým však musí předložit výše uvedené dokumenty (testovací scénář, testovací případ a dokument protokolu závad) ke konečným kontrolám a auditu.

Ujistěte se, že jste všechny zkontrolovali a poslali finální verze.

Přečtěte si také=>

Závěr

Toto je proces, kterého jsem byl svědkem a zažil na vlastní kůži, když jsem byl testerem, a doufám, že vám dal několik užitečných ukazatelů.

A konečně, kariéra v testování byla pro mě absolutní radostí a doufám, že i pro vás.

Všechno nejlepší pro vaši kariéru!

Doporučené čtení

^