So many types of testing… So what are they all?

When it comes to computer software, the word ‘bug’ is never welcome. To a software manufacturer a bug is a nightmare come true. But like all products, software needs to be tested. It needs to be tested from two points of view.

  • Does it have any bugs?
  • Does it do all it is supposed to do?

A bug is a glitch, a malfunction, a problem preventing the software from working at all or from working properly. But sometimes the software may apparently work smoothly yet behind the scenes things are not working properly. That’s where the application code needs checking. That’s why the software needs to be tested inside and out.

But there are inherent dangers when ‘fixing’ software. Testing can be seen as a never ending task so there comes a time when enough is enough and the product is finally released. The danger with testing which shows up a flaw, error or bug is that in fixing the fault, a new error is created. There are examples of this happening when a code was changed, sometimes only very slightly, and that in turn created greater and more widespread problems for the end users. Testing may be essential and may correct problems but it has its down side as well.

Software testing includes the obvious test of checking the finished product, sometimes called the script, against the application, the mechanics of the software. There are many other areas of testing that need to be considered:

  • Deciding on what is to be tested
  • Deciding on the test conditions
  • Examining the ability to close the software successfully
  • Creating test scenarios and evaluating the various results
  • Examining the source code

There are different types of software testing. White box testing examines the logic of the code used to write the software.  The examiner needs to know how to write code and the logic it follows and thus be able to discover what part or parts of the code are causing the software to not work properly or at all. White box testing can not only find faults but can ‘clean up’ the code making the software run more smoothly and quicker. This can also identify that all the requirements of the system have been met for those instances where it is not obvious from actually using the system.

Black box testing doesn’t look inside the computer and examine the code. Black box testing requires the examiner to know everything about the capabilities of the software – what it can actually do. Then by testing the operations of the software, a black box examiner can discover if the claims of the manufacturer can actually be substantiated.  Does it do what it is meant to do? Does it suit the needs of the actual user?

To go into a bit more detail, here is a definition of some common types of testing.

Unit Testing

Unit testing is the testing performed by Developers on other Developer’s code to ensure it functions correctly and as expected.

Requirements Based Testing

Requirements Based Testing is the testing of the final product from the user’s perspective. Requirements based test cases are based on the Use Cases as outlined in the Requirements Specifications or Scenarios created based on user requirements. The purpose of this type of testing is:

  • To ensure that the product fulfils user requirements.
  • To ensure that the product is stable when used in the way that the users will eventually use it.

Function Based Testing

Function Based Testing is the testing of the integrated system features that are not comprehensively covered in the Requirements Based Testing. The purpose of this type of testing is:

  • To ensure that the product is stable when used in the way that the users will eventually use it.
  • To ensure that all the individual components of the application function correctly together.

Destructive Testing

Destructive testing is testing that attempts to create errors by deliberately using the system in a way in that it was not designed to be used.

This type of testing should be done using two separate approaches:

  • Free play destructive testing – this type of testing requires imagination and persistence rather than structured test plans.
  • Systematic destructive testing – this testing uses a checklist of possibly destructive actions to be carried out systematically on the product.

It is important that time is allocated for both destructive testing modes.

Security Testing

Security testing is testing designed to ensure that only those users with appropriate permission can access the system. This testing includes testing the entire system with users with various levels of permission (read only, edit, administrator Etc).

Load Testing

Load testing is the simulation of many users accessing the system at the same time or over a long period. This testing is best performed by the use of an automated load testing tool, but for small systems with an anticipated low load, the testing may be done by organising for many users to access the system at the same time.

It might include such things as:

  • Testing that the product is stable when used at its maximum load.
  • Testing that the response times for a single user are within acceptable limits when the product is subjected to its maximum load.
  • Testing that the total time to perform a maximum number of simultaneous tasks falls within the acceptable limits.

Concurrency Testing

Concurrency testing is the testing of the database locking system that is implemented to prevent two users from modifying the same record at the same time.

Some applications will lock a record when a user has it open to prevent any other users accessing that record. Alternatively, many applications will be designed using optimistic concurrency locking (if two users edit the same record at the same time, after the first user saves the record, the second user should be presented with a message of the type: “The record has been modified by another user. Please refresh their changes before trying again.”)

Interface Standards Testing

Interface Standards Testing is the testing of the user interface. The following factors should be examined:

  • Usability - assess the usability of the user interface in terms of its affect on the user’s efficiency and in terms of ease of use (i.e. how easy is it to understand the application the first time it is used).
  • Spelling and grammar – ensure that the spelling and grammar are correct.
  • Consistency of format – check that font types and sizes, and screen layouts are consistent.
  • Browse paths and links - check that all browse paths and links take the user to the appropriate screen.
  • Commentary and on line help – check that help is available to the user on each screen/dialog and that the help content is correct, consistently formatted, and has correct spelling and grammar.
  • Data types: check that the system only accepts the required data type and should present a user-friendly error message where the incorrect data type is entered. For example entering text into a date field. List the required data type in the test specification.
  • Mandatory fields: the system should check that mandatory fields have been entered and present a user-friendly error message where they have not.
  • Default data: check that all fields that should have a default value selected work correctly.
  • Data range: Test data entry at the minimum, maximum, below minimum and above maximum ranges. (E.g. If the design range for the input field is 1-10, test with 0,1,10 &11).
  • List content: check that drop down lists contains the correct information.
  • Other factors - as outlined in the User Interfaces section of the Requirements Specification.

The need for software testing is obvious. From the success of a business to the loss of life, software needs to be tested thoroughly so that it works well and performs the tasks it is created to perform. Only by proper testing can software be approved and function well. Just as the creation of software is a highly skilled and ever evolving task, so too is the skill and science of testing software.


Tools and Templates

Code Review Checklist Form – you can grab yourself a Free copy of this tool here.


Powered by Facebook Comments

Leave a Reply

Your email address will not be published. Required fields are marked *