7 Common Types of Software Testing [Complete Guide + FAQ] (2023)

Most developers have no idea how testing is actually done, andhow valuable understanding the fundamentals of software testing can be for developers who really want to excel in their careers.

Much of the success I've had in my career as a software engineer is due to my experience in testing.

Why?

Because I learned the hard way.

In my days...

Quick Usersnap PSA: If you are aCustomer feedback guide, skip the jump and fly there now! That is all!

I'm John Sonmez, author of the bestselling Soft Skills: The Software Developer's Life Manual and one of my first official articles onsoftware developmentindustry was that of a tester.

In this post, I'll talk about the 7 most common approaches to software testing and how you can use them to become a better software developer.

My job was to look at stacks of paper printed by a new printer we were testing at HP and compare them to the "master" prints made by older printers.

In fact, I didn't compare the pages myself. Instead I would run the tests, ask someone else to compare prints and see what differences they made.

With any difference I would check and decide based on testing if the result was a real bug or defect. If it were the latter I would write a bug report for a developer to look into and possibly fix.

That background made me look at the code I was writing a little differently and realize that my job as a software developer was not just to implement features and fix bugs, but also to make sure the software I wrote was accurate and worked. As intended.

It seems like a simple and obvious idea, but ifIf you don't even know the basics of testing, you probably don't have the best idea of ​​what "works correctly and as designed" really means..

The basic idea behind software testing

Testing is often not understood by new programmers. They don't think it's necessary.

On the surface, it might seem a bit trivial.

Do we really need to test this code? I ran it on my machine and it worked perfectly, so let's send it.

[Tweet "Test is really about risk reduction at its core."]

The purpose of software testing is not to findErrorthe stopimprove the software. It's about reducing risk by proactively finding and fixing the issues that would most impact the customer using the software. Users can get frustrated with their software when it slows down and crashes. Running and hanging can be reasons for everythingslow performanceyour machine

This objective is particularly relevant forTry commercial softwarewith complex digital workflows. In this case, it is essential to ensure the proper functioning, usability, compatibility and data consistency of the software, as problems discovered after a release have a greater impact.

Customers can be affected by the frequency of a bug or unwanted functionality or the severity of the issue.

• Effect of the frequency of an error:
  If you have a glitch on youraccounting programhaving it freeze for a second or two when entering a value greater than $1000 wouldn't have much of an impact; but that would be a high enough frequency to really annoy the customer.
• Impact by severity of the problem:
  If you had an accounting software error that caused you to lose all data every 1000. The datastore is corrupted, this would have a big impact, but very rarely

I define the reasonsoftware teststhat's because, as any tester will tell you,You can never find every bug or flaw in any software, and you can never test every possible input.in software. (For any non-trivial application.)

So the idea is not to find every possible thing that could or could go wrong, or even to check software against a specification as some people like to define software testing, because both are impossible.

(Oh, even if you find a complete specification for an application in your software engineering history, let me know.)

Instead,The main focus and idea behind software testing is to reduce the risk of having a strong negative impact on the customer.when using the software.

This is typically done by prioritizing which areas of the software are likely to have the most impact (i.e. risk) and then deciding to run a suite of tests to verify the desired functionality in that area.

Typically, when actual functionality deviates from intended functionality, an error is logged and these errors are prioritized based on severity.

Some bugs are fixed, other bugs are so small that they are only noticed and left in the system.

Common approaches to testing software

The world of testing and QA is vast.

Just as the development world has many concepts and methods for creating software,There are many ways to think about testing, and the field is always changing.

Even in the name.

Early in my career, calling someone who worked on testing a tester could have been considered an insult or an insult; they preferred to be called quality assurance (QA) specialists.

Just a year or two ago I attended a test conference and made the mistake of calling someone QA. They corrected me and said the preferred term was tester.

You cannot win them all.

Anyway, let's talk about the different types of testing so that you get a general idea of ​​what someone is talking about by throwing out these terms, which you'll hear a lot in the software development world.

This is by no means a complete list.

black box test

Black box testing is easyTest as if the software itself were a black box.

Black box testing is one of the most common forms of testing and, in fact, a way to describe an entire category of testing.

When you do black box testing, you only deal with inputs and outputs. It doesn't matter how the actual expenses are derived.

You don't know anything about the code or how it works, you just know that given a specific set of inputs to the software, a specific set of outputs must be produced.

Most tests are done this way because they are largely unbiased. Either it works or it doesn't.

[Tweet "Every developer should know at least 1 of these 7 common types of software testing"]

white box test

The real white box testing is when you understand some of the internals of the system and perhaps have access to the actual source code., which you use to inform your tests and their goals.

White box testing is more or less the opposite of black box testing.

Swindlerwhite box test, you have at least a rough idea of ​​what's going on in the software.

Unit testing is often referred to as white box testing, but I beg to differ. Unit tests are not tests.

Example:
When you look at code that performs complex calculationsfor some accounting software and I saw that there was a section of code that did one set of calculations for values ​​above a certain value and another set of calculations for all other values,You can create tests that target both scenarios.

With black-box testing, you have no way of knowing whether either condition exists, so it's highly unlikely that you'll test both unless you're lucky.

college entrance examination

The basic idea of ​​acceptance testing is this.It has some tests that test the real needs or expectations of the client and other tests that are performed on the system as a whole.

sometimes he saysUser acceptance tests(abbreviation: UAT).

It is sometimes called a physical test.

This type of testing can be testing system functionality, or testing usability, or both.

The idea is that acceptance tests test what is expected and what actually happens.

automated tests

Automated testing is any test that involves running the test and verifying the results.automated.

So you can automate testing a web application by running scripts that open a web page, enter some data, press some buttons, and look for some results on a page.

You can also automate testing an API by writing scripts that call the API with different data and examine the returned results.

More and more is testedon the way to automated testingbecause iterating through test cases manually can be tedious, error-prone, and expensive, especially in an agile environment that might need to run the same set of tests every two weeks to make sure nothing breaks.

regression tests

This brings us to regression testing, which is basically what it is.Tests carried out to ensure that the system continues to function as before.

The purpose of regression testing is to ensure that the software does not lag behind in terms of functionality.

This is extremely important in agile development methodologies, where software is developed incrementally and there is constant potential that adding new features can break existing ones.

Most automated tests are regression tests.

In fact,You could actually argue that all automated tests are regression tests.since the whole purpose of automating a test is so that it can be run multiple times.

functional test

Functional testing is another broad term used in the testing world to refer to it.Testing activities in which the actual functionality of the system is tested.

This might sound obvious.

You might be thinking, "Obviously, what else would I be testing if I wasn't testing system functionality?"

But it turns out you can test all sorts of non-functional items like performance, usability, resiliency, security,scalabilityI could go on like this, believe me.

So functional testing is the kind of testing where you really care if the system is doing what it should from a functional perspective.

If I make this entry and press this key, do I get the expected result?

I don't care how long it takes. I don't care if the screen flashes bright red and the computer starts to smoke, do I get my score?

experimental research

I like to make fun of exploratory testing as "lazy testing".

It really annoys testers when I do this.

But the idea of ​​exploratory testing definitely has some legitimacy, and maybe I'm being too harsh and judgmental.

The idea behind exploratory testing, when done correctly, is that you have some guidelines and a basic plan of what application areas you are going to test and how you are going to test them.

Then skip the actual test cases and examine the app, looking for things that might be wrong or unexpected behavior.

Exploratory testing sessions are usually logged so that if a bug is found, the issue can be reproduced by following the steps taken by the exploratory tester.

While I'm generally not a big advocate of this type of testing, I must give it its merits, as exploratory testing can often uncover bugs that no rational test case would have designed to exploit.

Other test forms

We've really only scratched the surface of all the different test types and ratings.

There are many other forms of proof, including:

• Load Testing: How an App Performs Under Heavy Load
• Performance Test: Application performance based on specific scenarios
• Recovery Tests: Recovery from error conditions or hardware problems
• Security Tests - System Security
• resilience test
• Testing usability
• accessibility test

The list goes on and on.

the testing process

Different organizations will have very different ideas about how testing should be done and what process should be followed.

You will also see many formal specifications created by different testing organizations that cover the "testing process".

So, like a lot of what I've said about testing, the point here isn't to perfectly prescribe or model the perfect testing process, but rather to give you an idea of ​​what the testing process in general looks like and what it contains.

I like the pragmatic approach to life and trials.

Step 1 - Developing a test plan

Testing usually starts with developing some sort ofplano experimental.

• How is it tested?
• What is our testing strategy?
• What kind of tests will we do?
• What features will we test?
• what is the time

These are all questions that are usually answered in the test plan or, if the test plan is not a formal document, the test plan for a project.

Step 2 - Design Tests

Next,Tests are generally designed to a high standard.depending on system needs or functionality.

In this phase, a tester can create a list of common test cases to run, what types of conditions to test, and what is needed to run the tests.

Step 3: Creating and running the test

After that, theTests are typically created and run.

Sometimes this happens in one step.

Tests are sometimes written in test management software first and run later.

Step 4 - Registration Results

The results ofTests are recorded and graded.and it allErrors or defects are usually loggedin some waybug tracking system.

Bugs are prioritized and sent to developers for correction.

Fixed bugs are retestedand this cycle continues until the software meets standard quality criteria for shippable code.

And that's basically it.

plan tests, design tests, write tests, run tests,find bugs,error correction, Launch the software.

How testing works in agile teams

The standard testing process tends to have some issuesagile teamswhere new features are coded and implemented every few weeks.

Many teams try to strictly follow the standard testing process or throw it out the window instead of incorporating it into the process.agile testlife cycle ofsoftware development process.

Both approaches are wrong.

Instead,the focus really needs to shift to developing test cases and test scenarios earlyeven before any code is written and reduce the testing process to a smaller iteration, just like we do when developing software in an agile way.

It just means we need to cut things into smaller pieces and have a little tighter feedback loop.

Instead of spending a lot of time creating a test plan for the project and designing complicated test cases, teams should perform the testing process at the feature level.

Each role should be treated as a mini-project.and must be tested by a miniature version of the testing process that starts before any code is written.

In fact, test cases are ideally created before the code, or at least the test design, is written, so that code and test case development can occur concurrently.

Another important aspect of agile testing is automation.

As new software is released in very short iterations, regression testing becomes more important, making automated testing even more important.

In my perfect world of agile testing, automated tests are created before the code to implement the features is written, true test-driven development, but this rarely happens in reality.

Test and you the developer

What about you, the software developer? What is your role in all these tests?

at least you have one

Yes. Definitive!

One of the biggest failures of software development teams is not involving developers enough or taking enough responsibility for the testing and quality of their own code.

As a software developer, you need to care more about quality than anyone else.

You cannot assume that QA will find the bugs in your code.

Instead, you should definitely take responsibility for finding and fixing bugs before testing your code.

The reason is quite simple. The further into software development a bug is found, the more expensive it is to fix.

Think of it like this.

If you test your own code thoroughly and find a bug in that code before logging it and submitting it to QA, you can fix that bug quickly and it might cost you an extra hour.

If you get the same error and don't take the time to find and fix it yourself, the process might look something like this:

?? A tester runs a test that finds the bug in your code.

?? The tester reruns the test to make sure the error is valid.

?? The tester reports a bug in the bug tracking software.

?? A development manager decides the bug is severe enough for you to work on and assigns it to you.

?‍♂️ Are you trying to reproduce the error, but it seems to be working on your computer.

?? The tester reproduces the bug and includes more detailed steps in the bug report.

?? Finally, you can reproduce and fix the error.

✅ You update the bug report with the fix.

?? The tester goes back and verifies that the bug was indeed fixed and marks the bug as fixed.

Is that a lot of time someone can waste...?‍♂️

I don't mean to say you're lazy, but...

You might want to take an extra 10 minutes to test your own code before committing.

You're not going to catch everything, but if you can catch even 10% of the errors that would otherwise make it to QA, you'll save a little time, don't you think?

Okay, now I hope you have a good idea of ​​what testing is, what the purpose of testing is, what types of testing can be done, and what your role is in this whole process.

word of truth

I just wanted to cover some of the fundamentals you'll hear and see in a software developer's everyday conversations.

Hi John, I'm a little confused. Black box testing is very similar to functional testing. What is the difference? Oh, and also the same question for regression testing versus automated testing. Are not all automated tests essentially regression tests?

Okay, shhh... I'll let you in on a little secret that bothers QA people, ie testers.

Many of these test terms are basically the same thing. Sometimes I feel like the entire testing industry feels the need to come up with a lot of terminology and add a lot of complexity to something that is inherently simple.

Now, don't get me wrong, the tests are important and it takes skill to be good at them, but it's not that hard...really.

To address some details. Basically, functional testing can be white box or black box, but it will usually be black box. Black box and white box testing only refer to how functional tests or other tests are performed. It's really just some kind of functional test. Are you looking at the code for clues about what to test, or are you treating it like a mysterious black box? Black box testing is just the high level concept or idea of ​​testing an application without being able to look inside to see how it is implemented.

If you're doing effective functional testing, you're probably doing it black box style, although conceivably looking at the code will give you an idea of ​​some edge cases or special cases you might want to test. that otherwise might have been lost. Again, for automated testing versus regression testing, we are dealing with a higher level of concept and implementation.

Regression testing is a concept. It's the idea that if something breaks, or before it breaks, you should create a suite of tests to ensure that the system's functionality is not diminished or degraded. Automated tests serve this purpose very well because they are automated. Virtually all automated tests are regression tests, but you can manually run regression tests to ensure your software doesn't lag behind in terms of functionality.

If you decide to become a tester and want to interview for a testing position, you should probably know all of these things and be able to explain why exploratory testing is actually a valid way to test things and what user testing and testing look like. app. acceptance. not the same things.

But honestly, if you are a software developer, it only matters that you have an idea of ​​the concepts, the vocabulary and that you understand the real idea behind testing, which is risk mitigation.

So don't worry about all the semantics and focus on the big ideas. This is important.

Author's biography

John Sonmez is the author of the longtime hitSoft Skills: The Software Developer's Guide to Lifeand founder ofsimple programmer.This article is an excerpt fromThe complete professional guide for software developers.by Joao Sonmes. To receive the entire book in your inbox, visitHere. MilitaryComplete professional guide for software developersand, John shares the principles and insights that took him from a teenage hacker to high-paying senior development and consulting roles, and from early retirement at age 33 to a second career as an entrepreneur.

Today, he runs the popular Simple Programmer blog and YouTube channel, where every year he helps millions of developers master the professional and life skills that have made a difference to their success.

Bonus Tip: Software Testing with Usersnap

I know I just talked about the most common types of software testing. Finally I wanted you to knowfrom the user, which is a great solution forUAT Tests and User Tests, used by companies such asFacebook, Red Hat e Microsoft.

Collect feedback easily. Gain more knowledge and confidence.

Getting feedback has never been easier, and we hope you've noticed after reading this article. Let us know what you think, your opinion matters.

And if you're willing to try customer feedback software, Usersnap offers a free trial.Recordtoday orschedule a demowith our feedback experts.