Introducere
Bună ziua, comunitate Hub. Am rezolvat recent o sarcină de testare pentru un post de QA Lead la o companie fintech. Prima sarcină, de a redacta un plan de testare cu o listă completă de verificare și exemple de cazuri de testare pentru a verifica un fierbător electric, este destul de trivială:
Este greu de imaginat un plan de testare mai bun cu o listă completă de verificare.
Însă partea a doua a fost o întrebare: „Există probleme comune tuturor testatorilor care împiedică munca mai eficientă?”.
Primul lucru care mi-a venit în minte a fost să enumăr toate problemele mai mult sau mai puțin evidente cu care m-am confruntat la testare, să elimin elementele minore și să generalizez restul. Dar am realizat repede că metoda inductivă va răspunde la o întrebare care se referă nu la „toți”, ci, în cel mai bun caz, doar la „majoritatea” testatorilor. Așa că am decis să abordez problema dintr-o altă perspectivă, cea deductivă, și iată ce a ieșit.
Definiții
Primul lucru pe care îl fac de obicei când abordează o nouă sarcină este să încerc să înțeleg despre ce este vorba, iar pentru asta trebuie să înțeleg sensul cuvintelor prin care este formulată. Cuvintele cheie la care trebuie să mă clarific sunt următoarele:
- problema
- testator
- munca testatorului
- eficiența muncii testatorului
Să ne consultăm cu Wikipedia și bunul simț:
(din greaca veche πρόβλημα) în sens larg — o întrebare teoretică sau practică complexă, care necesită studiu, soluționare; în știință — o situație controversată, exprimată prin poziții opuse în explicarea unor fenomene, obiecte, procese, și care necesită o teorie adecvată pentru soluționarea acesteia; în viață, o problemă se formulează într-un mod clar pentru oameni: „știau ce, nu știau cum”, adică se știe ce trebuie obținut, dar nu este clar cum să se facă acest lucru. Provine din lat. tardiv. problēma, din greacă πρόβλημα „aruncat înainte, pus în față”; din προβάλλω „a arunca înainte, a expune în față; a acuza”.
Nu are prea mult sens, în esență, „problemă” = „orice lucru cu care trebuie să te descurci”.
— specialist (we won't differentiate types, as we are interested in all testers) involved in the testing of a component or system, the outcome of whose activities is:
— a set of activities related to testing.
(from Latin effectivus) — the ratio between the achieved result and the resources used (:2015).
— 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.
— a quantitatively measurable ability to perform any human or group activity; conditions that allow for obtaining the desired result through certain transformations. A tester is a person, and according to the theory of vital resources, every person possesses four economic assets:
monetary funds (income) — a renewable resource;
energy (vital force) — a partially renewable resource;
time — a fixed and fundamentally non-renewable resource;
knowledge (information) — a renewable resource, this part of human capital can both grow and diminish..
I want to note that the definition of effectiveness in our case is not entirely correct, as the more knowledge we use, the lower the effectiveness tends to be. Therefore, I would redefine effectiveness as 'the ratio between the achieved result and the resources expended.' Then everything is correct: knowledge is not spent during work, but reduces the expenditure of the only fundamentally non-renewable resource of the tester — their time.
Soluție
So, we are looking for the global problems of testers that worsen the efficiency of their work.
The most significant resource expended on a tester's work is their time (the others can somehow be linked to it), and in order for us to discuss a correct calculation of effectiveness, we must also relate the result to time.
Pentru aceasta, să luăm în considerare un sistem a cărui viabilitate este asigurată de activitatea unui tester. Un astfel de sistem este un proiect în care face parte un tester. Ciclu de viață al proiectului poate fi aproximativ reprezentat prin următorul algoritm:
- Lucrul cu cerințele
- Formularea cerințelor tehnice
- Dezvoltare
- Testare
- Lansarea în producție
- Suport (înapoi la punctul 1)
În același timp, întregul proiect poate fi recursiv împărțit în subproiecte (funcționalități), având același ciclu de viață.
Din perspectiva proiectului, eficiența realizării sale este cu atât mai mare cu cât mai puțin timp este petrecut pe acesta.
Astfel, ajungem la definirea eficienței maxime posibile a testerului din perspectiva proiectului - este acea stare a proiectului când timpul alocat testării este zero. O problemă comună pentru toți testerii este imposibilitatea de a atinge acest timp.
Ce ar trebui să facem în această situație?
Concluziile sunt destul de evidente și utilizate de mult de mulți:
- Dezvoltarea și testarea ar trebui să înceapă și să se finalizeze practic simultan (de obicei, acest lucru este gestionat de departamentul ). Varianta ideală este atunci când toată funcționalitatea dezvoltată la momentul finalizării este deja acoperită de teste automate, organizate într-un test de regresie (și, dacă este posibil, și într-un test pre-commit) cu ajutorul unui .
- Cu cât un proiect are mai multe funcționalități (cu atât este mai complex), cu atât mai mult timp trebuie să alocăm pentru a verifica că noua funcționalitate nu a stricat-o pe cea veche. Prin urmare, cu cât proiectul este mai complex, cu atât mai multă automatizare este necesară pentru .
- De fiecare dată când ratăm un bug în producție, iar utilizatorul îl găsește, suntem nevoiți să cheltuim timp suplimentar parcurgând ciclul de viață al proiectului începând cu punctul 1 (Lucrul cu cerințele, în acest caz, ale utilizatorilor). Deoarece cauzele ratării bug-ului sunt, în general, necunoscute, avem o singură opțiune de optimizare - fiecare bug găsit de utilizatori trebuie inclus în testarea de regresie pentru a ne asigura că nu va mai apărea.
Sursa: habr.com
