Meniu

Ghid de documentare pentru testarea software-ului (de ce este important)

software testing documentation guide

Încercați Instrumentul Nostru Pentru Eliminarea Problemelor

În cariera mea de testare software, nu am auzit niciodată oameni vorbind prea mult despre documentația de testare software. Opinia generală despre documentația de testare este că oricine are timp liber poate face documentația, cum ar fi un caz de testare, un plan de testare, un raport de stare, un raport de erori, o propunere de proiect etc.

Chiar și eu nu m-am subliniat mai mult în legătură cu documentația, dar pot spune că este obiceiul meu să plasez toate datele în alb și negru și să le actualizez și pe alții despre asta.

Ghid de documentare pentru testarea software-ului (De ce

Ce veți învăța:

Experienta mea

Vreau doar să vă împărtășesc experiența mea:

Am livrat un proiect (cu o problemă necunoscută) unuia dintre clienții noștri (clientul supărat). Și au găsit problema în partea clientului, ceea ce a fost o situație foarte proastă pentru noi și, ca de obicei, toată vina a fost pe QA-uri.

Problema se referea la compatibilitatea unui singur site web. Când am venit la mine, aveam dovada că nu am primit un astfel de document de cerință care să precizeze că trebuie să verific și compatibilitatea site-ului web. Slavă Domnului că am fost în siguranță.

Aceasta a fost lecția pentru mine, mi-am dat seama de importanța documentației și din acea zi am început să lucrez la documente și am creat documente de testare, cum ar fi planul de testare, cazurile de testare, lista de verificare a testelor de sănătate, raportul de erori și multe altele.

„Cerneala este mai bună decât cea mai bună memorie” - proverb chinezesc

Documentație de testare: Ce este asta?

Cu toții citim diverse articole despre tehnologii și metode de testare, dar câți dintre noi am văzut articole despre documentație? Fără îndoială, sunt puține, documentele nu sunt importante? Nu, dar este pentru că nu am realizat încă importanța documentelor.

Dar, dacă observăm, faptul este că, proiectele care au toate documentele au un nivel ridicat de maturitate.

Majoritatea companiilor nu acordă nici măcar puțină importanță documentației, atât cât acordă procesului de dezvoltare software. Dacă căutăm pe web, putem găsi diverse șabloane despre cum să creăm diferite tipuri de documente. Dar câte dintre ele sunt folosite cu adevărat de către organizații sau persoane fizice?

Faptul este că documentația atentă poate economisi timp, eforturi și bani unei organizații.

În timp ce căutați orice tip de certificare, motivul pentru care se stresează documentația, este doar pentru că arată importanța clientului și a proceselor pentru individ și organizație. Cu excepția cazului în care sunteți capabil să produceți un document care să fie confortabil pentru utilizator, indiferent cât de bun este produsul dvs., nimeni nu îl va accepta.

Este experiența mea, deținem un singur produs, care are o funcționalitate puțin confuză.

Când am început să lucrez la asta, i-am cerut managerului niște documente de ajutor și am primit răspunsul „Nu, nu avem niciun document” Apoi am făcut o problemă pentru că, în calitate de QA pe care îl știam, nimeni nu poate înțelege cum să utilizați produsul fără documente sau instruire. Și dacă utilizatorul nu este mulțumit, cum vom câștiga bani din acel produs?

„Lipsa documentației devine o problemă de acceptare” - Wietse Venema

Chiar și același lucru este aplicabil manualelor de utilizare. Luați un exemplu de Microsoft, lansează fiecare produs cu documente adecvate, chiar și pentru Office 2007 avem astfel de documente, care sunt foarte explicative și ușor de înțeles pentru orice utilizator. Acesta este unul dintre motivele pentru care toate produsele lor au succes.

În companiile mici, am auzit întotdeauna „respingerea proiectului în faza de propunere sau de lansare”, doar pentru că documentația propunerii este lipsită de un limbaj concis și expresiv și pentru a arăta capacitatea organizației.

Nu este faptul că companiile mici nu pot livra proiecte de bună calitate, ci este incapacitatea lor de a-și exprima capacitatea. (Eu lucrez și cu o mică organizație de 80 de angajați și am auzit asta de multe ori)

Personal, simt că Calitatea este singurul departament care o poate face posibilă. Suntem singurul departament care poate argumenta acest lucru și poate oferi un viitor de succes organizațiilor noastre.

Să organizăm toate discuțiile în câteva puncte din perspectiva calității:

- Clarificarea obiectivului și metodelor de calitate
- Asigurați claritatea cu privire la sarcini și consistența performanței
- Asigurați coordonarea internă în activitatea clientului
- Oferiți feedback cu privire la acțiunile preventive
- Oferiți feedback pentru ciclul dvs. de planificare
- Creați dovezi obiective ale performanței sistemului dvs. de management al calității

10 sfaturi pentru a vă ajuta să atingeți obiectivul documentației de testare

Așa cum am menționat în postarea mea anterioară, în general, înțelegerea despre documentația de testare a software-ului este „Poate fi făcută numai de către persoana care are timp liber”. Trebuie să schimbăm această mentalitate și apoi numai noi putem valorifica puterea de documentare a proiectelor noastre.

Nu înseamnă că nu știm cum să facem documentația corect. Pur și simplu nu credem că este important.

Toată lumea trebuie să aibă șabloane standard pentru toate tipurile de documentație, începând de la strategia de testare, planul de testare, cazurile de testare și datele de testare până la raportul de eroare.

Acestea sunt doar pentru a respecta unele standarde (CMMI, ISO etc.), dar când vine vorba de implementarea efectivă, câte dintre aceste documente sunt folosite cu adevărat de noi? Trebuie doar să sincronizăm procesul nostru de calitate cu standardele de documentare și un alt proces dintr-o organizație.

Cel mai simplu lucru de urmărit tot felul de documentații este de a implica o persoană în proiect încă din faza inițială, care înțelege dinamica, domeniul, obiectivul și tehnologia proiectului. Și cine altcineva mai bine decât o persoană de calitate pentru acest lucru (desigur, există scriitori tehnici prezenți pentru a face acest lucru - dar având în vedere un scenariu general al companiilor mici în care scriitorii tehnici nu sunt prezenți).

Pentru a atinge acest obiectiv de testare și documentare, consider că trebuie să ne concentrăm asupra unor puncte.

Iată primele 10 sfaturi pentru a vă ajuta să atingeți obiectivul documentației de testare:

# 1) QA ar trebui să se implice chiar în prima fază a proiectului, astfel încât QA și Documentația să lucreze mână în mână.

#Două) Procesul definit de QA ar trebui să urmeze de către persoane tehnice, acest lucru ajutând la eliminarea majorității defectelor într-o etapă foarte inițială.

# 3) Doar crearea și menținerea Șabloane de testare software nu este suficient, forțează oamenii să le folosească.

ce să folosiți pentru a deschide fișiere jar

# 4) Nu creați și nu părăsiți documentul, actualizați-l și când este necesar.

# 5) Cerința de modificare este o fază importantă a proiectului. Nu uitați să le adăugați pe listă.

# 6) Folosiți controlul versiunilor pentru orice. Acest lucru vă va ajuta să vă gestionați și să urmăriți documentele cu ușurință.

# 7) Faceți procesul de remediere a defectelor mai ușor prin documentarea tuturor defectelor. Asigurați-vă că includeți o descriere clară a defectului, reproduceți pașii, zona afectată și detalii despre autor în timp ce documentați orice defect.

# 8) Încercați să documentați ceea ce este necesar pentru a vă înțelege munca și ceea ce va trebui să produceți părților interesate ori de câte ori este necesar.

# 9) Utilizați șablonul standard pentru documentare. Ca orice șablon de foaie Excel sau șablon de fișier doc și rămâneți la el pentru toate nevoile dvs. de document.

# 10) Partajați toate documentele legate de proiect într-o singură locație, accesibile fiecărui membru al echipei pentru referință, precum și pentru a le actualiza ori de câte ori este necesar.

Nu spun că prin aplicarea pașilor veți obține rezultate bruște. Știu că această schimbare nu se va întâmpla într-o zi sau două, dar cel puțin putem începe astfel încât aceste schimbări să înceapă să se producă încet.

La urma urmei, „documentația are nevoie de documentație”. Nu-i așa?

Există sute de documente utilizate în dezvoltarea software-ului și testarea ciclului de viață.

Documente importante de testare software

Aici listez câteva documente importante de testare software pe care trebuie să le folosim / să le întreținem în mod regulat:

1) Planul de testare
2) Testarea proiectării și Specificația cazului de testare
3) Strategia de testare
4) Rapoarte sumare ale testelor
5) Raport de stare săptămânal
6) Documente / manuale de utilizare
7) Raport de acceptare a utilizatorului
8) Evaluare a riscurilor
9) Jurnal de testare
10) Rapoarte de erori
unsprezece) Date de testare
12) Analiza testului

De asemenea, testerii software trebuie să se refere în mod regulat la următoarele documente:
1) Specificațiile cerințelor software
2) Documente funcționale

Concluzie

Documentele de testare software joacă întotdeauna un rol important în faza de dezvoltare / testare a proiectului. Așadar, păstrați întotdeauna lucrurile documentate ori de câte ori este posibil. Nu vă bazați pe comunicarea verbală. Fiți întotdeauna în siguranță.

Documentarea nu numai că vă va salva, ci va ajuta organizația pe termen lung, economisind mii de dolari la instruire și, mai important, la remedierea problemelor cauzate de lipsa documentelor de dezvoltare și testare.

Nu vă documentați doar pentru a evita să vă arătați cu degetul, dar obișnuința documentării va aduce cu siguranță o abordare sistematică procesului de testare, lăsând în urmă testarea ad hoc.

Despre autor: Acest articol este scris de un membru al echipei STH Tejaswini. Lucrează ca manager QA într-o organizație.

Ce alte documente mai păstrați în activitățile de testare zilnice?

Lectură recomandată

^