Software Testing Terminology

You will, of course, come across a lot of software testing terminology which can be quite daunting when you are new to the subject. Here is a brief overview of some of the terms that you are likely to come across.

Manual Testing
Manual testing is probably one of the commonest types of software testing. It involves using the application, sometimes in the same way as a user would, and sometimes in a way intended to flush out defects. It is generally, though not exclusively, done by following a test script.

For the uninitiated, it can seem to be very complex, but in reality, the complexity of the testing is dependent on a mixture of the quality and the stage of development of the product. For a mature and stable product, the testing can be extremely mundane and generally uneventful. For a product under development, on the other hand, the testing can change over a period of time as the development of the product advances.

In the initial stages of product development, manual testing is essential, whilst in the latter stages of development, automated testing should have been developed to replace manual testing.



Automated Testing
Sometimes there are tests that are repetitive. In these instances, automated software testing, in which a programme can run the tests for you is very useful. There are also occasions in which you need to quickly go through, say, points ABCD so that you can test around point E and F - an automated programme that can quickly get you to the point you want to be is helpful on these occasions.

There are a number of automated software testing tools that can be used. Some require technical and/or development knowledge, and some are record and playback models. The type that you use will depend on the needs of the project, and on your own level of technical and/or development knowledge.


Functional Testing (aka System Testing)
When a product is being developed, it is expected to perform certain functions. These are generally defined in a Requirements document. Functional testing is testing that the product carries out the functions that it is supposed to. Naturally, this is a major part of the testing effort. If the product doesn't do what it is supposed to do, then nothing else about it matters.


Non Functional Testing
This covers a lot of different types of testing, so it will be covered in a separate post.


Black Box Testing
This is testing an application where you have no knowledge of what is going on inside it, or of how it is doing what it does. All you know is that when you do A, then B happens. The application is a black box to you.


White Box Testing
When you know what the meaning of Black Box Testing is, then the meaning of White Box Testing is fairly self explanatory. It is testing an application when you know what is happening inside it, or what it is doing. If you are working in a very technical test role - which as a beginner, you won't be - then it can be quite common that you have a level of technical knowledge about the application. You would also be doing this if you were in a test automation role, where you would be testing your own automation scripts, generally by stepping through them with a tool, verifying that what is happening is what you expect to happen.


Grey Box Testing
Again, this is fairly self explanatory once you know the meaning of Black Box Testing and White Box Testing. It is somewhere in between black and white. In this type of testing, you have a general understanding about what is happening in the application. The level of your technical knowledge will determine how much understanding you have about the application. It can range from understanding some, if not all, of the code to simply understanding what passes from one black box to another. Because of this, Grey Box Testing is probably the most common type of testing, since you will normally at some stage have at minimum, one or more diagrams to show what is expected to happen inside the application.

Regardless of the names given to them, these are all software testing techniques that you should become familiar with. You don't necessarily have to be an expert in every one of them, but you should at least know about them.










How To Write Your Test Cases, Part 5 (Equivalencies)

Equivalence partitioning

Equivalence partitioning is one of the software testing methodologies that you just have to know. It can reduce your workload by a huge amount and make you a more efficient tester. Essentially, it is a term for saying that a1 = a2 = a3 etc, etc, so that if you have tested a1, then you have also tested a2, a3, a4, etc, etc.

Say you are testing that the totalling functionality on an e-commerce website is working correctly, then calculating the total of purchases at £10, £11, and £12 is essentially the same as calculating the total of purchases at £15, £16, and £17. The functionality is supposed to add up the numbers and give the correct total.

How many permutations of numbers are there? It is an infinite amount, and so you cannot possibly expect to go through all of them and make sure that the amount calculated is always correct.

But you can say that it is basically a calculator function, and that if it adds up one set of numbers correctly, it will add up another set of numbers correctly. In essence, when you say this, you are saying that if it can add up 10, 11, and 12 correctly, then it can also add up 15, 16, and 17 correctly. That means that each of those tests is essentially the same, or that they are equivalents.

Another example is that you are testing a limit on a credit card. Supposing that the card will allow credit purchases up to £1000 in value. Clearly, a purchase of £2000 should be rejected. So should a purchase of £1001. A purchase which takes the value to more than £1000 should also be rejected. So if you are starting from, say, an existing balance of £995, then any amount which takes it over £1000 should be rejected, whether it is £5.01 or £10,000. This would be true of any amount inbetween, and also of any amount above £10,000. So in that respect, any amount of £5.01 or greater should produce the same result - in testing terms, they are equivalent.

With this example, you can also see that equivalence partitioning can be closely linked to boundary testing, because anything that falls outside the boundary is equivalent, regardless of it's value.

Hopefully you can see from these examples that as a tester, this is one of the types of testing techniques that you will find extremely useful.