Hogyan kell megírni a minőségbiztosítási dokumentációt, amely valóban működik?

A szoftveres termék olyan, mint egy repülőgép: indulás előtt műszaki ellenőrzésen kell átesnie.

A minőségbiztosítás szükséges lépés a sikeres szoftvertermék piacra dobása felé. Ez csak egy kis része a projektnek, de senki sem mondta, hogy ez egyszerű lesz.

Nagyon sokféle szoftvertesztelés létezik - automatizált és manuális, feltáró és funkcionális, kompatibilitási, UI / UX, regressziós, egység, API és teljesítmény tesztelés. Sok szerencsét mindegyik köré tekerve a fejét!

Mindezen típusoknál azonban az a közös, hogy mindegyikhez alapos minőségbiztosítási tesztdokumentációt kell megírnia. A tesztdokumentumok minősége meghatározza, hogy munkája hasznosnak bizonyul-e, vagy hiába megy.

Azért írtam ezt a cikket, hogy kissé megkönnyítsem az életét. Tehát itt van, a végső útmutató arról, hogyan kell megírni a megfelelő QA dokumentációt.

Készítsen teszttervet és tesztjelentést

A tesztterv egy útmutató dokumentum, amely felvázolja a minőségbiztosítási folyamat nagyobb képét, és tartalmaz tennivalók listáját, stratégiáját, erőforrásait és ütemezését.

Minőségbiztosítási tervdokumentum létrehozása előtt tegye fel a kérdést: „Mi a szoftveres megoldás célja?” és „Milyen funkciókat kell tesztelni?”. Ne rohanjon a szoftver minden egyes részének tesztelésével. El kell döntenie, hogy milyen módszereket, technológiákat és eszközöket fog használni.

A tesztterv segít megérteni a következőket:

  • Melyek az elfogadási kritériumok?
  • Milyen forrásokra van szüksége? Milyen operációs rendszerek, hány példány és milyen licenccel? Szüksége van műszaki tanácsadókra?
  • Jól vannak kijelölve szerepei és felelősségei?
  • Mik a tesztelési időkeretek?

A teszt előrehaladási jelentése a minőségbiztosítási dokumentáció másik része, amely hasonló a teszttervhez, de hozzáadott adatokat tartalmaz az aktuális előrelépésről. Ez a dokumentum lehetővé teszi Önnek és a fejlesztői csapatnak a projekt előrehaladásának nyomon követését és a szervezeti kérdések azonosítását, ha vannak ilyenek.

Tesztterv és jelentés

Hozzon létre teszteseteket

Miután tisztázta a tesztelési tervben tesztelendő funkciókat, létre kell hoznia egy tesztesetet a szoftver minden részéhez.

A tesztesetek meglehetősen egyszerűek - ez a minőségbiztosítási dokumentáció 7 szakaszból áll: azonosító, teszteset, tesztelési lépések, várható eredmény, állapot, tényleges eredmény és megjegyzések.

  1. Az azonosító a tesztesethez rendelt egyedi szám.
  2. A Teszteset részben rámutat a tesztelni kívánt követelmény (ek) re, és megad egy linket a specifikációs dokumentumban.
  3. A Tesztelési lépések részben felsorolja a teszteset befejezéséhez szükséges összes műveletet.
  4. A Várható eredmény részben összefoglalja egy adott teszt eredményét, ha az sikeres.
  5. Az Állapot szakaszban meg kell adnia, hogy egy adott lépés sikeres volt-e vagy sem.
  6. A Tényleges eredmény részben ismerteti a sikertelen teszt eredményét.
  7. A Megjegyzések szakasz nem kötelező, de felveheti, hogy további megjegyzéseket hagyjon.
Próbaper

Írjon hibajelentést

A hibajelentés a minőségbiztosítási dokumentáció fontos eleme. Minden nemkívánatos problémát regisztrál a programjával. A projektdokumentáció kulcsfontosságú eleme, amely egy hibamentes szoftvermegoldás megszerzéséhez irányít.

Egyszerűen hangzik, igaz? Igen, de csak addig, amíg el nem kezdi a dokumentálást. Itt láthat egy példát egy tipikus hibajelentésre:

Hibajelentés

A hibajelentés a következő szakaszokból áll: azonosító, összefoglaló, leírás, a reprodukálás lépései, reprodukálhatóság, súlyosság, prioritás, környezet és mellékletek.

  1. Minden egyes szoftverkiadáshoz egyedi szám - az azonosító - tartozik . Optimalizálja a minőségbiztosítási dokumentumokon keresztüli navigációt, és megkönnyíti a fejlesztők, tesztelők és PM-ek közötti kommunikációt.
  2. Az összefoglaló részben három egyszerű kérdésre adsz tömör választ: mi, hol és milyen körülmények között történt.
  3. A leírás részén , akkor írja le a hibát részletesen. El kell mondania a tényleges és a várható eredményeket. Hasznos megadni egy linket a szoftverigényeihez.
  4. Ezután írjon a reprodukálás lépéseiről (STR) . Ez megmutatja a fejlesztőknek, hogyan kell pontosan reprodukálni a problémát. Ne hagyjon ki egy lépést sem, különben a jelentése visszatérhet Önhöz.
  5. A reprodukálhatósági szakaszban tisztázza, hogy a hiba minden alkalommal megjelenik-e, amikor követi az STR-t. Használjon számokat a hozzávetőleges esélyek megjelenítéséhez, például a 10-ből 7-szer.
  6. A súlyosság szakaszban elmagyarázza, hogy a hiba mekkora kárt okozhat a projektben. Más szavakkal, ez mutatja a hiba technológiai mértékű hatását az egész rendszerre. Még egy apró kérdés is rossz hatással lehet az egész alkalmazásra.
  7. A prioritás megmutatja, mennyire fontos egy adott hibajelentés. Az elsőbbséget betűkkel jelölhetjük - „A” a legsürgősebb és „Z” a legkevésbé sürgős, számok - „1” a legsürgetőbb és „9” a legkevésbé sürgős, vagy egyszerűen csak olyan szavak, mint a „high” ”,„ Közepes ”vagy„ alacsony ”.
  8. A Környezet részben meg kell határoznia, hogy mely operációs rendszereket vagy böngészőverziókat érintette.
  9. Végül a mellékletek tartalmazzák a hibajelentéshez hozzáadott videók, képernyőképek vagy konzolnaplófájlok listáját.

Tartsa szem előtt ezeket a hasznos tippeket a hibajelentéshez

  1. Írjon elegendő és megfelelő összefoglalót. Nem számít, hosszú vagy rövid. Ami fontos, hogy egyértelmű legyen.
  2. Nézze meg az összefoglalót és a leírást. Nagyjából egyformának tűnnek? El kell felejtenie a várható és a tényleges eredmények felvázolását a leírásban, és hozzá kell adnia a követelményekhez vezető linket.
  3. Rögzítse a problémát egy képernyőkép segítségével. Ez sok időt takaríthat meg Önnek és a fejlesztői csapatnak. Néha egy pillantás a képre éppen elég ahhoz, hogy megértsük a helyzetet.
  4. Mielőtt jelentené a problémát, próbáljon meg legalább háromszor lemásolni, hogy megbizonyosodjon arról, hogy létezik.
  5. ASAP-ban jelentse be a problémát, és értesítse a projektvezetőt vagy a terméktulajdonost, ha a probléma súlyos.
  6. Ellenőrizze, hogy van-e nyelvtani hiba a minőségbiztosítási dokumentációban, hogy a nyelvtani rendőrség ne vegye le.
  7. Bármennyire is komikusan hangzik, győződjön meg arról, hogy a probléma nem jellemző - nézze át újra a dokumentációt!
  8. Ne hagyjon ki egyetlen fontos információt sem a reprodukció lépéseiben.

Küldjön hibajelentést

A hibajelentések életcikluson mennek keresztül - a probléma bejelentésétől a lezárásáig.

Hibajelentés életciklusa

Az első lépés a hibajelentés összeállítása és benyújtása . Ezen a ponton a projektmenedzser vagy egy technológiai vezető dönt arról, hogy egy fejlesztőhöz rendeli- e, vagy elégtelenség vagy elégtelenség miatt elutasítja .

Miután a kiosztott fejlesztő kijavította a hibát, Önnek, mint minőségbiztosítónak , még egyszer ellenőriznie kell, hogy javították-e. Ha igen, bezárhatja a hibajelentést. A legjobb gyakorlat az, hogy egy-két hét múlva bezárják.

Ha a hiba nincs kijavítva, újra megnyitja a hibajelentést, és visszaküldi a kijelölt fejlesztőnek. A hibajavítási folyamat hosszú lehet, de erősnek kell maradnia, amíg az összes hibajelentést végül lezárják.

Összecsomagolás

A minőségbiztosítás olyan folyamat, amelyet egyszerűen nem lehet elkerülni. Minden repülőgép indulás előtt műszaki ellenőrzésen esik át. Ha bármilyen probléma merül fel, a repülőgépet földeljük, amíg a probléma meg nem oldódik.

Hasonlóképpen, az egyes szoftvertermékeket az indítás előtt ellenőrizni kell. Nem engedheti meg magának, hogy hibás szoftvert telepítsen, mert a felhasználók nem adnak második alkalmat az alkalmazásának.

Javítania kell a szoftver minőségén?

A KeenEthics cégem szilárd fejlesztési és minőségbiztosítási szolgáltatásokat nyújt. Abban az esetben, ha hasonló projektre van szüksége, vegye fel a kapcsolatot .

Ha tetszett a cikk, folytassa a Mi a prototípus készítés és miért van rá szükségünk, valamint a minimálisan életképes termék: egy ötlet és a termék között.

PS

A KeenEthics blogon közzétett eredeti cikk itt található: Hogyan lehet működőképes minőségbiztosítási dokumentumokat írni?