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:
- System Integration
- User Acceptance
- Black/White/Grey Box
- Volume & Stress
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.
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.
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.
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 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.