Fundamentalni problem testiranja

Uvod

Dobar dan, stanovnici Habrovska. Upravo sam rješavao testni zadatak za QA Lead konkurs za fintech kompaniju. Prvi zadatak, kreiranje plana testiranja s kompletnom kontrolnom listom i primjerima test slučajeva za testiranje električnog kuhala, može se riješiti trivijalno:

• GOST 7400-81. Kuhala za vodu i električni samovari. Specifikacije (sa amandmanima br. 1-8)
• GOST IEC 60335-1-2015 Kućanski i slični električni aparati. Sigurnost. Dio 1. Opšti zahtjevi
  Teško je smisliti bolji plan testiranja s kompletnom kontrolnom listom.

Ali ispostavilo se da je drugi dio bio pitanje: "Postoje li neki problemi zajednički svim testerima koji ih sprečavaju da rade efikasnije?"

Prvo što mi je palo na pamet bilo je da navedem sve manje-više uočljive probleme na koje sam naišao tokom testiranja, izbacim male stvari i sumiram ostalo. Ali brzo sam shvatio da će induktivna metoda odgovoriti na pitanje koje se ne odnosi na "sve", već, u najboljem slučaju, samo na "većinu" testera. Stoga sam odlučio da pristupim s druge strane, deduktivno, i evo šta se dogodilo.

Definicije

Prva stvar koju obično radim kada rješavam novi problem je da pokušam razumjeti o čemu se radi, a da bih to učinio moram razumjeti značenje riječi koje ga postavljaju. Ključne riječi koje treba razumjeti su sljedeće:

• problem
• tester
• tester posao
• efikasnost testera

Okrenimo se Wikipediji i zdravom razumu:
Problem (starogrčki πρόβλημα) u širem smislu – složeno teorijsko ili praktično pitanje koje zahtijeva proučavanje i rješavanje; u nauci - kontradiktorna situacija koja se pojavljuje u obliku suprotstavljenih pozicija u objašnjenju bilo koje pojave, predmeta, procesa i zahtijeva adekvatnu teoriju da bi je riješila; u životu se problem formuliše u formi koja je ljudima razumljiva: „znam šta, ne znam kako“, odnosno zna se šta treba dobiti, ali se ne zna kako to učiniti . Dolazi od kasno. lat. problem, sa grčkog. πρόβλημα „bačen napred, postavljen ispred”; od προβάλλω „baciti napred, staviti ispred sebe; kriv".

Zapravo nema puno smisla, "problem" = "bilo šta sa čim se treba pozabaviti."
Tester - specijalista (nećemo se deliti na tipove, pošto smo zainteresovani za sve testere) koji učestvuje u testiranju komponente ili sistema, čiji je rezultat:
Rad testera — skup aktivnosti u vezi sa testiranjem.
Efikasnost (lat. effectivus) - odnos između postignutog rezultata i upotrijebljenih resursa (ISO 9000: 2015).
Rezultat - posljedica lanca (niza) radnji (rezultata) ili događaja, izraženih kvalitativno ili kvantitativno. Mogući ishodi uključuju prednost, nedostatak, dobitak, gubitak, vrijednost i pobjedu.
Kao i kod „problema“, tu je malo značenja: nešto što se pojavilo kao rezultat rada.
resurs - kvantitativno mjerljiva mogućnost obavljanja bilo koje djelatnosti osobe ili ljudi; uvjeti koji omogućavaju korištenje određenih transformacija za postizanje željenog rezultata. Tester je osoba, a u skladu sa teorijom vitalnih resursa, svaka osoba je vlasnik četiri ekonomska dobra:
gotovina (dohodak) je obnovljivi resurs;
energija (životna snaga) je djelimično obnovljiv resurs;
vrijeme je fiksni i u osnovi neobnovljivi resurs;
znanje (informacije) je obnovljiv resurs, dio je ljudskog kapitala koji može rasti i biti uništen[1].

Napominjem da definicija efikasnosti u našem slučaju nije sasvim tačna, jer što više znanja koristimo, to je efikasnost manja. Stoga bih efikasnost redefinirao kao „odnos između postignutih rezultata i utrošenih resursa“. Onda je sve ispravno: znanje se ne gubi tokom rada, ali smanjuje troškove jedinog suštinski neobnovljivog resursa testera - njegovog vremena.

odluka

Dakle, tražimo globalne probleme testera koji narušavaju efikasnost njihovog rada.
Najznačajniji resurs koji se troši na rad testera je njegovo vrijeme (ostatak se može svesti na to na ovaj ili onaj način), a da bismo mogli govoriti o ispravnom proračunu efikasnosti, rezultat se mora svesti i na vrijeme .
Da biste to učinili, razmotrite sistem čiju održivost tester osigurava svojim radom. Takav sistem je projekat čiji tim uključuje tester. Životni ciklus projekta može se grubo predstaviti sljedećim algoritmom:

1. Rad sa zahtjevima
2. Formiranje tehničkih specifikacija
3. Razvoj
4. Testiranje
5. Puštanje u proizvodnju
6. Podrška (idite na stavku 1)

U ovom slučaju, cijeli projekat se može rekurzivno podijeliti na podprojekte (obilježja), sa istim životnim ciklusom.
Sa stanovišta projekta, što je manje vremena utrošeno na njega, to je njegova implementacija efikasnija.
Tako dolazimo do definicije maksimalne moguće efikasnosti testera sa stanovišta projekta - to je stanje projekta kada je vreme za testiranje nula. Uobičajeni problem za sve testere je nemogućnost dostizanja ovog vremena.

Kako se nositi s ovim?

Zaključci su prilično očigledni i mnogi ih koriste već duže vrijeme:

1. Razvoj i testiranje bi trebali početi i završiti gotovo istovremeno (ovo obično radi odjel QA). Idealna opcija je kada je sva funkcionalnost koja se razvija već pokrivena autotestovima do trenutka kada je spremna, organizirana u regresijsko (i, ako je moguće, pre-urezivanje) testiranje koristeći neku vrstu CI.
2. Što više funkcija ima projekat (što je složeniji), to će više vremena morati da se potroši na proveru da nova funkcionalnost ne naruši staru. Dakle, što je projekat složeniji, potrebno je više automatizacije regresijsko testiranje.
3. Svaki put kada propustimo grešku u produkciji i korisnik je pronađe, moramo potrošiti dodatno vrijeme prolazeći kroz životni ciklus projekta počevši od tačke 1 (Rad sa zahtjevima, u ovom slučaju, korisnicima). Pošto su razlozi za propuštanje greške uglavnom nepoznati, ostaje nam samo jedan put optimizacije - svaka greška koju pronađu korisnici mora biti uključena u regresijsko testiranje kako bismo bili sigurni da se više neće pojaviti.

izvor: www.habr.com