Uvod u rad na testiranju softvera
Što vam prvo pada na pamet kad razmišljate o poslu za testiranje softvera? Rad bez kodiranja? Ili zanimanje koje je vrlo lako jer vam pruža mogućnosti pronalaska pogrešaka u radu drugih (pronalaženje grešaka kada je svima nama najlakši zadatak)? Ili to smatrate profesijom koja se bavi provjerom ispravnosti proizvoda? Sve su ove misli točne i svakodnevne su aktivnosti za testiranje softverskog softvera. Međutim, testiranje softvera nije ograničeno samo na ove aktivnosti.
Razumijevanje aplikacije
Aplikacija bi mogla biti iz bilo koje domene - zdravstva, osiguranja, financija itd. Učenje domene aplikacija vrlo je važno za svaki softverski rad kako bi se tijekom testiranja aplikacije otvorila vrata razmišljanju iz različitih uglova i različitih korisničkih perspektiva. Otkrivanje i potvrđivanje očiglednih i ne tako očiglednih putova primjene uvijek je od svega ovo glavno očekivanje. Posjedovanje dubljeg znanja o aplikaciji pomaže u učinkovitoj validaciji proizvoda u isto vrijeme, ispitivač može postati prednost projektu u kojem se smatra jednim od osnovnih izvora znanja s obzirom na ponašanje proizvoda.
Iako je učenje domene i funkcionalnosti proces koji je u toku, bilo koji drugi važan faktor je znanje o procesu testiranja.
Proces ispitivanja
Proces testiranja može se razlikovati od tvrtke do tvrtke ili čak od jednog do drugog projekta. Danas imamo razne modele razvoja softvera poput V modela, Prototyping modela ili posve drugačiju metodologiju poput Agile pristupa razvoju softvera. S promjenom u razvojnom modelu, varira i pristup testiranja koji se treba pridržavati. Rad u V modelu imat će dobro definirane procese, dok se očekuje da se ovaj rad u agilnoj metodologiji testira u stalno promjenjivim uvjetima.
Posao još nije u redu s prihvatljivim poznavanjem domene i razumijevanjem procesa testiranja, sljedeći je izazov koji dolazi pred život učenje učenja raznih alata.
alat
Alati podrazumijevaju alate za upravljanje testovima, alate za greške u radu s greškama, alate za upravljanje bazama podataka i tako dalje.
S raznim softverom za bilježenje oštećenja, kvalitetom i alatima, nekim otvorenim kodom, a neki licenciranim, uvijek je prednost imati znanje o više alata. To mu pomaže da lako prelaze projekte ili timove slijedeći različite alate. Uz adekvatno poznavanje domene, procesa i alata, život u radu softverskog testera je veći što njegov radni dan čini izazovnim i uzbudljivim. Suradnja unutar timova jedan je od važnih čimbenika uspjeha bilo kojeg projekta, a za učinkovitu suradnju komunikacija ima vrlo važnu ulogu.
Preporučeni tečajevi
- Kompletan tečaj J2EE
- Obuka za programiranje na mreži R
- Idi na tečaj programiranja
- Obuka za online certificiranje u Haskell programu
Komunikacija
Komunikacija igra vrlo važnu ulogu u pogledu kvalitete softvera. Od početnih faza razvoja softvera, članovi tima za testiranje su uključeni (kao najbolja praksa) u raspravu o zahtjevima, ispitivanje poslovnih analitičara u slučaju bilo kakvih upita ili nedostataka u zahtjevu. Potrošač s učinkovitim komunikacijskim vještinama može učinkovito komunicirati o rizicima, može učinkovito komunicirati s razvojnim timom i može učinkovito komunicirati rezultate ispitivanja i izvješća o testiranju.
Planiranje radova testera softvera
Kao što naziv govori, planiranje ispitivanja je faza u kojoj se obavlja priprema za testiranje. Priprema za žičare uključivat će različite vrste aktivnosti koje žičar obavlja kako bi učinkovito primijenio aplikaciju. To će vam pomoći u potvrđivanju aplikacije i učinkovito otkrivanju nedostataka u aplikaciji. Da bi se započelo s planiranjem, testiranje prolazi kroz zahtjeve kako bi se razumjela očekivanja.
1. Zahtjevi
Zahtjevi bi mogli biti postavljeni ispitnom timu u obliku žičanih okvira, ploča s pričama, excel listova. Svrha svih ovih dokumenata je predstaviti zahtjeve klijenta na učinkovit i razumljiv način. Wireframe dokument nije ništa drugo nego dokument koji može biti u obliku PowerPoint prezentacije koji prikazuje zahtjeve klijenta. Na istim linijama ploče s pričama obično prikazuju potrebni izgled / dizajn ekrana. Danas su na tržištu dostupni razni alati koji se mogu koristiti za pripremu potrebnih dokumenata. Izrada potrebnih dokumenata glavna je odgovornost poslovnog analitičara. Očekuje se da degustacija temeljno razumije zahtjeve. Kako bi teste i programeri pravilno razumjeli zahtjeve, poslovni analitičari drže forum otvoren za sve da odgovore i odgovore na bilo koji od zahtjeva. Platforma za raspravu i komunikaciju o otvorenim pitanjima i upitima varira od projekta do projekta. To bi mogao biti lanac e-poruka ili konferencijski poziv ili čak zajedničko pogon diska koji se održava kako bi se pratila sva otvorena pitanja i njihovi odgovori pruženi od strane poslovnog analitičara.
Jasno Komunikacija i zapis komunikacije igraju vrlo važnu ulogu kao dokaz. Mala pretpostavka u zahtjevu ponekad može dovesti do većih oštećenja proizvoda. U svakoj se fazi preporučuje ispitivač kvalitete softvera da bi komunikacija bila čista. Softver Tester Radna komunikacija može biti s poslovnim analitičarima ili čak u timu. Jasna komunikacija pomaže u uklanjanju pretpostavki tijekom planiranja i provođenja. Istovremeno se preporučuje voditi evidenciju o komunikaciji (po mogućnosti komunikaciji putem e-pošte). Pisanje komunikacije o upitima o zahtjevima pomaže u kasnijim fazama izvođenja testa u kojima funkcionalnost možda nije razvijena kako je potvrđeno u snimljenoj komunikaciji.
2. Scenarij
Nakon što se zahtjevi razumiju, ispitivač započinje dokumentiranje scenarija u dokumentu Test Scenario. Scenarij kao što ime sugerira je tijek funkcionalnosti koji korisnik slijedi kako bi ispunio zadatak.
Primjeri scenarija -
- Korisnik bi se trebao moći uspješno prijaviti.
- Korisnik treba biti u mogućnosti rezervirati ulaznice u sustavu.
- Korisnik bi trebao moći otkazati karte u sustavu.
- Korisnik bi trebao biti u mogućnosti pregledavati / ažurirati detalje o profilu.
Ovo su logični zadaci koje korisnik izvršava u sustavu. Ovi logički zadaci združeni zajedno pomažu da se zabilježe svi mogući scenariji koje se očekuje od korisnika. Ovi scenariji se obično dokumentiraju u Excel listovima ili se ponekad koriste neki alati. Dokaz se trudi izvući sve takve scenarije iz dokumenata o zahtjevu. Dokument koji sadrži takve scenarije naziva se Test Scenario Document (ili negdje kao Document Scenario High-Level). Ovaj dokument služi kao ulazni dokument za izradu testnih slučajeva.
3. Slučaj
Ovaj je slučaj detaljnija verzija radnog scenarija softvera Tester u kojem se scenarij raščlanjuje na detaljnije korake koje će korisnik zaista izvoditi dok koristi aplikaciju. Jednostavni primjer temeljen na gore navedenim scenarijima je:
Scenarij - Korisnik se treba moći uspješno prijaviti.
Slučajevi ispitivanja:
- Provjerite može li korisnik upisati ispravno korisničko ime.
- Provjerite je li korisnik sposoban unijeti zaporku.
- Kada kliknete gumb za prijavu nakon unosa ispravnog korisničkog imena i lozinke, potvrdite da se korisnik može uspješno prijaviti.
Takav popis ovih slučajeva može uključiti provjeru valjanosti za svako polje, provjeriti negativne scenarije i tako dalje.
Ispod je nekoliko dodatnih primjera ovih slučajeva -
- Provjerite da korisničko ime kad nije uneseno, sustav izbacuje odgovarajuću pogrešku.
- Provjerite da lozinka kad nije unesena, sustav izbacuje odgovarajuću pogrešku.
- Provjerite da korisničko ime i zaporka kada nisu uneseni, sustav izbacuje odgovarajuću pogrešku.
- Provjerite da sustav unosi pogrešnu lozinku i šalje odgovarajuću poruku o pogrešci.
- Provjerite da sustav unosi pogrešno korisničko ime i šalje odgovarajuću poruku o pogrešci.
4. Matrica sljedivosti zahtjeva (RTM)
Matrica sljedivosti zahtjeva, kao što ime sugerira, pomaže dokazati provjeru i uključiti pokrivenost zahtjeva koje pruža Business u testne dokumente poput scenarija i testnih slučajeva.
Kao najbolja praksa, ovo je zasebni dokument koji prikazuje preslikavanje broja zahtjeva s onim scenarijem / slučajevima koji uključuju taj zahtjev.
Ovaj se dokument ne može koristiti na svim vrstama projekata, ali kad se koristi, na snažan način pomaže u pronalaženju scenarija visoke razine koji preslikavaju zahtjeve. Ukazuje na pokrivenost i može se koristiti za provjeru prisutnosti barem jednog slučaja protiv svakog zahtjeva. Stvaranje i održavanje RTM dokumenta smatra se najboljom praksom, no nisu sve vrste projekata (poput Agile) korištenje softvera dokazuju radni dokument. Kada se zahtjevi vrlo često mijenjaju, održavanje ovog dokumenta moglo bi se čuti. Kako bi se izbjeglo ovo pokriće i istovremeno imalo načina da se prate zahtjevi, neki projekti uključuju dio sljedivosti u radni slučaj softvera Tester ili u njegov dokument sa scenarijem.
Važan aspekt je pronaći način za praćenje scenarija / slučajeva prema zahtjevima i obrnuto. Dobro dokumentirani zahtjevi za Prover olakšavaju izradu i održavanje tih dokumenata. Dvosmisleni zahtjevi, stalno mijenjajući zahtjevi čine životni vijek napornijim i mogu dovesti do nedosljednih dokumenata koji se mogu isporučiti, što rezultira nedostatkom provjere valjanosti, a time i nedostatkom u krajnjem proizvodu.
Putovanje dosad za ispitivača je planiralo i pripremalo se za testiranje. Kako je priprema za rat dio rata, ovdje se isto odnosi. Što su ti dokumenti izrađeni koncizniji, lakši je dokazima da potvrde funkcionalnost i otkriju gotovo sve nedostatke. Sljedeća faza putovanja ispitivača je Izvršenje.
Izvođenje softverskog testera radi
Ovo je faza u kojoj se svi gore navedeni dokumenti stavljaju u uporabu. Za stvaranje scenarija korišteni su zahtjevi, a za izradu scenarija korišten je Scenario. ovaj dokument slučaja ovdje je dokument koji nije dovoljan za početak provjere zahtjeva. Prover započinje provjeru aplikacije izvršavanjem koraka iz ovog dokumenta slučaja. Za potvrđivanje jednog scenarija može se upotrijebiti više slučajeva ili čak jedan testni slučaj može odgovarati jednom scenariju ispitivanja. Sve ovisi o složenosti scenarija ili ponekad standardu koji slijedi u ispitnom timu. Dakle, jedan dokument testnog slučaja može sadržavati 20-50 ispitnih slučajeva ili može imati 100-120 test slučajeva. Ovi su brojevi samo u svrhu objašnjenja, a mogu se jako razlikovati od projekta do projekta. Ishod ove faze su testni nedostaci. Broj valjanih oštećenja dobivenih u ovoj fazi daje dobru predstavu o stabilnosti primjene, kvaliteti ispitivanja, kvaliteti izrade i mnogim takvim čimbenicima koji izravno utječu na proizvod. Ova faza je najvažnija faza jer ispitivač uspijeva pokriti sve ispitne slučajeve (potvrđivanje gotovo svih potrebnih korisničkih staza) i istodobno stvoriti što više valjanih nedostataka. Sve pripreme, komunikacijske vještine, upiti koji se traže od tvrtke dolaze da djeluju u ovoj fazi testiranja.
Kvar softvera ispitivač radi
Za vrijeme izvođenja ovog slučaja, svako ponašanje koje nije jednako očekivanom rezultatu postavlja se kao defekt. Svaki testni slučaj sadrži Opis, Očekivani rezultat i stupac Stvarni rezultat. Dok se u ovom dokumentu o radu softvera za ispitivanje softvera planira opisati i očekivati rezultate i prazan stupac za stvarne rezultate. Tijekom izvođenja testnih slučajeva, ispitivač je trebao popuniti stupac stvarnih rezultata. Istovremeno, ako stvarna vrijednost nije jednaka očekivanom rezultatu, kvar se bilježi. Kvar greške jednostavno ne znači informiranje razvojnog programera o problemu. To je opet formalni postupak koji se obično izvodi uz pomoć alata. Trenutno na tržištu postoje razni alati, neki otvorenog koda, a neki licencirani. Svaki alat za evidentiranje oštećenja ima sljedeće polje -
- Naziv projekta / izdanja
- Sažetak defekta
- Opis detalja o defektu
- Oštećena ozbiljnost
- Prioritet defekta
- Faza je pronađena
- Dodijeljena
- Prilozi
Kao što možemo vidjeti, svrha svih ovih polja je da se pronađe formalni postupak koji sadrži mudre detalje. To pomaže programerima da reproduciraju kvar u svom okruženju i da ga riješe. Ispod je kratak opis svih ovih polja -
- Naziv projekta / izdanja - Naziv izdanja na kojem je utvrđen kvar, projekt obično ima više izdanja i isti projekt može imati više podprojekata. Ovo polje pomaže u pokretanju problema za određeno izdanje.
- Sažetak defekta - kratak opis pronađenog nedostatka u jednom sloju.
- Opis detalja o defektu - Ovo je detaljan opis oštećenja, trebao bi sadržavati detalje poput okruženja u kojem je kvar pronađen, i korišteni testni podaci, stvarni rezultati očekivani rezultat i sve dodatne informacije koje dionicima dodaju više vrijednosti za razumijevanje mana.
- Ozbiljnost defekta - označava koliko je oštećenje ozbiljno. Obično ima vrijednosti slične kritičnim, visokim, srednjim, niskim ili numeričkim vrijednostima poput 4, 3, 2, 1.
- Prioritet defekta - označava koliko je potrebno hitno popraviti kvar.
- Faza je pronađena - Kako postoje mnoge faze kada se kvar može zabilježiti, faza ispitivanja jedinice, SIT (ispitivanje integracije sustava), UAT (testiranje prihvaćanja korisnika) ili čak faza proizvodnje.
- Dodijeljeno - Naziv programera ili razvojnog vodiča.
- Prilozi - ovo je ispitivaču dalo mogućnost da priloži snimku zaslona na kojoj je naišao problem.
Izvršenje testa i evidentiranje oštećenja faza je faza s kojom se tester može suočiti. Neki od njih učinkovito komuniciraju s programerima. Možemo li tvrditi da je kvar greške sa svim potrebnim informacijama koji nisu dovoljni da programeri razumiju kvar?
U nekim slučajevima to zahtijeva dodatno objašnjenje / raspravu s programerima. Postoje slučajevi gdje ispitivač naiđe na neočekivano ponašanje za koje možda nije siguran je li kvar. S ovim se okolnostima obično suočavaju oni koji su novi u timu, koji imaju ograničeno znanje o domenu ili imaju dvosmislenost u pogledu zahtjeva. Pa, ovdje ne treba kriviti testera ako postoje kratki rokovi i postoje zahtjevi koji se stalno mijenjaju i u većini slučajeva dokazuju domenu dok zapravo planiraju i izvršavaju testne slučajeve. Kao što vidimo, put testera nije lak kao što se percipira. To zahtijeva ikad učenje stav, dobre komunikacijske vještine, dobre suradničke vještine i spremnost da se prilagodite uvjetima u kojima se mijenjaju domene, alati, procesi koji se koriste. Dok smo razgovarali o putovanju ručnih testera, cjelokupni postupak odnosi se i na testere za automatizaciju. S druge strane, automatizacija ima značajne promjene u procesu jer se opseg testiranja i planiranja, izvršavanje znatno razlikuje.
Uzimajući u obzir putokaz dolje navedenog gore, možemo li ipak reći da je posao kvalitete ispitivača softvera lakši nego kod proizvođača programera?
Može se reći da će biti korisnije voditi raspravu o tome kako suradnja dvaju ljudi može dovesti do velikog uspjeha proizvoda kao cjeline više nego uspoređivanje uloga programera tester v / s. Ponekad zaboravljamo da je posao testera da pronađe probleme u aplikaciji, a ne da ukazuje na greške programera. Kad zaboravimo na samu ideju svog posla, to ponekad vodi do nepotrebne rasprave. Međutim, primijećeno je da postoje podjednako dobri testiranje, razvojni timovi u kojima svi razumiju da je krajnja svrha da aplikacija funkcionira onako kako se i očekivalo. Nadajmo se da će svi gledati na pozitivnu stranu posla testiranja kao na ulogu koja pomaže u čišćenju proizvoda, a ne kao onu koja upravo otkriva pogreške!
Preporučeni članci
Ovo je vodič za otkrivanje i potvrđivanje očiglednih i ne tako očitih putova primjene uvijek primarno očekivanje rada testa softvera. Ovo su sljedeće vanjske poveznice vezane uz rad testera softvera.
- Neispravan životni ciklus u testiranju softvera
- 6 najneverovatnijih pitanja o ispitivanju intervjua za softver
- Karijere u testiranju softvera