Problemi themelor i testimit

Hyrje

Mirë dita, anëtarë të Habr. Sapo isha duke zgjidhur një detyrë provuese për pozitën QA Lead për një kompani fintech. Detyra e parë, për të përgatitur një plan testi me një listë të plotë kontrolli dhe shembuj të rasteve të testimit për të verifikuar një çajnik elektrik, është lehtësisht e zgjidhshme:

Por pjesa e dytë rezultoi të ishte një pyetje: "A ka ndonjë probleme të zakonshme për të gjithë testuesit që pengojnë punën me efikasitet më të madh?".

E para që më erdhi në mendje: të renditja të gjitha problemet më të dukshme me të cilat jam përballur gjatë testimit, të filtroj detajet e vogla dhe të përgjithësoj të tjerat. Por shpejt kuptova se metoda induktive do të jepte një përgjigje që i përkiste jo "të gjithë", por, në rastin më të mirë, vetëm "më të shumtëve" të testuesve. Prandaj vendosa të qasem ndryshe, me metodë deduktive, dhe ja çfarë rezultoi.

Përkufizimet

E paraja që zakonisht bëj kur ballafaqohem me një detyrë të re është të përpiqem të kuptoj se për çfarë bëhet fjalë, dhe për këtë duhet të kuptoj domethënien e fjalëve me të cilat është formulur. Fjalët kyçe që duhet të kuptoj janë:

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

Le të shikojmë në Wikipedia dhe shëndoshësinë e mendjes:
Problemi (gjuhĂ« e lashtĂ« greke πρόÎČληΌα) nĂ« kuptim tĂ« gjerĂ« — njĂ« pyetje teorike ose praktike komplekse qĂ« kĂ«rkon studim dhe zgjidhje; nĂ« shkencĂ« — njĂ« situatĂ« kontradiktore, qĂ« shfaqet si pozita tĂ« kundĂ«rta nĂ« shpjegimin e disa dukurive, 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 çka, nuk di si», dmth dihet çfarĂ« duhet arritur, por nuk dihet se si tĂ« arrihet. Shprehja rrjedh nga latinishtja e vonĂ« problēma, prej greqishtes πρόÎČληΌα «e hedhur pĂ«rpara, e vendosur pĂ«rpara»; nga Ï€ÏÎżÎČÎŹÎ»Î»Ï‰ «hedh pĂ«rpara, ekspozon; akuzon».

Nuk ka shumĂ« kuptim, nĂ« thelb, “problemi” = “gjĂ« e çdo lloji qĂ« duhet tĂ« kuptohet”.
Testuesi — specialist (we won’t break it down further since we are interested in all testers) involved in testing a component or system, whose activity results in:
Tester’s work — a set of activities related to testing.
Effectiveness (Lat. effectivus) — the ratio between the achieved result and the resources used (ISO 9000:2015).
Result — the consequence of a sequence (series) of actions (outcome) or events, expressed qualitatively or quantitatively. Possible results include advantage, inconvenience, benefit, loss, value, and victory.
Just like with the 'problem,' it means little: something that was achieved as a result of work.
Burimi — a quantitatively measurable ability to perform some activity by an individual or individuals; conditions that allow achieving the desired result through certain transformations. A tester is a person, and according to the theory of vital resources, each person possesses four economic assets:
financial resources (income) — a renewable resource;
energy (life force) — a partially renewable resource;
koha — njĂ« burim i kufizuar dhe nĂ« thelb i pa-ripĂ«rtĂ«ritshĂ«m;
dijes (informacionit) — njĂ« burim i ripĂ«rtĂ«ritshĂ«m, pjesĂ« e kapitalit njerĂ«zor, qĂ« mund tĂ« rritet dhe shkatĂ«rrohet[1].

Dua tĂ« theksoj se pĂ«rcaktimi i efikasitetit nĂ« rastin tonĂ« nuk Ă«shtĂ« krejt i saktĂ«, pasi sa mĂ« shumĂ« dije tĂ« pĂ«rdorim, aq mĂ« e ulĂ«t Ă«shtĂ« efikasiteti. Prandaj do tĂ« pĂ«rcaktoja efikasitetin si "raporti ndĂ«rmjet rezultatit tĂ« arritur dhe burimeve tĂ« shpenzuara". KĂ«shtu çdo gjĂ« bĂ«het e saktĂ«: dijet gjatĂ« punĂ«s nuk shpenzohen, por zvogĂ«lojnĂ« shpenzimet e burimit tĂ« vetĂ«m qĂ« Ă«shtĂ« nĂ« thelb i pa-ripĂ«rtĂ«ritshĂ«m pĂ«r testuesin — kohĂ«n e tij.

Zgjidhja

Pra, kërkojmë problemet globale të testuesve që përkeqësojnë efikasitetin e punës së tyre.
Burimi më i rëndësishëm që shpenzohet për punën e testuesit është koha e tij (të tjerët në një farë mënyre mund të lidhen me të), dhe në mënyrë që të flasim për një llogaritje të saktë të efikasitetit, duhet të lidhet rezultati me kohën.
Për këtë, le të shqyrtojmë një sistem, në të cilin jetësinë e tij e siguron testuesi me punën e tij. Ky sistem është një projekt, në ekipin e të cilit përfshihet një testues. Jetëgjatësia e projektit mund të përshkruhet përafërsisht me algoritmin e mëposhtëm:

  1. Puna me kërkesat
  2. Formimi i specifikimeve teknike
  3. Zhvillimi
  4. Testimi
  5. Lëshimi në prodhim
  6. Mbeshtetje (shkoni në p.1)

Në të njëjtën kohë, i gjithë projekti mund të ndahet recursisht në nënprojekte (funksionalitete), me të njëjtën jetëgjatësi.
Nga këndvështrimi i projektit, efikasiteti i realizimit të tij është më i madh sa më pak kohë të harxhohet për të.
Prandaj, ne arrijmĂ« nĂ« pĂ«rk 정의jen e efikasitetit maksimal tĂ« mundshĂ«m tĂ« testuesit nga kĂ«ndvĂ«shtrimi i projektit — kjo Ă«shtĂ« njĂ« gjendje e projektit kur koha pĂ«r testim Ă«shtĂ« e barabartĂ« me zero. Dhe njĂ« problem i pĂ«rgjithshĂ«m pĂ«r tĂ« gjithĂ« testuesit Ă«shtĂ« pamundĂ«sia pĂ«r ta arritur kĂ«tĂ« kohĂ«.

ÇfarĂ« tĂ« bĂ«jmĂ« 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 të përfundojnë praktikisht njëherësh (këtë zakonisht e bën departamenti QA). Varianti ideal është kur të gjitha funksionalitetet që zhvillohen deri në përfundim janë mbuluar tashmë me teste të automatizuara, të organizuara në testim regresiv (dhe sa më shumë që të jetë e mundur, testim para-commit) me ndihmën e ndonjë CI.
  2. Sa mĂ« shumĂ« veçori tĂ« ketĂ« projekti (sa mĂ« i komplikuar tĂ« jetĂ«), aq mĂ« shumĂ« kohĂ« do tĂ« duhen pĂ«r tĂ« kontrolluar qĂ« funksionaliteti i ri nuk ka prishur atĂ« tĂ« vjetĂ«r. Prandaj, sa mĂ« i komplikuar tĂ« jetĂ« projekti — aq mĂ« shumĂ« automatizim kĂ«rkohet testimi regresiv.
  3. Çdo herĂ« qĂ« ne kalohem njĂ« gabim nĂ« prodhim dhe pĂ«rdoruesi e gjen atĂ«, na duhet tĂ« shpenzojmĂ« kohĂ« shtesĂ« pĂ«r tĂ« kaluar nĂ«pĂ«r ciklin e jetĂ«s sĂ« projektit duke filluar nga p.1 (Puna me kĂ«rkesat, nĂ« kĂ«tĂ« rast, tĂ« pĂ«rdoruesve). Duke qenĂ« se arsyet e kalimit tĂ« gabimit zakonisht nuk janĂ« tĂ« njohura, na mbetet vetĂ«m njĂ« rrugĂ« optimizimi — çdo gabim tĂ« gjetur nga pĂ«rdoruesit duhet tĂ« pĂ«rfshihet nĂ« testimin regresiv, nĂ« mĂ«nyrĂ« qĂ« tĂ« jemi tĂ« sigurt se ai nuk do tĂ« shfaqet mĂ«.

Burimi: habr.com

Bli njĂ« hosting tĂ« besueshĂ«m pĂ«r faqet me mbrojtje DDoS, VPS VDS serverĂ« đŸ”„ Bli njĂ« hosting tĂ« besueshĂ«m pĂ«r faqet me mbrojtje DDoS, VPS VDS serverĂ« | ProHoster