this scenario explains how important it is document frequently encountered errors
Gelooft u dat softwarefouten maar één keer voorkomen en dat ze na het oplossen nooit meer de kop opsteken? Ik denk dat ongeveer 30% van de fouten opnieuw optreden.
In dit artikel wil ik bespreken hoe belangrijk het is om enkele van de vaak voorkomende fouten te documenteren.
Hieronder vindt u er enkele gemeenschappelijke ruimtes waar problemen worden gezien en een sjabloon om ze te documenteren.
Ik hoop dat je het nuttig zult vinden!
beeld bron
Scenario 1
Code is geïmplementeerd en klaar voor QA. John, de tester is klaar met zijn testcases. Halverwege het testen komt hij een probleem tegen. Hij heeft het gevoel dat het al verschillende keren eerder is opgemerkt, maar John wist niet hoe hij het moest oplossen.
Zowel John als Sheryl gingen op zoek naar Smith die dezelfde fout eerder had gezien en eerder had opgelost. Helaas had Smith die dag verlof.
Wat moet John nu doen? Moet John proberen contact op te nemen met Smith om een oplossing te vinden, zelfs als Smith niet beschikbaar is?
Daarom, als een milieuprobleem herhaaldelijk wordt gezien in meerdere releases, het is een goed idee om de details te documenteren en plaats het op een gedeelde locatie. Dit elimineert de afhankelijkheid van één persoon en helpt alle teamleden om zelf een oplossing te vinden wanneer dit gebeurt.
Scenario # 2
John test een nieuwe release en komt opnieuw een bekende fout tegen. Dit keer weet hij dat er in een van de vorige releases een defect voor is gemaakt. Maar de vraag is: 'hoe vind ik het defectnummer en andere bijbehorende details?'
Wat denk je dat John ook in dit geval zou helpen?
- Zoek het defect in Foutopsporingstool met de beschrijving?
- Doorzoek het verleden defectrapporten
- Benader je zijn teamleider voor hulp?
Dit zijn mogelijkheden.
Maar naar mijn mening, als dergelijke problemen goed worden gedocumenteerd in een apart gebied en worden gedeeld met het team, voegt het waarde toe en bespaart het tijd.
Wat je leert:
- Enkele van de gebieden met veel voorkomende fouten:
- Download sjablonen om vaak voorkomende fouten bij te houden
- Voordelen van het documenteren van vaak voorkomende fouten
- Gevolgtrekking
- Aanbevolen literatuur
Enkele van de gebieden met veel voorkomende fouten:
1) Parameterbestand - Gebaseerd op mijn ervaring met de Informatica-tool, heb ik in veel gevallen opgemerkt dat het param-bestand naar een onjuiste DB-verbinding verwijst. Het heeft meerdere keren tot dezelfde problemen geleid. De belangrijkste reden was dat de verbinding werd gedeeld tussen dev en QA. Het param-bestand moest dus altijd worden bijgewerkt volgens de behoeften om de fout te voorkomen.
2) URL die verwijst naar onjuiste database
3) Toegangsproblemen - Gebruikers komen in de problemen wanneer ze onvoldoende of onjuiste toegangsrechten tot de database hebben. In dit geval zou een document met de te nemen stappen of de te contacteren persoon / personen super nuttig zijn.
4) Probleem met testgegevens - Het gebruik van een onjuist formaat of waarden van gegevens zal vaker wel dan niet tot problemen leiden.
5) DB-problemen - Een time-out van de DB-verbinding is zo'n veel voorkomend probleem. Een deel van de downtime is tijdelijk, gepland en soms hebben we de hulp van DBA nodig. Gebruikers worden vooraf op de hoogte gebracht voor gepland onderhoud, maar voor tijdelijke fouten en oplossingen hebben de testers zeker behoefte
De meeste herhaalde fouten zijn over het algemeen milieu problemen
Echter, code problemen kan niet worden genegeerd. De bovenstaande bespreking is algemeen en omvat geen codeproblemen omdat codeproblemen specifieker zijn voor uw toepassing, framework, programmeertaal, enz.
youtube video-downloader-app voor pc
Een klein gebied met defecten kan ook zijn gegevensinvoer of fout van menselijk gebruik s
DownloadenSjablonen om vaak voorkomende fouten bij te houden
Word-indeling
Foutopsporingssjabloon downloaden (Wereld)
Excel-indeling
Foutopsporingssjabloon downloaden (Excel)
Voordelen van het documenteren van vaak voorkomende fouten
1) Elimineert afhankelijkheid - In scenario 1 was John afhankelijk van Smith voor een oplossing. Als er een document was geweest ter referentie van John, zou dat niet het geval zijn.
2) Snellere doorlooptijd - Neem scenario 2. Een tester zou niet de volledige lijst van reeds geregistreerde defecten hoeven te doorlopen als er een speciaal document was voor hoogfrequente problemen.
3) Helpt nieuwe teamleden om zelfvoorzienend te zijn
4) Helpt bij het oplossen van menselijke fouten
Gevolgtrekking
Ik zou zeggen dat het zeker nuttig is om de vaker voorkomende problemen te documenteren, aangezien het een prachtige referentie en een meerwaarde zou zijn.
Het kan vervelend worden om te documenteren terwijl de test wordt uitgevoerd, maar als best practice kunnen tijdens de uitvoering ruwe notities worden gemaakt die later kunnen worden samengevat en bijgewerkt in gedeelde documenten.
Aanbevolen literatuur
- 10 beste documentbeheersystemen voor een betere workflow
- MongoDB Update en verwijder document met voorbeelden
- MongoDB-querydocument met behulp van de methode Find () (voorbeelden)
- SharePoint Document Management System-zelfstudie
- 7 soorten softwarefouten die elke tester moet weten
- Slimmer testen: meer ontdekken, minder documenteren
- Testscenario versus testcase: wat is het verschil tussen deze twee?
- Hoe een teststrategiedocument te schrijven (met voorbeeldteststrategiesjabloon)