Introducere
Bună ziua, locuitori din Khabrovsk. Tocmai acum rezolvam o sarcină de testare pentru un post vacant de lider QA pentru o companie fintech. Prima sarcină, de a crea un plan de testare cu o listă de verificare completă și exemple de cazuri de testare pentru testarea unui fierbător electric, poate fi rezolvată trivial:
Este greu să te gândești la un plan de testare mai bun cu o listă de verificare completă.
Dar a doua parte s-a dovedit a fi o întrebare: „Există probleme comune tuturor testerilor care îi împiedică să lucreze mai eficient?”
Primul lucru care mi-a venit în minte a fost să enumerez toate problemele mai mult sau mai puțin vizibile pe care le-am întâlnit în timpul testării, să îndepărtez lucrurile mărunte și să rezumam restul. Dar mi-am dat repede seama că metoda inductivă va răspunde la o întrebare care nu se aplica pentru „toți”, ci, în cel mai bun caz, doar pentru „majoritatea” testatorilor. Prin urmare, am decis să o abordez din cealaltă parte, deductiv, și așa s-a întâmplat.
defini
Primul lucru pe care îl fac de obicei atunci când rezolv o problemă nouă este să încerc să înțeleg despre ce este vorba și pentru a face acest lucru trebuie să înțeleg sensul cuvintelor care o pun. Cuvintele cheie de înțeles sunt următoarele:
- problemă
- tester
- job de tester
- eficiența testerului
Să ne întoarcem la Wikipedia și bunul simț:
(greaca veche πρόβλημα) în sens larg - o problemă teoretică sau practică complexă care necesită studiu și rezolvare; în știință - situație contradictorie care apare sub forma unor poziții opuse în explicarea oricăror fenomene, obiecte, procese și necesită o teorie adecvată pentru a o rezolva; în viață, problema este formulată într-o formă care este pe înțelesul oamenilor: „Știu ce, nu știu cum”, adică se știe ce trebuie obținut, dar nu se știe cum se face. . Vine de târziu. lat. problema, din greaca. πρόβλημα „aruncat înainte, pus în față”; din προβάλλω „aruncă înainte, pune în fața ta; vina”.
Nu prea are sens, de fapt, „problemă” = „orice lucru cu care trebuie rezolvat”.
- un specialist (nu vom împărți în tipuri, deoarece suntem interesați de toți testerii) care participă la testarea unei componente sau a unui sistem, al cărui rezultat este:
— un set de activități legate de testare.
(lat. effectivus) - relația dintre rezultatul obținut și resursele utilizate (: 2015).
- o consecință a unui lanț (serii) de acțiuni (rezultat) sau evenimente, exprimate calitativ sau cantitativ. Rezultatele posibile includ avantajul, dezavantajul, câștigul, pierderea, valoarea și victoria.
Ca și în cazul „problemei”, există puțin sens: ceva care a ieșit ca rezultat al muncii.
- posibilitatea măsurabilă cantitativ de a desfășura orice activitate a unei persoane sau a unor persoane; condiţii care permit utilizarea anumitor transformări pentru a obţine rezultatul dorit. Testerul este o persoană și, în conformitate cu teoria resurselor vitale, fiecare persoană este proprietarul a patru active economice:
numerarul (venitul) este o resursă regenerabilă;
energia (forța vitală) este o resursă parțial regenerabilă;
timpul este o resursă fixă și fundamental neregenerabilă;
cunoașterea (informația) este o resursă regenerabilă, face parte din capitalul uman care poate crește și poate fi distrus.
Aș dori să remarc că definiția eficienței în cazul nostru nu este în întregime corectă, deoarece cu cât folosim mai multe cunoștințe, cu atât eficiența este mai mică. Prin urmare, aș redefini eficiența ca „raportul dintre rezultatele obținute și resursele cheltuite”. Atunci totul este corect: cunoștințele nu sunt irosite în timpul lucrului, dar reduc costurile singurei resurse fundamental neregenerabile a testerului - timpul său.
decizie
Așadar, căutăm probleme globale ale testerilor care afectează eficiența muncii lor.
Cea mai semnificativă resursă pe care o cheltuiește pe munca unui tester este timpul acestuia (restul poate fi redus la el într-un fel sau altul), iar pentru a putea vorbi despre calculul corect al eficienței, rezultatul trebuie redus și la timp. .
Pentru a face acest lucru, luați în considerare un sistem a cărui viabilitate o asigură testatorul prin munca sa. Un astfel de sistem este un proiect a cărui echipă include un tester. Ciclul de viață al proiectului poate fi reprezentat aproximativ de următorul algoritm:
- Lucrul cu cerințe
- Formarea specificațiilor tehnice
- desen
- Testarea
- Lansare în producție
- Asistență (treceți la articolul 1)
În acest caz, întregul proiect poate fi împărțit recursiv în subproiecte (funcții), cu același ciclu de viață.
Din punct de vedere al proiectului, cu cât este mai puțin timp petrecut cu el, cu atât implementarea lui este mai eficientă.
Astfel, ajungem la definirea eficienței maxime posibile a unui tester din punctul de vedere al proiectului - aceasta este starea proiectului când timpul de testare este zero. O problemă comună pentru toți testerii este incapacitatea de a atinge acest timp.
Cum să te descurci cu asta?
Concluziile sunt destul de evidente și au fost folosite de mulți de mult timp:
- Dezvoltarea și testarea ar trebui să înceapă și să se termine aproape simultan (de obicei, acest lucru este făcut de departament ). Opțiunea ideală este atunci când toată funcționalitatea dezvoltată este deja acoperită de autotestări până la momentul în care este gata, organizată în teste de regresie (și, dacă este posibil, pre-commit) folosind un fel de .
- Cu cât un proiect are mai multe caracteristici (cu atât este mai complex), cu atât va trebui să se aloce mai mult timp verificând că noua funcționalitate nu o rupe pe cea veche. Prin urmare, cu cât proiectul este mai complex, cu atât este nevoie de mai multă automatizare .
- De fiecare dată când ratăm un bug în producție și un utilizator îl găsește, trebuie să petrecem timp suplimentar parcurgând ciclul de viață al proiectului începând de la punctul 1 (Lucrul cu cerințele, în acest caz, utilizatorii). Deoarece motivele lipsei unei erori sunt în general necunoscute, ne rămâne cu o singură cale de optimizare - fiecare eroare găsită de utilizatori trebuie inclusă în testarea de regresie pentru a fi sigur că nu va apărea din nou.
Sursa: www.habr.com