Menu

Documentatiegids voor softwaretests (waarom het belangrijk is)

software testing documentation guide

Probeer Ons Instrument Voor Het Oplossen Van Problemen

In mijn carrière als softwaretest heb ik nog nooit mensen horen praten over documentatie over softwaretests. De algemene mening over testdocumentatie is dat iedereen die vrije tijd heeft, de documentatie kan doen, zoals een testcase, testplan, statusrapport, bugrapport, projectvoorstel, etc.

Zelfs ik beklemtoonde niet meer over de documentatie, maar ik kan zeggen dat het mijn gewoonte is om alle gegevens in zwart-wit te plaatsen en anderen daarover ook op de hoogte te houden.

Software Testing Documentation Guide (Why It

Wat je leert:

Mijn ervaring

Ik wil gewoon mijn ervaring met je delen:

We hadden een project (met een onbekend probleem daarin) opgeleverd aan een van onze klanten (boze klant). En ze vonden het probleem bij de klant, wat een zeer slechte situatie voor ons was, en zoals gewoonlijk lag alle schuld bij QA's.

Het probleem was iets met betrekking tot de compatibiliteit van één website. Toen het op mij aankwam, had ik het bewijs dat ik niet zo'n vereiste document had gekregen waarin staat dat ik ook de compatibiliteit van de website moet controleren. Godzijdank was ik veilig.

Dat was de les voor mij, ik realiseerde me het belang van documentatie en vanaf die dag begon ik aan documenten te werken en testdocumenten te maken, zoals testplan, testcases, checklist voor gezond verstand, bugrapport en nog veel meer.

'Inkt is beter dan het beste geheugen' - Chinees gezegde

Testdocumentatie: wat is dat?

We lezen allemaal verschillende artikelen over testtechnologieën en -methoden, maar hoeveel van ons hebben artikelen over documentatie gezien? Ongetwijfeld zijn er maar weinig. Zijn documenten niet belangrijk? Nee, maar dat komt omdat we ons het belang van documenten nog niet hebben gerealiseerd.

Maar als we observeren, is het een feit, projecten met alle documenten hebben een hoge mate van volwassenheid.

De meeste bedrijven hechten niet eens zo veel belang aan de documentatie als aan het softwareontwikkelingsproces. Als we op internet zoeken, kunnen we verschillende sjablonen vinden voor het maken van verschillende soorten documenten. Maar hoeveel ervan worden echt gebruikt door organisaties of individuen?

oracle sql interviewvragen en antwoorden voor 3 jaar ervaring

Het feit is dat zorgvuldige documentatie kan een organisatie tijd, moeite en geld besparen.

Hoewel er voor elk type certificering wordt gekozen, waarom wordt er nadruk gelegd op documentatie, is dat gewoon omdat het het belang van de klant en processen voor individu en organisatie laat zien. Tenzij u in staat bent om een ​​document te produceren dat comfortabel is voor de gebruiker, hoe goed uw product ook is, zal niemand het accepteren.

Het is mijn ervaring, we hebben één product dat een beetje verwarrende functionaliteit heeft.

Toen ik eraan begon te werken, vroeg ik de Manager om enkele hulpdocumenten en ik kreeg het antwoord: 'Nee, we hebben geen documenten'. Toen maakte ik daar een punt van omdat ik als QA wist dat niemand kan begrijpen hoe gebruik het product zonder documenten of training. En als de gebruiker niet tevreden is, hoe gaan we dan geld verdienen aan dat product?

“Gebrek aan documentatie wordt een acceptatieprobleem” - Wietse Venema

Zelfs hetzelfde is van toepassing op gebruikershandleidingen. Neem een ​​voorbeeld van Microsoft, ze lanceren elk product met de juiste documenten, zelfs voor Office 2007 hebben we dergelijke documenten, die zeer verklarend en gemakkelijk te begrijpen zijn voor elke gebruiker. Dat is een van de redenen waarom al hun producten succesvol zijn.

In kleine bedrijven hoorden we altijd 'afgekeurde projecten in de voorstel- of startfase', alleen omdat de documentatie van het voorstel niet beknopt en expressief is, en om de bekwaamheid van de organisatie te laten zien.

vr-headset voor pc en ps4

Het is niet zo dat kleine bedrijven geen projecten van goede kwaliteit kunnen leveren, maar het is hun onvermogen om hun bekwaamheid tot uitdrukking te brengen. (Ik werk ook met een kleine organisatie van 80 werknemers, en ik heb dit vaak gehoord)

Persoonlijk vind ik dat Kwaliteit de enige afdeling is die dit mogelijk maakt. Wij zijn de enige afdeling die hierover kan discussiëren en onze organisaties een succesvolle toekomst kunnen bieden.

Laten we alle discussies in kwaliteitsperspectief op een paar punten organiseren:

- Kwaliteitsdoelstelling en -methoden verduidelijken
- Zorg voor duidelijkheid over taken en consistente prestaties
- Zorg voor interne coördinatie bij het werk van de klant
- Feedback geven over preventieve maatregelen
- Geef feedback voor uw planningscyclus
- Creëer objectief bewijs van de prestaties van uw kwaliteitsmanagementsysteem

10 tips om u te helpen het doel van de testdocumentatie te bereiken

Zoals ik in mijn eerdere bericht al zei, is het begrip over documentatie over softwaretests in het algemeen: 'Het kan alleen worden gedaan door de persoon die vrije tijd heeft'. We moeten deze manier van denken veranderen, en alleen dan kunnen we de documentatiekracht van onze projecten gebruiken.

Het is niet dat we niet weten hoe we de documentatie goed moeten doen. We vinden het gewoon niet belangrijk.

Iedereen moet beschikken over standaardsjablonen voor alle soorten documentatie, van teststrategie, testplan, testcases en testgegevens tot het bugrapport.

Dit zijn slechts om enkele standaarden te volgen (CMMI, ISO, etc.) maar als het gaat om de daadwerkelijke implementatie, hoeveel van deze documenten worden echt door ons gebruikt? We hoeven alleen ons kwaliteitsproces te synchroniseren met documentatiestandaarden en een ander proces in een organisatie.

Het eenvoudigste is om allerlei soorten documentatie te volgen is het betrekken van een persoon bij het project vanaf de kick-off fase die de projectdynamiek, het domein, de doelstelling en de technologie begrijpt. En wie anders beter dan een QA-persoon hiervoor (er zijn natuurlijk technische schrijvers aanwezig om dit te doen - maar gezien een algemeen scenario van kleine bedrijven waar technische schrijvers niet aanwezig zijn).

Om dit doel van testen en documenteren te bereiken, denk ik dat we ons op een aantal punten moeten concentreren.

Hier zijn de 10 beste tips om u te helpen het doel van de testdocumentatie te bereiken:

# 1) QA moet in de allereerste fase van het project worden betrokken, zodat QA en documentatie hand in hand gaan.

#twee) Het proces dat door QA is gedefinieerd, moet worden gevolgd door technische mensen, dit helpt de meeste defecten in een zeer beginstadium te verwijderen.

# 3) Alleen creëren en onderhouden Sjablonen voor softwaretests is niet genoeg, mensen dwingen om ze te gebruiken.

# 4) Maak niet alleen het document en laat het achter, werk het bij wanneer dat nodig is.

# 5) Veranderingsvereiste is een belangrijke fase van het project, vergeet niet om ze aan de lijst toe te voegen.

# 6) Gebruik versiebeheer voor alles. Dit zal u helpen uw documenten gemakkelijk te beheren en te volgen.

# 7) Maak het herstelproces van defecten eenvoudiger door alle defecten te documenteren. Zorg ervoor dat u een duidelijke beschrijving van het defect bijvoegt, de stappen, het getroffen gebied en details over de auteur reproduceert terwijl u een defect documenteert.

# 8) Probeer te documenteren wat u nodig heeft om uw werk te begrijpen en wat u indien nodig voor uw belanghebbenden moet produceren.

java 8 interviewvragen en antwoorden

# 9) Gebruik de standaardsjabloon voor documentatie. Zoals elke Excel-bladsjabloon of doc-bestandssjabloon en houd u eraan voor al uw documentbehoeften.

# 10) Deel alle projectgerelateerde documenten op één locatie, die voor elk teamlid toegankelijk is als referentie en om ze indien nodig bij te werken.

Ik zeg niet dat je door het toepassen van stappen plotselinge resultaten zult krijgen. Ik weet dat deze verandering niet binnen een dag of twee zal plaatsvinden, maar we kunnen tenminste beginnen zodat deze veranderingen langzaam beginnen.

Immers “de documentatie heeft documentatie nodig”. Is het niet?

Er zijn honderden documenten die worden gebruikt in de levenscyclus van softwareontwikkeling en testen.

Belangrijke testdocumenten voor software

Hier noem ik enkele belangrijke software-testdocumenten die we regelmatig moeten gebruiken / onderhouden:

1) Testplan
2) Testontwerp en Test Case Specificatie
3) Teststrategie
4) Testoverzichtsrapporten
5) Wekelijks statusrapport
6) Gebruikersdocumenten / handleidingen
7) Gebruikersacceptatierapport
8) Risicobeoordeling
9) Testlogboek
10) Foutmeldingen
elf) Testgegevens
12) Testanalyse

Softwaretesters moeten ook regelmatig de volgende documenten raadplegen:
1) Specificaties softwarevereisten
2) Functionele documenten

Gevolgtrekking

Software Testing Documenten spelen altijd een belangrijke rol in de Projectontwikkeling / Testfase. Houd de zaken dus altijd waar mogelijk gedocumenteerd. Vertrouw niet op verbale communicatie. Wees altijd aan de veilige kant.

Documentatie bespaart u niet alleen, maar helpt de organisatie ook op de lange termijn duizenden dollars te besparen op training en, nog belangrijker, op het oplossen van problemen die worden veroorzaakt door een gebrek aan ontwikkelings- en testdocumenten.

Documenteer niet alleen om te voorkomen dat u met de vinger naar u wijst, maar de gewoonte van documentatie zal zeker een systematische benadering van uw testproces met zich meebrengen, waarbij het ad-hoc testen achter u blijft.

Over de auteur: Dit artikel is geschreven door STH-teamlid Tejaswini. Ze werkt als QA-manager in een organisatie.

Welke andere documenten onderhoudt u bij uw dagelijkse testactiviteiten?

Aanbevolen literatuur

^