ISTQB – CTFL Certified Tester Foundation Level – Test Design Techniques

1. The Test Development Process [CC]

Hello and welcome back. This section covers a very important and beloved topic of test case design techniques. This is where testers get their creativity. We will learn many techniques but before we start, let’s first know exactly what we are trying to add achieve here. First, let’s talk about the test development process. Remember the tested process defined in the introduction. The five steps blending and controlling, analysis and design, implementation and execution, evaluating the executor and reporting and five test closure activity. What we are trying to do here is creating dist cases which is related to step number two analysis and design. But let’s go deeper to see how test cases are created from the very beginning and how they will be used throughout the whole test process. In the analysis part of the analysis and design step we should decide on the test conditions. So what is the test condition? A test condition is an item or event of a component or system that could be verified by one or more test cases.

For example a function, transaction, feature, quality, attribute or structure element. So any tiny minor thing that needs to be tested is called a test condition. We should collect all the test conditions that we have and bought them in a document called test Design specification document. There could be hundreds or thousands of test conditions. So we need to be utilize them. But the most important conditions first, so we can provide the highest ranking test conditions and extra care and testing. Let’s see an example. Imagine in our software called Expert Wave, we have a screen where we need to enter the age of the employee and then hit OK, don’t ask me why, we have a single field called age and a screen. But this is just a customer request.

Anyway, this part of the requirement could be read like this requirement one point a the age of the employee shall be in the range from 20 to 50 whole numbers only. Now what would you do to test this part of the requirement? The way I think about it is every word in the requirement document need to be tested. So almost every word is a test condition. I know this is a very extreme and doesn’t actually happen like this, but this is just so you can get the idea. So in our example we have the following test conditions one range 20 to 52 the word whole. Three the word numbers. So those are the three test conditions. If I asked you to list these test conditions according to their importance, how would you do that? Well, I think they look perturb to me that way. One is a range. Second is the word whole. Three is the word number. The design part of the analysis and design boss step means design a test case that will verify the test conditions or test objectives.

So now what is a test case? A test case is a set of input values, v conditions, expected results and boss to conditions developed for a particular objective or test condition. Again, we should collect all the test cases that we have onboard them in a document called the Test Case Specification Document. There could be hundreds or thousands of test cases. So again, we need to parameterize them both the most important test cases first, so we can provide the highest ranking test cases and extra attention. Let’s continue with our example. To see how to create test cases first, let’s look at the first test condition range 22 50. How would you test this test condition? Give it a thought for a second, pause the video and then come back again. Correct. So we should test below the range. So we will try ten, which should be rejected by our software. And we should test inside the range. So we will try 40, which should be accepted by our software and above the range.

So we will try 60, which should be again rejected by the software. Notice here that I didn’t say just we will test below the range and in the middle of the range and above the range, but I said I will try ten, which is below the range. Test cases contain data. Again, test cases contain data. The second test condition whole. So whole numbers are valid, but nonhole numbers are not valid. So let’s make sure our software does this. So let’s try 40, which should be accepted by the software as a whole number, and try 30. 4, which should be rejected by the software because it’s not a whole number. Last test condition numbers. So let’s try 40, which should be accepted by the software, and try XYZ as characters, which should be rejected by the software. Great. Did you notice something? There could be more than one test decay to satisfy a single test condition. And there could be a single test case in our example, the 40 that satisfies more than one test condition. Now, if you need to bertwise those tested cases, how would you do that? In my opinion, and you might not agree with me fully about this, I would say 40, then 30. 4, then ten, then 60, then XYZ. It doesn’t matter if you thought different. It could actually be different depending on the context of the software.

Remember this testing principle testing is context dependent. Well, but I have bought 30. 4 high because I thought many users might do the mistake of boating a decimal more than boating, a lower or higher value than the range. So it varies in opinions. The third step is the implementation, part of implementation and execution. We should write a test procedure to execute the test case and write a test execution schedule. This is beyond the scope of this lecture, but I will talk about it for a second to demonstrate how test cases are used. So if you want to actually test the number 40, can you just type 40. No, you need to set up the software to be ready to try the test case. Therefore, to test 40 you would one, launch the Expert Wave application. Two, select the new employee menu item from the employee menu, the new employee dialogue should be displayed. And three, check that the Kelso blinking inside the age field. Four, type in 40 and click the OK button. Five, it checks that the message thank you is displayed.

Do you really need it to go into these detailed steps? Yes. Do you need to write the steps? Yes. Why? You may ask. Because this testable feature can be exceeded by anyone other than you. So you want it to be as clear as possible for anyone to understand and execute without any ambiguities. Notice few points in this testable seizure. One, it tested that the Castle is blinking in the Edge field, even though it’s not mentioned in the requirement document. Two, the testable seizure tested more than one test case. Actually, it tested the existence of the menu item new employee under the employee menu. It tested the KESO’s blinking and it tested the number 40 is accepted in the Edge field. Another testable CJA for the three four test case might look like this one launches the Expert Wave application. Two, type control n the new employee dialogue should be displayed.

Three, it checks that the Kesor is blinking inside the Edge field. Four, tight N 30. 4 and with the enter key. Five, it checks that the alert age should be whole numbers only is displayed. You can notice more extra points here. We change it the way we do things whenever we can for triggering the new employee menu item. In the first testable seizure, we tried to click on the menu, and in the second testable procedure we tried the shortcut control N. Same thing for triggering the OK button. This is how you should do things in test cases and test case procedures. Try to vary the scenario of doing the same thing. After implementing all the testable procedures, we bought them in a document called Test Case Procedure Document.

And again, there could be hundreds of thousands of testable procedures. So we need to prioritize them both. The most important test cases first, so we can provide the highest ranking testable procedure. More frequency of execution. Also, the sequence of the testable seizure should be intelligent enough to minimize the time required to execute the testable seizures. For example, if you need to execute three test procedures, create new employee delete Embry, update Embry. How would you virtualize them? Think about it for a second, pause the video and come back again. Correct. We will start by creating a new Embry, then updating that Embry, then deleting that Embry so the employee’s database will be exactly the same after executing the three test procedures. Even if we tried those test procedures hundreds of times, any other sequence will be a waste of time and database space. The last thing to talk about here is the execution part of the implementation and execution test bosses step here. We would run the test procedure, log the result in the test log and we bought any discrepancies to the developer, if any. Thanks.

2. Categories of Test Design Techniques [CC]

As we have 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 foundations, test cases and test data. But why? There are many techniques to design a test case, you may ask? Well, 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 every year on software testing techniques because there are new techniques bubble up every year. All these are to help the tester do his job effectively and efficiently.

Effective testing means that we find more faults focus attention on specific types of fault if needed. In some situations you might need to concentrate on calculations false. Other situations you might need to concentrate on your eye issues and so on, in addition 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 and with the minimum number of test cases. Avoiding duplications 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. The test case design techniques we will look at are grouped into three categories those based on driving test cases directly from a specification of a model of a software or system known as a specification based or black box techniques.

It called this way because we cannot know what’s inside the box, which is the software in this case, but we only know how it should behave. We might know how it should behave from other documents, requirements, documentation, user manuals, technical or we might 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. The second category of test design techniques is those based on driving test cases directly from the structure of a component or system known as structure based 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 is constructed, but on the contrary, we might not know how it should behave. This might seem a little bit weird that you are testing something without knowing how it should behave, but in white box testing techniques this is the way it is. We know how it is constructed, but we don’t know how it should behave.

In the Istkb curriculum we will concentrate on testing based on the code written to implement a component or a system. But other aspects of structure, such as a database structure, for example, can be tested in a similar way. Here we will also talk about the concept of coverage we have mentioned before. Lastly, experience based techniques where we will look at those test design techniques based on driving test cases from stakeholder, experience of similar systems and general experience of testing. What do you mean by stakeholders? Well, stakeholders could be testers developers, customers, subject matter experts. Anyone can be a stakeholder to the software. Before we go into each technique in each category, both in mind 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.

3. Specification-Based Or Black-Box Techniques : Equivalence Partitioning [CC]

The test bases or the source of information on which we drive. Test cases and specificationbased techniques are the specification of some other kind of models of what the system should do. If you have a 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. Remember also that the certification can contain nonfunctional elements as well as functional elements. Topics such as usability, variability and performance are examples of nonfunctional elements. These need to be systematically tested as well. What we need then are techniques that can explore the specific behavior systematically and thoroughly in a way that is as efficient as we can make it. You need to know file physician based techniques for this foundation certificate, curriculum 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 sample principles that arise from what we know in general about software behavior. Let’s start by the first one equivalence partitioning.

Let’s go back to our assembled example of the employee age and let’s assume that the tester decided to use 2030 and 40 to test this screen for some. Wow. This tester has created three test cases, which is very good. But look closely. What do you think of those test cases 2030 and 40? Can you claim that this method is correct? Absolutely not. Actually, that shows in sweetest cases are exactly the same. Each one of them will test exactly the same behavior as the others. This is very inefficient. Well, you know as a tester from the certification that the age of the employee accepts a number. If you try to test each number, you will end up with tens of thousands of test cases. Again, this will be inefficient. So what should we do? Equivalent partitioning is based on the idea that in books are divided into partitions that are expected to exhibit similar behavior.

One value from each partition should be selected. Equivalent partitions, or classes, as some books might refer to, can be found for both valid data and invalid data applicable at all levels of testing. Remember the levels of testing, component testing, integration testing, system testing, etcetera. Testing and so on. So in our example, the field accepts any value between 20 and 60. We would expect the software to accept values in the range and reject the values below the range and maybe display an error message saying sorry, but number should be above or equal 20 and also reject the values above the range and maybe display an error message saying sorry, but number should be lower than or equals to 50. Each of these is known as equivalence partition because every value inside the bartition is exactly equivalent to any other value as far as our software is concerned. The next step is to choose one value to represent the bartition for testing, that for sure will reduce the number of test cases we need to write. So in our case we might select 1040 and 60 and that’s it.

Three test cases. You might ask what about real numbers and characters? You are totally correct. In the real world we should include them. If you think about it for a moment, we would have a boutation for whole numbers and another for real numbers. Also, we would have a battle for numbers and another for non numbers, characters and special characters. You might also have a partition for Boston numbers, a second for negative number, and a third partition just for zero. Finally, you should select one value from each of those partitions.

This is as far as you need to know for the exam. According to the Iced UKB curriculum, equivalent partitioning is a virtual topic than this. But this is all what you need to know for now. So the main idea in equivalent partitioning is to actually define the partitions. And as you may notice, valid and invalid partitions should be defined. One trick in equivalent 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 valid and invalid partitions.

4. Equivalence partitioning Example [CC]

Let’s solve one of the equivalence partitioning questions together. Purchase discount is 0% for up to $500. 05 per cent is added for each additional $500 up to $2,000 and 25 per cent is applied for above $2,000. Which test inputs in US dollars would be selected for valid equivalence partitions? And we have the four or answers. Sometimes those kind of questions are more like an English questions, not like testing questions. So we have to be very careful, like reading the words to understand what the questions are actually about.

So in our case, what are the partitions? It’s clear that our first partition will be from zero to $500 and in that case we will only get 0% discount. The tricky part is what is the second partition? Reading the sentence 5% 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 one thousand and one dollars to one thousand five hundred dollars 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. And now for the following partition 25% is applied for above $2,000. So from 2001 till the very end we will get 25% discount. Let’s look at the questions you ask. They ask for valid equivalence partitions, so we will not care in this case about any invalid equivalents partition. So looking at this, how many valid partitions we have?

We will have one from zero to 500, the second partition from 501 to 1000, the third partition from 1001 to 1500, the fourth 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 B has only three choices. So we can simply discard this choice from our list because it contains very few equivalent partitions. Same thing about a choice C, it has six test inputs and in our case we are looking for only five. So we can also discard choice C.

So we are now only have the options between choice A and its choice D. So looking at each value one by one in each choice, we can decide if we are in right track or not. We have now fully defined our partition, so it would be very easy to map the numbers to the partition. 250 yes, it’s between zero and 500. 700 yes, it’s between 501 and 1001. 400 is between 1001 501. 800 is between 1502,000. 40,000 is above 2001. So most likely choice number A is correct. But let’s confirm our answer by looking at choice D. 200 yes, 200 is between zero and 500. 720 is between 501 and 1001. 600 is between 501 and 2000. So we completely ignored vocation number three. So choice D is not correct. So the correct answer will be choice A. I think the only advice I will ask you when you’re solving privileged partitioning questions is that you would be very cool, very relaxed, make sure that you are just defining the partitions right. If you define the partitions right, then everything will be solved very smoothly. After that, we’re going to look at more questions again in another videos.

5. Specification-Based Or Black-Box Techniques : Boundary Value Analysis [CC]

Poison spicer, an American software engineer and author, says that bugs lock in corners and congregate at boundaries. One thing we know about the kinds of mistakes that programmers make is that airs tend to cluster around boundaries. Some developers might get confused about our employee age and unintentionally get confused about the number 20 and 50 and bought them out of range. A developer might use the wrong comparison sign and use less than instead of less than or equal, or vice versa. There are many ways a developer can make such a mistake.

This works hand in hand with our equivalent partitioning from the previous lecture, because partitions have boundaries. In our example, the first partition, 20 to 50, has boundaries of 20 and 50, which are valid boundaries. The second partition, less than 20, has a boundary of 19. The third partition, above 60, has a boundary of 61. To solve the boundary value analysis, or BVA questions right, you must identify the partitions correctly and identify the boundaries of each partition. Your test cases should use the exact boundaries you have just identified. This is a boundary value technique more or less from the Isttp curriculum point of view. But again, the topic of boundary value analysis, or BVA, is richer than that, so please read some books about it for your own knowledge. The best way to consolidate the idea of boundaries is to look at some examples. Let’s look at one together.

• Category: Uncategorized