Menu

Sedemstupňová praktická implementácia manuálneho testovania pred uvedením do výroby

7 step practical implementation manual testing before production release

Vyskúšajte Náš Nástroj Na Odstránenie Problémov

V predchádzajúcom príspevku tejto série okolo manuálneho testovania som sa snažil vrhnúť čo najviac svetla na základy manuálneho testovania.

Ak ste to nestihli, môžete si ich prečítať tu .

Dúfam, že sa vám podarilo dostať vás čo najbližšie k odpovediam, ktoré ste hľadali.

V takom prípade by vás nebavilo vedieť viac o praktickej implementácii manuálneho testovania, o tom, ako sa s ním lepšie oboznámiť a ako v ňom vlastne začať kariéru?

Tento článok objasní všetky tieto aspekty.

Implementácia manuálneho testovania

Začnime.

Čo sa dozviete:

Cyklus ručného testovania

Rozumieť Cyklus ručného testovania alebo Testovací životný cyklus softvéru (STLC), v prvom rade musíme porozumieť životnému cyklu vývoja softvéru (SDLC), o ktorom som si istý, že mu už rozumiete.

Ľudia o nich hovoria osobitne, ale nie sú si istí, či môžu skutočne existovať spolu. Sú navzájom úzko prepojené. No aj tieto cykly majú toľko ich verzií vytvorených a plávajúcich v internetovom priestore, ktoré sa výrazne líšia podľa toho, aký vývojový model je vybraný.

Ako väčšina z svet ide agilne v dnešnej dobe budem svoje veci okolo Agile zjednodušovať.

7 praktických ručných testovacích krokov pred uvedením do výroby

Idem na to.

Pamätajte, že hovorím o SDLC aj STLC.

# 1) Zhromažďovanie požiadaviek

Fáza zhromažďovania požiadaviek

Požiadavky zdokumentuje obchodný analytik (osoba / tím zodpovedný za zhromažďovanie požiadaviek). Dokumentujú požiadavky, to je najdôležitejšie, môžete sa sústrediť iba na to. Tam, kde je to zdokumentované, záleží menej.

Ľudia na dokumentovanie používajú čokoľvek, čo im vyhovuje, ale neobmedzujú sa iba na tradičné platformy ako MS word doc, moderné platformy ako Jira / Rally a nástroje new age ako Trello.

# 2) Požiadavka na diskusiu / zdieľanie

Fáza diskusie o požiadavkách

Obchodný analytik má potom zdieľať zdokumentované požiadavky s vývojovým tímom, testovacím tímom a tímom UX (ak je to potrebné). To sa zvyčajne deje prostredníctvom formálneho stretnutia, kde SPOC (Single Point Of Contacts alebo celý tím, záleží to) od všetkých troch funkcií splní a pochopí celú požiadavku.

V zdravej pracovnej kultúre sú požiadavky diskutované z každého uhla pohľadu a každý člen stretnutia môže klásť otázky a pochybovať. Po zodpovedaní všetkých otázok a vykonaní potrebných úprav v požiadavke možno túto fázu považovať za dokončenú. To, čo niekto nazýva toto konkrétne stretnutie / krok a jeho dokumentácia, sa líši spoločnosť od spoločnosti.

Ďalšie čítanie=> Ako skontrolovať dokument SRS

Po zodpovedaní všetkých otázok a vykonaní potrebných úprav v požiadavke možno túto fázu považovať za hotový .

To, čo niekto nazýva toto konkrétne stretnutie / krok a jeho dokumentácia, sa líši spoločnosť od spoločnosti.

Napríklad, dokumentácia sa nazýva alebo sa rozpadá ako SRS (špecifikácia systémových požiadaviek), dokument požiadaviek, epos, príbeh používateľa, bod príbehu (pravdepodobne najmenšia jednotka požiadavky) atď. Na podobných riadkoch sa toto stretnutie, na ktorom sa zdieľa požiadavka, nazýva ako Požiadavka Diskusné stretnutie, úprava, dierovanie atď., Dúfam, že mi rozumiete?

Stlačenie týchto terminológií, aby ste si vždy pamätali hlavnú myšlienku bez ohľadu na rôzne názvy.

Uverejnite toto stretnutie, súčasne sa spustia dva kroky, v žiadnom konkrétnom poradí, pozrite si ďalšie dva kroky.

# 3) Navrhovanie

Vývojový tím začína s ich technickým návrhom hneď po prerokovaní požiadaviek a v prípade, že neexistujú žiadne zásadné nevyriešené body. To, čo sa deje v tejto fáze, sa opäť líši od spoločnosti k spoločnosti.

Táto fáza môže okrem iného zahŕňať nasledujúce úlohy:

  • Rozhodovanie o rozvojovom prístupe
  • Príprava projektového dokumentu
  • Navrhovanie vývojových diagramov
  • Odhad úsilia
  • Zistenie vplyvu tejto novej požiadavky na existujúcu funkčnosť
  • Potrebujete opraviť existujúce údaje atď.

Tím UX sa môže tiež zapojiť do tejto fázy, keď dôjde k zmene UI alebo k vývoju novej obrazovky. Tím UX pomáha vývojovému tímu a testovaciemu tímu s prototypom používateľského rozhrania pre funkčnosť / funkciu v diskusii. Môže to byť dokument Photoshopu, jednoduchý obrázok, prezentácia v PowerPointe alebo čokoľvek iné, vďaka čomu vývojový tím pochopí, ako by sa mali obrazovky vyvíjať.

Poznámka: V ideálnom prípade sú tieto obrazovky alebo prinajmenšom ich verzie konceptu zobrazené v diskusnej relácii Požiadavka iba preto, aby pomohli tímu lepšie porozumieť. Bude označený na pôvodnú požiadavku, aby bolo možné na neho kedykoľvek odkázať.

# 4) Návrh scenára / testovacieho prípadu

Testovací scenár Fáza návrhu

Súbežne s fázou projektovania začína testovací tím zostavovaním testovacích scenárov a / alebo testovacích prípadov na základe diskutovaných požiadaviek. To, či sa testovacie scenáre vždy najskôr napíšu a až potom preniknú do testovacích prípadov, je opäť niečo, čo nie je stále.

Podľa môjho názoru, či už dokumentačné scenáre dokumentujete, alebo nie, vždy sú tu pred testovacími prípadmi. Testovací scenár je vaša odrážka, ktorú môžete povedať, a ktorá vás prevedie ďalšími krokmi. Hneď ako skončíte s písaním testovacích prípadov, je možné ich zdieľať s vývojovým tímom, aby ste získali predstavu o rozsahu testovania, a tiež sa môžu ubezpečiť, že vývoj, ktorý sa stal alebo deje, vyhovuje písomným testovacím prípadom.

Hneď ako skončíte s písaním testovacích prípadov, je možné ich zdieľať s vývojovým tímom, aby ste získali predstavu o rozsahu testovania, a tiež sa môžu ubezpečiť, že vývoj, ktorý sa stal alebo deje, vyhovuje písomným testovacím prípadom.

Po napísaní testovacích prípadov je ideálne vykonať kontrolu testovacím vedúcim alebo kolegom z mnohých uhlov, ako napríklad:

  • Krytie požiadaviek
  • Pravopisná gramatika
  • Normy na písanie testovacích prípadov (nič iné ako šablóna, podľa ktorej sa tím / spoločnosť riadi)
  • Spätná kompatibilita
  • Kompatibilita s platformami
  • Odkazy na testovacie údaje
  • Typy cieleného testovania atď.

Ďalšie čítanie=> Písanie testovacích prípadov z dokumentu SRS

V ideálnom prípade sa iba po kontrole a potrebných úpravách postúpia vývojovému tímu.

Keď som povedal „raz bude koniec písania testovacích prípadov“, mal som na mysli „všetky testovacie prípady budú napísané na základe úplnej znalosti danej požiadavky a možných testovacích scenárov odhalených do toho konkrétneho času“. Je takmer nemožné mať 100% pokrytie testovacích prípadov na prvý pokus.

Vyskytnú sa chyby, ktoré nájdete v náhodných (ale zamýšľaných) akciách, v čisto náhodných akciách (testovanie opíc) a v niektorých zriedkavých scenároch. Existuje šanca, že o niekoľko z nich prídete. A niekedy vám môžu uniknúť aj tie úplne základné, koniec koncov, ste ľudia. Ale tu vás môže zachrániť aspoň dobrá kontrola a štruktúrovaný spôsob písania testovacích prípadov.

Tester alebo testovací tím častejšie pridáva k existujúcemu bloku stále viac a viac testovacích prípadov, keď odhaľujú pravdu alebo viac premýšľajú o požiadavkách.

No, niektorí z vás už musia pochybovať o mojich znalostiach o testovaní softvéru, pretože nejaké slovo (ktoré sa v softvérovom testovaní stalo normou) zatiaľ nepoužívam. Testovací plán, nie?

Niečo k tomu poviem. Pevne verím v potrebu väčšiny informácií, ktoré sú uvedené v pláne skúšok, ale považujem za diskutabilné zdokumentovanie všetkých na rovnakom mieste a ich absolútna povinnosť.

Je to celkom samostatná téma na diskusiu. Zdieľať informácie „vyhovuje všetkým“ je ťažké, ale skúsim to.

Buď vy, vy, so svojím testovacím káblom alebo so svojím testovacím káblom pripravujete plán testov, alebo dokumentujete požadované informácie na rôznych miestach.

Ďalšie čítanie=> Ako napísať dokument o testovacom pláne

Informácie, ktoré by v tejto fáze mali byť absolútne zmrazené:

  • Rozsah testovania: Požiadavka, spätná kompatibilita, platformy, zariadenia atď.
  • Osoba / tím, ktorý sa chystá testovať
  • Odhad testovacieho úsilia
  • Obmedzenia: Všetky predpoklady alebo obmedzenia prijaté vopred.
  • Ľudia navyše dokumentujú vstupné kritériá, výstupné kritériá, riziko atď., Ktoré si myslím, že v skutočnosti nepotrebujú osobitnú zmienku, pretože by to malo byť skôr bežné pochopenie.
    • Kritériá vstupu (Kedy začať testovať): Málo sa začne, keď je k dispozícii testovateľná časť funkčnosti na testovanie. Málo čakať na testovanie celej funkčnosti. Len čo sa zistí, že základný tok funguje, začne sa testovanie.
    • Kritériá výstupu (Kedy sa má zastaviť): Ak nie sú žiadne blokátory, je možné zastaviť kritické a závažné chyby (vystavené nárazom) pri testovaní na otvorenom stupni. Alebo v polovici cesty, keď existuje príliš veľa chýb, ktorým čelia testovanie, môžu príslušné zainteresované strany zastaviť.
    • Riziko : Obchodné riziko alebo funkčné riziko, ak sa testovanie neuskutoční podľa zdokumentovaného plánu.

# 5) Fáza vývoja

Fáza vývoja softvéru

Vývojový tím po fáze návrhu začína skutočným vývojom a testovaním jednotiek, keď sú hotové s vývojom testovateľných blokov požiadaviek. Môžu odovzdať funkcionalitu na testovanie v blokoch hneď, ako bude implementovaná, alebo môžu odovzdať celú funkcionalitu naraz.

V ideálnom scenári prebehne formálna kontrola kódu a testovanie bieleho poľa pred odovzdaním vyvinutej funkčnosti pre Testovanie. v ideálnom prípade by sa vývojový tím mal okrem požiadaviek a projektových dokumentov odvolať aj na Testovacie prípady poskytnuté testovacím tímom.

# 6) Fáza testovania

Ako už bolo spomenuté, začiatok tejto fázy sa líši spoločnosť od spoločnosti, tím od tímu.

Testovací tím začne testovať buď vtedy, keď je vyvinutá testovateľná (niečo, čo je možné nezávisle otestovať) časť celej požiadavky, alebo keď je vyvinutá celá požiadavka.

top 10 špionážnych aplikácií pre Android

Dovoľte mi, aby som sa v tejto fáze podrobnejšie zameral a hovoril o dôležitých úlohách:

  • Tím pre testovanie / testovanie začína testovacím kolom (prieskumné testovanie a vykonávanie písomných testovacích prípadov) a zaznamenávaním chýb
  • Vývojový tím ich rieši podľa priority.
  • Nové zostavenie (kód) je prevzaté z prostredia, v ktorom prebieha testovanie
  • Vyriešené chyby potom overí tester / testovací tím a označia ich ako Opravené
  • Tento cyklus pokračuje až do dosiahnutia časových výstupných kritérií.
  • Upozorňujeme, že podľa potreby sú chyby tiež označené ako neplatné, duplikované a možno ich tiež kategorizovať ako vylepšenia.

Ďalšia vec, ktorá sa líši spoločnosť od spoločnosti, je počet testovacích kôl, ktoré je potrebné vykonať. Rovnako ako v niektorých prípadoch, prvé kolo testovania sa deje na malých súčastiach funkcií, keď sú pripravené, a po vývoji všetkých požiadaviek nasleduje kompletné testovacie kolo v inom prostredí. Ale znova som tiež počul o ľuďoch, ktorí robili tri správne úplné testovacie kolá a štvrté ako kolo zdravého rozumu / dymu.

Prvým programom, ktorý stojí za vykonaním viacerých kôl testovania, je testovanie funkčnosti v rôznych prostrediach a druhým programom je vykonávanie komplexného testovania, akonáhle sú vyvinuté všetky body príbehu. Rozum zdravého rozumu zvyčajne získa rýchlu dôveru, akonáhle sú všetky príbehy vo vydaní vyvinuté a testované nezávisle.

Prečítajte si podrobné kroky=> Fáza vykonania testu

# 7) Recenzia obchodného analytika (BA)

Obchodný analytik kontroluje požadované funkcie buď odkazom na výsledok testu, alebo odkazom na výsledok testu a hraním sa s aplikáciou, aby získal skutočný dojem. Tento krok je opäť predmetom rôznych krokov naprieč spoločnosťami.

BA môže preskúmať rozsah celého vydania naraz alebo naraz. V závislosti od toho istého môže tento krok nastať pred záverečným testom zdravého rozumu alebo po záverečnom kole testovania zdravého rozumu testovacím tímom.

Vyššie ako 7 krokov sa deje, aby boli splnené všetky užívateľské príbehy / požiadavky, najmä vydanie (zásielka). Po dokončení všetkých týchto krokov pre splnenie všetkých požiadaviek je vydanie údajne pripravené na odoslanie.

# 8) Zásielka / prepustenie

Toto vydanie je označené ako Pripravené na odoslanie po úspešnej kontrole vykonanej obchodným analytikom.

Odporúčané čítanie=> Testovací proces uvoľnenia

Typy manuálneho (čítaného človeka) testovania

No, ak sa máme baviť o celkových typoch testovania v číslach, tak niekde som to našiel 100 druhov testovania s rôznymi názvami . Úprimne povedané, nie som dosť chytrý na to, aby som pochopil rozdiel medzi všetkými týmito typmi (zamýšľaná hračka).

Je to priame a jednoduché: Ľudské úsilie a inteligencia otestujú funkčnosť aplikácie proti danej požiadavke. Ďalej sa delí na niekoľko typov podľa rozsahu a agendy testovania. Druhy uvedené v nasledujúcom ods.

Ďalej sa delí na niekoľko typov podľa rozsahu a agendy testovania. Druhy uvedené v nasledujúcom ods.

Ak to môžem, dovoľte mi povedať zopár riadkov ľudského testovania (ktoré odporúčam každému testerovi, aby vykonal iba manuálne funkčné testovanie). Teraz sa nenechajte zmiasť, podľa môjho názoru je manuálne funkčné testovanie podmnožinou ľudského testovania. Pretože existuje toľko vecí, ktoré dokáže iba ľudská myseľ.

Ďalej je uvedený zoznam niektorých populárnych a dôležitých typov testovania, ktoré je možné rozdeliť do kategórií na testovanie na ľuďoch:

  • Ručné funkčné testovanie : Ľudské úsilie a inteligencia otestujú funkčnosť aplikácie proti danej požiadavke. Ďalej sa delí na niekoľko typov podľa rozsahu a agendy testovania, ako je testovanie systému, testovanie jednotiek, testovanie dymu, testovanie zdravého rozumu, testovanie integrácie, regresné testovanie, testovanie používateľského rozhrania atď.
  • Testovanie výkonu : Toto bude kategorizované do kategórie Nefunkčné testovanie, nie? Ale opäť je to človek, ktorý to implementuje, aj keď popravu vykonáva človek alebo nástroj. Tester by mal robiť toto testovanie aspoň z hľadiska doby odozvy (aby zistil, či je to prijateľné), ak nemá používať žiadny nástroj na testovanie záťaže a podobne.
  • Prehliadač / Testovanie kompatibility platformy: Testovaná aplikácia by mala vyzerať a fungovať podľa očakávaní (samozrejme môže existovať malý rozdiel v závislosti od enginu prehľadávača) naprieč prehľadávačmi a platformami (alebo zariadeniami, ak ide o mobilnú aplikáciu).
  • Testovanie použiteľnosti : Najprv mi dovoľte súhlasiť s tým, že je to sama o sebe obrovská téma, ktorú zvyčajne vlastnia odborníci na testovanie použiteľnosti. Stále si myslím, že ako tester by sme mali aspoň oznámiť alebo zvýrazniť, ak zistíme, že je niečo menej použiteľné, alebo by sme sa mali podeliť o svoj názor.
  • Testovanie bezpečnosti : Opäť veľmi obrovský testovací typ a samozrejme vyžaduje veľa praktických znalostí. Tester by sa mal pokúsiť naučiť a vykonať aspoň základné testy, ako je neoprávnená manipulácia s URL, skriptovanie medzi webmi, vstrekovanie SQL, únos relácie atď., V závislosti od dostupných znalostí a všade, kde je to vhodné.
  • Testovanie viacerých nájomných zmlúv: Ak je vaša aplikácia multitenantom, t. J. Uchováva údaje jednej inštancie viacerých klientov, je toto testovanie nevyhnutnosťou. Toto by sa malo vykonať bez ohľadu na výslovné uvedenie v požiadavkách. Údaje jedného klienta, ktoré sa zobrazujú druhému, sú akýmsi vývojovým a testovacím zločinom.

Poznámka: Vyššie uvedené názory sú moje osobné názory. Tiež vám odporúčam pozrieť sa na rozsiahly zoznam typov testovania, aby ste ich ovládali, a podľa potreby ich sledovať / používať. V priebehu rokov som pochopil, že či už niečo používate alebo nie, v niečo veríte alebo nie, stále by ste mali mať vedomosti o široko používaných koncepciách vo vašom odbore.

To je pre túto časť všetko. Ďakujem za čítanie. Podeľte sa o svoje názory / spätnú väzbu v komentároch.

V ďalšej a poslednej časti tohto článku séria príručiek manuálneho testovania , Pokúsim sa vám všetkým pomôcť akú prípravu by ste mali robiť, ak sa chcete dostať do oblasti testovania a aké sú možné spôsoby, ako sa tam dostať.

Odporúčané čítanie

^