Test all the Things! Types and Examples of Software Tests
The volume of material, information and tests available on the internet can be overwhelming. To put some order on this chaos, we’ve divided things up into two sections: Test Levels and Types of Software Tests. To help make things even clearer - we’ve also included some practical examples of each test. If you feel a little bit lost with the names and categories of the test world - this is exactly what you need to read!
There are different ways to categorise software tests. We’ve chosen to follow the lead of the ISTQB Foundation Level Syllabus, where tests are grouped by target or specific reason for testing.
Netguru builds digital products that let people do things differently. Share your challenge with our team and we'll work with you to deliver a revolutionary digital product. Create a product with Netguru.
Test levels
Component/Unit Testing
Component (or unit) tests need knowledge of code and component requirements. Their main purpose is finding defects in components or units of software. Modules, components and classes can be tested separately from each other. Since this requires access to source code, it often involves the developer. Writing this type of test is usually easy and fast.
Practical example: Given a class User with fields like first_name, last_name and a method called fullname, we can check if the described method returns the value we are expecting:
Integration testing
After unit tests have made sure that chunks of code work properly in isolation, integration tests assure us that the submodules of the application will integrate and communicate with each other in the way described by use-cases and system design.
Practical example: We test to see if a user’s full name is displayed when we visit their profile page. In this way we confirm that our views, controller and model methods are working together as intended:
System testing
System testing is concerned with the behaviour of the whole system/application. In this type of test, the environment should be as similar as possible to the production environment. This helps the test team to minimize the risk of environment-specific failures not being found during testing. These tests can be based on use-cases, requirements specifications, business processes and other high-level descriptions of system behaviour.
Acceptance testing
Acceptance testing is mainly done by the clients or future users of an application. The most important goal in this type of test is not to find defects, but to establish confidence in the system, its parts, and its non-functional characteristics. It also checks readiness for product deployment and usage. The best examples of acceptance testing are alpha and beta tests. Alpha tests are performed on-site, but not by the development team. Beta tests are performed by a chosen group of potential customers at their own location. After each of these tests, feedback about the application is gathered and new functionalities or fixes can be added.
Types of software tests
Functional testing (black-box method)
Functional tests are based on functions and features. They refer to activities that verify a specific action or function of the code. How the features should work may be described in the app’s specification or product documentation. Functional tests tend to ask questions like "can the user do X?" or "does this particular feature work?”.
The Black-box testing method treats the software as a "black box" - the examination happens without any knowledge of the internal implementation. The tester doesn’t analyze or have access to the code during tests.
Practical example: confirming that a user can register through Facebook, and that any created passwords have at least 8 characters.
Non-functional testing
Non-functional testing refers to aspects of the software that may not be related to a specific function or user action, such as scalability or security. Tests are aimed at determining breaking points - where extremes of scalability or security may lead to unstable execution. Functional tests check what the system does while non-functional tests aim to check how the system works.
Practical example: load testing or stress testing. Since we know from functional testing that the application works - we now need to check if, for example, it still works with a huge influx of users.
Structural testing (white-box method)
Structural testing is often referred to as ‘white box’ or ‘glass box’ testing because it deals with what is happening inside the system/application. As such, structural testing requires access to the code. The aim is to measure the thoroughness of testing through assessment of coverage of a type of structure, and it’s best used after specification-based techniques. Structural testing can be used in all test levels, but may be most useful in component testing.
Practical example: how are the loops in the software working? Different test cases may run the loops once, twice, and many times.
Re-testing and regression testing
Software should be re-tested from time to time, just to make sure that new fixes don’t destroy some other part of the system. The ISTQB syllabus definition says: “Regression testing is the repeated testing of an already tested program, after modification, to discover any defects introduced or uncovered as a result of the change”. The main aim is to find defects in software that was working previously.
Practical example: a pre-deployment or post-deployment test which checks all the most important features, like registration and login/logout functionality.
Keep calm and test!
There are plenty of other tests out there - for example, smoke tests, sanity tests and A/B tests. A/B tests are particularly interesting, but that’s a topic for another blog post! Hopefully this post has been informative, and you’re now better able to understand and implement the battery of tests required for software development. It can be difficult to make practical use of each type of test - but practice makes perfect!
