Test Types


Now that we have covered some of the basics of test cases, it is time to start looking at the various types of testing that can occur. Once again, we will start at a high level, and then go into more detail in future posts. For some/most of you, this will be very basic information, but I feel that it is important

So what are some of the various types of testing that can occur? The following is a list of types of tests:

  • Unit
  • Integration
  • System
  • System Integration
  • Regression
  • User Acceptance
  • Black/White/Grey Box
  • Alpha/Beta
  • Stability
  • Usability
  • Security
  • Internationalization/Localization
  • Destructive
  • Performance
  • Volume & Stress
  • Automated

As you can see, there are many types of tests that can be run, and there and many forms and combinations that these different test types can come in, so it pays to understand what each does. I won’t bore you with the details of each of these, but if you would like more information, you can visit the Software Testing wiki page to get more details about each test type. I do want to focus on a few of these however, as a couple are much more common than the rest.


Unit Testing

This is typically an area of testing that falls in the purview of the developers, but the QA should ensure that it is being done. The goal of Unit testing is to verify functionality of code, typically at the function or module level. This is usually much more technical than what the QA teams needs to worry about, but it is an important safety measure. If unit testing is being done, there are usually far fewer show-stopper type of bugs that make it out of development. It also provides a very good sanity check for the developers to ensure the function is doing what it is expected to do.


Integration/System/System Integration

I combine these three into a single concept. These are essentially the tests that you run to make sure all of the various pieces and components of the system(s) play well together, and do what is expected. These tests are usually rolled up together when doing performance or volume & stress testing as well. This testing is pretty key to the overall health of the final system, and should be planned for as early as possible in the overall lifecycle. This will have a pretty major impact on both functional and usability testing, so if your integration testing is flawed, you are bound to run into more issues down the line.


Regression

This refers to testing that occurs to ensure that changes do not introduce new issues into the system. You want to make sure previous issues were not impacted, working items were not broken, etc. This can happen either as a manual test, or it can be rolled into a more comprehensive automated testing plan. You are primarily looking to make sure that old bugs do not make their way back into the system after an update (or rollback) occurs. One way to approach this is to create a special test plan that includes all of the issues previously found that you can quickly run through whenever a new build is available. You should run this in addition to any other testing that you may be doing.


Automated

Automated testing is a very big piece of any strategy that you will be putting together. It’s important to keep in mind what it is, and also what it isn’t. It is a tool that allows you to quickly run through a suite of tests to ensure that the system is still functioning properly. It is not a way to get out of doing manual testing. A good automated strategy and implementation will cover about 60-75% of a given system, so you will have a good basis on which to plan your manual tests. It is simply not feasible to try and automate your entire system.


That should give you a basic understanding of all the different types of tests that there are available to you, as well as some of the more common ones that are used in pretty much every environment.

Advertisements

2 thoughts on “Test Types

  1. nick

    Great post! Its always good to take another look at the basics especially for the people who have been doing it for a while.

    How do you feel about User Acceptance Test (UAT) and where they fit in?

    1. Thanks Nick, you hit it exactly…sometimes we just need a refresher!

      In terms of UAT, I definitely think it is a needed and useful tool, however the implementation of it will vary depending on your product/company/environment. The purpose of UAT is for the end user to provide feedback/sign off on the product from a usability stand-point. That end user could be a product owner, a third-party, or even a consumer. Sometimes we call it a alpha/beta test, but at the end of the day, it is still an end-user providing feedback on how the app works in a real world environment. While the QA team is not typically the team that does this piece of the test cycle, they will more than likely be very involved, either in coordinating it, or responding to the feedback in some fashion. Again, how that is handled would depend entirely on your organization…there is no one-size-fits-all solution.

      I was planning on doing a full post on this in the future already, but I think it makes sense to do it sooner rather than later!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s