Și de ce avem nevoie de o documentație de testare

O dată la un moment dat ...

Cândva, în tinerețea mea, am început să lucrez departamentul de testare angajat în aceeași companie. Documentația de testare a existat sub forma unor liste de verificare în Excel și unele cerințe de la pagina 1-2 pentru dezvoltatori, care, uneori, ar putea arata si testeri. De-a lungul timpului, compania a încetat să aloce timp pentru a scrie CHL, dar documentația pentru dezvoltatori era încă într-o formă mai mult sau mai puțin decente. Deoarece compania a fost implicată în dezvoltarea normală a software-ului pentru dispozitive mobile, care susțin documentația relevante de testare și de a construi sale generale pentru testerii au dovedit costisitoare. Caietul de sarcini a devenit rare.

Argumentul pentru a opri scrierea documentației de testare și orice specificații este faptul că pierderea de ieșire a fost mai mare decât profitul. Caietul de sarcini și diverse documente nu sunt justificate, deoarece cererea prețuri ridicate pentru mici companie aplicații mobile nu a putut. Și ce ar putea fi listele de verificare la noua funcționalitate atunci când:

- Am ajuns sa facem ordine de cumpărare în aplicație!
- Ansamblu ad-hoc a fost de aproximativ! O oră mai târziu, este necesar să se stabilească!
- Avem, de asemenea, bug-uri critice fixe și acum acest lucru „Gizmo“ blocat în cod.
- Pornește orice fum brusc, ceva a mers prost!
- și așa mai departe ..

În final, am avut nici o documentație să se gândească la ceea ce este și ce părți ar putea afecta. Nevoia urgentă de a efectua o testare de explorare completă pentru o jumătate de oră! În acest caz, a fost necesar pentru a găsi bug-uri critice pentru utilizatori. O jumătate de oră - aceasta este timpul maxim, deoarece problemele identificate încă mai trebuie să se stabilească și retestare. De-a lungul timpului, o astfel de lucrări de amenajare a început să aibă probleme:

- Ascultă, cineva aminte ce sa întâmplat aici? Cineva știe cum ar trebui să funcționeze?
- Nu-mi amintesc. Este necesar de a cere dezvoltatorilor ...
- Hmm ... Cred că-mi amintesc că am făcut-o acum trei luni? Am 5 aplicații! Nu-mi amintesc unde am scris odată ...
... (time-out)
- Nu știu. Ei bine, lăsați-l să fie.
- Am eroarea nu se repetă. A-ah ... tu esti uh, apăsați butonul atunci când iese. Și împing întotdeauna ...
- Hei, nu vă aduceți aminte, așa cum am testat un astfel de abonament? Și acest lucru este modul în care ar trebui să fie? Se pare că nu ar trebui să fie atât de ... Nu-mi amintesc.

Și nimeni nu a cere. Profesioniștii care vor fi implicați în documentația, nr. Testeri efectuate adesea testarea completă a cererii, care a fost consumatoare de timp - timp de săptămâni, și, uneori, chiar luni. Și la întrebarea: „Când ați terminat verificarea“, urmată de răspunsul: „bug-uri critice lezuuuut!“ A existat o înțelegere clară a cât de mult timp este necesar pentru programul de testare. Și timp, după cum știți - bani. Rezultatul este ceva care începe să-și trăiască viața ...

Cum, ce și în ce legi se întâmplă - nu era clar pentru oricine. Mai ales pentru noi dezvoltatori, care au trecut de dezvoltare în continuare:

Din moment ce multe companii operează. Și nu obține toate rezultate bune.

Deși povestea descrisă mai sus și inexacte, deoarece mulți ani au trecut și ceva parafrazate, dar sensul este același. Există companii care încă scrie documentația de testare și-l utilizați în mod activ. De obicei, acestea sunt companii mari in curs de dezvoltare pe scară largă sistem multi-funcțional. Și există companii cu privire la calitatea și disponibilitatea documentației care ar putea afecta viața oamenilor (de exemplu, compania dezvolta un pilot automat pentru un avion). Pilotul automat poate fi dezvoltat de-a lungul anilor, ca urmare a odată ce eliberarea către public. Acesta este un proces foarte scump. În cazul în care pilotul automat este buggy, pierderile vor fi enorme.

Cum de a face în așa fel încât produsul a dovedit de înaltă calitate și de bună-vânzare? Noi trebuie să înceapă cu documentația.

În ce formă și ce are nevoie de documentația de testare?

Există diferite tipuri de documente folosite în timpul testării. Fiecare dintre ele joaca un rol in atingerea unui obiectiv comun - crearea unui produs de succes. Următorul aspect la cele mai frecvente tipuri de documente și motivele de utilizare a acestora.

documente de proiectare de lucru utilizate de testeri

Termenii de referință (TOR) - vă permite să transmită esența subiectului de dezvoltare a angajaților companiei. Ea ne ajută să înțelegem ce fel de funcționalitate ar fi dezvoltat un produs (uneori cu o indicație a tehnologiei utilizate și metodele).

Dacă TK este în domeniul public, personalul slab intersectându-se cu echipa de dezvoltare va fi capabil să-l vadă. Este posibil ca, atunci când testarea este detectată nici o problemă raportată de aparatul de probă (de exemplu, programul nu își îndeplinește scopul pentru care a fost creat).

Noii angajați nu vor trebui să vorbească despre semnificația programului și metodele de implementare a acesteia. Veți fi capabil de a intra rapid în cursul afacerilor oricărei persoane.

TK ajută angajații să înțeleagă mai bine programul. Neînțelegerea produs dezvoltat duce la erori.

Atunci când testarea nu va avea loc încercări de a verifica inutile. În primul rând, verificați-l supus la ceea ce trebuie să lucreze în mod necesar pe TK.

TK oferă o oportunitate de a înțelege esența produsului în cadrul personalului de dezvoltare, care va reprezenta versiunea finită a punerii în aplicare a unui public.

CTZ (specificație special) - creat pe baza TK. De obicei, o descriere completă a unei anumite părți a produsului elaborat și VI (cazuri de utilizare, scenarii pentru utilizatorii în dezvoltarea modelelor de obiecte a dezvoltat o parte a dezvoltării subiectului, logica și esența ei).

Acesta ajută dezvoltatorii să pună în aplicare produs dezvoltat exact așa cum doriți. Aceasta ajută să înțelegem logica și regulile de înregistrare.

Aceasta ajută noii angajați să înțeleagă proiectele majore și pe scară largă, deoarece unele sisteme au nevoie de o săptămână studiind. Având la îndemână CTZ, angajatul va fi capabil de a găsi cu ușurință informațiile necesare imediat pentru a începe testarea. Nu aveți nevoie pentru a implica alte categorii de personal, cunoștințe despre produs, astfel le distrage atenția de la locul de muncă. Evidentă economie de timp!

Aceasta face posibilă estimarea forței de muncă de dezvoltare și testare înainte de începerea lucrărilor.

Acesta ajută la crearea unor testere CHL și cazuri de testare înainte de începerea lucrărilor și testarea.

CTZ și TK pot fi afișate:

ca text cu imagini

ca un tabel de model grafic

sub formă de hărți mentale, UML sau un algoritm similar cu

Documentația de proiect, pregătește testere

CHL (lista de verificare) - o listă de lucruri de verificat.

Aceasta ajută datele planului de finalizare în viitor și în prezent, ca în CHL, puteți specifica cât de mult timp ai nevoie pentru a testa și cât de mult a fost cheltuit.

Se păstrează o istorie de teste trecut. Acesta va fi ușor să vă amintiți exact care teste au fost efectuate cu erori, și dublu-a verifica le.

CHL cu rezultatele arată în mod clar orice angajat al stadiului actual al produsului dezvoltat. Aceasta ajută să se determine gradul său de pregătire.

Aceasta ajută să-și amintească ceea ce a fost deja testat, și ceea ce nu este.

Aceasta ajută să-și amintească ce teste trebuie făcut în primul rând, care a doua, care, în al treilea, etc. Acest lucru dă naștere la încredere că un anumit interval de timp programat cele mai importante teste vor fi efectuate și rezultatele de ea - .. Obținute.

putem scrie liste de verificare:

sub formă de tabele (convenabil în Google Foi de calcul)

sub formă de hărți mentale (la îndemână în XMind)

sub forma unor verificări în lista de sistem special conceput (util în Sitechco)

ca o listă într-un document text, care este familiar.

TC (caz test) - este creată pe baza CTZ (dacă este cazul), analiștii de testare și testeri.
De ce este necesar?

Împreună cu CHL poate stoca și afișa istoricul de testare, ce și cum de a testa. Puteți fi siguri că acest lucru sau că funcționalitatea a fost în mod necesar sau vor fi testate și atinse în timpul testării.

Aceasta ajută la rândul său, rapid noilor angajați. Angajații nu sunt obligate să săptămâni pentru a învăța subiectul de dezvoltare, va fi suficient pentru a deschide TK salvat și du-te prin ea pas cu pas precum și de alta a luat un profesionist cu experiență, care a lucrat anterior la companie.

El ajută pentru a vedea cum ar trebui să arate subiectul de dezvoltare (software, site-ul și așa mai departe. N.) cum ar fi. Cu capturi de ecran disponibile de ecrane, în cazul în care acestea sunt, nu poți uita de faptul că „există butonul“ ar trebui să fie gri, nu roșu.

cazuri de testare pot fi afișate:

sub forma unui tabel cu date de tip text

un serviciu special pentru desfășurarea cazurilor de testare (de exemplu, în TestLink).

Raportul de testare - scris sau un raport de mass-media cu privire la activitatea desfășurată și rezultatul acesteia.

Vizualizare ce este rezultatul muncii efectuate se obține.

Punct de vedere istoric, acesta înregistrează informații. Pentru a-l puteți merge mereu înapoi și să vedem ce a fost făcut și că a ajuns în cele din urmă.

Acesta notifică rezultatele tuturor celor care sunt importante să știe despre ele. De exemplu, pentru personalul de rapoarte cu privire la departamentul de asistență pentru o nouă versiune a unui program în curs de dezvoltare, precum și despre problemele cele mai critice. Veți fi capabil să se pregătească pentru plângerile emergente.

Aceasta ajută să ia o decizie privind măsuri suplimentare (de exemplu, dacă să lanseze o versiune a programului în starea sa actuală).

Raportul Mostra în scris:

Cum de a determina ce tip de documente este necesară pentru punerea în aplicare a proiectului?

Următoarele sunt exemple de când și ce fel de documentație și instrumente pot fi folosite ca minimul necesar.

Pe de proiect până la 15 persoane (proiecte de complexitate redusă):

Termenii de referință (pentru a preveni interpretarea greșită a problemei de către dezvoltatori, astfel încât documentația nu este ..);

liste de verificare (ușor de întreținut, nu ia o mulțime de timp);

rapoarte în formă de o scurtă scrisoare sau dezabona într-un management de proiect special de servicii, cu bug-uri critice pentru eliberarea.

La proiectul de la 15 la 50 de persoane (complexitate medie a proiectului):

baza de cunoștințe (de exemplu, Wiki);

rapoarte în forma unei scrisori cu un CHL atașat călătorit cu bug-uri critice.

Big proiect - de la 50 de persoane și mai multe proiecte (complexitate ridicata):

Termeni privați de referință;

baza de cunoștințe (de exemplu, Wiki);

rapoartele adoptate sub forma unei societăți (de obicei sub forma unei scrisori cu un program detaliat și fișierele atașate);

Altele (depinde de tipul, obiectivele și nevoile companiei).

Cu această alegere - angajații decid pentru ei înșiși, astfel încât acestea vor fi de a dezvolta și să fie capabil să înțeleagă ceea ce au nevoie ... Toate cele de mai sus - doar o idee și recomandări dur.

Ce se întâmplă dacă documentația de scriere este consumatoare de timp?

Experiența arată că trebuie să fie în măsură să se adapteze atunci când lucrează la un proiect mic. Puteți modifica documentația, astfel încât comportamentul său confortabil și nu a durat mult. De exemplu, TK poate fi făcută sub forma unei prezentări sau webinar și să obțină întrebări de clarificare din partea dezvoltatorilor. Fiecare dintre tipurile de documentare are plusuri și minusuri, astfel încât să nu fie frica de a experimenta și de a crea ceva nou. Toate descoperirile științifice sunt realizate de încercare și eroare, cu acest caz și eșec!
Dar un rezultat negativ - un rezultat prea! Trebuie să fie capabil să-l folosească și să-l în considerare în experimentele lor ulterioare, până când se obține un rezultat acceptabil. progresul Splendid vă și de a face în documentația de scris!