Menu

Praktické testování softwaru Tok procesu QA (požadavky na vydání)

practical software testing qa process flow

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

Kompletní přehled procesu testování softwaru QA mezi koncovými body:

Poznámka - Znovu publikujeme tento užitečný příspěvek s aktualizovaným obsahem.

Práce profesionála v oblasti testování softwaru není snadná. Je plná výzev, které jsou stejně náročné. Testeři mají být ve střehu a nadšení v každé fázi životního cyklu aplikace.

I když existují výzvy, existuje několik obrovských příležitostí, jak se podrobně naučit a prozkoumat různé aspekty metodik testování, procesů a samozřejmě softwaru.

Role zkušebního inženýra začíná velmi brzy. A hned od konceptualizace projektu jsou testeři zapojeni do diskusí s vlastníkem produktu, projektovým manažerem a různými zúčastněnými stranami.

Požadavky na vydání

Tento výukový program „Průběh procesu testování softwaru“ vám poskytne kompletní přehled o různých fázích v STLC spolu se souvisejícími výzvami a osvědčenými postupy, jak tyto výzvy snadno pochopitelným způsobem překonat.

Co se naučíte:

Požadavek na vydání - úplný přehled

Životní cyklus testování softwaru

Již od požadavku na vydání je každá fáze vysvětlena jasně. Pojďme se na ně podívat podrobně.

# 1) Požadavek

Projekt nemůže vzlétnout bez jasného požadavku. Toto je nejdůležitější fáze, kdy je třeba nápady zapsat do dobře srozumitelného a formátovaného dokumentu. Pokud jste součástí projektu, kde se účastníte fáze shromažďování požadavků, považujte se za šťastného.

zdarma software pro kopírování DVD pro Windows 10

Zajímá vás proč? Je to proto, že jste svědky projektu, který vyrábí od nuly. Ačkoli existuje hrdost na to, že je od počátku, přichází také s určitými povinnostmi a výzvami.

Výzvy

Člověk si nedokáže představit všechny požadavky na shromáždění na jednom sezení. Buďte dost trpěliví.

Proběhne spousta diskusí, z nichž některé mohou být pro váš projekt jednoduše irelevantní, ale i tak mohou obsahovat některé důležité informace pro váš projekt. Rychlost diskuzí může někdy překročit vaše uchopovací schopnosti, nebo byste jednoduše nevěnovali pozornost vlastníkovi produktu.

Níže uvedený obrázek zdůrazňuje klíčové kroky při shromažďování požadavků:

Životní cyklus požadavků

Každá chybějící informace má obrovský dopad na celkové porozumění a testování projektu. Abychom to překonali, uvádíme několik osvědčených postupů, které by se během této fáze měly dodržovat.

Osvědčené postupy

  • Udržujte svou mysl otevřenou a věnujte pozornost každému slovu vlastníka produktu.
  • Jen neposlouchejte, vyjasněte si své pochybnosti, jakkoli se zdá být.
  • Pro rychlé uchování poznámek vždy používejte notebooky. Notebook byste měli používat, pouze pokud opravdu dokážete psát spravedlivou rychlostí.
  • Opakujte věty a objasněte je z PO, o které si myslíte, že jste jí porozuměli.
  • Nakreslete bloková schémata, text odkazu atd., Aby byly požadavky jasnější v pozdější době.
  • Pokud jsou týmy na různých místech, zkuste to udělat jako záznam WebEx nebo podobný záznam. Vždy pomůže, když budete mít po diskusích pochybnosti.

Ačkoli pro každou fázi neexistuje samostatná zeď jako taková, požadavky se ve vývoji mění i velmi pozdě. Myšlenkou je tedy uchopit většinu požadavku a řádně to zdokumentovat.

Jakmile je dokumentován se všemi potřebnými body, rozdělte a prodiskutujte všechny zúčastněné strany, aby byly jakékoli návrhy nebo změny zachyceny včas a před pokračováním jsou všichni na stejné stránce.

# 2) Testovací strategie

Testeři by měli přijít s testovací strategií, která nestačí jen k lepšímu testování softwaru, ale měla by také vnést důvěru v všechny zúčastněné strany, pokud jde o kvalitu produktu.

Testovací strategie

Výzvy

Nejdůležitějším aspektem této fáze je vytvoření strategie, která by při práci měla přinést softwarový produkt, který je bezchybný, udržitelný a akceptovaný koncovými uživateli.

Testovací strategie jsou něco, co nebudete měnit každý druhý den. V některých případech musíte prodiskutovat své testovací strategie také se zákazníky. Této části je tedy třeba věnovat velkou důležitost.

Osvědčené postupy

  • Zde jsou některé z osvědčených postupů, které vám při dodržení mohou poskytnout velkou úlevu a vést k hladkému testování.
  • Projděte si znovu dokument s požadavkem. Zvýrazněte body importu s ohledem na prostředí cílového softwaru.
  • Vytvořte seznam prostředí, kde bude software skutečně nasazen.
  • Prostředí lze chápat jako typ operačních systémů nebo mobilních zařízení.
  • Pokud je operačním systémem Windows, uveďte všechny verze okna, ve kterém budete svůj software testovat. Pokud verze viz. Windows 7, Windows 10 nebo Windows Server (y) stále nejsou definovány v dokumentu požadavku, pak je nejvyšší čas, kdy je třeba o nich diskutovat.
  • V podobné poznámce získejte cílové prohlížeče s diskutovanými a zdokumentovanými verzemi, pokud je AUT webový systém.
  • Vytvořte seznam veškerého softwaru třetích stran, který aplikace bude potřebovat (je-li vyžadován / podporován). Mezi ně může patřit Adobe Acrobat, Microsoft Office, jakékoli doplňky atd.

Myšlenkou zde je uchovat veškerou potřebnou a požadovanou platformu, zařízení a software, které bude naše aplikace muset před námi fungovat, aby bylo možné formulovat komplexní strategii.

Níže uvedený obrázek vám pomůže pochopit nástin testovací strategie, pokud pracujete na agilním projektu:

Strategie testování

# 3) Plánování testů

Poté, co jsou testeři vyzbrojeni všemi informacemi týkajícími se AUT, je ve fázi plánování implementována Strategie.

Stejně jako testovací strategie je i plánování testů zásadní fází.

Testovací plán

Výzvy

Jelikož úspěch (nebo neúspěch) AUT závisí do značné míry na tom, jak byly testy provedeny, stává se tato fáze důležitým aspektem celého životního cyklu testu. Proč? Protože v této fázi je definována část testování.

Abychom překonali některé výzvy, mohou být tyto osvědčené postupy skutečně užitečné.

Osvědčené postupy

  • Vždy pamatujte na to, abyste při testování své aplikace nenechali kámen na kameni.
  • Je čas formulovat testovací strategii.
  • Vytvořte matici prostředí tak, aby byl software testován na všech platformách.
  • Stejně jako Windows 10 + Internet Explorer 11+ Windows Office 2010+.
  • Stejně jako prohlížeč Android 4.2.2+ a Chrome.
  • Pokud vaše aplikace pracuje s více databázemi (je-li dokumentováno), udržujte databáze (MySQL, Oracle, SQLServer) v testovací matici takovým způsobem, aby byly příliš integrovány s některými testy.
  • Podle toho nakonfigurujte testovací stroje a pojmenujte je jako SetUp1, SetUp2 atd.
  • SetUp1 bude mít Windows 7+ IE 10+ Office 2007+.
  • SetUp2 může mít Windows 10+ IE Edge + Office 2013+.
  • SetUp3 může mít telefon Android s nainstalovaným souborem .apk.
  • Gratulujeme! Vaše testovací nastavení je připraveno a zahrnuli jste také všechny možné kombinace platforem, na kterých bude vaše aplikace fungovat.

# 4) Testování

Hledání chyb

Konečně je vaše aplikace sestavena a vy jste připraveni najít chyby! Nyní je čas pracovat na plánování testů a najít co nejvíce chyb. Pokud pracujete v agilním prostředí, mezi tím budou nějaké fáze, pak jednoduše postupujte podle těchto scrum metod.

Níže uvedený diagram zobrazuje kategorizaci různých typů testování:

Druhy testování

Výzvy

Testování je těžkopádný proces, který je sám o sobě náchylný k chybám! Při testování aplikace najde člověk mnoho výzev. Níže uvádíme některé doporučené postupy pro záchranu.

Osvědčené postupy

Hlavu vzhůru! Snažíte se najít vady kódu. Musíte věnovat pozornost celkovému fungování softwaru.

  • Vždy je vhodné dívat se na aplikaci s novým vzhledem, BEZ PROSTŘEDNICTVÍ PŘÍPADŮ ZKOUŠEK.
  • Postupujte podle navigační cesty vašeho softwaru (AUT).
  • Seznamte se s AUT.
  • Nyní si přečtěte testovací případy (Všechny) libovolného konkrétního modulu (Možná podle vašeho výběru).
  • Nyní přejděte na AUT a porovnejte nálezy s těmi, které jsou uvedeny v očekávané části testovacích případů.
  • Myšlenkou toho je otestovat každou zmíněnou funkci na každé podporované platformě.
  • Poznamenejte si každou odchylku, jakkoli se zdá triviální.
  • Zapište si kroky, jak dosáhnout jakékoli odchylky, pořiďte snímky obrazovky, zachyťte protokoly chyb, protokoly serveru a jakoukoli další podpůrnou dokumentaci, která může prokázat existenci vad.
  • Neváhejte se zeptat. Ačkoli máte dokument s požadavky, budou chvíle, kdy budete na pochybách.
  • Než se obrátíte na vlastníka produktu, obraťte se na vývojáře (pokud sedí vedle vás nebo jsou dosažitelní). Pochopte perspektivu vývojáře na fungování softwaru. Pochopte je. Pokud si myslíte, že tato implementace není v souladu s požadavkem, informujte správce testů.

# 5) Před vydáním

Než uvedeme jakýkoli produkt na trh, je třeba zajistit jeho kvalitu. Software je vyvíjen jednou, ale ve skutečnosti je testován, dokud není vyměněn nebo odstraněn.

Výzvy

Software musí být přísně testován na mnoho svých parametrů.

Parametry nemusí být omezeny na:

  • Funkčnost / chování.
  • Výkon.
  • Škálovatelnost.
  • Kompatibilní s uvedenými platformami.

Úkolem je také předpovědět úspěšnost aplikace, která závisí na mnoha iteracích provedeného testování.

Osvědčené postupy

  • Ujistěte se, že jsou testovány všechny funkce na všech platformách.
  • Zvýrazněte oblasti, které nejsou testovány, nebo ty, které vyžadují větší úsilí při testování.
  • Před vydáním si uschovejte matici všech výsledků testu. Zkušební matice poskytne celkový obraz stability produktu. Vedení také pomůže zavolat v den vydání.
  • Při testování produktu poskytněte týmu své podněty / návrhy týkající se vašich zkušeností.
  • Váš příspěvek, který vás bude považovat za koncového uživatele, bude pro software velkým přínosem.
  • Kvůli časové tísni nebo jakékoli jiné podobné situaci buď vynecháme nějaké testování, nebo se tím nebudeme zabývat. Neváhejte sdělit stav testování svému nadřízenému.
  • Předložte zdravotní kartu aplikace zúčastněným stranám. Karty zdraví by měly mít řadu všech zaznamenaných, otevřených, uzavřených, občasných vad s jejich závažností a prioritou.
  • Navrhněte dokument vydání a sdílejte jej v týmu.
  • Práce na dokumentu vydání připravena.
  • Vylepšete oblasti, které navrhl management / tým.

Níže uvedený obrázek ukazuje mapu životního cyklu vydání softwaru:

Před vydáním

# 6) Uvolněte

Konečně přichází čas, kdy musíme produkt dodat jeho zamýšleným uživatelům. Všichni jsme jako tým tvrdě pracovali, abychom produkt odhlásili a nechali software pomáhat jeho uživatelům.

Výzvy

Za vydání jakéhokoli softwaru jsou primárně zodpovědní technici pro testování softwaru. Tato aktivita vyžaduje procesně orientovaný pracovní tok. Zde jsou některé z osvědčených postupů, které jsou v této fázi zahrnuty.

Osvědčené postupy

  • Vždy pamatujte, že nepracujete na dokumentu k vydání ke dni SKUTEČNÉHO UVEDENÍ.
  • Aktivitu vydání vždy naplánujte před skutečným datem vydání.
  • Standardizujte dokument podle zásad společnosti.
  • Dokument o vydání by se měl pokusit vytvořit pozitivní očekávání od softwaru.
  • V dokumentu jasně uveďte všechny softwarové a hardwarové požadavky specifické pro jejich verze.
  • Zahrňte všechny otevřené vady a jejich závažnost.
  • Neskrývejte hlavní zasažené oblasti kvůli otevřeným vadám. Dejte jim místo v dokumentu Release.
  • Nechte dokument zkontrolovat a digitálně podepsat (může se lišit podle zásad společnosti).
  • Buďte si jisti a odešlete dokument o vydání spolu se softwarem.

Proces testování QA na reálném projektu - metoda vodopádu

Od čtenáře jsem dostal zajímavou otázku, Jak probíhá testování ve společnosti, tj. V praktickém prostředí?

Tuto kuriozitu mají ti, kteří právě opustí školu a začnou hledat práci - jaké by bylo skutečné pracovní prostředí ve společnosti?

Zde jsem se zaměřil na skutečný pracovní proces Testování softwaru ve společnostech .

Skutečný testovací proces ve společnostech

Kdykoli získáme jakýkoli nový projekt, uskuteční se úvodní setkání se znalostmi projektu. Na tomto setkání v zásadě diskutujeme, kdo je klientem? jaká je doba trvání projektu a kdy je jeho dodání? Kdo jsou všichni zapojeni do projektu, tj. Manažer, technický vedoucí, vedoucí QA, vývojáři, testeři atd.?

Ze SRS (specifikace softwarových požadavků) je vypracován plán projektu. Odpovědností testerů je vytvořit plán testování softwaru z tohoto SRS a plánu projektu. Vývojáři začínají kódovat od návrhu. Projektová práce je rozdělena do různých modulů a tyto projektové moduly jsou distribuovány mezi vývojáře.

Do té doby je odpovědností testera vytvořit testovací scénář a zapsat testovací případy podle přiřazených modulů. Snažíme se pokrýt téměř všechny funkční testovací případy od SRS. Data lze udržovat ručně v některých šablonách testovacích případů Excel nebo nástrojích pro sledování chyb.

Když vývojáři dokončí jednotlivé moduly, jsou tyto moduly přiřazeny testerům. Testování kouře se provádí na těchto modulech a pokud tento test neuspějí, jsou moduly znovu přiděleny příslušným vývojářům pro opravu.

U předaných modulů se ruční testování provádí z písemných testovacích případů. Pokud je nalezena nějaká chyba, která bude přiřazena vývojáři modulu a bude přihlášena do nástroj pro sledování chyb . Při opravě chyby tester provede ověření chyby a regresní testování všech souvisejících modulů. Pokud chyba projde ověřením, je označena jako ověřená a označena jako uzavřená. Jinak se výše uvedený cyklus chyb opakuje. (Životní cyklus chyby se budu zabývat v jiném příspěvku)

Na jednotlivých modulech se provádějí různé testy a testování integrace na integraci modulů. Mezi tyto testy patří testování kompatibility, tj. Testování aplikací na jiném hardwaru, verzích OS, softwarových platformách, různých prohlížečích atd.

Zátěžové a zátěžové testování se rovněž provádí podle SRS. Nakonec se testování systému provede vytvořením prostředí virtuálního klienta. Jakmile jsou provedeny všechny testovací případy, je připraven testovací protokol a je rozhodnuto o vydání produktu!

Kroky v požadavcích na uvolnění

Níže jsou uvedeny podrobnosti o každém kroku testování, který se provádí v každé kvalitě softwaru a životním cyklu testování specifikovaném v Standardy IEEE a ISO.

# 1) Recenze SRS : Přezkoumání specifikací požadavků na software.

# 2) Cíle jsou nastaveny pro hlavní vydání.

# 3) Cílové datum plánováno na vydání.

# 4) Podrobný plán projektu je postaven. To zahrnuje rozhodnutí o specifikacích designu.

# 5) Vypracovat testovací plán je založen na specifikacích designu.

# 6) Testovací plán: To zahrnuje cíle, metodiku přijatou při testování, funkce, které mají být testovány a které nebudou testovány, kritéria rizika, plán testování, podpora více platforem a alokace prostředků pro testování.

# 7) Specifikace testu: Tento dokument obsahuje technické podrobnosti (softwarové požadavky) požadované před testováním.

# 8) Psaní testovacích případů

# 9) Vývoj: Moduly jsou vyvíjeny jeden po druhém.

# 10) Vazba instalátorů: Instalační služby jsou postaveny na jednotlivých produktech.

jak převést char na int c ++

#jedenáct) Postup sestavení : Sestavení zahrnuje Instalační služby dostupných produktů - více platforem.

# 12) Testování: Kouřový test (BVT): Základní aplikační test k rozhodnutí o dalším testování.

  • Testování nových funkcí
  • Cross-browser a testování napříč platformami
  • Zátěžové testování a testování úniku paměti.

# 13) Souhrnná zpráva o testu

# 14) Zmrazení kódu

  • V tuto chvíli nejsou přidány žádné další nové funkce.

# 15) Testování: Testování sestavení a regrese.

# 16) Rozhodnutí o uvolnění produktu.

# 17) Scénář po vydání pro další cíle.

Toto byl souhrn skutečného procesu testování v prostředí společnosti.

Závěr

Práce softwarového testeru je plná výzev, přesto příjemná. To je pro někoho, kdo je stejně vášnivý, motivovaný a plný nadšení. Najít chyby u někoho není vždy snadná práce! To vyžaduje hodně dovedností a vady býků.

Kromě všech kvalit by měl být tester také orientovaný na procesy. Stejně jako všechna ostatní průmyslová odvětví jsou i projekty v IT zpracovávány ve fázích, kde každá fáze má určité dobře definované cíle. A každý cíl má dobře definované přijímací kritérium. Zkušební inženýr musí nosit na svých bedrech mnoho zátěže kvality softwaru.

Při práci v jakékoli fázi softwaru by se testeři měli řídit osvědčenými postupy a měli by se přizpůsobit procesu v příslušných fázích. Dodržování osvědčených postupů a dobře formulovaného procesu nejen pomáhá usnadnit práci testerů, ale také pomáhá zajistit kvalitu softwaru.

Byli jste součástí některé z výše uvedených fází? Neváhejte se podělit o své zkušenosti níže.

Doporučené čtení

^