this scenario explains how important it is document frequently encountered errors
Верујете ли да се софтверске грешке јављају само једном и да се након поправљања никада више неће појавити? Осећам да се око 30% грешака понавља.
У овом чланку желим да објасним колико је важно документовати неке од често наилазећих грешака.
Испод ћете пронаћи неке заједничке области у којима се виде проблеми и образац за њихово документовање.
Надам се да ће вам бити од помоћи!
слика извор
Сценарио # 1
Код је постављен и спреман за КА. Јохн, тестер је спреман за тестове. Делимично пролазећи кроз тестирање, наишао је на проблем. Осећа да је то примећено неколико пута раније, али Џон није знао како да то реши.
И Јохн и Схерил отишли су да потраже Смитха који је раније видео исту грешку и раније је решио. На несрећу, Смитх је тог дана био на одсуству.
Шта би Јохн сада требало да уради? Да ли би Јохн требало да покуша да се обрати Смитху како би пронашао решење чак и када Смитх није доступан?
Стога, ако се проблем заштите животне средине више пута виђа у више издања, добра је идеја да документујете детаље и поставите га на заједничку локацију. Ово ће елиминисати зависност од било ког појединца и помаже свим члановима тима да сами пронађу решење када се то догоди.
Сценарио # 2
Џон тестира ново издање и поново наилази на познату грешку. Овог пута зна да му је у једном од прошлих издања створен недостатак. Али питање је: „како да пронађем број квара и друге повезане детаље?“
И у овом случају, шта мислите да би помогло Џону?
- Потражите квар у Алат за праћење недостатака са описом?
- Претражите све прошлости извештаји о недостацима ?
- Приступити вођи његовог тима за помоћ?
То су могућности.
Али по мом мишљењу, ако су такви проблеми добро документовани у посебном подручју и подељени са тимом, то додаје вредност и штеди време.
Шта ћете научити:
- Неке од области са честим грешкама:
- Преузмите предлошке за праћење грешака које се често сусрећу
- Предности документовања грешака које се често сусрећу
- Закључак
- Препоручено читање
Неке од области са честим грешкама:
1) Датотека параметара - На основу мог искуства са алатком Информатица, у многим случајевима сам приметио парам датотеку која указује на нетачну ДБ везу. Довело је до истих проблема више пута. Главни разлог је био тај што су везу делили дев и КА. Дакле, парам датотека се увек морала ажурирати у складу са потребама како би се избегла грешка.
2) УРЛ који упућује на нетачан ДБ
3) Проблеми са приступом - Корисници наилазе на проблеме када имају недовољне или нетачне дозволе за приступ ДБ-у. У овом случају, документ који описује кораке које треба предузети или особа / особе које треба контактирати био би од велике помоћи.
4) Издавање података о тестирању - Коришћење нетачног формата или вредности података чешће доводи до проблема.
5) ДБ издања - Истекло је ограничење ДБ везе један од таквих честих проблема. Неки застоји су привремени, планирани и понекад ће нам можда требати помоћ ДБА-е. Корисници су унапред обавештени о планираном одржавању, али за привремене грешке и решење, тестери свакако требају
Већина поновљених грешака је углавном еколошки проблеми .
Међутим, издавања кода не може се занемарити. Горња дискусија је генеричка и не укључује проблеме са кодом јер су проблеми с кодом специфичнији за вашу апликацију, оквир, програмски језик итд.
обриши елемент из низа јава
Такође би могла бити и мала површина дефеката унос података или грешка у коришћењу људи с .
ПреузимањеПредлошци за праћење грешака које се често сусрећу
Формат речи
=> Преузми образац за праћење грешака (Свет)
Екцел формат
=> Преузми образац за праћење грешака (Екцел)
Предности документовања грешака које се често сусрећу
1) Елиминише зависност - У сценарију 1, Јохн је зависио од Смитха због решавања. Да постоји документ за Јованову референцу, то не би био случај.
2) Бржи преокрет - Узмимо сценарио 2. Испитивач не би морао да прође кроз целу листу већ евидентираних кварова ако постоји наменски документ за високофреквентне проблеме.
3) Помаже да нови чланови тима буду самозадовољни
4) Помаже у решавању људских грешака
Закључак
Рекао бих да је дефинитивно корисно документовати све чешће проблеме, јер би то представљало дивну референцу и додало вредност.
Документирање може бити заморно док је извођење теста у току, али као најбоља пракса, током извођења могу се правити грубе белешке које се касније могу резимирати и ажурирати у заједничким документима.
Препоручено читање
- 10 најбољих система за управљање документима за бољи ток посла
- МонгоДБ Ажурирање и брисање докумената са примерима
- МонгоДБ документ са упитом помоћу методе Финд () (примери)
- Водич за систем управљања СхареПоинт документима
- 7 врста софтверских грешака које би сваки тестер требао знати
- Како тестирати паметније: истражите више, мање документујте
- Тест сценариј против тест случаја: Која је разлика између њих?
- Како написати документ стратегије тестирања (са узорком предлошка стратегије тестирања)