One common question in any tester’s education is aimed at understanding the difference between functional and nonfunctional testing.

Functional testing verifies that features work according to requirements, whereas nonfunctional testing performs checks on wider quality concerns.

In this post, I am going to make that difference crystal clear, and give examples and strategies.

The main difference between functional and nonfunctional testing

Before we can understand the difference between functional and nonfunctional testing, we need to know the difference between functional and nonfunctional requirements:

  • Functional requirements: describe the behavior/execution of the software system
  • Nonfunctional requirements: describe performance or usability of the software system

While a functional requirement will specify that a feature must execute some action, a nonfunctional requirement might specify the speed with which the feature performs that action.

Functional requirements are the WHAT; nonfunctional requirements are the HOW.

So, the testing of functional requirements is the verification that the software is executing actions as it should, while nonfunctional testing helps verify that customer expectations are being met.

Examples of functional testing versus nonfunctional testing

To help make the difference even more clear, I am going to detail some side by side examples of each.

Functional testing Nonfunctional testing
When inputs are valid, app login functions After login, the dashboard loads within 3 seconds
When email notifications are on, and user receives a new message, an email notification is sent The email notification is sent within 5 minutes
When a JPG file under 1MB is uploaded, the uploader accepts the file When eight files or less (each under 1MB) are uploaded at the same time, the queues all
When the settings menu item is clicked, the settings page loads The settings page has a matching appearance to the rest of the GUI

 

Functional testing strategies

There are a variety of functional testing strategies, and the best way to ensure functional test coverage is a mix of manual and automated testing.

The most common functional testing strategies are black box testing methods—wherein the tester does not need to review the internal source code, but validates functionality by testing various input combinations.

Here are some of the common functional testing techniques:

  • Installation testing – for desktop or mobile application, testing proper installation
  • Boundary value analysis – testing of the boundaries of numerical inputs
  • Equivalence partitioning – grouping tests together to reduce overlap of similar functional tests
  • Error guessing – assessing where functional issues are most likely to be found and testing these more extensively than other areas
  • Unit testing – testing performed at the smallest level of the software—not how the system is functioning as a whole, but whether each unit is executing properly
  • API testing – checks that internal and external APIs are functioning properly, including data transfer and authorization
  • Regression testing – tests that are performed to verify that new software changes did not have adverse effects on existing functionality (most common automation technique)

All functional tests have a specific output that is expected of any input. If you enter valid data, then you expect the data to be accepted. All functional tests can be scripted with very clear pass/fail criterion.

Nonfunctional testing strategies

Nonfunctional testing can sometimes require more creativity and technical expertise, because you are testing what the customer expects for an overall quality experience—not X input leads to Y output.

These are the chief nonfunctional testing techniques:

  • Load testing – tests performed on simulated environment to test the behavior of the system during expected conditions (various number of users)
  • Stress testing – testing performance when low on resources, such as server issues or lack of hard drive space on a device
  • Scalability testing – checking a system’s ability to scale with increased usage and to what extent performance is affected
  • Volume testing – testing performance with a high volume of data, not necessarily high number of users, but could be one user performing a high-volume task, such as a multiple-file upload
  • Security testing – tests performed to uncover how vulnerable the system is to attacks, and how well data is protected
  • Disaster recovery testing – checks on how quickly a system can recover following a crash or major issue
  • Compliance testing – tests of the software system against any set of standards (whether due to industry regulations or a company’s set of standards)
  • Usability testing – testing whether the GUI is consistent and if the application as a whole is intuitive and easy to use

While some nonfunctional testing techniques can have pass/fail criterion (such as volume testing), others can be more objective and based on the opinion of the tester (such as usability testing). However, nonfunctional tests should be written to be measurable and quantifiable wherever possible.

Listening to customer feedback is essential for updating nonfunctional requirements. While a business might identify certain scalability and security factors during requirements gathering, customer feedback can expand the set of checks to include better testing of how an app recovers after a crash or how an app performs with minimal storage space left on a device.

Customer feedback can help with risk assessment for functional testing, but is even more valuable to nonfunctional testing, because the feedback can help set the bar—whereas with functional tests the bar is already set.

Ultimately, knowing the difference between these two types of tests can help during test planning, so that you are clear on what is being covered and why.

For testing that fits in with your process and team, contact us for a demo.

<p>Dayana is a QA engineer turned technology writer living in Milan, Italy. She’s always down for a smoothie.</p>