Meni

Kaj storiti, ko ni dovolj časa za testiranje?

what do when there isn t enough time test

Ali se na koncu preizkusnega cikla pogosto zavedate, da nimate dovolj časa za testiranje? Za začetek ste imeli vse pod nadzorom, vendar kmalu dosežete načrt ukrepov ob nepredvidljivih dogodkih 'Kaj storiti, ko ni dovolj časa za testiranje?' oddelku.



Tudi jaz sem bil tam in ni zabavno. :)

O tem sem dolgo premišljeval. Kako lahko nekaj, kar se je začelo tako dobro, pade tako slabo, tako hitro. In tukaj je moja analiza.

=> Kliknite tukaj za celotno serijo vadnic o načrtu preizkusov



Kaj se boste naučili:

Kam je šel moj čas testiranja?

Ni dovolj časa za testiranje



Prvič, zakaj se to zgodi?Veliko razlogov, med katerimi so nekateri:

kako odpreti datoteko .dat?

# 1) Napačna ocena :

Če ste začeli z netočnim pričakovanjem, bodo stvari zagotovo propadle. Dobra ocena testa mora upoštevati naslednje:

  • Čas za pripravljalne naloge - Govorimo o nalogah, kot so:
    • Opredelitev in sestavljanje regresijske zbirke
    • Ustvarjanje testnih podatkov
    • Čas za določitev pripravljenosti na test (npr .: Test dima / zdrave pameti) itd.
  • Vzdrževanje testnih primerov : Testni primeri so sredstva za dolgoročno uporabo. Med izvajanjem bodo zagotovo deležni manjših posodobitev. Priporočljivo je, da za nove izdelke za te manjše vzdrževalne naloge namenite do 30% časa izvajanja testa. Vse ekipe in projekti morda ne bodo potrebovali 30%, vendar za to nalogo namenijo nekaj časa in truda.
  • Za to Raziskovalno preskušanje - Število skriptnih testov je glavni imenovalec števil za ocenjevanje testov. Vendar nobena preizkusna skupina na tem svetu ne bo zanikala raziskovanja vaše programske opreme, tudi če je model pretežno skriptiran.
  • Poročanje / komuniciranje - To vključuje triažne / stand-up sestanke, posodabljanje orodij za upravljanje dela itd.
  • Nepredvideni faktor: Standardi priporočajo 25–30% blažilnika glede na vaše prvotne ocene. A ekipe si tega le redko lahko privoščijo. Tudi takrat pustite malo prostora za dihanje, kadar je to mogoče.
  • Ekipa in njene zmogljivosti: Če imate novo ekipo ali če orodje uporabljajo prvič, boste morda morali nekaj časa rezervirati za trening. Prilagodite svoje ocene glede na svojo ekipo, s katero delate.

Priporočeno branje=> Preverite to za več informacij o uspehu in metodah ocene testa

# 2) Nestabilne gradnje in druge tehnične težave:

  • Napaka pri preskusu dima / zdravega razuma : Ko osnovni testi na AUT po neuspešnem uvajanju v QA-okolje ne uspejo, ekipa QA skoraj nič ne more storiti za izvajanje preizkusa. Res je, da lahko delamo na drugih nalogah, medtem ko se to zgodi, vendar kljub temu ne bo zapolnil preskusni cikel čas. Torej, to veliko prispeva k zapravljenemu času.
  • Podatki o preskusu ni na voljo : Podatki, podobni proizvodnji, so nujni za vsak testni projekt. Če tega ne dosežemo pravočasno v okolje za zagotavljanje kakovosti, je tudi drugi dejavnik, ki blokira. Včasih lahko preizkuševalci to rešijo ustvarjanje in upravljanje lastnih testnih podatkov , vendar je zamudno in morda ne bo vedno na mestu.
  • Okoljska vprašanja - Umestitve gradnje so neuspešne, strežnik je vedno časovno omejen, veliko več takšnih težav vam poje testni cikel. To verjetno izhaja iz dejstva, da nekatera podjetja (ne vsa) spodkopavajo pomen dobrega, živega okolja za učinkovito zagotavljanje kakovosti. Pogosto poskušajo pobegniti z nizko zmogljivimi strežniki in napravami za pripravljanje. To je res kratek popravek in nikomur ne nakloni. Pravzaprav bi jih to lahko stalo kakovosti testiranja in izgube dragocenega časa za testiranje.

# 3) Pomanjkanje dogovora med vsemi vpletenimi stranmi:

To je lahko redka težava pri ekipah, ki spremljajo Agile oz VARNO zaradi ožjih krogov, v katerih delajo, a številne ekipe še vedno trpijo zaradi nestrinjanja ali napačne komunikacije glede tega, kdaj naj bi Dev, Ops in QA medsebojno prejemali rezultate. Zato zamude.

Če želite razumeti komunikacijske tankosti, preverite to => Kako lahko podjetja, razvoj in zagotavljanje kakovosti sodelujejo pri dokončanju projekta

Zdaj, ko težave poznamo, je nekaj načinov, kako jih odpraviti.

Kako lahko preizkuševalci dobijo dovolj časa za testiranje?

# 1) Natančno ocenite. V dvomih pretirano ocenite, vendar ne podcenjujte. Ne pozabite narediti prilagoditev ocen glede na svojo ekipo, orodja in procese. Ko končate, poiščite uradno odjavo, da se bodo vsi zavedali in bodo obveščeni.

kako odpreti jar datoteko windows 10

#two) Upoštevajte zgodovinske podatke - Orodje Test Management je vaš najboljši prijatelj .

  • Kako dolgo so trajali preskusni cikli prejšnjih izdaj?
  • Kakšne težave so povzročile prekinitve prejšnjega preskusnega cikla?
  • Koliko voženj je opravilo večino testnih primerov, preden so minili?
  • Katere napake so bile prijavljene?
  • Katere napake so povzročile prekinitev testiranja?

# 3) Zastavite ta vprašanja in v skladu s tem načrtujte v času krčenja:

  • Ugotovite Pomembna funkcionalnost je vaš projekt?
  • Ugotovite modul projekta z visokim tveganjem?
  • Katera funkcionalnost je uporabniku najbolj vidna?
  • Katera funkcionalnost ima največji varnostni vpliv?
  • Katera funkcionalnost ima največji finančni vpliv na uporabnike?
  • Kateri vidiki aplikacije so za kupca najpomembnejši?
  • Kateri deli kode so najbolj zapleteni in zato najbolj izpostavljeni napakam?
  • Kateri deli aplikacije so bili razviti v načinu hitenja ali panike?
  • Kaj razvijalci menijo, da so vidiki aplikacije najbolj tvegani?
  • Kakšne težave bi povzročile najslabšo reklamo?
  • Katere težave bi povzročile največ pritožb v zvezi s storitvami za stranke?
  • Katere vrste testov bi lahko zlahka zajemale več funkcionalnosti?

Upoštevajoč te točke lahko močno zmanjšate tveganje, da se projekt sprosti pod manj časa.

# 4) Uporabite orodje za upravljanje testov. To bo znatno zmanjšalo količino časa in truda za pripravo, poročanje in vzdrževanje.

=> Seznam najbolj priljubljenih orodij za upravljanje testov , preverite tukaj :

# 5) Glede nepravilne gradnje / tehničnih težav ne moremo storiti veliko, toda ena stvar, ki lahko pomaga, je pogled na rezultate preskusa enote. To nam bo dalo idejo, ali je bila gradnja uspešna ali ne in kakšni testi niso uspeli - zato kolesa ne izumimo znova.

Če tvoj Test Management Tool podpira CI integracija , imate te informacije na voljo brez kakršnih koli težav, tako da bolje razumete stabilnost aplikacije.

# 6) Pogosto merite svojo produktivnost in napredek . Ne dovolite, da poročila o stanju prinesejo rezultate samo v korist zunanjih skupin. Prepričajte se, da natančno spremljate svoje dnevne cilje in svojo sposobnost, da jih dosežete.

Pazite tudi, da se ne spustite v klasično uganko 'hitrost proti kakovosti'. Ker ko na primer prijavite recimo 50 hroščev na dan, se vam zdi, kot da ste super produktivni. Če pa se večina od njih vrne kot neveljavna, imate težave.

Torej spremljajte, spremljajte in spremljajte še malo :)

Zaključek:

Končno, kljub vsem varnostnim ukrepom in ukrepom, če se še vedno znajdete zdrobljeni za čas, prosite za pomoč .

Večina ekip je pripravljena sodelovati na zasedanju vojne sobe, da se stvari spet vrnejo na pravo pot.

O avtorju: Te koristne nasvete za testiranje ponuja član ekipe STH Swati S.

Kateri so vaši triki, da ostanete pravočasno in zagotovite kakovostno storitev testiranja? Katere točke v zgornjem članku vas resnično odmevajo?

Cenimo vaše povratne informacije in cenimo vaše bralstvo. Hvala za branje!

=> Obiščite tukaj za popolno serijo vadnic o načrtu preizkusov

Priporočeno branje



^