Home QA & Testing soorten Niet-functioneel testen

Niet-functioneel testen

“Wat zijn niet functionele requirements?”

  • Stress testen
  • Performance/load testen
  • Failover testen
  • Recovery testen
  • Soak testen

Wat zijn niet functionele requirements?

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:

  • Prestaties
  • Beveiliging
  • Betrouwbaarheid
  • Bruikbaarheid
  • Schaalbaarheid
  • Compatibiliteit

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.

Wat is niet-functioneel testen?

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?

Soorten niet-functionele testen

Aangezien de niet-functionele testen een breed scala aan onderwerpen kunnen bevatten, zijn er ook meerdere soorten testen.

  • Performance/load testen. De software wordt getest onder een bepaalde belasting (load), waarbij wordt gekeken of de prestaties van de software binnen bepaalde normen blijven. 
  • Stress testen. Hierbij wordt een hogere (extreme) belasting van de applicatie getest om te kijken hoe de software hierop reageert en wat er maximaal voor belasting mogelijk is. Bij performance testing wordt dus getest met de maximale belasting die gevraagd wordt, terwijl stress testen meer dan de maximale belasting test en kijkt wat er gebeurt.
  • Failover testen. Software heeft vaak redundante systemen die ingeschakeld worden wanneer er een fout optreed of het systeem overbelast raakt. Failover testen hoe deze systemen werken en hoe de basis applicatie zich hersteld, nadat het weer in functie is.
  • Soak testen. Hierbij wordt de software over langere periode getest met een bepaalde workload. Hoe gedraagt het systeem zich in de praktijk tijdens langdurig en intensief gebruik. Is het tegen de dagelijkse praktijk opgewassen?
  • Security testen. Wat gebeurt er met de software wanneer er vijandige acties worden ondernomen? Hoe goed is de beveiliging en hoe reageert de software (na de aanval)?
  • Usability testen. Hoe gemakkelijk is de software in gebruik? Hoe wordt er om gegaan met specifieke gebruik situaties en hoe makkelijk is de software in het gebruik? Het gaat hier voornamelijk om de UI test.

Functioneel en niet-functioneel 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.

Niet-functioneel testen uitbesteden

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.

Agile testen van niet functionele requirements

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.

  • Professioneel getest
  • Integratie in het Agile team
  • Tijd besparen op ontwikkeling
  • Maak gebruik van onze ervaring
  • Investeren om kosten te besparen

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."