this scenario explains how important it is document frequently encountered errors
Veríte tomu, že softvérové chyby sa vyskytujú iba raz a že pri opravách sa už neobjavia znova? Mám pocit, že asi 30% chýb sa opakuje.
V tomto článku by som chcel priblížiť, aké dôležité je zdokumentovať niektoré z často sa vyskytujúcich chýb.
Ďalej nájdete niektoré z nich spoločné priestory, v ktorých sa vyskytujú problémy a šablónu na ich zdokumentovanie.
Dúfam, že vám to bude užitočné!
obrázok zdroj
Scenár č. 1
Kód je nasadený a pripravený na kontrolu kvality. John, tester je pripravený na svoje testovacie prípady. Čiastočne v testovaní narazil na problém. Cíti, že si to všimli niekoľkokrát skôr, ale John nevedel, ako to vyriešiť.
John aj Sheryl išli hľadať Smitha, ktorý rovnakú chybu videl už skôr a predtým ju vyriešil. Ten deň bol, bohužiaľ, na dovolenke.
Čo by mal John urobiť teraz? Mal by sa John pokúsiť osloviť Smitha, aby našiel riešenie, aj keď Smith nie je k dispozícii?
Preto ak sa environmentálny problém vyskytuje opakovane vo viacerých vydaniach, je dobré zdokumentovať podrobnosti a umiestnite ho na zdieľané miesto. To eliminuje závislosť na ktoromkoľvek jednotlivcovi a pomôže všetkým členom tímu nájsť riešenie sami, keď sa to stane.
Scenár č. 2
John testuje nové vydanie a znova narazil na známu chybu. Tentoraz vie, že pre ňu bola vytvorená chyba v jednom z minulých vydaní. Otázka však znie: „Ako zistím číslo chyby a ďalšie súvisiace podrobnosti?“
Čo si myslíte, že by aj v tomto prípade pomohlo Johnovi?
- Poruchu hľadajte v Nástroj na sledovanie defektov s popisom?
- Hľadať celú minulosť správy o chybách ?
- Požiadať o pomoc vedenie jeho tímu?
Toto sú možnosti.
Ale podľa môjho názoru, ak sú tieto problémy dobre zdokumentované v samostatnej oblasti a zdieľané s tímom, zvyšuje to hodnotu a šetrí čas.
Čo sa dozviete:
- Niektoré z oblastí s častými chybami:
- Stiahnite si šablóny na sledovanie často sa vyskytujúcich chýb
- Výhody dokumentácie často sa vyskytujúcich chýb
- Záver
- Odporúčané čítanie
Niektoré z oblastí s častými chybami:
1) Súbor parametrov - Na základe mojich skúseností s nástrojom Informatica som si v mnohých prípadoch všimol, že súbor param ukazuje na nesprávne pripojenie DB. Výsledkom boli viackrát rovnaké problémy. Hlavným dôvodom bolo, že spojenie bolo zdieľané medzi dev a QA. Takže súbor param musel byť vždy aktualizovaný podľa potreby, aby sa zabránilo chybe.
2) URL smerujúce na nesprávnu databázu
3) Problémy s prístupom - Používatelia narazia na problémy, keď majú nedostatočné alebo nesprávne prístupové oprávnenia do databázy DB. V takom prípade by bol veľmi užitočný dokument s popisom krokov, ktoré je potrebné podniknúť, alebo s osobami, ktoré je potrebné kontaktovať.
4) Problém s testovacími údajmi - Používanie nesprávneho formátu alebo hodnôt údajov bude mať často za následok problémy.
5) Problémy s databázou - Jedným z bežných problémov je vypršané pripojenie DB. Niektoré prestoje sú dočasné, plánované a niekedy budeme možno potrebovať pomoc DBA. Používatelia sú vopred informovaní o plánovanej údržbe, avšak o dočasných chybách a riešení musia testeri určite vedieť
Väčšina opakovaných chýb je spravidla otázky životného prostredia .
Avšak problémy s kódom nemožno ignorovať. Vyššie uvedená diskusia je všeobecná a nezahŕňa problémy s kódom, pretože problémy s kódom sú konkrétnejšie pre vašu aplikáciu, rámec, programovací jazyk atď.
rozdiel medzi testovacím scenárom a testovacím prípadom
Malá oblasť defektov by tiež mohla byť chyba pri zadávaní údajov alebo ľudskom použití s .
Stiahnuť ▼Šablóny na sledovanie často sa vyskytujúcich chýb
Formát slova
=> Stiahnite si šablónu na sledovanie chýb (svet)
Formát Excel
=> Stiahnite si šablónu na sledovanie chýb (Excel)
Výhody dokumentácie často sa vyskytujúcich chýb
1) Eliminuje závislosť - V scenári 1 bol John závislý na riešení od Smitha. Keby existoval dokument na Johnovo odporúčanie, nebolo by to tak.
2) Rýchlejší obrat - Vezmime si scenár 2. Ak by existoval špeciálny dokument pre vysokofrekvenčné problémy, tester by nemusel prechádzať celým zoznamom už zaznamenaných defektov.
3) Pomáha novým členom tímu byť sebestačnými
4) Pomáha pri riešení ľudských chýb
Záver
Povedal by som, že je určite prospešné zdokumentovať častejšie problémy, pretože by to prinieslo vynikajúci odkaz a pridanú hodnotu.
Počas vykonávania testu môže byť zdĺhavé dokumentovať, ale ako osvedčený postup je možné počas vykonávania robiť hrubé poznámky, ktoré je možné neskôr zhrnúť a aktualizovať v zdieľaných dokumentoch.
Odporúčané čítanie
- 10 najlepších systémov na správu dokumentov pre lepší pracovný tok
- Aktualizácia MongoDB a odstránenie dokumentu s príkladmi
- Dokument dopytu MongoDB pomocou metódy Find () (príklady)
- Výukový program pre systém správy dokumentov SharePoint
- 7 typov softvérových chýb, ktoré by mal poznať každý tester
- Ako testovať inteligentnejšie: Preskúmajte viac, menej dokumentujte
- Scenár testu Vs Testovací prípad: Aký je rozdiel medzi nimi?
- Ako napísať dokument o stratégii testu (so vzorovou šablónou stratégie testovania)