Meni

Umijeće prijavljivanja grešaka: Kako plasirati na tržište i popraviti svoje greške?

art bug reporting

Isprobajte Naš Instrument Za Uklanjanje Problema

Zašto postoji potreba za marketingom greške?

Prve stvari koje mi padnu na pamet kad započnem pisati ovaj članak su riječi Cem Kaner - “Najbolji ispitivač nije onaj koji pronađe najviše grešaka ili koji osramoti većinu programera. Najbolji je ispitivač onaj koji ispravi najviše bugova. '

Sad - u čemu je razlika pronalaženje većine bugova i popravljanje većine bugova ?

Nije li očito da je bilo koja greška prijavljena u sustav za upravljanje bugovima treba popraviti programer? Odgovor je ne. Čimbenici poput vremena za plasiranje proizvoda na tržište, vremena za završetak projekta prema rasporedu i programera koji rade u njemu nepraktični uski rasporedi itd. prisiljavaju tvrtke da puste proizvod s nekoliko grešaka koje neće u velikoj mjeri utjecati na korisnike.

Umjetnost prijavljivanja grešaka

(slika izvor )

Tko daje povjerenje menadžmentu navodeći da greške prisutne u proizvodu neće utjecati na povjerenje, pouzdanost i interes dionika? - Inženjer za ispitivanje ili tim za ispitivanje - dužnost je svakog inženjera za ispitivanje ispraviti programske pogreške koje bi mogle imati negativan utjecaj na kvalitetu proizvoda.

Prioritet buga , po mom mišljenju, uvelike ovisi o tome kako ispitivač prezentira problem timovima za razvoj i upravljanje.

Shvatite to kao oglašavanje ili marketing problema - to uključuje 2 koraka:

  1. Napišite ili ispravno prijaviti greške
  2. Znajte sve o grešci, tako da se daljnji detalji mogu bolje objasniti

Što ćete naučiti:

Umijeće prijavljivanja grešaka

Da, prijavljivanje grešaka je umjetnost . Način na koji je programska pogreška napisana pokazuje tehničku vještinu, stručnost domene i komunikacijske sposobnosti inženjera ispitivanja.

Tipično bug treba sadržavati sljedeće podatke:

  • Sažetak grešaka
  • Koraci za reprodukciju
  • Prilozi (snimka, datoteke dnevnika itd.,)
  • Mogućnost reprodukcije grešaka
  • Ozbiljnost bugova
  • Verzija softvera, Informacije o okolišu
  • Ostale informacije na temelju organizacijskih zahtjeva.

Važna napomena: Uvijek kopajte dublje kako biste pronašli osnovni uzrok problema i prijavili ga. Na primjer, jednostavan neuspjeh prijave s ispravnom kombinacijom korisničkog imena i lozinke može se povezati iz različitih razloga kao što su:

  1. Vjerodajnice za prijavu uopće nisu provjerene
  2. Problemi s mrežnim istekom u slučaju udaljenih prijava
  3. Sustav može sve CAPS smatrati ne-CAPS-ima.

Dakle, kao Tester trebali biste moći dešifrirati razlike dok slijedite sažetke izjava o programskim pogreškama:

  • 'Ne mogu se prijaviti s ispravnim korisničkim imenom i lozinkom'
  • 'Ne mogu se prijaviti s ispravnim korisničkim imenom i lozinkom kada korisničko ime ili lozinka sadrže kombinaciju CAPS i ne-CAPS abeceda.'

Potonji je vrlo jasan opis problema i nedvosmislen je. Ovim ne samo da povećavate svoju vjerodostojnost ispitivača, već i prijavljujete stvarni problem umjesto simptoma.

Sada, pogledajmo svako polje uključeno u izvještaj o programskoj pogrešci i raspravimo o važnim aspektima svakog od njih:

# 1. Sažetak grešaka

Sažetak programske pogreške trebao bi pružiti brzu snimku o čemu se točno radi. Mora biti precizan i dobro usmjeren.

Primjer :

Osim teorije, pokušat ću objasniti na primjerima.

Pretpostavimo da je to jednostavan modul za prijavu. Pretpostavimo da je problem budući da se novi korisnik koji posjećuje web mjesto ne može prijaviti sa svojom zadanom lozinkom. Kada sam predstavio isti scenarij mnogim studentima koje sam trenirao tijekom početne faze treninga, bilo je nekoliko odgovora kao sažetak grešaka. Slijedi nekoliko primjera kako je sažetak izgledao:

Java j2ee intervju pitanja i odgovori za iskusne

' Novi se korisnik ne može prijaviti ”

'Prijava korisnika ne radi kako se očekivalo'

'Korisnik se ne može prijaviti s ispravnom lozinkom'

sažetak pogrešaka pogrešno i ispravno

Možete li iz gornjih uzoraka odabrati jednu izjavu koja zapravo opisuje problem? Mislim da nije. Sažetak uvijek treba davati cjelovite informacije o neuspjelom scenariju.

Razmotrite sljedeću izjavu:

'Novi korisnik nije u mogućnosti prijaviti se zadanom lozinkom dostavljenom putem e-pošte ili SMS-a'

Kao što vidite, iz gornje izjave programer može jasno razumjeti u čemu je problem i gdje je problem.

Dakle, pokušajte pronaći prave riječi za opis sažetka koji bi izravno davali informacije. Moraju se izbjegavati generičke izjave poput 'ne radi ispravno', 'ne radi kako se očekivalo' itd.

# 2. Koraci za reprodukciju i privitke

Neponovljive bugove uvijek zaostaju iako su možda značajne. Stoga pripazite da korake napišete pravilno i opisno.

Koraci bi trebali biti točni i potpuno jednaki onima koji su doveli do problema. Za programske greške povezane s funkcionalnošću sljedeći je uzorak najbolji primjer.

Primjer :

Razmotrimo isto pitanje navedeno u prethodnom odjeljku.

  1. Stvorite novog korisnika pomoću opcije Registracija na početnoj stranici. (Uzorak korisničkog imena: HelloUser)
  2. Primit će se e-pošta i SMS sa zadanom lozinkom. ID e-pošte i broj mobitela za SMS pružaju se tijekom stvaranja korisnika u koraku # 1. (Primjer e-maila: HelloUser@hello.com , Uzorak broja mobitela: 444-222-1123)
  3. Odaberite opciju Prijava na početnoj stranici.
  4. U tekstualnom polju korisničkog imena navedite uzorak korisničkog imena naveden u koraku # 1.
  5. U polje za lozinku unesite zadanu lozinku primljenu e-poštom ili SMS-om.
  6. Kliknite gumb Prijava
  7. Očekivani rezultat: Korisnik bi trebao biti u mogućnosti prijaviti se s navedenim korisničkim imenom i lozinkom i prijeći na stranicu korisničkog računa.
  8. Stvarni rezultat: Prikazuje se poruka 'Nevažeće korisničko ime / lozinka'.

koraci izvješća o kvaru

Ako bilo koja informacija nije navedena u gornjem uzorku, tada će biti rezultirati komunikacijskim prazninama a programer neće moći reproducirati problem. Koraci moraju biti specifični i detaljni s uzorcima podataka koje koristite tijekom testiranja.

Ako je moguće ili gdje je to primjenjivo, navedite a snimak onoga što točno vidite na ekranu. Na taj će način razvojnim programerima pružiti ne samo dobar pogled na problem, već i dokaz vašeg rezultata testa.

The nefunkcionalan test slučajevi kao što su stres, stabilnost ili testovi performansi, osim gore navedenih detalja, informacije o scenariju koji uzrokuje stres u sustavu mogu se izvijestiti takvi kakvi jesu. Uz to, malo je sustava koji izvještavaju zapisnike za svaku izvršenu operaciju. Zapisnici su obično ispisi za izjave koje programeri pružaju u svom kodu. Kad god se modul izvrši, odgovarajući zapisnici bit će ispisani ili prikazani. Kada su dnevnici dostupni, to bi programerima u velikoj mjeri pomoglo u reprodukciji problema.

# 3. Obnovljivost grešaka

Pitanje koje je veliko ili malo imat će prioritet na temelju ponovljivosti. Može se vidjeti uvijek, ponekad, rijetko ili čak samo jednom. Broj koji se reproducira kao 'uvijek' bit će prioritet veći od ostatka.

ne mogu reproducirati kvar

Dakle, dužnost je inženjera ispitivanja pratiti scenarij točno za problem koji se uvijek reproducira. Ponekad može biti malo problema koji su izvan kontrole ispitivača, što bi rezultiralo time da se problem reproducira samo nekoliko puta, ali u više pokusa. U takvim slučajevima uvijek navedite broj pokusa, izvrši se određeni scenarij, zajedno s brojem prikaza problema tijekom tih pokusa.

To bi, pak, dodalo vjerodostojnost izvješću o greškama koje ste spomenuli. Opet, ovo bi poboljšalo vašu reputaciju ispitivača. Kasnije ću vam reći razloge dobre reputacije.

# 4. Ozbiljnost bugova

Ozbiljnost je nesumnjivo jedan od najvećih utjecaja na davanje prioriteta Bugu.

Slijede različite kategorije težine. Napominjemo da su ovo samo općeniti uzorci i oni se razlikuju od tvrtke do tvrtke.

  1. Ozbiljnost 1 - Prikaži zaustavljač - za bugove koji su katastrofalni, bez popravljanja, korisnik neće moći nastaviti koristiti softver i nema mogućeg rješenja
  2. Ozbiljnost 2 - visoka - za programske pogreške slične ozbiljnosti 1, ali postoji zaobilazno rješenje
  3. Ozbiljnost 3 - srednja
  4. Ozbiljnost 4 - niska
  5. Ozbiljnost 5 - trivijalno.

Na primjer, usporedimo dva slična problema.

U našim set-top boksovima, malo davatelja usluga pruža informacije o frekvenciji usluge kako su trenutno podešene. Pretpostavimo da se frekvencija prikazuje kao 100 MHz umjesto kao 100,20 MHz. To možda neće utjecati na korisnikov pregled usluga, ali može utjecati na nadzor dijagnostike postavljenih vrhova. Stoga se ovo može predstaviti kao problem ozbiljnosti 3.

Pod pretpostavkom sličnog problema u bankarskoj domeni: Ako je stanje vašeg računa prikazano kao 100 USD, umjesto 100,20 USD, zamislite utjecaj problema. Ovo mora biti greška ozbiljnosti -1. Kao što možete vidjeti u oba slučaja, problem je vrlo sličan tome što korisničko sučelje ne prikazuje znamenke nakon decimalne točke. No, utjecaj se razlikuje ovisno o domeni koja je u pitanju.

Učinkovito sudjelovanje na sastancima za kontrolu verzije softvera

Obično svaka organizacija ima svoj vlastiti postupak za ispitivanje i utvrđivanje prioriteta grešaka. Općenito, sastanak bi se održavao u određenim intervalima tijekom projekta kako bi se raspravljalo o programskim pogreškama i davalo se prioritetima.

Proces tijekom takvih sastanaka je sljedeći:

  1. Ispitajte popis bugova iz sustava za upravljanje bugovima prema težini.
  2. Pogledajte sažetak i razgovarajte o utjecaju programske pogreške na korisničko iskustvo u korištenju softverskog proizvoda.
  3. Na temelju procjene rizika i utjecaja postavite prioritet i dodijelite pogrešku odgovarajućem programeru za popravak istih.

Tijekom koraka 2 nužno je da svaki inženjer ispitivanja zastupa utjecaj programske pogreške na korisničko iskustvo ako programska pogreška ne dobije prioritet koji zaslužuje. Napokon, mi smo inženjeri koji ispituju stajalište korisnika da bi napisao slučajeve i testirao proizvod.

Razmotrite gornji primjer problema s neprikazivanjem znamenki nakon decimalne točke u bankarskoj domeni. Programeru se to može činiti kao manje ozbiljan problem. Mogao bi tvrditi da bi, umjesto da varijablu proglasi cijelim brojem, proglasio to pokretnom točkom za rješavanje problema, a time i manje ozbiljne.

Ali kao ispitivač, vaša uloga objašnjava situaciju kupca. Vaša bi poanta trebala biti kako bi se korisnik žalio u ovom scenariju. Tester bi trebao reći da će to izazvati paniku među korisnicima jer kupac novac gubi u centi.

Učinak nepropisnog oglašavanja programske pogreške

Ako se programska pogreška ne prodaje pravilno, stvorit će probleme poput:

  • Neispravan prioritet kvara
  • Kašnjenje u rješavanju važnih problema
  • Puštanje proizvoda s ozbiljnim nedostacima
  • Negativne povratne informacije kupaca
  • Devalviranje vrijednosti marke

Učinak nepropisnog oglašavanja programske pogreške

Pored svih gore spomenutih razloga, vrlo je važno izgraditi svoj reputacija inženjera ispitivanja . To je više poput razvijanja vrijednosti marke za sebe.

Ako u početnoj fazi svoje karijere budete mogli zadržati svoj broj 'Ne mogu reproducirati' ili 'Treba mi više informacija' ili 'Nije valjana greška' ili promjene ozbiljnosti što je moguće niže, u jednoj fazi vaše bugove neće biti pod nadzorom i oni bi bili izravno dodijeljeni odgovarajućem programeru da bi se popravio.

Da biste razvili takvu vrijednost marke i stekli povjerenje svog tima i razvojnih / ili upravljačkih timova, morate razviti neke tehničke vještine u smislu testiranja znanja, domene i komunikacijskih vještina.

Zaključak

Bilo koji proizvod ili usluga, bili oni veliki ili mali, uvijek će propasti bez odgovarajućeg oglašavanja. Jednom kada se marka uspostavi, bilo koji mali proizvod može biti super hit kod publike.

Uz to, pretjerano oglašavanje proizvoda također može naštetiti ugledu.

Dakle, programska pogreška uvijek treba biti napisana na jasan, sažet i precizan način tako da daje točnu lokaciju greške na opsežnoj / iscrpnoj programskoj mapi. Ponavljam da ovo ne samo da poboljšava kvalitetu softvera već u velikoj mjeri smanjuje troškove testiranja i razvoja softvera.

Sada nije prekasno! Krenimo i odmah popravimo bugove!

Primjer sortiranja mjehurića c ++

Preporučena literatura

^