Problemi themelor i testimit

Hyrje

Përshëndetje, banorët e Habra. Po zgjidhja këtu së fundmi një detyrë testimi për një pozitë QA Lead për një kompani fintech. Detyra e parë, për të hartuar një plan testimi me një listë të plotë kontrolli dhe shembuj testesh për kontrollin e një çajniku elektrik, zgjidhet thjesht:

Por pjesa e dytĂ« u shfaq si njĂ« pyetje: “A ekzistojnĂ« ndonjĂ« problem, tĂ« pĂ«rbashkĂ«t pĂ«r tĂ« gjithĂ« testuesit, qĂ« pengojnĂ« punĂ«n me efikasitet mĂ« tĂ« madh?”.

E para qĂ« mĂ« erdhi nĂ« mendje: tĂ« pĂ«rmendja tĂ« gjitha problemet mĂ« tĂ« dukshme, me tĂ« cilat kam hasur gjatĂ« testimit, tĂ« ndaheshin mĂ« tĂ« voglat, dhe tĂ« pĂ«rgjithĂ«sohej e gjithĂ« pjesa tjetĂ«r. Por shpejt e kuptova se metoda induktive do t’i pĂ«rgjigjej njĂ« pyetjeje qĂ« nuk i pĂ«rkiste “tĂ« gjithĂ«â€, por, nĂ« mĂ« tĂ« mirĂ«n e rasteve, vetĂ«m “shumicĂ«s” sĂ« testuesve. Prandaj vendosa t’i qasem nga njĂ« tjetĂ«r kĂ«nd, deduktivisht, dhe ja çfarĂ« kam arritur.

Përcaktimet

E para që bëj zakonisht kur zgjidh një detyrë të re, është të përpiqem të kuptoj për çfarë është, dhe për këtë duhet të kuptoj kuptimin e fjalëve me të cilat është formuluar. Fjalët kyçe, në të cilat duhet të merrem, janë si më poshtë:

  • problemi
  • testues
  • puna e testuesit
  • efikasiteti i punĂ«s sĂ« testuesit

Të kthehemi te Wikipedia dhe shëndeti i arsyeshëm:
Problem (grek. πρόÎČληΌα) nĂ« njĂ« kuptim tĂ« gjerĂ« - Ă«shtĂ« njĂ« çështje e komplikuar teorike ose praktike, qĂ« kĂ«rkon studim, zgjidhje; nĂ« shkencĂ« - njĂ« situatĂ« e kundĂ«rthĂ«nĂ«se, qĂ« paraqitet nĂ« formĂ«n e pozita tĂ« kundĂ«rta nĂ« shpjegimin e disa fenomeneve, objekteve, proceseve dhe qĂ« kĂ«rkon njĂ« teori adekuate pĂ«r zgjidhjen e saj; nĂ« jetĂ«, problemi formulohet nĂ« njĂ« mĂ«nyrĂ« tĂ« kuptueshme pĂ«r njerĂ«zit si "e di çfarĂ«, nuk e di si", qĂ« do tĂ« thotĂ« se Ă«shtĂ« e njohur se çfarĂ« duhet fituar, por nuk e di si ta bĂ«sh atĂ«. E pakĂ«suar nga latinishtja e vonĂ«, problēma, nga greqishtja πρόÎČληΌα "e hedhur pĂ«rpara, e vendosur pĂ«rpara"; nga Ï€ÏÎżÎČÎŹÎ»Î»Ï‰ "hedh pĂ«rpara, paraqes para vetes; akuzoj".

Nuk ka shumë kuptim, në esencë, "problemi" = "çdo gjë që duhet të zgjidhet".
Testues — specialist (we won't divide into types, since we're interested in all testers) participating in the testing of a component or system, whose activity results in:
Tester Work — a set of activities related to testing.
Effectiveness (from Latin effectivus) — the ratio between the achieved result and the resources used (ISO 9000:2015).
Result — the consequence of a chain (series) of actions (outcome) or events, expressed qualitatively or quantitatively. Possible results include advantage, inconvenience, benefit, loss, value, and victory.
As with the "problem," the meaning is little: something that resulted from the work.
Burimi — a quantitatively measurable capability to perform some activity by a person or people; conditions that allow achieving a desired result through certain transformations. The tester is a person, and according to the theory of vital resources, each person owns four economic assets:
financial resources (income) — renewable resource;
energy (life force) — partially renewable resource;
time — fixed resource and fundamentally non-renewable;
knowledge (information) — renewable resource, part of human capital that can grow or diminish[1].

I want to note that the definition of effectiveness in our case is not entirely correct, since the more knowledge we use, the lower the effectiveness turns out. Therefore, I would redefine effectiveness as "the ratio between the achieved result and the resources expended." Then everything is correct: knowledge is not spent in work but reduces the expenditure of the only fundamentally non-renewable resource of the tester — their time.

Zgjidhja

So, we are looking for global problems of testers that worsen their work effectiveness.
The most significant resource that is spent on the tester's work is their time (the others can be related to it), and for us to talk about a correct calculation of effectiveness, we need to relate the result to time.
Për këtë, let's shqyrtojmë një sistem, qëndrueshmëria e të cilit sigurohet nga puna e testuesit. Një sistem i tillë është projekti, në ekipin e të cilit bën pjesë një testues. Cikli jetësor i projektit mund të përshkruhet përafërsisht me algoritmin e mëposhtëm:

  1. Punimi me kërkesat
  2. Formimi i detyrës teknike
  3. Zhvillimi
  4. Testimi
  5. Lançimi në prodhim
  6. Mbështetje (shkoni te p.1)

Në të njëjtën kohë, e gjithë projekti mund të ndahet në mënyrë rekursive në nënprojekte (funksione) me të njëjtin cikël jetësor.
Nga këndvështrimi i projektit, efikasiteti i realizimit të tij është aq më i madh sa më pak kohë shpenzohet për të.
KĂ«shtu, arrijmĂ« nĂ« definimin e efikasitetit maksimal tĂ« mundshĂ«m tĂ« testuesit nga kĂ«ndvĂ«shtrimi i projektit — Ă«shtĂ« njĂ« gjendje e projektit kur koha pĂ«r testim Ă«shtĂ« e barabartĂ« me zero. NjĂ« problem i pĂ«rbashkĂ«t pĂ«r tĂ« gjithĂ« testuesit Ă«shtĂ« pamundĂ«sia pĂ«r tĂ« arritur kĂ«tĂ« kohĂ«.

Si të veprojmë me këtë?

Përfundimet janë mjaft të qarta dhe shumë prej tyre përdoren prej kohësh:

  1. Zhvillimi dhe testimi duhet të fillojnë dhe përfundojnë praktikisht në të njëjtën kohë (këtë zakonisht e bën departamenti QA). Opcioni ideal është kur të gjithë funksionalitetet e zhvilluara, në momentin e gatishmërisë, janë mbuluar tashmë nga testet automatike, të organizuara në testimin regresiv (dhe, sa më shumë që është e mundur, testimin para-komit) me ndihmën e ndonjë CI.
  2. Sa mĂ« shumĂ« funksione tĂ« ketĂ« projekti (sa mĂ« i ndĂ«rlikuar tĂ« jetĂ« ai), aq mĂ« shumĂ« kohĂ« do tĂ« duhet pĂ«r tĂ« kontrolluar qĂ« funksionaliteti i ri nuk ka prishur atĂ« tĂ« vjetrin. Prandaj, sa mĂ« kompleks tĂ« jetĂ« projekti — aq mĂ« shumĂ« automatizim kĂ«rkohet pĂ«r testimin regresiv.
  3. Çdo herĂ« qĂ« ne lĂ«shojmĂ« njĂ« defekt nĂ« prodhim dhe pĂ«rdoruesi e gjen atĂ«, na duhet tĂ« shpenzojmĂ« kohĂ« shtesĂ« pĂ«r tĂ« kaluar nĂ«pĂ«r ciklin jetĂ«sor tĂ« projektit duke filluar nga p.1 (Punimi me kĂ«rkesat, nĂ« kĂ«tĂ« rast, tĂ« pĂ«rdoruesve). Duke qenĂ« se arsyet e kalimit tĂ« defektit nĂ« pĂ«rgjithĂ«si janĂ« tĂ« panjohura, mbetet vetĂ«m njĂ« rrugĂ« optimizimi — çdo defekt tĂ« gjetur nga pĂ«rdoruesit duhet tĂ« pĂ«rfshihet nĂ« testimin regresiv, pĂ«r tĂ« qenĂ« tĂ« sigurt se mĂ« shpejt do tĂ« shfaqet pĂ«rsĂ«ri.

Burimi: habr.com

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster