Functional vs Non-functional testing

Software testing usually has two types of tests. These are firstly functional and also non-functional.

But why the two? And why are they both important?

Let’s give the example that we are testing a new website. The websites main purpose is to provide an easy way for people to order items online. And although it does allow the processing of orders. Concerns are raised about the quality of the product.

Testers have found that the website is slow to respond. What’s more, it has a confusing UI, doesn’t work in certain browsers. And if released to the public. Wouldn’t attract many sales.

If the goal of software testing is to provide feedback to contribute to a quality product. Then we can say that functional and non-functional testing are two sides of the same coin.

But what is the purpose of each one? What are the advantages, and disadvantages? And in what situations are they used?

Let’s take a closer look at these in detail.

If software testing was a marathon for example. Functional testing would certainly take up most of the first half.

Functional testing is about testing what the product does

The goal of functional testing is to ensure the core features of your application are in line with the requirements which the client has asked for. Generally, these will be in the specification document. So essentially answering the question: ‘Are the outputs the same as expected’.

Below is a sample of the types of functional tests.

Smoke Testing

We perform smoke testing to check if the critical areas of the program are functioning.. Usually, run after the release to testers. This quick check enables software testers to easily conclude if the software is OK for further testing.

Sanity Testing

Sanity testing verifies quickly if all functions of the software are working. Again, this is not an in-depth check and is only performed when there isn’t time to do in-depth testing. But this enables testers to quickly see what is working, and what is not.

Unit Testing

Covered in my article on white-box testing. Unit tests are essentially bits of code that test other bits of code. When used with a unit testing framework. Unit tests can be run automatically when the code compiles. Enabling functions in the code to be isolated and tested rigorously.

Regression Testing

Also covered in my article on regression testing. Regression testing is performed with the aim of ensuring that the newly developed code. Has not adversely affected the functionality of the previously working software. Usually performed when new features are added, or bugs are fixed. Regression testing allows us to quickly tell if the software has not been affected by changes to the code base.

Functional tests can be good candidates for automated testing. Although it’s important to remember that while automating all test cases isn’t advised. You should instead take the time to think about your automation strategy and what tests to automate. This will enable you to get the most value out of automated testing.

Non-functional testing is concerned with qualities

Let’s say I am developing a new kettle. I want my kettle to hold water, and boil it within 60 seconds when I press a certain button.

The time it should take to boil is an example of a non-functional requirement. Also, it demonstrates a key value of non-functional requirements. They should not be ambiguous, or open to interpretation.

Saying a webpage should be fast. Isn’t a good example, because ‘fast’ means something different to us all. A better example would be: ‘The webpage should load within 2 seconds’.

Non-functional requirements do not cover just the performance of the software. They can also cover:

  • Usability
  • Scalability
  • Security
  • Availability
  • Portability
  • Flexibility

And many more ‘ilities’ besides. A full list can be found here.

There are many types of tests that utilize non-functional requirements:

Performance Testing

The aim of performance testing is to test the responsiveness of the application under a diverse set of workloads.

Performance testing has four areas:

Load testing
In which the application gets tested under an increasing workload.

Stress Testing
Testing the behaviour of the application at the peak (or beyond) it’s expected workload.

Endurance Testing
Giving the application a high workload at a continuous pace.

Spike Testing
Increasing the application’s workload until it’s at the limit of what it expects.

Usability Testing

We focus this type of testing on how users interact with the application.

Scalability Testing

Sometimes associated with performance testing. Scalability testing is all about how the application is able to scale up or down depending on the demands of it.

Security Testing

We focus these tests on determining whether applications are free of risks or weaknesses. The exploitation of which may cause loss of data, or unauthorised actions taking place.

Recovery Testing

This testing checks how the application can recover after a system’s failure. Whether it is through hardware, software or some other error.

Reliability Testing

This verifies if the software can perform its intended operation without error. Usually performed within varying environments and time limits.

Documentation Testing

Documentation testing concerns itself with testing the various artefacts produced by software testers. An example of items to test would be test cases, test plans. Etc.

Functional testing vs. Non-functional testing

The table below shows some advantages and disadvantages of each approach.

Functional TestingNon-Functional Testing
Verifies the expected functions of the application.Verifies the expected behaviours of the application.
Helps to enhance the behaviour of the application.Helps to enhance the performance of the application.
Tests are easy to execute. And maybe automated.Hard to gauge a website’s performance for example. Without the help of an automated tool.

Summing up, both methods of testing go hand in hand with each other and it’s uncommon to perform one type of testing, without the other. Effective use of tests to target both types of requirements. Enables the creation of a well-rounded and effective test strategy.

Posted by Kevin Tuck

Kevin Tuck is an ISTQB qualified software tester with nearly a decade of professional experience. Well versed in creating versatile and effective testing strategies. He offers a variety of collaborative software testing services. From managing your testing strategy, creating valuable automation assets, or serving as an additional resource.

Leave a Reply