practical software testing qa process flow
Kompletný prehľad toku procesu testovania softvéru end-to-end QA:
Poznámka - Zverejňujeme tento užitočný príspevok s aktualizovaným obsahom.
Úloha profesionála v oblasti testovania softvéru nie je ľahká. Je plná výziev, ktoré sú rovnako náročné. Testéri majú byť v strehu a nadšení v každej fáze životného cyklu aplikácie.
Aj keď existujú výzvy, existuje niekoľko obrovských príležitostí, ako sa podrobne naučiť a preskúmať rôzne aspekty testovacích metodík, procesov a samozrejme aj softvéru.
Úloha testovacieho inžiniera sa začína veľmi skoro. A už od konceptualizácie projektu sú testeri zapojení do diskusií s vlastníkom produktu, projektovým manažérom a rôznymi zainteresovanými stranami.
Tento návod na tému „Tok procesu testovania softvéru“ vám poskytuje kompletný prehľad rôznych fáz v STLC spolu s príslušnými výzvami a osvedčenými postupmi na prekonanie týchto výziev ľahko pochopiteľným spôsobom.
Čo sa dozviete:
- Požiadavka na vydanie - úplný prehľad
- Proces testovania zabezpečenia kvality na skutočnom projekte - metóda vodopádu
- Kroky v požiadavkách na uvoľnenie
- Záver
- Odporúčané čítanie
Požiadavka na vydanie - úplný prehľad
Hneď od požiadavky na vydanie je každá fáza vysvetlená jasne. Pozrime sa na ne podrobne.
# 1) Požiadavka
Projekt nemôže vzlietnuť bez jasných požiadaviek. Toto je najdôležitejšia fáza, keď je potrebné nápady zapísať do dobre zrozumiteľného a naformátovaného dokumentu. Ak ste súčasťou projektu, kde sa zúčastňujete fázy zhromažďovania požiadaviek, považujte sa za šťastného.
sql dotazy pohovor otázky a odpovede na 3 roky skúseností
Pýtate sa prečo? Je to preto, lebo ste svedkami toho, ako sa projekt vyrába od nuly. Aj keď je hrdosť na to, že je od samého začiatku, prináša so sebou aj určité zodpovednosti a výzvy.
Výzvy
Jeden si nevie predstaviť všetky požiadavky, ktoré by sa zhromaždili na jednom sedení. Buďte dostatočne trpezliví.
Uskutoční sa veľa diskusií, z ktorých niektoré môžu byť pre váš projekt jednoducho irelevantné, ale aj napriek tomu môžu obsahovať niektoré dôležité informácie pre váš projekt. Rýchlosť diskusií niekedy môže prekročiť vaše uchopovacie schopnosti alebo by ste jednoducho nevenovali pozornosť vlastníkovi produktu.
Nasledujúci obrázok zdôrazňuje kľúčové kroky spojené so zhromažďovaním požiadaviek:
Každá zmeškaná informácia má obrovský vplyv na celkové pochopenie a testovanie projektu. Aby ste to prekonali, uvádzame niekoľko osvedčených postupov, ktoré by sa mali počas tejto fázy dodržiavať.
Osvedčené postupy
- Majte svoju myseľ otvorenú a dávajte pozor na každé slovo vlastníka produktu.
- Neposlúchajte iba, vyčistite svoje pochybnosti, nech už sa javia akékoľvek.
- Na rýchle uchovanie poznámok vždy používajte notebooky. Mali by ste používať notebook, iba ak skutočne dokážete písať primeranou rýchlosťou.
- Zopakujte vety a objasnite ich z PO, o ktorej si myslíte, že ste jej porozumeli.
- Nakreslite blokové diagramy, text odkazu atď., Aby boli požiadavky jasnejšie v neskoršom časovom období.
- Ak sú tímy na rôznych miestach, vyskúšajte to ako nahrávku WebEx alebo podobnú. Vždy pomôže, keď budete mať po skončení diskusií pochybnosti.
Aj keď pre každú fázu neexistuje samostatná stena ako taká, požiadavky sa vo vývoji menia dokonca veľmi neskoro. Cieľom je teda chopiť sa väčšiny požiadaviek a riadne to zdokumentovať.
Akonáhle je dokumentovaný so všetkými potrebnými bodmi, rozdeľte a prediskutujte všetky zainteresované strany, aby boli akékoľvek návrhy alebo zmeny zachytené včas a pred posunom ďalej sú všetci na jednej stránke.
# 2) Testovacia stratégia
Testéri majú prísť s testovacou stratégiou, ktorá nestačí len na lepšie otestovanie softvéru, ale mala by tiež vniesť dôveru do všetkých zainteresovaných strán, pokiaľ ide o kvalitu produktu.
Výzvy
Najdôležitejším aspektom tejto fázy je vytvorenie stratégie, ktorá by pri vývoji mala priniesť softvérový produkt, ktorý je bezchybný, udržateľný a akceptovaný koncovými používateľmi.
Stratégie testovania sú niečo, čo nebudete meniť každý druhý deň. V niektorých prípadoch musíte so zákazníkmi prediskutovať svoje testovacie stratégie. Táto časť by sa preto mala zaoberať veľmi dôležito.
Osvedčené postupy
- Tu sú niektoré z najlepších postupov, ktoré, ak sa budete držať, vám môžu poskytnúť veľkú úľavu a viesť k bezproblémovému testovaniu.
- Znova si prečítajte dokument s požiadavkami. Zvýraznite body importu vzhľadom na prostredie cieľového softvéru.
- Vytvorte zoznam prostredí, v ktorých bude softvér skutočne nasadený.
- Prostredia možno chápať ako typ operačných systémov alebo mobilných zariadení.
- Ak je operačným systémom Windows, uveďte všetky verzie okna, v ktorom budete testovať softvér. Ak verzie viď. Windows 7, Windows 10 alebo Windows Server (y) stále nie sú definované v dokumente s požiadavkami, je preto najvyšší čas diskutovať o nich.
- Podobne, získajte cieľové prehľadávače s diskutovanými a zdokumentovanými verziami, ak je AUT webový systém.
- Vytvorte zoznam všetkých softvérov tretích strán, ktoré bude aplikácia potrebovať (ak je požadovaný / podporovaný). Môžu to byť napríklad Adobe Acrobat, Microsoft Office, akékoľvek doplnky atď.
Tu je základnou myšlienkou uchovať každú potrebnú a požadovanú platformu, zariadenia a softvér, ktoré bude naša aplikácia musieť pred sebou fungovať, aby bolo možné formulovať komplexnú stratégiu.
Nasledujúci obrázok vám pomôže pochopiť osnovu stratégie testovania, ak pracujete na svižnom projekte:
# 3) Plánovanie testu
Potom, čo sú testéri vyzbrojení všetkými informáciami týkajúcimi sa AUT, je vo fáze plánovania implementácia stratégie.
Rovnako ako stratégia testovania, aj plánovanie testov je zásadnou fázou.
Výzvy
Pretože úspech (alebo neúspech) AUT závisí vo veľkej miere od spôsobu vykonania testov, stáva sa táto fáza dôležitým aspektom celého životného cyklu testu. Prečo? Pretože v tejto fáze je definovaná časť testovania.
S cieľom prekonať niektoré výzvy môžu byť tieto osvedčené postupy skutočne užitočné.
Osvedčené postupy
- Vždy pamätajte na to, aby pri testovaní vašej aplikácie nezostal kameň na kameni.
- Je čas formulovať testovaciu stratégiu.
- Vytvorte maticu prostredia tak, aby bol softvér testovaný na všetkých platformách.
- Rovnako ako Windows 10 + Internet Explorer 11+ Windows Office 2010+.
- Rovnako ako prehliadač Chrome pre Android 4.2.2+ alebo novší.
- Ak vaša aplikácia pracuje s viacerými databázami (ak sú zdokumentované), udržujte databázy (MySQL, Oracle, SQLServer) v testovacej matici tak, aby boli príliš integrované s niektorými testami.
- Podľa toho nakonfigurujte testovacie stroje a pomenujte ich ako SetUp1, SetUp2 atď.
- SetUp1 bude mať Windows 7+ IE 10+ Office 2007+.
- SetUp2 môže mať Windows 10+ IE Edge + Office 2013+.
- SetUp3 môže mať telefón so systémom Android s nainštalovaným súborom .apk.
- Blahoželáme! Vaše testovacie nastavenie je pripravené a zahrnuli ste tiež všetky možné kombinácie platforiem, na ktorých bude vaša aplikácia pracovať.
# 4) Testovanie
Konečne je vaša aplikácia postavená a vy ste pripravení nájsť chyby! Teraz je čas popracovať na plánovaní testov a nájsť čo najviac chýb. Ak pracujete v agilnom prostredí, medzi tým budú nejaké fázy, potom jednoducho postupujte podľa týchto skrumážových metód.
Nižšie uvedený diagram zobrazuje kategorizáciu rôznych typov testovania:
Výzvy
Testovanie je ťažkopádny proces, ktorý je sám osebe náchylný na chyby! Pri testovaní aplikácie človek nájde veľa výziev. Ďalej uvádzame niekoľko osvedčených postupov na záchranu.
Osvedčené postupy
Rozveselte sa! Snažíte sa nájsť chyby v kóde. Musíte venovať pozornosť celkovému fungovaniu softvéru.
- Vždy je vhodné pozrieť sa na aplikáciu s novým vzhľadom, BEZ PROSTREDIA SKÚŠOBNÝCH PRÍPADOV.
- Postupujte podľa navigačnej cesty vášho softvéru (AUT).
- Zoznámte sa s AUT.
- Teraz si prečítajte testovacie prípady (Všetky) ľubovoľného konkrétneho modulu (možno podľa vášho výberu).
- Teraz choďte na AUT a porovnajte zistenia so zisteniami uvedenými v očakávanej časti testovacích prípadov.
- Cieľom je vyskúšať každú spomenutú funkciu na každej podporovanej platforme.
- Poznačte si každú odchýlku, nech už sa zdá byť akákoľvek triviálna.
- Zapíšte si kroky, ako dosiahnete akúkoľvek odchýlku, urobte snímky obrazovky, zaznamenajte chybové protokoly, protokoly servera a akúkoľvek ďalšiu podpornú dokumentáciu, ktorá dokáže existenciu chýb.
- Neváhajte sa opýtať. Aj keď máte dokument s požiadavkami, niekedy budete mať pochybnosti.
- Predtým, ako sa obrátite na produktového vlastníka, obráťte sa na pochybnosti s vývojármi (ak sedia vedľa vás alebo sú dosiahnuteľní). Pochopte perspektívu vývojára na fungovaní softvéru. Pochopte ich. Ak si myslíte, že táto implementácia nie je v súlade s požiadavkami, informujte o tom manažéra testu.
# 5) Pred vydaním
Predtým, ako uvedieme akýkoľvek produkt na trh, je potrebné zabezpečiť jeho kvalitu. Softvér sa vyvíja jednorazovo, ale v skutočnosti sa testuje, kým sa nevymení alebo neodstráni.
Výzvy
Softvér musí byť dôsledne testovaný na mnoho svojich parametrov.
Parametre sa nemusia obmedzovať na:
- Funkčnosť / správanie.
- Výkon.
- Škálovateľnosť.
- Kompatibilné s uvedenými platformami.
Výzvou je tiež predpovedať úspešnosť aplikácie, ktorá závisí od mnohých opakovaní vykonaného testovania.
Osvedčené postupy
- Uistite sa, že sú testované všetky funkcie na všetkých platformách.
- Zvýraznite oblasti, ktoré nie sú testované, alebo oblasti, ktoré si vyžadujú väčšie úsilie pri testovaní.
- Pred vydaním si uschovajte maticu všetkých výsledkov testu. Testovacia matica poskytne celkový obraz stability produktu. Pomôže tiež vedeniu prijať hovor v deň vydania.
- Poskytnite tímu svoje návrhy / návrhy týkajúce sa vašich skúseností pri testovaní produktu.
- Váš príspevok, ktorý vás bude považovať za koncového používateľa, bude pre softvér prínosom.
- Z dôvodu časovej tiesne alebo akejkoľvek inej podobnej situácie buď vynecháme nejaké testovanie, alebo do toho nejdeme hlboko. Neváhajte oznámiť stav testovania svojmu manažérovi.
- Predložte zdravotnú kartu aplikácie zúčastneným stranám. Karty zdravotného stavu by mali mať počet všetkých zaznamenaných, otvorených, uzavretých, prerušovaných chýb s ich závažnosťou a prioritou.
- Vypracujte dokument o vydaní a zdieľajte ho s celým tímom.
- Práce na dokumente o vydaní sú pripravené.
- Zdokonaliť oblasti, ktoré navrhuje vedenie / tím.
Nasledujúci obrázok zobrazuje mapu životného cyklu vydania softvéru:
# 6) Uvoľnite
Konečne prichádza čas, keď musíme produkt dodať určeným používateľom. Všetci ako tím sme tvrdo pracovali na tom, aby sme produkt odhlásili a umožnili používateľom softvér pomáhať.
Výzvy
Za vydanie každého softvéru sú zodpovední predovšetkým technici testovania softvéru. Táto aktivita vyžaduje procesne orientovaný pracovný tok. Tu uvádzame niektoré z najlepších postupov, ktoré sú súčasťou tejto fázy.
Osvedčené postupy
- Vždy pamätajte, že na dokumente vydaní nepracujete k dátumu SKUTOČNÉHO UVEDENIA.
- Aktivitu vydania si naplánujte vždy pred skutočným dátumom vydania.
- Štandardizujte dokument podľa zásad spoločnosti.
- Váš dokument o vydaní by sa mal pokúsiť vytvoriť pozitívne očakávania týkajúce sa softvéru.
- V dokumente jasne uveďte všetky softvérové a hardvérové požiadavky špecifické pre ich verzie.
- Zahrňte všetky otvorené chyby a ich závažnosť.
- Nezakrývajte hlavné zasiahnuté oblasti kvôli otvoreným chybám. Poskytnite im miesto v dokumente k vydaniu.
- Nechajte dokument skontrolovať a digitálne podpísať (môže sa líšiť v súlade s pravidlami spoločnosti).
- Buďte si istí a dokument s vydaním odošlite spolu so softvérom.
Proces testovania zabezpečenia kvality na skutočnom projekte - metóda vodopádu
Od čitateľa som dostal zaujímavú otázku, Ako sa testuje v spoločnosti, t. J. V praktickom prostredí?
Tí, ktorí práve ukončia štúdium a začnú hľadať zamestnanie, majú túto kuriozitu - aké by bolo skutočné pracovné prostredie v spoločnosti?
Tu som sa zameral na skutočný pracovný proces Testovanie softvéru v spoločnostiach .
Kedykoľvek dostaneme akýkoľvek nový projekt, uskutoční sa prvé stretnutie so známymi projektu. Na tomto stretnutí v zásade diskutujeme, kto je klientom? aké je trvanie projektu a kedy je jeho dodanie? Kto sú všetci zapojení do projektu, tj manažér, technickí vedúci, vedúci QA, vývojári, testéri atď.?
Zo SRS (špecifikácia softvérových požiadaviek) je vypracovaný projektový plán. Zodpovednosťou testerov je vytvorenie plánu testovania softvéru z tohto SRS a plánu projektu. Vývojári začínajú kódovať od návrhu. Projektová práca je rozdelená do rôznych modulov a tieto projektové moduly sú distribuované medzi vývojárov.
Medzitým je zodpovednosťou testera vytvoriť testovací scenár a napísať testovacie prípady podľa pridelených modulov. Snažíme sa pokryť takmer všetky funkčné testovacie prípady od SRS. Údaje je možné udržiavať manuálne v niektorých šablónach testovacích prípadov programu Excel alebo v nástrojoch na sledovanie chýb.
Keď vývojári dokončia jednotlivé moduly, tieto moduly sa priradia testerom. Na týchto moduloch sa vykonáva dymové testovanie. Ak v tomto teste zlyhajú, moduly sa znova pridelia príslušným vývojárom na opravu.
U odovzdaných modulov sa ručné testovanie vykonáva z písomných testovacích prípadov. Ak sa vyskytne chyba, ktorá bude priradená vývojárovi modulu a bude prihlásený do nástroj na sledovanie chýb . Pri opravách chýb tester vykonáva overenie chyby a regresné testovanie všetkých súvisiacich modulov. Ak chyba prejde overením, bude označená ako overená a označená ako uzavretá. V opačnom prípade sa vyššie uvedený cyklus chýb opakuje. (Životnému cyklu chyby sa budem venovať v inom príspevku)
Na jednotlivých moduloch sa vykonávajú rôzne testy a integračné testovanie na integrácii modulov. Tieto testy zahŕňajú testovanie kompatibility, t. J. Testovanie aplikácií na rôznych hardvéroch, verziách OS, softvérových platformách, rôznych prehliadačoch atď.
Zaťažovacie a záťažové skúšky sa tiež vykonávajú podľa SRS. Nakoniec sa testovanie systému vykoná vytvorením prostredia virtuálneho klienta. Po vykonaní všetkých testovacích prípadov je pripravený testovací protokol a je prijaté rozhodnutie o vydaní produktu!
Kroky v požiadavkách na uvoľnenie
Ďalej sú uvedené podrobnosti o každom testovacom kroku, ktorý sa vykonáva v každej kvalite softvéru a životnom cykle testovania, ktoré uvádza Normy IEEE a ISO.
# 1) Recenzia SRS : Preskúmanie špecifikácií softvérových požiadaviek.
# 2) Ciele sú stanovené pre hlavné vydania.
# 3) Cieľový dátum plánované na vydania.
# 4) Podrobný plán projektu je postavený. To zahŕňa rozhodnutie o technických špecifikáciách.
# 5) Vypracujte plán testov je založený na technických špecifikáciách.
# 6) Testovací plán: Patria sem ciele, metodika použitá pri testovaní, vlastnosti, ktoré sa majú testovať a ktoré sa nebudú testovať, kritériá rizika, plán testovania, podpora viacerých platforiem a pridelenie zdrojov na testovanie.
# 7) Špecifikácie testu: Tento dokument obsahuje technické podrobnosti (softvérové požiadavky) požadované pred testovaním.
# 8) Písanie testovacích prípadov
- Dym ( BVT ) testovacie prípady
- Prípady testu príčetnosti
- Prípady regresného testu
- Negatívne testovacie prípady
- Rozšírené testovacie prípady
# 9) Vývoj: Moduly sa vyvíjajú jeden po druhom.
# 10) Väzba inštalatérov: Inštalatéri sú zostavení okolo jednotlivých produktov.
odovzdanie poľa metóde java
#eleven) Postup zostavenia : Zostavenie obsahuje inštalačné programy dostupných produktov - viacerých platforiem.
# 12) Testovanie: Smoke Test (BVT): Základný aplikačný test, ktorým sa prijíma rozhodnutie o ďalšom testovaní.
- Testovanie nových funkcií
- Cross-browser a multiplatformové testovanie
- Stresové testovanie a testovanie úniku pamäte.
# 13) Súhrnná správa o teste
- Hlásenie o chybe a vytvárajú sa ďalšie správy
# 14) Zmrazenie kódu
- V tejto chvíli nie sú pridané žiadne ďalšie nové funkcie.
# 15) Testovanie: Testovanie zostavenia a regresie.
# 16) Rozhodnutie o prepustení produktu.
# 17) Scenár po prepustení pre ďalšie ciele.
Toto bol súhrn skutočného procesu testovania v prostredí spoločnosti.
Záver
Práca softvérového testera je plná výziev, napriek tomu príjemná. To je pre niekoho, kto je rovnako vášnivý, motivovaný a plný nadšenia. Nájsť chyby na niekom nie je vždy ľahká práca! To si vyžaduje veľa zručností a býčie oko pre chyby.
Okrem všetkých kvalít by mal byť tester aj procesne zameraný. Rovnako ako všetky ostatné odvetvia, aj projekty v oblasti IT sú vypracované vo fázach, kde každá fáza má určité dobre definované ciele. Každý cieľ má presne definované kritérium prijatia. Skúšobný inžinier musí mať na svojich pleciach množstvo softvérovej kvality.
Pri práci v ktorejkoľvek fáze softvéru by sa testéri mali riadiť najlepšími postupmi a mali by sa zosúladiť s procesom, ktorý je súčasťou príslušných fáz. Dodržiavanie osvedčených postupov a dobre formulovaného procesu pomáha nielen uľahčiť prácu testerov, ale pomáha tiež zaistiť kvalitu softvéru.
Boli ste súčasťou niektorej z vyššie uvedených fáz? Neváhajte a podeľte sa o svoje skúsenosti nižšie.
Odporúčané čítanie
- Najlepšie nástroje na testovanie softvéru 2021 (QA Test Automation Tools)
- Kurz testovania softvéru: Do ktorého inštitútu pre testovanie softvéru by som sa mal pripojiť?
- Úloha pomocníka QA pri testovaní softvéru
- Ako svoju kariéru si zvolíte testovanie softvéru
- Práca na voľnej nohe pre spisovateľa technického obsahu, ktorý testuje softvér
- Niektoré zaujímavé otázky týkajúce sa testovania softvéru
- Spätná väzba a recenzie na kurz testovania softvéru
- Ako vylepšiť proces testovacieho vydania pre úspešnú produkciu softvéru bez chýb