9 Types Of Software Testing In Software Engineering

Software testing is a craft. A software tester, like a craftsman, is meant to have a firm understanding of the tools at their disposal. We’ve compiled a list of 9 different types of software testing, and the tools each type uses, to help QA analysts and anyone else working in the software testing profession better understand their craft.

Why Do We Need Software Testing?

Sometimes it’s important to be reminded why what you’re doing matters. The simple fact is that every piece of software ever developed that found success did so with the help of software testers working tirelessly to ensure the product was at as high a standard possible. Here’s three reasons why software testing matters. 

1. Customer Satisfaction: While developing a project it can be easy to get lost in the woods of code and forget that the user needs to be satisfied with how the software works, too. QA analysts and other QA members get to occupy that role. 
2. Product Quality: Every profession in which a team or individual creates something from scratch requires another team to catch their mistakes. Writers need editors. Film directors also need editors. Software developers don’t need editors, but they do need a QA team to provide an objective point of view and catch any errors. 
3. Security: With every passing day, it seems this point becomes increasingly important. Customers want peace of mind knowing the information they put into the software, and the work they do within it stays private. Part of QA is making sure that customers have that trust. 

Software Testing Methodologies

Every type of software testing technique mentioned in this article belongs to one of two main categories, static testing, and dynamic testing. Before we delve into the specific details of the 9 different software testing techniques, I’ll explain the difference between these two methodologies and wherein the software development cycle comes into play.

Static Testing

Static testing is a type of software testing that performed early in the development cycle. It’s a cost-effective way to find bugs before they become major headaches for the development team. static tests are ran early in the development cycle because they can be done without having fully functional software. That’s right, the software can be debugged before it’s even near completion. See how that can come in handy? 

Static tests are performed in two ways:

• Manual Examinations: Where the code in analysed by a QA analyst or tester. 
• Automatic Analysis: Where a testing tool automatically checks the program document and notes any errors.

Static Testing Is:

• Performed without executing code.
• Cost effective.
• Useful for making sure the software meet the verification specifications.
• A way to determine the root cause of bugs.

Most static tests are conducted in the form of document reviews. In this scenario, a document is either a written description of a product (known as a software design document) or the program source code. Here are some static test techniques every QA analyst should know:

• Informal Review:  There is no strict guidelines to the informal review. The team looks over the test documents and comment on what they see. There is no documentation.
• Walkthrough: The author of the code goes through their document and the QA team raises any questions and concerns. Walkthroughs are typically very informal and a good way to discuss topics with people who work outside the software field. 
• Technical Review: Technical experts will come together and review the technical specifications of the code. Doing this early in the development process ensures that the final product will meet the required specifications.
• Inspections: The most formal of all reviews. A team of trained moderators will thoroughly inspect the documents during the meeting. Any found bugs will be formally documented and log for review. There will be a follow up to check that the documented bugs were addressed. 

In most cases, static test reviews are useful because the entire QA team will analyze the product and propose changes based on problems they see and problems for forecast. Other than the benefit of getting a wide variety of voices involved in the conversation, this has an additional benefit of getting all the team members caught up regarding the project’s progress and design. 

Use static testing if your team is:

• Early in the development process.
• Looking for a cost effective way to find bugs.
• Have software that’s not ready to be executed.
• Want to catch errors early in development.

Join our Newsletter

Discover what’s new in the QA world.

• Your email

  *

• By submitting this form you agree to receive The QA Lead emails in your inbox. For further details, review our Privacy Policy.
• Name

  This field is for validation purposes and should be left unchanged.

Δ

Dynamic Testing

Unlike static testing, dynamic testing is a type of software testing that requires the execution of code. Naturally, this requires the development to be further along in the production cycle. The benefit of testing executable code is that QA analysts can get a look at how the software performs while running in a real-world situation. There is a great way to check the functional behavior of the software and other things like CPU usage. Dynamic testing checks that the expected outcome matches the real-life outcome. The main goal of dynamic testing is to verify that the product meets the design and functional requirements set forth before the project began.

Typically, there are four steps involved when system software is dynamically tested that QA analysts should know:

• Unit Testing: When software is being unit tested, it’s being divided into the smallest possible components and tested individually. By testing in this way, QA analysts have peace of mind knowing that each individual part of the software is working as intended. And if a bug is found, it will be easier to fix at this stage of development, where they can quickly isolate the problem code. Typically, when the QA team begins dynamic testing (although sometimes this stage of testing will be handled by the development team) they will start with unit tests.
• Integration Testing: After the software has been thoroughly broken down into its components and tested via unit testing, the software will be assembled into groups and tested again. Now, if unit testing were to make sure each individual part was running properly, integration testing makes sure those individual parts are talking to each other like they’re supposed to. Think of it like the assembly of a car. At each stage of assembly the car parts (the motor, the pedals, the steering wheel) will be tested individually. Then, the car will be assembled and tested as a whole, to make sure the gas pedal is talking properly to the engine (and that the breaks are, too!).
• System Testing: System testing is the third level of software testing. At this stage a complete and fully integrated software is tested. The purpose of the system test is to ensure that the software is meeting requirements, aka, doing what it was designed to do. 
• Acceptance Testing: The final stage of dynamic testing. The acceptance test is to once again test against the requirements and make sure the software is polished to an acceptable standard. It’s done to make sure that no errors slipped through the other stages of testing. Essentially, it’s double checking for the sake of safety. 

Stages of Dynamic Testing

1. Unit Testing
2. Integration Testing
3. System Testing
4. Acceptance Testing

Quick Tip: Verification vs Validation Testing 

Verification testing shares all the key characteristics of static testing. The purpose of a verification test is to verify all the documents and code and is achieved through the same methods used when static testing

Similarly, validation testing shares all the key characteristics of dynamic testing. A verification test is concerned with confirming that the software is high quality, which is exactly what the system and acceptance tests are concerned with. 

Now that we’ve covered some key concepts concerning software testing, let’s explore the 9 types of software testing every QA analyst should know.

9 Types of Software Testing Every QA Analyst Should Know:

1. Black Box
2. White Box
3. Grey Box 
4. Automated 
5. Unit
6. Regression
7. Exploratory
8. Functional Testing
9. Usability Testing

1. Black Box Testing

Black box testing is a software testing strategy where the design of the software system being tested is unknown to the tester.

Remember that scene at the end of Pulp Fiction, where Samuel Jackson opens up the briefcase and his face lights up? As the audience, we know what the briefcase means and represents in the context of the film, but we never learn what’s inside. A black box tester is the audience member, knowing what the thing (whether it’s a briefcase or system software) is supposed to do, but not what it’s made of.

A tester in charge of black box testing a time tracking software will open the program without knowledge of the internal design of the software and try the different features and menus to make sure they’re working as expected. The reason for black box testing is that without intimate knowledge of the software’s design, the tester will approach the software with similar expectations as the end user. 

Some benefits of black box testing are:

• Testers don’t need much knowledge of programming languages because the tester is using the software from the perspective of a user.
• Provides an unbiased review of the software because the software test is done by the QA team instead of the software developers.
• The testers do not need to be caught up with the software systems development, meaning there’s very little lead up time before the tests can be performed.

Related read: 10 Best Black Box Testing Tools

2. White Box Testing

In white box testing the QA member will fully understand the internal structure and design of the software being tested. They will approach the test as an inspector, making sure every part of the program is running properly. White box testing is sometimes referred to as clear box testing because the tester observes the interactions between units as they test the software. Unlike black box testing, a white box tester is not nearly as concerned with the user experience. 

Some benefits to white box testing are:

• Tests can be run at early stages of development. The graphic user interface (GUI) doesn’t have to be fully functional. 
• The tests are more thorough and deliberate than black box tests.

In the Pulp Fiction example, the white box tester is Tim Roth’s character, staring directly at what’s inside the briefcase. 

3. Grey Box Testing

In grey box testing the tester has some knowledge of the software’s internal structure and design (white box) but is still testing from the perspective of an end user (black box). Just like that, grey box testing was born. In grey box testing the design of the test will be developed by looking at the software’s internal structure and the actual test will be performed using the user interface.

Again, if this were that famous Pulp Fiction scene, the grey box tester is neither the audience nor Tim Roth. This time, the tester is Quentin Tarintino himself.  

4. Automated Testing

Automated tests use software to perform tasks without the manual instruction of a tester.

In manual testing, the tester will write the code they want to execute or plan the software path they want to check is working properly. Automated tests take care of such things on the testers behalf. Here’s a quick list of automated software and QA tools that QA analysts should know:

For a more in-depth review of automated testing tools, check out the list of Best Automated Testing Tools you should be using.

5. Unit Testing

Unit testing tools make sure every individual part of the software works properly. It’s extremely important to make sure unit testing is properly done otherwise the development team will suffer huge setback when they later realize a key part of their software doesn’t work. 

6. Regression Testing

Regression testing tools will run old tests on new builds to make sure the software still performs as intended. Running regression tests protects developers from latent effects by making sure a change in the software at point A didn’t accidentally break something way over at point D. 

For a QA analyst, two steps forward, one step back should not be viewed as a negative. By taking one step back every once in a while you make sure you’re not poised to take fifty steps back later.

7. Exploratory Testing

Exploratory testing is testing for people who don’t like planning. In most other situations, the test case will be thoroughly planned before executed. Not here. When a tester is performing an exploratory test they are exploring the software without any predefined plan.

The benefit of exploratory testing is that it allows the tester to adapt to their findings on the fly, without the need to write another test case. Exploratory testing also allows for collaboration, theory crafting and collaboration all on the fly.

As the agile theory of development has become more prominent, so has exploratory testing. By allowing QA testers to use their intuition, many interesting bugs are caught that a traditional test execution might not have looked for. 

Be warned: exploratory testing can require a great deal of creativity. 

8. Functional Testing

Functional testing is performed to make sure the system software matches the requirements of the project before development began.

The software tester will check that their inputs match the expected output. It’s performed during one of the last stages of testing, either in system or acceptance testing, and is exclusively a form of black box testing, as it isn’t concerned with how the software works as long as it works. 

9. Usability Testing

Usability testers make sure the design choices are functional yet intuitive.

If you predict that many users of your software will want to back-up their documents every half hour, it’s best to have the back-up function at an easily accessible place instead of hidden behind four sub-menus. 

On many occasions a piece of software has been developed that works flawlessly and fills an important need in the market, but is completely impossible to navigate from a user perspective. This can be explained by a lack of usability testing during the software testing phase.

At the end of the day, no matter how good a piece of software is technically, it’ll be difficult to find a market if users don’t enjoy using it.

What Do You Think?

The software testing industry is always changing and QA analysts need to stay up to date on current trends. What are some types of software testing you’re using in the workplace? Let me know in the comments below!