1. Test Techniques
This section covers a very important and the popular topic of test design techniques. This is where testers get their creativity to work and come up with ideas on how to test the software. As we mentioned before, exhaustive testing is impossible. That means we cannot test everything. So we have to be very, very selective on how to test the software. So how to design the perfect test case is where the test design techniques come into action.
The purpose of a test design technique is to identify test conditions, test cases and test data. But while there are many techniques to design a test case, you may ask, each test technique tackles a different situation. Some are general, others are very specific. Some are straightforward. Others are difficult and complex to implement. There are many excellent books published on software testing techniques. There are new techniques that bubb up every day. All these to help the tester do his job effectively and efficiently.
We have talked in the first section about effectiveness versus efficiency. From the testing point of view, effective testing means we find more faults or defects, focus attention on specific types of defects if needed. In some situations you might need to concentrate on calculation faults. In other situations you might need to focus on new eye issues and so on. In addition, we want to make sure that you are testing the right thing. Efficient testing, on the other hand, means that we find faults with the minimum effort, with the minimum number of distances, avoiding duplication to minimize cost and time. Plus, using techniques that are measurable in this section, we will learn the most important famous ones.
However, as a tester, I encourage you to read more and more about test design techniques. Categories of Test Techniques In this syllabus, the test scale design techniques we will look at are grouped into three categories black box, whitebox and experience based. Black box or specification based techniques are those based on driving test cases directly from a specification of a model of a system or proposed system. They are called this way because we cannot know what’s inside the box, which is the software. It’s also called behavior or behavior based techniques because we know how it should behave from other documents, requirements, documents, user manuals, technical specification use cases, user stories, or business processes.
We might know how it should behave because we have a model or another system that behaves like ours. If we have any information about how the system should behave, then we are using black box testing or specification based testing. These techniques are applicable to both functional and non functional testing. Black box test techniques concentrate on the inputs and outputs of the test object without reference to its internal structure. The second category of test design techniques those based on driving test cases directly from the structure of a component or system known as structure based or structure or white box techniques. And it’s called white box because in this situation we know what’s inside the box, we know how it’s constructed. We might know architecture, detailed design, internal structure or the code of the test object. But on the contrary, we might not know how it should behave in the Ice TKB curriculum. We would concentrate on tests based on the code written to implement a component or system. But other aspects of a structure, like database structure for example, can be tested in a similar way.
Lastly, experiencebased techniques are test design techniques based on driving test cases from stakeholders, experience of similar systems and general experience of testing stakeholders. What do you mean by stakeholders? Well, stakeholders could be testers developers, users, customers, subject matter experts and so on. Before we go into techniques in each category, bottom line that you can use as many techniques as you can while testing. We will explain this more after we visit all the techniques in this curriculum. Now, what kind of questions you can get in this boat? Simply you need to know the differences between each category of design techniques of black box versus structure, or white box versus experience based techniques. The international standard ISO 291194 contains descriptions of test techniques and their correspondence coverage measures. So, we have learnt so far that 291191 talks about testing concepts and definitions. Standard 291192 talks about test processes. Standard ISO 291193 talks about test documentation or test work products. And we have learned that ISO 291194 talks about test techniques. And before we had talked about ISO 20246, which talks about work product reviews. Next video we will start talking about black box test techniques.
2. Introduction to Equivalence Partitioning
System consists of different modules as shown in the screen. In black box testing, you don’t have any information about how the software is constructed. It’s a black box for you. Common characteristics of black box test techniques include the following test conditions test cases and test data are derived from a test basis that may include software requirements, specification models, use cases, and user stories. Test cases may be used to detect gaps between the requirements and the implementation of the requirements, as well as deviations from the requirements. Coverage is measured based on the items tested in the test bases and the technique applied to the test bases. You need to know five physication based techniques for the foundation certificate equivalence partitioning, boundary value analysis, decision table testing, state transition testing, and use case testing. Each of those test case design techniques is based on some simple principles that arise from what we know in general about software behavior. Let’s start with the equivalence boutashnik.
Let’s go back to our assembled example of the employee age, where we have a field in a form that accepts a value between 20 and 50. And let’s assume that the tester decided to use 2030 and 40 to test this screen. For some wow sweetest cases are very good. But look closely. What do you think of those test cases? Can you claim that this method is correct? Absolutely not. Actually, the three chosen test cases are exactly the same. Each one of them will test exactly the same behavior as the others. This is very inefficient. Well, you as a tester know forms as vilifications that the age field accepts a number. If we try to test each number, we will end up with tens of thousands of test cases. Again, this will be very inefficient. So what should we do? Equivalent boutitioning is based on the idea that inputs are divided into partitions or classes that are expected to exhibit similar behavior, and one value from each partition should be selected. So in our example, the field accepts any value between 20 and 50.
We would expect the software to accept the values in the range and reject the values below the range and maybe display an error message saying sorry numbers should be above or equal 20 and also reject the values above the range and maybe display an error message saying sorry numbers should be lower than or equal 50. Each of these is known as equivalence partition because every value inside the partition behaves the same as any other value in the partition or class. As far as our software is concerned, the next step is to choose one value only to represent the partition. For testing just one value to be efficient, more than one value from the same partition will be redundant.
Selecting one value will for sure reduce the number of test cases we need to write. So in our case, we might select 1040 and 60 and that’s it. So this technique will help you create those three test cases. You might ask what about real numbers and characters? You are correct. In the real world we should include them. But that means you will need to use another technique to get those extra test cases. If you think about it for a minute, we would have a Beautician for whole numbers and another for real numbers. In addition, we would have a rotation for numbers and another for non numbers, meaning characters and special characters. We might also have a partition for positive numbers and a second for negative number, and a third partition just for zero.
Finally, you should select one value from each of those partitions. Nice. So far we are done with equivalence partitioning. This is as far as you need to know for the exam. According to the Ice TKB curriculum, equivalence partitioning is a richer topic than this. But this is all what you need to know for now. So the main idea in equivalence partitioning is to actually define the partitions. And as you notice, valid and invalid partitions should be defined. One trick in equivalence partitioning questions is to know if they are looking for valid partitions or invalid partitions or both. If they didn’t indicate anything, then they are looking for both. Let’s look at an example to understand it better. Sometimes those kinds of questions are more like English language questions, not testing questions. So we have to be very careful reading the words to understand what the question is actually about.
So in our case, what are the boutations? It’s clear that our first boutation will be from zero to $500 and in that case we will only get zero cent discount. The tricky part is what the second partition is. Reading the sentence 5 billion is added for each additional $500 means that we will have a partition for each additional $500. So the next partition will start from 501 and will end at $1,000. The following partition will be from 1001 to one $500, and in that case we will get 10% discount. The following partition will be from 1501 to 2000 and in that case we will get 15% discount. This is the interpretation of the sentence 5% is added for each additional $500, up to $2,000 for the following partition. 25% is applied for above $2,000. So from 2001 till the very end of infinity, we will get 25%. Let’s look at the question they asked. They ask for valid equivalent partitions, so we will not care in this case about any invalid partitions. So looking at this, how many valid partitions we have? We have one partition from one to 500, the second partition from 501 to 1000, the third partition from 1001 to 1500, the following partition from 1501 to 2000 and the last partition from 2001 till infinity. So we have five valid partitions. Looking at the answers, we notice that choice P has only three choices.
So we can simply discard this choice from our list because it contains very few equivalent partitions. Same thing about choice C, it has six test inbox and in our case we are looking for only five. So we can also discard choice C. So we are now left with options A and D. So looking at each value one by one in each choice, we can decide if we are on the right track or not. We have now fully defined our partitions, so it will be very easy to map the numbers to the partitions. 250 yes, it’s between zero and 500. 700 yes, it’s between 501 and 1000. 1400 is between 1001 and 1401. 800 is between 1501 and 2000. 4000 is above 2001. So most likely choice number A is correct. But let’s confirm our answer by looking at a choice D. 200 yes, 200 is between zero and 500. 720 is between 501 and 1001.
600 is between 1501 and 2000. But we completely ignored by tension number three. Then a choice D is not correct. So the correct answer will be choice A. I think the only advice I can give you when solving equivalent partitioning questions is that you should be very cool, very relaxed and make sure that you are defining the partitions right. If you define the partition, then everything will be solved very smoothly after that.
