Meni

Umetnost poročanja o napakah: Kako tržiti in odpraviti napake?

art bug reporting

Preizkusite Naš Instrument Za Odpravo Težav

Zakaj obstaja potreba po trženju hrošča?

Prve stvari, ki mi pridejo na misel, ko začnem pisati ta članek, so besede Cem Kaner - »Najboljši preizkuševalec ni tisti, ki najde največ napak ali ki osramoti večino programerjev. Najboljši preizkuševalec je tisti, ki odpravi največ napak. '

Zdaj - Kakšna je razlika med iskanje večine napak in odpravljanje večine napak ?

Ali ni očitno, da je kakršna koli napaka prijavljena v sistem za upravljanje napak naj določi razvijalec? Odgovor je ne. Dejavniki, kot so čas za trženje izdelka, čas za dokončanje projekta po urniku in razvijalci, ki delajo v njem nepraktični strogi urniki itd. prisilijo podjetja, da izdajo izdelek z nekaj napakami, ki v veliki meri ne bodo vplivale na uporabnike.

Umetnost poročanja o napakah

(slika vir )

Kdo daje zaupanje vodstvu m, ki navaja, da napake v izdelku ne bodo vplivale na zaupanje, zanesljivost in interes zainteresiranih strani? - Preizkuševalni inženir ali preskusna skupina - dolžnost vsakega preskusnega inženirja je odpraviti napake, ki bi lahko negativno vplivale na kakovost izdelka.

Prednost napake je po mojem mnenju v veliki meri odvisno od tega, kako preizkuševalec zadevo predstavi razvojnim in vodstvenim skupinam.

Mislite na to kot na oglaševanje ali trženje izdaje - to vključuje dva koraka:

  1. Napišite ali pravilno prijavi napake
  2. Vedeti vse o napaki, tako da je vse nadaljnje podrobnosti mogoče bolje razložiti

Kaj se boste naučili:

Umetnost poročanja o napakah

Da, poročanje o napakah je umetnost . Način, kako je napaka napisana, prikazuje tehnično znanje, strokovno znanje o domeni in komunikacijske zmožnosti testnega inženirja.

Običajno mora napaka vsebovati naslednje informacije:

  • Povzetek napak
  • Koraki za reprodukcijo
  • Priloge (posnetek, dnevniške datoteke itd.,)
  • Obnovljivost hroščev
  • Resnost hroščev
  • Različica programske opreme, informacije o okolju
  • Druge informacije na podlagi organizacijskih zahtev.

Pomembno: Vedno se poglobite, da poiščete vzrok težave in jo prijavite. Na primer, preprosta napaka pri prijavi s pravilno kombinacijo uporabniškega imena in gesla je lahko povezana z različnimi razlogi, kot so:

  1. Poverilnice za prijavo sploh niso potrjene
  2. Težave z omrežno časovno omejitvijo v primeru oddaljenih prijav
  3. Sistem lahko vse CAPS obravnava kot ne-CAPS.

Torej bi morali kot preizkuševalec razbrati razlike, medtem ko sledite povzetkom napak:

  • 'Ne morem se prijaviti s pravilnim uporabniškim imenom in geslom'
  • 'Ne morem se prijaviti s pravilnim uporabniškim imenom in geslom, če uporabniško ime ali geslo vsebuje kombinacijo abeced CAPS in ne-CAPS.'

Slednje je zelo jasen opis problema in je nedvoumno. S tem ne samo povečate svojo verodostojnost preizkuševalca, temveč namesto simptoma poročate tudi o dejanski težavi.

Zdaj pa si oglejmo vsako področje, ki je vključeno v poročilo o napaki, in razpravljajmo o pomembnih vidikih vsakega od njih:

# 1. Povzetek napak

Povzetek napak naj vsebuje hiter posnetek, v čem je točno težava. Biti mora natančen in dobro usmerjen.

Primer :

Poleg teorije bom poskusil razložiti s primeri.

Predpostavimo preprost prijavni modul. Predpostavimo, da je težava, ker se novi uporabnik, ki obišče spletno mesto, ne more prijaviti s privzetim geslom. Ko sem mnogim študentom, ki sem jih treniral v začetni fazi usposabljanja, predstavil isti scenarij, je bilo več odgovorov kot povzetek napak. Spodaj je nekaj vzorcev, kako je izgledal povzetek:

aplikacija za brezplačno razporejanje objav v instagramu

' Nov uporabnik se ne more prijaviti '

'Uporabniška prijava ne deluje po pričakovanjih'

'Uporabnik se ne more prijaviti s pravilnim geslom'

povzetek napake napačno in pravilno

Ali lahko med zgornjimi vzorci izberete eno izjavo, ki dejansko opisuje težavo? Mislim, da ne. Povzetek mora vedno vsebovati popolne informacije o neuspešnem scenariju.

Upoštevajte naslednjo izjavo:

'Nov uporabnik se ne more prijaviti s privzetim geslom, posredovanim po e-pošti ali sms-u'

Kot lahko vidite, lahko razvijalci iz zgornje izjave jasno razumejo, v čem je težava in kje je težava.

Poskusite torej najti prave besede za opis povzetka, ki bi neposredno dajal informacije. Izogibati se je treba splošnim izjavam, kot so „ne deluje pravilno“, „ne deluje po pričakovanjih“ itd.

# 2. Koraki za reprodukcijo in priloge

Neponovljive napake se vedno znajdejo v ozadju, čeprav so lahko pomembne. Zato bodite pozorni, da pravilno in opisno napišete korake.

Koraki naj bodo natančni in popolnoma enaki tistim, ki so privedli do težave. Za napake, povezane s funkcionalnostjo, je najboljši primer naslednji vzorec.

Primer :

Razmislite o istem vprašanju, navedenem v prejšnjem poglavju.

  1. Ustvarite novega uporabnika z možnostjo Prijava na domači strani. (Vzorčno uporabniško ime: HelloUser)
  2. Prejeli boste e-pošto in SMS s privzetim geslom. E-poštni ID in mobilna številka za SMS sta na voljo med ustvarjanjem uporabnika v 1. koraku. (Vzorec e-pošte: HelloUser@hello.com , Vzorčna številka mobilnega telefona: 444-222-1123)
  3. Na domači strani izberite možnost Prijava.
  4. V besedilno polje uporabniškega imena vnesite vzorčno uporabniško ime, navedeno v 1. koraku.
  5. V polje za geslo vnesite privzeto geslo, prejeto po e-pošti ali SMS-u.
  6. Kliknite gumb Prijava
  7. Pričakovani rezultati: Uporabnik mora imeti možnost prijave z navedenim uporabniškim imenom in geslom ter se pomakniti do strani z uporabniškim računom.
  8. Dejanski rezultat: Prikaže se sporočilo »Neveljavno uporabniško ime / geslo«.

koraki poročila o napakah

Če katera od informacij ni navedena v zgornjem vzorcu, potem bo povzročijo vrzeli v komunikaciji in razvijalec ne bo mogel reproducirati težave. Koraki morajo biti natančni in podrobni z vzorčnimi podatki, ki jih uporabljate med testiranjem.

Če je mogoče ali kjer koli je primerno, navedite a posnetek tega, kar natančno vidite na zaslonu. Na ta način razvijalcem ne bo le dober pogled na težavo, temveč bo tudi dokaz vašega rezultata testa.

The nefunkcionalna testni primeri, kot so primeri stresa, stabilnosti ali uspešnosti, poleg zgornjih podrobnosti lahko informacije o scenariju, ki povzroča stres v sistemu, poroča takšne, kot so. Poleg tega je malo sistemov, ki poročajo dnevnike za vsako izvedeno operacijo. Dnevniki so običajno izjave za tiskanje, ki jih v svoji kodi navedejo razvijalci. Vsakič, ko se izvede modul, se ustrezni dnevniki natisnejo ali prikažejo. Ko so dnevniki na voljo, bi to razvijalcem v veliki meri pomagalo pri reprodukciji težave.

# 3. Obnovljivost hroščev

Veliko ali majhno vprašanje bo prednostno določeno glede na obnovljivost. Vidimo ga vedno, včasih, redko ali celo samo enkrat. Številka, ki se reproducira kot »vedno«, bo imela prednost pred ostalimi.

ne more reproducirati napake

Dolžnost preizkusnega inženirja je, da natančno sledi scenariju za težavo, ki se vedno reproducira. Včasih je nekaj preizkusnih inženirjev brez nadzora, zaradi česar bi se težava reproducirala le nekajkrat, vendar v več preskusih. V takih primerih vedno navedite število poskusov, izveden je določen scenarij, skupaj s številom primerov, ko je bila težava opažena med temi preizkušnjami.

To pa bi dodalo verodostojnost poročilu o napakah, ki ste ga omenili. Še enkrat, to bi izboljšalo vaš ugled preizkuševalca. Pozneje bi vam povedal razloge za dober ugled.

# 4. Resnost hroščev

Resnost je nedvomno eden največjih vplivov pri določanju hrošča.

Sledijo različne kategorije resnosti. Upoštevajte, da gre le za splošne vzorce in se od podjetja do podjetja razlikuje.

  1. Resnost 1 - Prikaži zamašek - za napake, ki so katastrofalne, brez odprave uporabnik ne bo mogel nadaljevati z uporabo programske opreme in ni možnih rešitev
  2. Resnost 2 - visoka - za napake, podobne resnosti 1, vendar obstaja rešitev
  3. Resnost 3 - srednja
  4. Resnost 4 - nizka
  5. Resnost 5 - malenkost.

Primerjajmo na primer dve podobni težavi.

V naših set-top boxih le malo ponudnikov storitev zagotavlja informacije o frekvenci storitve, kot je trenutno nastavljena. Predpostavimo, da je frekvenca prikazana kot 100 MHz namesto kot 100,20 MHz. To morda ne bo vplivalo na uporabnikov ogled storitev, lahko pa vpliva na nadzor diagnostike nastavitev. Zato je to mogoče predstaviti kot izdajo Severity 3.

Ob predpostavki podobne težave v bančni domeni: če je stanje na vašem računu prikazano kot 100 USD, namesto 100,20 USD, si predstavljajte vpliv težave. To mora biti napaka resnosti -1. Kot lahko vidite v obeh primerih, je težava zelo podobna, da uporabniški vmesnik ne prikazuje številk za decimalno vejico. Toda vpliv se razlikuje glede na zadevno domeno.

Učinkovito sodelovanje na sestankih za nadzor različic programske opreme

Običajno ima vsaka organizacija svoj postopek za raziskovanje in določanje prioritet hroščev. Na splošno bi se med projektom v določenih časovnih presledkih sestal sestanek, na katerem bi razpravljali o napakah in prednostno razporejali iste.

Postopek med takšnimi sestanki je naslednji:

  1. Poizvedite seznam napak v sistemu za upravljanje napak glede na resnost.
  2. Oglejte si povzetek in razpravljajte o vplivu napake na uporabniško izkušnjo pri uporabi programskega izdelka.
  3. Na podlagi ocene tveganja in vpliva določite prioriteto in napako dodelite ustreznemu razvijalcu za njeno odpravo.

Med 2. korakom je nujno, da vsak testni inženir zagovarja vpliv napake na uporabniško izkušnjo, če napaka ne dobi prednostne funkcije, ki si jo zasluži. Navsezadnje smo testni inženirji tisti, ki upoštevamo stališče uporabnika pri pisanju testnih primerov in testiranju izdelka.

Razmislite o zgornjem primeru težave, ko števke za decimalno vejico niso prikazane v bančni domeni. Razvijalcu se morda zdi manj resna težava. Lahko bi trdil, da bi namesto, da bi spremenljivko razglasil za celo število, to izjavil kot plavajočo vejico za rešitev težave in s tem manj resno.

Toda kot preizkuševalec vaša vloga razlaga situacijo stranke. Vaša točka bi morala biti, kako bi se uporabnik pritožil v tem primeru. Preizkuševalec naj pove, da bo to povzročilo paniko med uporabniki, saj kupec izgubi denar v centih.

Vpliv neustreznega trženja napake

Če se napaka ne trži pravilno, bo ustvarila težave, kot so:

  • Napačna prednostna napaka
  • Zamuda pri odpravljanju pomembnih težav
  • Sprostitev izdelka s hudimi napakami
  • Negativne povratne informacije strank
  • Razvrednotenje vrednosti blagovne znamke

Vpliv neustreznega trženja napake

Poleg vseh zgoraj omenjenih razlogov je zelo pomembno, da zgradite svoj sloves preizkusnega inženirja . To je bolj kot razvijanje vrednosti blagovne znamke zase.

Če lahko v začetni fazi kariere obdržite svoje število »Ne morem reproducirati« ali »Potrebujem več informacij« ali »Ni veljavna napaka« ali spremembe resnosti čim nižje, na enem mestu vaše napake ne bodo pod drobnogledom in bi bili neposredno dodeljeni ustreznemu razvijalcu, ki ga je treba popraviti.

Če želite razviti takšno vrednost blagovne znamke in pridobiti zaupanje svoje ekipe in razvojnih / ali vodstvenih skupin, morate razviti nekaj tehničnih veščin v smislu preverjanja znanja, domenskih in komunikacijskih veščin.

Zaključek

Vsak velik ali majhen izdelek ali storitev bo vedno zagotovo propadel brez ustreznega oglaševanja. Ko je blagovna znamka ustanovljena, je lahko vsak majhen izdelek super uspešnica za občinstvo.

Če omenimo, da lahko preveč oglaševanje izdelka škoduje tudi ugledu.

Torej, napako je treba vedno napisati na jasen, jedrnat in natančen način, tako da poda natančno lokacijo napake na obsežnem / izčrpnem zemljevidu programske opreme. Ponavljam, da to ne samo izboljšuje kakovost programske opreme, ampak tudi v veliki meri zmanjšuje stroške testiranja in razvoja programske opreme.

Zdaj ni prepozno! Gremo naprej in takoj odpravimo napake!

aplikacije, ki omogočajo prenos youtube videoposnetkov

Priporočeno branje

^