5 belangrijke diagrammen die testers moeten leren gebruiken

5 important diagrams that testers need learn how use

Als er geen foto's waren, waren er geen opnames van vroege geschiedenis, redelijke kennis en evolutie van taal.

Niet overdreven dramatiserend, maar diagrammen hebben hun eigen speciale plaats, zelfs in een wereld met hoogontwikkelde en geavanceerde vormen van schrijven en expressie.

In de technologische industrie zijn onze diagrammen ons dierbaar.

Hier zijn enkele van de prominente waarmee wij testers vaak in nauw contact komen en hoe we ze gebruiken.

Wat je leert:

• 5 diagrammen die testers moeten leren gebruiken
• # 1) Stroomdiagrammen:
• # 2) Staatsovergangsdiagrammen:
• # 3) Contextdiagrammen:
• # 4) Mindmaps:
• # 5) ER-grafieken:
• # 6) Bonus: bespeel schermen / wireframes:
• Om af te sluiten - Hoe kunt u deze diagrammen maken als dat nodig is?
• Aanbevolen literatuur

5 diagrammen die testers moeten leren gebruiken

Daar gaan we.

# 1) Stroomdiagrammen:

Stroomdiagrammen zijn het beste voor procesillustraties. Ze gebruiken specifieke symbolen voor elke taak / type actie die binnen het proces wordt uitgevoerd. Het maakt beslissingen, vertakkingen, loops etc. mogelijk, waardoor het een perfect hulpmiddel is voor documentatie en begrip.

De testers vinden de stroomschema's meestal in het testplan, de teststrategie, requirementsartefacten (BRD, FRD, etc.) of andere procesdocumenten.

De meest gebruikte symbolen en hun betekenis in een stroomschema zijn:

• Ovalen Voor start en stop
• Rechthoeken Voor verwerking / of een taak
• Diamant- Voor beslissingen

Voor volledige informatie over stroomdiagramvormen, ga naar Stroomdiagram symbolen ​

Het is supereenvoudig om een ​​proces of controlestroom te begrijpen via een stroomschema. Het helpt bij het onthouden, begrijpen en dient als een snelle referentie.

Lees ook => Hoe complexe testscenario's voor bedrijfslogica te schrijven met behulp van de beslissingstabeltechniek

Hier zijn twee manieren waarop wij testers stroomdiagrammen gebruiken:

a) Stroomdiagrammen voor controlestroom en statistische analyse:

Cyclomatische complexiteit is een statistiek die ons helpt te meten hoe complex een bepaald softwareprogramma is. Een van de toepassingen van het kennen van de cyclomatische complexiteit is dat het ons helpt te begrijpen in welke mate eenheidstests moeten worden uitgevoerd om een ​​volledige dekking te verkrijgen (meer informatie en links hieronder).

Stroomschema is een go-to-methode om tot deze maatregel te komen.

Laten we leren hoe we de cyclomatische complexiteit kunnen berekenen voor het volgende programma via een controlestroomschema.

Maak eenvoudig een controlestroomschema zoals hieronder weergegeven en gebruik deze formule:

Cyclomatische complexiteit: = Aantal verbindingen of lijnen - aantal knooppunten + 2

Uit het diagram is het aantal knooppunten 7 en verbindingen 7.

Daarom is de cyclomatische complexiteit van dat stuk code 7-7 + 2 = 2.

Wilt u meer informatie over het gebruik van het controlestroomschema en de cyclomatische complexiteit?

Bekijk dit eens:

• Correlatie tussen cyclometrische complexiteit en codedekking tijdens het testen van de witte doos
• De cyclomatische complexiteit van McCabe en waarom we die niet gebruiken

b) Stroomdiagrammen ter illustratie van het proces:

Het volgende is een proces voor het opsporen van defecten, weergegeven in een stroomschema. Zoals je kunt zien, is het super gemakkelijk te absorberen en te implementeren:

​Notitie:Klik op de afbeelding voor de vergrote weergave)

# 2) Staatsovergangsdiagrammen:

Statusovergangstabellen of -diagrammen zijn geweldige analysehulpmiddelen wanneer u naar complexe systemen kijkt die veel veranderingen ondergaan van de ene staat naar de andere.

Voor die beginners die denken, ‘wat is toestandsovergang?’ - Denk aan een gloeilamp die wordt bestuurd door een schakelaar. Een schakelaar kan AAN / UIT worden gezet. Dus de toestand dat een gloeilamp op een bepaald moment kan zijn, is AAN of UIT en de gebeurtenis / actie waardoor deze van de ene toestand naar de andere overgaat, is het omdraaien van de schakelaar.

Dit kan worden weergegeven in de vorm van een diagram of een tabel. Zoals hieronder:

Simpel, is het niet? Laten we iets ingewikkelder aanpakken. Bekijk een toestandsovergangsdiagram voor een ticketingsysteem. Het is vrij eenvoudig en gemakkelijk te begrijpen.

Houd er rekening mee dat toestandsovergangsdiagrammen meestal bedrijfsentiteitgericht zijn en niet visueel, pagina voor pagina-navigatie gericht.

Bijvoorbeeld: De kernactiviteit in ons geval is het ticket zelf dat via de applicatie wordt aangemaakt. Het eerste deel, het maken van het ticket, zou kunnen bestaan ​​uit het navigeren door het systeem door een paar pagina's:

• Pagina 1-> Selecteer nr. van reizigers - volwassenen, kinderen en senioren.
• Pagina 2-> Kies het type ticket: een dagkaart, een weekkaart, een maandkaart, enz.
• Pagina 3-> Bekijk de details en rond af.
• Pagina4-> Betalen, etc.

Er kunnen dus veel verschillende visuele pagina-voor-pagina-overgangen zijn, maar het ticket zelf bevindt zich in de staat van maken. Normaal gesproken maken we dus geen ST-diagram voor visuele overgangen (dat kan als je wilt, maar het wordt niet zo vaak gebruikt), maar voor staatstransities van de core business-entiteit.

Zodra het ST-diagram is gemaakt, kunt u het als volgt gebruiken om eenvoudig de end-to-end-testscenario's en eindgebruikertransacties te identificeren:

De drie gele lijnen zijn 3 end-to-end cases die, wanneer ze worden getest, de meest kritische en meest gebruikte gebieden van de toepassing beslaan. Dit is zo'n handig hulpmiddel om zinvolle testcases en end-to-end acceptatietests te creëren.

Voor een veel uitgebreidere uitleg en gebruik in de echte wereld, kijk op => State Transition Testing Technique voor het testen van complexe applicaties

# 3) Contextdiagrammen:

Softwaresystemen functioneren zelden als onafhankelijke eenheden. Eenvoudige toepassingen zoals rekenmachine, kladblok, enz. Werken misschien op zichzelf, maar bedrijfstoepassingen werken vaak samen met veel andere toepassingen.

Bijvoorbeeld: Een salarissysteem kan interageren met de boekhoudapplicatie, het urenregistratiesysteem voor uren van werknemers en het HR-portaal voor werknemersgegevens. Contextdiagrammen zijn uitstekende diagrammen die al deze relaties op een gemakkelijk te begrijpen manier laten zien.

Het volgende is een contextdiagram voor het zojuist beschreven salarissysteem:

Een contextdiagram toont heel duidelijk de context van een bepaald systeem met alle andere entiteiten die erop betrekking hebben. Voor een eenvoudige uitleg, kijk hier =>

Voor een eenvoudige uitleg, kijk hier => Systeemcontextdiagram

Contextdiagrammen helpen testers het systeem in een bredere zin te begrijpen en helpen bij het creëren van teststrategieën die deze inkomende en uitgaande relaties omvatten die het systeem heeft met de andere entiteiten. We maken misschien geen contextdiagram als onderdeel van ons testproces, maar als het beschikbaar is, helpt het een goed begrip.

# 4) Mindmaps:

Een mindmap volgt een drukke geest die van onderwerp naar onderwerp springt; elke gedachte wordt dieper en breidt zich breder uit bij elk idee. Het is een diagramvorm waarbij je net begint met je hoofdidee en elke subgedachte die eruit voortkomt documenteert.

app om instagram-berichten gratis in te plannen

Mindmaps kunnen voor van alles en nog wat worden gebruikt. Hoewel ze nog niet verschijnen in de IEEE-, CMMI- of andere standaardsjablonen of procesdocumenten, zijn ze nog steeds een zeer populair onderdeel van de cultuur van de software-industrie.

Een zeer populair gebruik van mindmaps is het volgen van verkennende tests. (Ik weet het, ik weet het, u denkt: waarom moeten verkennende tests überhaupt worden gevolgd? Het is omdat, met snelle ontwikkelingscycli, agile en andere snellere methoden voor softwareontwikkeling, het voor testers minder waarschijnlijk wordt om de tijd en ruimte voor volledige documentatie. Dit betekent dat de omvang van het onderzoek toeneemt en dat het versterkt moet worden. Mindmaps kunnen precies dat voor u doen.)

Bijvoorbeeld: Het volgende is een diagram voor een e-commercetoepassing waarbij u uw testen eenvoudig als volgt volgt met een mindmap:

Testers krijgen de mindmaps mogelijk niet als invoer. Maar we kunnen situaties zien waarin we ze moeten creëren. Dat is heel eenvoudig. Begin met uw centrale idee of uitgangspunt en volg waar uw gedachten u heen leiden. Er zijn veel eenvoudige en gemakkelijke gratis online tools die u kunt gebruiken voor mindmapping. Dit is degene die ik heb gebruikt om het bovenstaande te tekenen kaart hier.

Voor meer informatie en tools, kijk op => Mindmapping bij softwaretests - manieren om testen leuker te maken!

# 5) ER-grafieken:

Entity-Relationship (ER) -diagrammen worden gebruikt voor databasemodellering. Ze helpen ons de tabellen, hun velden te begrijpen en hoe velden in de ene tabel zich verhouden tot velden in andere tabellen in het databasesysteem. Het toont de componenten van uw databasesysteem en de relaties daartussen op een visuele manier.

ER-diagrammen fungeren ook als een eerste testrun van het DB-model en de visualisatie voordat DB-systemen worden ontworpen en gebouwd.

ER-diagrammen hebben entiteiten (de instanties van DB-tabellen) en hun relaties (één op één, één op veel, één op verplicht, etc.) weergegeven met behulp van vakken en kraaienpootjesconnectoren.​

Er zijn veel variaties op de ER-diagrammen, maar de eenvoudigste versie kan er als volgt uitzien:

Beeld Bron

Voor een korte introductie en uitleg, kijk op:

• Entity Relationship Diagram (ERD) trainingsvideo
• Tutorial Entity Relationship Diagram (ERD)

# 6) Bonus: bespeel schermen / wireframes:

Wireframes zijn HTML of eenvoudige afbeeldingen (schermafbeeldingen) die ons schematisch de toekomstige UI-pagina / component laten zien.

Wireframes zijn een zegen voor testers, omdat ze het ons supergemakkelijk maken om het eindproduct te visualiseren en het analyseproces van hun testontwerp te verbeteren. Dit betekent betere testscenario's, betere testcases en op zijn beurt een hogere testeffectiviteit.

Wireframes kunnen eenvoudige handgetekende afbeeldingen zijn, of interactief gemaakte webpagina-structuren of andere diagrammen die representatief zijn voor het uiteindelijke systeem.

Een eenvoudig draadframe voor het inlogscherm kan er als volgt uitzien:

Hier is een snelle link om te begrijpen hoe QA-teams wireframes gebruiken voor vroege tests en enkele tools om ze te maken => Wireframes - Moeten ze echt worden getest? En zo ja, hoe?

Om af te sluiten - Hoe kunt u deze diagrammen maken als dat nodig is?

Meestal interpreteren testers de meeste van de bovengenoemde diagrammen. Maar het komt zelden voor dat we ze moeten maken. MS Visio en SmartDraw zijn geweldige tools om te gebruiken. Als u echter op zoek bent naar iets gratis en lichts (geen installatie en configuratie), kijk hier.

Als je geen toegang hebt tot internet en je hebt alleen je woord of verf, dan kun je de beschikbare vormen gebruiken om deze diagrammen te maken (nou ja, de meeste ervan). Dit is mijn minst favoriete methode omdat het tijdrovend en niet zo gebruiksvriendelijk is, maar het zal het doen.

Over de auteur: Dit artikel is geschreven door ons teamlid Swati.

Dus, welke diagrammen gebruikt u en welke zijn uw favorieten?

Aanbevolen literatuur

• Softwaretestadvies voor beginnende testers
• Beste softwaretesttools 2021 (QA Test Automation Tools)
• Wat is componenttesten of moduletesten (leer met voorbeelden)
• Wat is vergelijkingstesten (leren met voorbeelden)
• Verliezen testers hun grip op testen door automatisering?
• Wereldwijd softwaretestbedrijf bereikt binnenkort $ 28,8 miljard
• Hoe houd je motivatie levend in softwaretesters?
• Primer eBook downloaden testen