Traducere: Olga Alifanova
Rapid Testare Software Desigur, am oferi studenților acest exercițiu: le cer pentru a lista totul, din punctul lor de vedere, complică sau întârzie testul. Răspunsurile lor sunt, de obicei, de același tip - am auzit în mod regulat aceeași variație (un exemplu de astfel de răspunsuri pot fi găsite, de exemplu, în discuția de pe Bursa de stivă). De obicei, acest lucru este ceva de genul lista de mai jos:
- Sunt doar de testare, și de lucru cu mai mulți dezvoltatori (sau unul dintre testeri, și echipa noastră o mulțime de dezvoltatori).
- Sunt foarte limitate în timp. În mod constant vine construcții noi, și noi de presă în fiecare săptămână sau două.
- Produsul (e) pe care am testat, este foarte dificil în sine.
- Între produs unități (sau între diferite produse), setul de interdependențelor.
- Văd că o serie de probleme apar din cauza acestor relații - o mica schimbare într-un singur modul poate duce la o catastrofă în cealaltă.
- Eu cred că, în scopul de a prinde aceste bug-uri trebuie să-și alunge regresie completă pentru fiecare nou build.
- Am încercat să facă față cu sarcina, folosind auto-teste, dar complexitatea produsului face dificilă pentru a testa automatizare - „ancora“ pentru testele automate sunt modificări minime sau absente, și frecvente de produse complica suport de automatizare.
- Pe suportul Autotest durează destul de mult timp, iar eu nu am timp pentru a face teste care ar dori să scape de.
- Toate acestea sunt extrem de obositoare, dar eu încerc să facă față.
Și, un plus la cele de mai sus,
- Compania, în care lucrez, spune că lucrează la Agile
- În plus față de cele două săptămâni iterații, de fapt, vom folosi un maxim de un cuplu de practici legate de Agile-abordare - ca o regulă, de zi cu zi scrum-întâlnire sau Kanban bord.
Iar cireasa de pe tort:
- Venind pentru testare se bazează sunt foarte instabile. Sistemul se încadrează în cele mai multe de bază de fum-teste, iar eu trebuie să aștepte și / sau reconstrui în loc de a construi care urmează să fie angajate în activitatea directă.
Cum pot analiza aceste observații?
Noi le putem considera ca fiind o problemă de testare, dar ne putem uita, de asemenea, la ele în mod diferit - ca rezultatele testului.
Rezultatele testelor nu ne spun că ceva a mers bine sau rău. Acestea furnizează informații pentru luarea deciziilor, evaluare, și lucruri de genul asta. Oamenii care primesc rezultatele testelor, decide dacă există o problemă în produs și ceea ce sunt, ceea ce este necesar pentru a afla, și ce decizii să ia. Este nevoie de implicarea oamenilor care trăiesc, evaluarea o varietate de factori, precum și un număr de posibile interpretări.
La fel cum este cazul cu autotests și alte rezultate ale testelor, este important să se ia în considerare întregul spectru de cauze posibile și interpretarea testelor meta-rezultate - observații cu privire la testul. Dacă nu facem, riscăm să lipsesc pe probleme importante care amenință calitatea atât testarea și produsul în sine.
Dzherri Vaynberg în cartea sa „Perfect Software și alte iluzii cu privire la testarea“, constată că ceea ce obținem ca rezultat - este în primul rând informațiile. Dacă testarea, în conformitate cu Jerry - este colectarea de informații în vederea transmiterii acesteia către factorii de decizie, nu putem lăsa în urmă observație potențial semnificativ.
În testare, suntem adesea se confruntă cu diverse probleme. Cu toate acestea, în loc să le trateze ca o problemă pentru testare, ne putem gândi, de asemenea, dintre ele ca simptome ale problemelor de produs sau proiect - problemele pe care testarea se poate rezolva.
De exemplu, în cazul în care testerul suferă din cauza numărului mare de dezvoltatori, sau în cazul în care tester nu este suficient timp pentru a testa - acest test rezultat. Adesea, acest sentiment este cauzat de faptul că programatorii generează multe probleme complexe, care tester pur și simplu nu pot face față cu ei singuri. Complexitatea modului și de calitate - este relația dintre om și altceva. Prin ea însăși, complexitatea nu este neapărat o problemă, spre deosebire de reacțiile oamenilor la ea. Urmărind modul în care oamenii reacționează la subiective complexitatea și riscurile, putem învăța multe.
- Fie că ajută ca testeri, colegii să fie conștienți de riscurile - în special a „lebede negre“ - sunt de obicei asociate cu complexitatea?
- Când oamenii imagina riscurile, indiferent dacă acestea acordă o atenție pentru a le? Au intra in panica, sau pur si simplu ignora în speranța că totul va fi bine? Sau altceva?
- Oamenii reacționează calm și pragmatic? Ele nu recunosc complexitatea produsului, dacă încearcă să facă față cu ea?
- În cazul în care complexitatea produsului sau procesul nu poate fi redusă, este luat acolo ceva pentru a face produsul / procesul mai ușor de înțeles?
- Se întâmplă ca programatorii să scrie cod sau se schimbă atât de repede încât acestea pur și simplu nu au timp să dau seama ce se întâmplă cu adevărat?
- Dacă cineva crede că echipa au nevoie de mai multe testere, de ce crede el? (Am discutat această problemă în urmă cu câțiva ani)
Cum de a găsi răspunsuri la aceste întrebări? O modalitate - să ia o privire atentă la rezultatele și rezultatele meta-test:
- El consideră dacă cineva din echipa, că testarea este dificil sau consumatoare de timp? Cine?
- De ce el crede acest lucru, ce ipoteze l-au dus la ideea?
- Ea nu se deteriorează acoperirea de testare a ceea ce testere petrece o mulțime de timp pentru a studia localizarea și proiectarea erorilor? (Am scris despre această problemă înainte).
- Fie că testarea dezvăluie modele consistente de eșecuri?
- Sistematic dacă aceste eșecuri și modelele lor surpriză programatori?
- Are codul de mici modificări probleme mari sau subtile?
- Ei bine, dacă programatorii înțelege relațiile interne ale produsului? Am nevoie de această relație de produs, sau pot fi evitate?
- Nu dezvoltatorii au luat unele măsuri pentru a preveni sau de a preveni problemele asociate cu interfețele și interacțiunile?
- Dacă verificarea automată este dificil să se stabilească și să mențină, spune în cazul în care situația privind nivelul de competențe profesionale ale testere, ca o interfață de automatizare, sau scara inspecțiilor? Sau indică altceva?
- Nu preveni instabilă construiește testul profund?
- Este posibil să se interpreteze instabilă construiește ca un semn că produsul este atât de multe probleme grave pe care le pot găsi chiar și o testare sumară?
- În cazul în care, după o succesiune de instabile construiește în sfârșit un stabil - așa cum este cu adevărat stabil?
Poate că răspunsurile la aceste întrebări, putem pune mai multe întrebări.
- Pe măsură ce aceste probleme sunt în pericol succesul produsului pe termen scurt și lung?
- În cazul în care testarea indică un model sistematic de eșecuri și a riscurilor asociate, ceea ce face o echipă cu aceste informații?
- Nu programatori sunt obligați să furnizeze în mod exclusiv codul sau care sunt obligați să furnizeze codul pentru a garanta că codul face ceea ce ar trebui să (și nu fac ceea ce nu), cât de mult știu? Cum programatori sincer preferat a doua opțiune?
- Se face dacă programatorii pe cineva să mențină calendarul / volumul de muncă, în măsura în care de fapt nu se pot întâlni?
- Poate programatori și testeri pentru a rezista impuse asupra lor timp și volumul de muncă în cazul în care acești termeni crește riscurile de alimente sau de proiect?
- Nu asculta preocupările echipei de afaceri? Nu știu despre riscurile găsite de testeri și dezvoltatorii? În cazul în care echipa de dezvoltare se referă la riscurile existente, luând dacă măsurile adecvate de management / de afaceri ca răspuns la acest lucru?
- Dacă echipa lucrează în modul de confort, sau a unui produs / proiect zdrobit serios complexitate, relații interne, fragilitatea și dificultățile care se află în afara capacităților de dezvoltare / testare pentru a face față cu ei?
- Este echipa de lucru pe Agile, manifest Agile observarea? Poate că „flexibilitatea“ este folosit ca un cult de marfă - și artefacte practica masca numai prostia proiectului?
Testeri de multe ori cred că sarcina lor - pentru a căuta, de a explora și a raporta bug-uri în software-ul testat. De obicei, acesta este cazul, dar o privire la testarea este extrem de limitată. Produsul - este tot ceea ce a făcut cineva: cerințele programului, graficul, caietul de sarcini, program, prototip, proces, ideea ... Testarea poate căuta informații cu privire la orice produse, dacă li se oferă o atenție adecvată.
Pe de o parte, problemele enumerate mai sus în acest articol, uita-te probleme serioase de testare. Poate că da, dar nu este tot ceea ce este în spatele lor. Dacă ne amintim definiția Dzherri Vaynberga - „testare - o colecție de informații care urmează să fie transmise factorilor de decizie“, se pare că tot ceea ce găsim și să respecte în procesul de testare - acest test rezultat.