Kako napisati QA dokumentaciju koja će zapravo funkcionirati

Softverski proizvod sličan je avionu: prije lansiranja mora proći tehničku provjeru.

Osiguranje kvalitete nužan je korak ka lansiranju uspješnog softverskog proizvoda. To je samo mali dio cjelokupnog projektnog rada, ali nitko nije rekao da će to biti jednostavno.

Postoji toliko mnogo vrsta testiranja softvera - automatizirano i ručno, istraživačko i funkcionalno, kompatibilnost, UI / UX, regresija, jedinica, API i ispitivanje performansi. Sretno oko svih njih!

Zajedničko je za sve ove vrste, međutim, da svaka od vas zahtijeva da napišete temeljitu dokumentaciju o ispitivanju kvalitete. Kvaliteta ispitnih dokumenata određuje hoće li se vaš rad pokazati korisnim ili će proći uzalud.

Ovaj sam članak napisao da bih vam olakšao život. Eto, to je vaš konačni vodič za pisanje softverske QA dokumentacije koja će raditi.

Napravite plan ispitivanja i izvještaj o napretku ispitivanja

Plan ispitivanja je dokument vodilja koji ocrtava širu sliku procesa osiguranja kvalitete i uključuje popis obveza, strategiju, resurse i raspored.

Prije izrade dokumenta QA plana, zapitajte se "Koja je svrha softverskog rješenja?" i "Koje značajke treba testirati?". Ne žurite s testiranjem svakog pojedinog dijela softvera. Morate odlučiti koje ćete metodologije, tehnologije i alate koristiti.

Plan testa pomoći će vam da razumijete sljedeće:

  • Koji su kriteriji prihvaćanja?
  • Koji su vam resursi potrebni? Koji operativni sustavi, koliko kopija i s kojom licencom? Trebate li tehničkog savjetnika?
  • Jesu li vaše uloge i odgovornosti dobro određene?
  • Što su vremenski okviri za testiranje?

Izvještaj o napretku testa još je jedan dio QA dokumentacije, koji je sličan planu ispitivanja, ali s dodanim podacima o trenutnom napretku. Ovaj dokument omogućuje vama i vašem razvojnom timu da nadgledate napredak projekta i prepoznate organizacijske probleme, ako ih ima.

Plan ispitivanja i izvještaj

Stvorite test slučajeve

Nakon što razjasnite skup funkcija koje treba testirati u vašem planu ispitivanja, morate stvoriti testni slučaj za svaki dio vašeg softvera.

Ispitni slučajevi prilično su jednostavni - ova se QA dokumentacija sastoji od 7 odjeljaka: ID, test slučaj, koraci testiranja, očekivani rezultat, status, stvarni rezultat i komentari.

  1. ID je jedinstveni broj dodijeljen vašem test slučaju.
  2. U odjeljku Test Case ukazujete na uvjete koje ćete testirati i dajete vezu na njih u dokumentu sa specifikacijama.
  3. U odjeljku Koraci testiranja navodite sve radnje potrebne za dovršenje testnog slučaja.
  4. U odjeljku Očekivani rezultat rezimirate ishod određenog testa ako je uspješan.
  5. U odjeljku Status naznačujete je li određeni korak prošao ili nije prošao testiranje.
  6. U odjeljku Stvarni rezultat objašnjavate ishod neuspjelog testa.
  7. Odjeljak Komentari nije obvezan, ali možete ga dodati da biste ostavili neke dodatne napomene.
Test slučaj

Napišite izvještaj o nedostacima

Izvještaj o kvaru važan je element QA dokumentacije. Registrira bilo koji neželjeni problem s vašim programom. To je presudni element projektne dokumentacije koji vas usmjerava prema softverskom rješenju bez grešaka.

Zvuči jednostavno, zar ne? Da, ali samo dok ne počnete dokumentirati. Ovdje možete vidjeti primjer tipičnog izvješća o kvaru:

Izvještaj o nedostacima

Izvještaj o kvaru sastoji se od sljedećih odjeljaka: identifikator, sažetak, opis, koraci za reprodukciju, ponovljivost, ozbiljnost, prioritet, okruženje i prilozi.

  1. Svakom izdanju softvera dodjeljuje se jedinstveni broj - identifikator . Optimizira navigaciju kroz QA dokumente i olakšava komunikaciju između programera, testera i premijera.
  2. U odjeljku sažetka dajete jezgrovit odgovor na tri jednostavna pitanja: što se dogodilo, gdje i pod kojim okolnostima.
  3. U opisu sekciji , opisali bug u detalje. Trebali biste reći o stvarnim i očekivanim rezultatima. Korisno je dati vezu na vaše softverske zahtjeve.
  4. Zatim pišete o koracima za reprodukciju (STR) . To programerima pokazuje kako točno reproducirati problem. Ne propustite korak ili će vam se izvještaj možda vratiti.
  5. U odjeljku o ponovljivosti objašnjavate pojavljuje li se greška svaki put kad slijedite STR. Trebali biste koristiti brojke da biste pokazali približne šanse, na primjer 7 puta od 10.
  6. U odjeljku ozbiljnosti objašnjavate koliko šteta programska pogreška može donijeti projektu. Drugim riječima, pokazuje tehnološki stupanj utjecaja kvara na cjelokupni sustav. Čak i mali problem može loše utjecati na cijelu aplikaciju.
  7. Prioritet pokazuje koliko je važno izvješće o kvaru važno. Prioritet se može označiti pomoću slova - "A" za najhitnije i "Z" za najmanje hitne, brojevi - "1" za najhitnije i "9" za najmanje hitne, ili jednostavno riječi poput "visoko ”,„ Srednja ”ili„ niska ”.
  8. U odjeljku o okolišu trebali biste definirati koji su operativni sustavi ili verzije preglednika bili pogođeni.
  9. Konačno, privitci uključuju popis videozapisa, snimki zaslona ili datoteka dnevnika konzole dodanih u izvješće o kvaru.

Imajte na umu ove korisne savjete za pisanje izvještaja o nedostacima

  1. Napišite dovoljan i adekvatan sažetak. Nije važno je li dugačak ili kratak. Bitno je da to treba biti jasno.
  2. Pogledajte sažetak i opis. Izgledaju li približno jednako? Sigurno ste zaboravili u opisu opisati očekivane i stvarne rezultate i dodati vezu na zahtjeve.
  3. Snimite problem uz pomoć snimke zaslona. Možda ćete uštedjeti puno vremena vama i razvojnom timu. Ponekad je jedan pogled na sliku dovoljan da shvatite situaciju.
  4. Prije nego što prijavite problem, pokušajte ga reproducirati najmanje 3 puta kako biste bili sigurni da postoji.
  5. Prijavite problem što prije i obavijestite voditelja projekta ili vlasnika proizvoda ako je problem velik.
  6. Provjerite ima li gramatičkih pogrešaka u QA dokumentaciji kako vas gramatička policija ne bi uklonila.
  7. Koliko god komično zvučalo, pobrinite se da problem nije značajka - ponovno pregledajte dokumentaciju!
  8. Ne propustite nijednu važnu informaciju u Koracima za reprodukciju.

Pošaljite izvještaj o nedostacima

Izvješća o nedostacima prolaze kroz životni ciklus - od trenutka kada prijavite problem do trenutka kada je problem zatvoren.

Životni ciklus izvješća o nedostacima

Prvi je korak sastaviti i predati izvještaj o kvaru. U ovom trenutku voditelj projekta ili tehnički voditelj odlučuje hoće li ga dodijeliti programeru ili će ga odbiti zbog nedostatka ili neadekvatnosti.

Nakon što je dodijeljeni programer ispravio bug, vi kao QA morate ponovno provjeriti i provjeriti je li ispravljen. Ako je odgovor da, možete zatvoriti izvještaj o kvaru. Najbolja praksa je zatvoriti je za tjedan ili dva.

Ako programska pogreška nije ispravljena, ponovno otvorite izvješće o nedostatku i pošaljite ga natrag dodijeljenom programeru. Popravak programskih pogrešaka može biti dug, ali morate ostati jaki dok se konačno ne zatvore svi izvještaji o nedostacima.

Zamotati

Osiguranje kvalitete postupak je koji jednostavno ne možete izbjeći. Svaki zrakoplov prije polijetanja podvrgava se tehničkoj provjeri. Ako postoji bilo kakav problem, zrakoplov je uzemljen dok se problem ne riješi.

Slično tome, svaki softverski proizvod treba provjeriti prije pokretanja. Ne možete si priuštiti postavljanje programskog softvera s programskim pogreškama jer korisnici neće pružiti vašoj aplikaciji drugu priliku.

Trebate li poboljšati kvalitetu svog softvera?

Moja tvrtka KeenEthics pruža solidan razvoj i usluge osiguranja kvalitete. U slučaju da trebate procjenu za sličan projekt, slobodno nas kontaktirajte .

Ako ste uživali u članku, trebali biste nastaviti s temom Što je prototipiranje i zašto nam to treba te Minimalni održivi proizvod: između ideje i proizvoda.

P.S

Izvorni članak objavljen na blogu KeenEthics možete pronaći ovdje: Kako napisati QA dokumentaciju koja će funkcionirati?