Software testing, whether manual or automated, is a key quality assurance process in application lifecycle management. It helps testers, developers, IT operations, project owners, business analysts, and end users determine that a system satisfies the stated project requirements. There are dozens of software testing types you could run on an application.

Nevertheless, these tests fall into two broad categories: functional testing and non-functional testing. We’ll take a closer look at these two categories as well as examples of the types of software testing found within these two categories.

Functional Testing 

Functional testing seeks to determine whether an application feature works exactly as set out in the project’s functional requirement specification.

A functional requirement is one that describes what the application should do when fed certain inputs. It describes the software’s behavior when a given input condition is satisfied. This could be, for example, automatically sending out a confirmation email when new users sign-up to a service. Functional requirements include business procedures, transaction rules, user authentication, user authorization, audit trails, reporting requirements, regulatory compliance, and interfaces with other applications.

Functional tests are conducted by crafting several test cases, preparing test data, feeding the test data into the application and checking whether the actual output is identical to the expected result. The overwhelming majority of functional testing types are considered forms of black-box testing. That’s because the tester has no concern about the code-level structure and internal workings of the application. This contrasts with white box testing where the focus is on the inner workings of the system.

Types of Software Testing: Functional Testing 

So, what are some examples of types of functional testing?

Smoke Testing 

Smoke testing is a quick, elementary, and high-level test that’s a precursor to more extensive QA testing. It’s usually performed by a developer or tester, immediately after a build is completed or after it’s deployed into production. A smoke test confirms that the build is stable, and its core features are working.

The rationale for smoke testing is that there’s no point in subjecting a build to rigorous testing if its most critical functionality is broken. So if a build fails the initial smoke test, it’s rejected, and the development team is advised to make changes accordingly.

Sanity Testing 

A sanity test is typically performed by a tester, after the smoke test. It checks that the major capabilities in the build are present and working as expected, and are ready for further, more in-depth testing. Sanity tests go into more detail than the smoke test but is still one of the types of software testing that is considered minimal and basic.

The tester would, for instance, confirm whether the result of a calculation is correct or if the application’s menus are working fine.

Unit Testing 

Agile development often involves different teams working on various modules of an application at the same time. It can be said that unit testing is the functional test that occurs closest to the application code. Unit tests focus on the smallest component, or unit, of an application, and the tester, who is usually a developer, knows and understands the unit’s internal structure and design. For that reason, unlike most functional types of software testing, it’s classified as white-box testing.

The test evaluates the individual components of the build to confirm that each is working as expected. Unit testing precedes integration testing, and due to the detailed knowledge of the module needed, unit testing is usually done by the component’s developers as opposed to the testers.

Because unit testing is done at the beginning stage of the development process, any defects detected are usually easy and cheap to fix.

Integration Testing 

While unit testing may confirm that each module works flawlessly on its own, that’s no guarantee that it will necessarily work when integrated with the other modules of the application.

Integration testing confirms that the combined parts of the application work as well as (or better than) the individual components. It seeks to expose defects and conflicts in the interaction between the various units.

Regression Testing 

Regression testing checks that, following a code change, such as a bug fix or the introduction of a new feature, a build has not taken one or more steps back on its functionality. It’s run whenever there’s a modification to a module, group of modules, or the entire build.

This is an especially important test in the agile methodology, since the application is built incrementally. There’s an ever-present risk that the introduction of new features could negatively affect an existing function or create new bugs, and these issues should be detected as early as possible.

Regression testing can be performed manually, but given the number of features that must be tested, regression testing should be automated as much as possible. Automated regression tests can be scheduled to run every night, effectively replacing hundreds of manual testing hours with a few hours of automated testing.

Defects found at this stage are less costly to fix than defects that escape into production. For this reason, testing contributes not only to application quality, but also to cost savings.

Localization Testing 

Localization testing confirms that the build can be customized to the tastes and preferences of different types of users, different geographical locations, different languages, and different devices.

For instance, an application’s English language setup may run well but perhaps the German language setup doesn’t. Testers verify that the build conforms to custom user requirements and that localization efforts don’t lead to breaks in functionality.

User Acceptance Testing 

User acceptance testing (UAT) subjects the application to a simulated, real-world user environment. Unlike most other types of software testing, UAT is conducted by the system’s intended end users. It checks that the software’s management of business processes is at an acceptable level.

The test occurs in an environment that’s a near replica of the production environment. UAT is one of the last activities that occur before the build is deployed to production. It takes place after all key defects of the application have been resolved.

Non-Functional Testing 

Whereas functional testing deals with what the application does, non-functional testing checks how well the application runs in order to identify areas of improvement. Non-functional requirements are a part of the project’s specifications and define the operational characteristics and limits of the system.

An example of a non-functional requirement is ensuring that any update to a shared database is visible to all users within 3 seconds. Non-functional testing looks at, among others, the application’s usability, throughput, response time, capacity, scalability, reliability, maintainability, recoverability, security, integrity, and interoperability.

Types of Software Testing: Non-Functional Testing 

There are at least a dozen types of non-functional testing types. Let’s look at the most important ones.

Performance Testing 

Performance testing examines various aspects of the capability and quality of the application. Performance is a broad term and includes speed, efficiency, effectiveness, scalability, reliability, stability, and other technical elements around the working of the system.

For that reason, some of the non-functional types of software testing we cover below, such as stress testing and load testing, are considered forms of performance testing.

Usability Testing 

Usability testing examines the application’s navigation, logical flow, intuitiveness, user-friendliness, and content, as well as how easily a new user can understand its operation. That includes checking that the system’s online and offline documentation is sufficiently helpful for users who get stuck.

Security Testing 

Security testing investigates the ability of the application to withstand a malicious attack and protect its data. The testing would at the minimum cover user authentication, authorization, non-repudiation, role-based access, audit trails, password encryption, and automatic logoff after a specified period of inactivity.

The testing is best done by highly skilled security experts who have a deep understanding of the various loophole’s attackers could exploit to penetrate an application.

Volume Testing 

In volume testing, the application is subjected to large data volumes to gauge its response times, processing times, reliability, accuracy, and overall system behavior under such circumstances. Volume testing is also referred to as flood testing and is considered a subset of performance testing.

Scalability Testing 

Scalability testing is a form of performance testing that evaluates the software’s ability to grow in tandem with the increasing demands of the system’s end users and data. It checks that the application can scale up or out as required up to the desired threshold.

Load Testing 

Load testing is a type of performance testing that determines the maximum load that the application can handle without experiencing a degradation in performance. For instance, how many simultaneous logins or concurrent users can the system support? During the test, the load is increased continuously until it reaches the limit as stated by the development team. Given the nature of this test, it’s almost exclusively done via automated tools.

Stress Testing 

Stress testing is a type of performance testing and is more extensive than load testing. It pushes the system to its limits by subjecting it to extreme loads well beyond the application’s specifications that could occur during extraordinary circumstances.

It investigates how hard the system can be pushed before it breaks. Stress testing also evaluates the recoverability and error handling of the system after a crash occurs. It tests whether recovery happens without jeopardizing the security and integrity of application data.

Recovery Testing 

Recovery testing often goes hand in hand with stress testing. It checks the system’s ability to protect and recover data in the event of a system crash, hardware failure, power loss or network disruption. The system is forced to fail, and the tester establishes whether the application can be brought back up unscathed.

Configuration Testing 

While the requirements specification may outline the hardware and software environment the application should operate in, it doesn’t specify the type and model of infrastructure it will be installed on. Configuration testing studies whether the application performs consistently when setup and configured for different types of hardware, browser, operating system, and drivers.

It’s virtually impossible to run tests for every platform scenario. Ergo, configuration testing must focus on platforms that already exist in the production environment.

Final Thoughts on Types of Software Testing 

Testing confirms that the application meets or exceeds the expectations of project owners, end users, IT department, and the organization’s senior management. Though different from one another, both functional and non-functional types of software testing are a critical component of ALM.

Micro Focus delivers a number of tools for functional and non-functional software testing. Click on the links to learn more:

• Functional Testing: UFT Family
• Performance Testing: LoadRunner Family
• Security Testing: Fortify

Additional information

• Have technical questions about the UFT Family? Visit the Discussion Forums for UFT One, UFT Developer, UFT Mobile, and Service Virtualization.
• Keep up with the latest tips and information about UFT One, UFT Developer, UFT Mobile, and Service Virtualization.
• Do you have an Idea or Product Enhancement Request for the UFT Family? Submit it in one of the Idea Exchanges for UFT Developer, UFT Mobile, and Service Virtualization.

We’d love to hear your thoughts on this blog. Comment below.