“Wat zijn niet functionele requirements?”
- Stress testen
- Performance/load testen
- Failover testen
- Recovery testen
- Soak testen
Niet-functionele requirements, of ook wel niet functionele eisen, zijn criteria die de kwaliteitskenmerken van een systeem of software beschrijven. Ze zijn het tegenovergestelde van functionele vereisten. Doorgaans bestaat dit uit:
Ze richten zich niet op de specifieke functionaliteit van het systeem zoals functionele requirements, maar op hoe goed de software werkt. De niet functionele requirement ondervind je door middel van niet-functioneel testen; dit kan direct bijdragen aan de verbetering van je softwareontwikkeling en testing.
Niet-functioneel testen richt zich op de applicatie als een geheel. Hoe goed presteert de applicatie in gegeven situaties en is dit voldoende in relatie tot het gewenste gebruik? Het gaat hierbij dus niet zozeer om de business requirements of het zoeken naar fouten, maar meer om de vraag of het product goed is in het gebruik. Is er een voldoende goede gebruikerservaring, is het veilig, snel genoeg, prettig in gebruik etc? Simpel gezegd; voldoet het aan de verwachtingen van de uiteindelijke gebruiker?
Aangezien de niet-functionele testen een breed scala aan onderwerpen kunnen bevatten, zijn er ook meerdere soorten testen.
Wat zijn de verschillen tussen functioneel en niet-functioneel testen? Waar functioneel testen zich richt op het vergelijk tussen de vooraf opgestelde functies van een applicatie, richt het niet-functionele testen zich meer op de applicatie als een geheel. Hoe goed presteert de applicatie in gegeven situaties en is dit voldoende in relatie tot het gewenste gebruik?
Functionele testen gaan dus over eisen en functionaliteiten (wat doet het), terwijl niet-functioneel testen gaat over verwachtingen en prestaties onder bepaalde omstandigheden. Functioneel testen is vaak handmatig uit te voeren, terwijl niet-functioneel testen vaak gesimuleerd moet worden.
In het proces van opstellen van wensen en eisen wordt niet-functioneel testen vaak vergeten. Over de functionaliteiten valt veel te vertellen, maar wat er verwacht wordt binnen bepaalde situaties van de software als geheel is lastiger te omschrijven of aan te geven wat er verwacht wordt.
Is het altijd mogelijk om niet-functioneel testen uit te besteden? Nog meer dan functioneel testen, leent niet-functioneel testen zich voor uitbesteding. Is de overdracht van kennis bij functioneel testen van cruciaal belang om de testen goed uit te kunnen voeren (anders weet je niet wat er verwacht wordt), geldt dit voor niet-functioneel testen in mindere mate. Hier is het van groot belang om in te schatten (en te onderzoeken) wat de eindgebruikers van de applicatie verwachten en in kaart te brengen welke situaties voor kunnen komen die het prettige gebruik kunnen verstoren. Op basis hiervan kun je de niet functionele requirements opstellen en testen. Ervaren test engineers kunnen hier een belangrijke bijdrage leveren aan het opstellen en uitvoeren van de verschillende testen. Zaken waar u normaal niet aan denkt of die u zelf niet kunt simuleren, kunnen door professionals, met behulp van diverse tools, worden uitgevoerd.
Ook niet-functioneel testen dient reeds vanaf het begin geborgd te zijn binnen de Agile ontwikkelmethodiek en niet achteraf, als sluitpost van de ontwikkeling, te worden uitgevoerd. Juist door tijdig bepaalde niet-functionele testen uit te voeren zal er minder werk zijn om eventuele tekortkomingen in een later stadium op te lossen. Goed testen (eigenlijk Quality Assurance) is ook vooruitkijken. In hoeverre kunnen wij voorspellen waar niet-functionele knelpunten kunnen ontstaan? Wanneer je dit weet kan je er rekening mee houden tijdens de ontwikkeling en op die manier fouten voorkomen. Dit spaart tijd, geld, frustraties en ontevreden gebruikers.
Egor Gucinsky QA Manager
"Testing is a preventive activity and focuses on revealing risky from quality point of view areas before testing starts. It is done in order to put dedicated testing stress on areas that are tend to have issues. Testing of functional and business critical scenarios is a priority. Scenarios are prepared beforehand and support development from the beginning."