SharePoint

Testen en SharePoint – Het testproces

3 december 2012

Het testproces voor een SharePoint solution kent diverse onderdelen. In deze blog worden al die onderdelen besproken. In een serie van blogs wil ik graag die verschillende onderdelen van het testproces verder uitlichten en ondersteunen met voorbeelden. Het testen van SharePoint solutions kan volgens diverse testaanpakken. Iedere aanpak kent zijn mogelijkheden en beperkingen. Deze blog gaat over het functioneel testen van SharePoint. Over het technisch testen van SharePoint al veel geschreven. Het is geen nieuws dat onder andere unit testen de kwaliteit van de op te leveren software vergroot. Wat onder belicht blijft is dat, het uitvoeren van functionele systeemtests en acceptatietest minstens zo belangrijk zijn.

Testing

Een strategische testaanpak is vooral gericht op het onderkennen van risico’s. Het is onmogelijk om SharePoint in zijn geheel te testen. Hiervoor is gewoon weg geen tijd en bovendien is het niet noodzakelijk. Dit is immers al door Microsoft gedaan. Bij het uitvoeren van een functionele test is het van belang om dat gedeelte te testen waar het zwaartepunt ligt. Wat is de kans dat iets mis gaat, en wat is het gevolg hiervan?

Stap 1: Een productrisicoanalyse

Een productrisicoanalyse (PRA) analyseert het te testen product met als doel dat de tester en andere belanghebbenden tot een gezamenlijk beeld komen over wat de meer of minder risicovolle kenmerken het product zijn.  De grondigheid van testen relateert hieraan. Bij het testen van SharePoint is vooral het schatten van risico’s met betrekking tot maatwerk van groot belang. Daar waar wordt afgeweken van de standaard is het risico op fouten groter. De realisatie van een maatwerkcomponent kost meer tijd en de zwaarte en grondigheid van de test wordt hierop aangepast.

Stap 2: Een testplan

De PRA vormt de basis voor een testplan. In dit testplan wordt op basis van het PRA de teststrategie en testaanpak uitvoerig beschreven. Daarnaast wordt er in het testplan ook aandacht besteed aan organisatorische voorwaarden. Voor een SharePoint solution kun je hierbij denken aan de beschikbaarheid van omgevingen. Een OTAP-straat is hier een belangrijk onderdeel van. Een goede test uitvoeren, heeft alleen nut wanneer dit gebeurd op een representatieve omgeving met representatieve (test)users.

Stap 3: De uitvoering van een systeemtest

Op basis van scenario’s worden de gerealiseerde software getest en getoetst. Het toetsen van de solution gebeurd aan de hand van de testbasis. Je kunt hierbij denken de functionele eisen of een grafisch ontwerp wat is opgesteld voorafgaand aan de realisatie van de SharePoint solution. Op deze manier controleer je of de oplossing voldoet aan de kwaliteitseisen die vooraf zijn gesteld.

Stap 4: Acceptatietest

Na het uitvoeren van de systeemtest en het (eventueel) oplossen van bugs kan de gerealiseerde software worden opgeleverd aan de opdrachtgever. Wanneer de ontwikkeling van software wordt uitbesteedt, dan vindt doorgaans direct na oplevering een acceptatietest plaats. Hiermee worden de activiteiten van de opdrachtgever bedoeld die erop zijn gericht om in een overeengekomen testperiode het geleverde product systematisch te testen en beoordelen. Het doel van de acceptatietest is vast te stellen dat de software voldoet aan de eisen en wensen en dat de software geschikt is voor bedrijfsmatige ingebruikname.

Binnenkort dus meer over de verschillende stappen, zoals deze hierboven staan beschreven. Deze zullen worden ondersteund met voorbeelden om het inzichtelijk te maken wat het belang is van het functioneel testen van SharePoint en het toepassen hiervan.

You Might Also Like

Geen reacties

Plaats een reactie