If you decided to stay here for a while and see what it is going to lead to, let’s get straight to the point. Software testing types can be grouped not only by the testing objectives and quality criteria but also by the factors, closely connected to the software development life-cycle.

By the testing object

To the first grouping belong:

• Functional testing
• Performance testing
• Usability testing
• Localization testing
• UI testing
• Security testing
• Compliance testing.

You’ll need to run functional testing to evaluate the performance of separate application features and their compliance with all initial requirements and specifications. If, for some reason, you decide to neglect this type of testing, imagine for a moment a situation when a real-world user selects your application for some important business process. You’re happy to receive a long-term customer. A customer is glad to find the solution that perfectly fits his business requirements. Serious functional shortcomings arise a bit later resulting in unpleasant, if not disastrous, consequences for both sides. Negative feedback, damaged reputation, and it’s only the beginning. If only you could turn the time back and pay due attention to functional testing. So, think twice before making the final choice.

Performance testing checks the software speed, scalability and stability to see whether it meets performance requirements under expected workloads. Who wants his application to run slow while several users use it simultaneously, hear about inconsistencies across different operating systems or poor usability after the release? I’m sure you’re not on the list.

Following the title, usability testing aims to expose usability defects the application or website may have from the end user perspective. Convenience, user-friendliness, accessibility, and ease of use are top aspects to take into account. What are the benefits for you?

• Increased chances of repeat usage.
• Positive references.
• Reduced risk of the product failing.
• Potential problems highlighted before the launch.
• A chance to receive direct feedback from the target audience.

Focusing on content and UI, localization testing is used to verify the application customization for each targeted country, language or location. You’d probably want to exclude any typos, cultural appropriateness of UI, make sure that time, language and money formats will follow corresponding standards. Investing in localization testing you reduce overall support and testing expenses.

UI testing focuses on checking the functionality visible to users: menu bars, toolbars, colors, fonts, sizes, content, buttons, etc. Advantages? Opportunity to test UI from the customer’s perspective, to validate icons and elements compliance with design specifications, to cut down the number of risks and new spending on bugs fixing toward the end of SDLC, to rise credibility and improve product quality.

Security testing uncovers current and potential system vulnerabilities, identifies threats and data security from possible intruders. We all care about personal data protection. We take the security and reliability of the application we use really seriously. No breaches, no data losses, no lost customers. This is why security testing is worth doing.

Developing a product, your company is more likely to follow certain IT, external or your own internal standards. Compliance testing, also known as conformance or regulation testing, is usually conducted to determine system compliance with such requirements. Why spend time and money on this type of testing?

• To check the accurate implementation of specifications.
• To ensure application portability and interoperability.
• To utilize the prescribed standards properly.
• To dispel doubts regarding the correct work of interfaces and functions.

By the automation level

Here, we’re going to compare the most popular types of software testing:

• Manual testing
• Automated testing
• Semi-automated testing.

With this group, everything is quite clear and I’m not going to deep into details. During manual testing, a tester manually checks software for errors, defects or vulnerabilities, from the end-user perspective, following pre-defined test cases. Automated testing is performed with the help of special automation testing tools and test scripts written by a tester. Semi-automated testing combines both types of testing.

This is just a quick explanation that allows paying due attention to another question able to impact your product quality and expenses. If manual testing requires a lot of effort, why not skip or automate the process?

Although the new tendency in testing is to automate heavily, humans are still the best when it comes to analyzing the vast number of bugs that imminently show up. There are numerous situations when automation testing is not the best option for your product. So when it’s better to use a manual one?

• Physical interfaces. The Internet of Things (IoT), fitness trackers, health monitors, media players, and voice-activated devices have deeply rooted in our daily life. They all are used to interact with the real world. Of course, it’s difficult to simulate such interaction with automated test scripts. Remember one rule: any manual manipulation should be tested manually by real people.
• Testing across apps. There are situations when it’s necessary to test, let’s say, a transaction process from the buyer’s and seller’s perspective. Such a scenario can be automated, but the investment and the probability of repeatable tests with new requirements speak in favor of manual testing.
• Media testing. Each social media platform has its own parameters and formats that best work for your media content. Can such compatibility be verified with automation testing? Well, yes. To some extent. But do not forget that a human eye is the most efficient visual processor.
• Very early product stage. Introducing automation testing in the initial phase of the SDLC may probably double the engineering cost to areas that will inevitably change as you receive feedback from customers and enhancement ideas from your team. It will be quite expensive to maintain the automation suite up-to-date.

By the system knowledge level

In this group we have:

• Black box testing
• White box testing
• Gray box testing.

Imagine, there are two boxes in front of you. The first one is opened. The second one is closed. You have carefully examined both of them. The only difference is that in the first case you’ve looked inside the box. In the second, you’ve checked the box from outside only. This is how the white box and black box testing work. With the first type, you check the interface without examining the application code or internal structure. With the second one, you work directly with the code to detect bugs or errors.

Gray box testing is a combination of mentioned above testing types. A tester has access to internal data structures to design test cases but is obliged to test at the user level.

What benefits each type entails and what impact can it have on the end product?

Black box testing doesn’t require programming, deep code knowledge and can be easily conducted by a product manager, outsourcing provider or by a team of dedicated testers. You get more time to focus on strategic planning and further software development. It also the best option for emulating user experience with the application and for checking the correct functioning of all components at the UI level.

Due to the direct interaction with and deep coverage of the internal structure, white box testing helps to optimize the code by revealing hidden errors and provides so popular automation opportunity in a form of unit tests.

As for gray box testing, it a happy medium if you want to combine code knowledge with user experience. It enables a tester to uncover flaws and more significant vulnerabilities missed by developers spending fewer efforts and time.

By the level of components’ isolation

• Unit Testing
• Integration testing
• System testing.

Unit testing checks the smallest testable parts, software components to validate their performance. Why focus on it?

• More reliable and reusable codes, as they must be modular to run this type of testing.
• Easier debugging, since only the latest changes should be debugged if the test fails.
• Reduced cost of bug fixing compared to acceptance testing or to the situation when errors arise after the product release.

When you need to reveal faults in the interaction between integrated units, like interfaces, systems or packages, there is hardly a more suitable variant than running integration testing. Flaws in the software interface impact the overall user experience. No one wants his users to abandon the application after the first try. It’s far better to verify the functionality, performance, and reliability between the integrated modules during the SDLC.

Once you’ve got a complete and integrated software, the next step is to evaluate the system as a whole. System testing helps to validate both software architecture and business requirements in the environment that closely resembles the production one. Time, cost, good reputation, timely bug detection and fixing are the benefits one cannot neglect.

By the software testing stage

When to start testing your product? It should seem to be an easy question the answer to which describes the next set of testing types:

• Before the deployment
• After the deployment.

The final decision regarding the QA introduction into the development process depends on various factors, like your budget or product complexity. One way or another, there is hardly a software released to the audience without thorough testing.

The common question we hear when discussing future testing is how the workflow in both cases can be organized. Sharing our own experience, it usually looks like the following:

1. The most typical practice is to work by sprints running testing during the development process. There is a time for testing at the end of each sprint (1 or 2 days) when the team verifies new functionality and runs regression testing of the previously implemented features.
2. At the end of the development process, the build is passed for testing. The QA team checks it, provides reports and performs regression testing after the bug fixing.

In each situation, the aim is to ensure the utmost bugs coverage and top product quality.

By the scenarios positivity and the preparation degree

What if a user will exceed the allowed number of characters in the User Name field? Will the system show a notification to re-enter the name using the valid number of characters or will simply stop working? What if your system is highly vulnerable to invalid data input?

The key strategies in software testing may help to validate the work of your application:

• Positive testing
• Negative testing.

Positive testing is used to verify whether your software works as expected, per specified requirements with the valid data input.

Negative testing, in its turn, ensures that the system can deal with invalid data input or unforeseen user behavior. The ultimate goal here is to detect critical situations and prevent cases that directly lead to crushing. It also provides a chance to spot weak points and enhance quality.

A common practice is to combine positive and negative approaches for better test coverage and in-depth application study.

The last on our list are:

• Documentation testing
• Intuitive testing.

It’s great when a testing team has requirements, test plan or test cases developed, prepared before the work start. They can not only conduct documentation testing but also track requirements, estimate test coverage and testing effort, providing you an accurate estimate along with the defined timeline.

Intuitive testing is conducted without any accompanying documentation and is based on tester’s skills and experience. Although it does not follow any predefined procedure, it can uncover bugs overlooked during systematic testing, support, and complete documentation testing.

Summing up

After reading the article you may think that yes, there are plenty of software testing types that directly impact the end product quality, your reputation on the market, income in the long run and, thus, cannot be neglected. Even more, you’d better focus on complex software testing, integrating various software testing types to build a single system for an in-depth product check.

The next step is to define whether to run QA in-house or find a vendor specializing in it. It would be even better to say finding not just a vendor but a partner able to advise on the right testing types for your particular case, who shares your values and works to nurture trusted long-term partnership instead of peddling additional checks to earn more. Agree? Share your ideas in comments.