ISTQB CTFL-2018 – 2018: Test Design Techniques

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 bubby 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, white box 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 physician 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 visifications 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 bartitions 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 Bautician for whole numbers and another for real numbers. In addition, we would have a boutation 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.

3. Advanced Equivalence Partitioning

To summarize what we have learned so far, there are equivalence partitions for both valid and invalid values. Valid values are values that should be accepted by the component or system, and equivalence partition containing valid values is called a valid equivalence partition. The invalid values are values that should be rejected by the component or system, and equivalence partition containing invalid values is called and invalid equivalence boutition double daw. Each value must belong to one and only one equivalence partition. One value from each botation should be selected.

Partitions can be identified for any data element related to the test object, including inputs, outputs, internal values, time related values, for example, before or after an event, and for interface parameters, for example, integrated components being tested during integration. Let me give you an example regarding this point. One value from each partition should be selected. When invalid equivalence partitions are used in test cases, they should be tested individually, meaning that combined with other invalid equivalence partitions to ensure that failures are not masked. Failures can be masked when several failures occur at the same time, but only one is visible, causing the other failures to be undetected. Let me give you an example regarding this last point. Imagine if we have a screen to enter a password.

The password lens is from one to six, but the specs also say that the password should start with alphabet characters but can contain characters and numbers. Okay, this is different here, so we need to list the conditions of the example of the password. Actually, those are sort of test conditions. Has one to six characters, begins with e to z, contains e to z and zero to nine. Further, has one to six characters. We have three partitions, zero characters partition. You cannot enter negative characters from one to six characters partition and more than six characters partition. The one to six characters is a valid partition and the other two are invalid partitions. For the begins with a to z condition, we would have two partitions, starts with an alphabet character which is a valid partition and starts with anything else which is an invalid partition. For the contains a to z and zero to nine condition, we also would have two partitions.

One contains alphanumeric characters, which is a valid partition, and the other partition contains anything else which is an invalid partition. So we have three valid partitions and four invalid partitions to the total of seven partitions. That would be a question by itself in the exam asking for the total number of partitions. Another question would be what is the minimum number of test cases to COVID this problem using equivalents partitioning? Well, let’s agree on some basics here. You want to try at least one value from each partition to achieve 100% coverage. You can combine valid partitions in a single test case, and you cannot combine more than one invalid value in the same tester case. This is the exhibition of the last bone we were talking about. You may ask why.

Well, simply, if you have a tester case with two invalid values or two invalid partitions, and the test case successfully displayed an error, I’m afraid you won’t know which invalid value actually reduced the error. So exercise each invalid value in a separate tester case. So let’s play with the test cases here. First test case EB 36 p. This one will exercise all the valid partitions, starts with an alphabet and contains alphanumeric characters and length within range, which is five, and we are done with all the valid partitions. One XY twelve starts with a number, a 15 hash percentage x contains special characters and we have zero lengths, and we have very long, which is above length range, which is seven, and we are done with the invalid partitions. So we needed five test cases to COVID our problem in the exam.

You don’t need to write the test cases, but rather see how many test cases can hold all developed partitions, then add to it the number of invalid partitions. Just make sure you read that question carefully to make sure you understand the constraints you are testing. Another characteristic of equivalence partitioning is that partitions can be identified for any data element related to the test object, including inputs, outputs, internal values, time related values, for example, before or after an event, and for interface elements, for example, integrated components being tested during integration. Let me give you an example again regarding this last point. So far, we have dealt with inputs as data. We want to create partitions for using our previous password. Example the system would either accept your password or display an error message saying wrong password.

So how many partitions for the output here to approve or reject? So you need only two testing cases one that will lead you to go through the approval scenario, and another that would lead you through the rejection scenario. Any value here can be used AB three six p for the approval and one XY twelve for the rejection. That’s it. Just two test cases are needed to achieve 100% coverage on the output partitions. Continuing talking about the characteristics of equivalents partitioning, any partition may be divided into sub partitions if required. Here we simply need to tweet sub partitions as we tweet any partition and one value from each sub partition should be selected. Last point equivalent partitioning is applicable at all test levels of testing. Looking at the sample questions in the Sits sample exam, there are three extra points that we need to mention here. The first one is related to coverage.

To achieve 100% coverage with this technique, testing cases must cover all identified partitions, including invalid partitions, by using a minimum of one value from each partition. Coverage is measured as the number of equivalent partitions tested by at least one value divided by the total number of identified equivalents partitions normally expressed as a percentage so in our password example, we analyze the problem and agree that we have seven partitions. If the tester decided to use AB three six B and Very long only as test cases, for some reason AB three six B exercises three partitions, all the valid partitions and Very Long exercises one invalid partition only. So a total of four partitions have been covered using those two test cases. So the coverage is four divided by seven multiplied by 100 equal almost 57%.

The second point is related to using discrete values as input or out whatever meaning. Instead of having a range of numbers, we would have separate discrete values. For example, Mrs. And Miss as titles or Egypt, Canada, US. And India. As a country, the question that pops to mind is should a field like country be in one partition or each value should be in a separate partition? Here we need little understanding of the software at hand. Would the value of the country change the way the software behaves? If the answer is yes, then every value should be in a separate partition. But if the answer is no, then all the values can reside in a single partition. For example, if the country is an input will use gesture your information in a gaming website. I don’t think the country here will have any effect on how the game behaves.

So one partition for all the countries would be fine. But if the country is a field will use an address to ship an item, then each country might have different behavior according to how we calculate the taxes or how we calculate the shipping cost according to the shipping methods valid in that address. In the example mentioned in the Istibassemble exam, they used the screen resolution as an input. Of course, each screen resolution would behave differently in displaying an image. That’s why we had to put each screen resolution in a separate partition. The third and last point is having more than one input, and each input has its own boutitions. Let’s assume we have two inputs age from 20 to 60 and country Egypt to Canada, USA and India. The age field has three partitions and the country field has four partitions. Remember when we say that we need to exercise one value from each partition? That’s still the case here we have three plus four equals seven partitions. We need to exercise each partition here. But a single testing case can carry a value from age and a value from country.

So to use equivalence partitioning in our example, how many Tistic cases would we need? Right, four. Simply because the highest number of partitions in a single field is four, which is the field country examples of district cases would be ten egypt 40 canada 60 USA. And it doesn’t matter what to use from the age beauticians again to fulfill the 100 test coverage. So say the fourth test case would be 45 India. I wanted to use the fact that we can test a boutition here once again, which is a valid beautician. And so instead of using 40 again, I decided to use 45. So I simply decided to use a different value. That’s it. Actually, those points of multiple inputs, calculating test coverage and discrete values are discussed in detail in the Test Analyst Advanced level. I hope they make sense to you. Not.