ISTQB – CTFL Certified Tester Foundation Level – Test Design Techniques Part 2

6. Boundary Value Analysis Example [CC]

Hi. Let’s look now at one of the boundary value analysis questions. Bank fee is 0% for balance less than $500, 2% for less than $1,000 and 4% for $1,000 or more. Which test the inputs in US dollars would be selected using boundary value analysis. Considering valid boundary values, again you need to be very careful with the wording of the question. All we need to do is define the partitions correctly with its boundaries. So looking at the question, bank fee is 0% for balance less than $500. What will be the boundaries for this partition? Yes, we’ll start from zero but what will be the higher boundary in these partitions? Notice that it says here less than $500.

So in that case $499 or to be more accurate, 499. But $99 will be the higher partition for this one. Again, wording is the tricky part on those kind of questions. So from zero to 499 we will have 0% bank fee. The following partition will start from 500 and again looking at the question we will pay 2% for less than $1,000. So what will be the upper boundary for these partitions? Yes, it will be $999. The second partition will be from $500 to $999. The following partition is for $1,000 or more. So from $1,000 up to infinity we will pay 4% bank fee. Looking at the equation itself, what they’re actually looking for, they are looking for the valid boundary analysis. So we are fine just defining the valid boundaries here. So we have three boutitions from zero to 499. 99 and the second one from 500 to 999. 99 and the third partition from 1000 to infinity.

So which choice is our? Actually this is the simplest part of boundary value analysis questions. Once you have defined the partitions correctly and the boundaries correctly, then the answer is just in front of your eyes right now. For valid boundary analysis, I will just say it without looking at any of the choices. It will be zero 499. 99, 500 and 999. 99 and 1000. The numbers that you wrote with your own hands are the answers. So looking at the choices we can simply discard a choice C because it contains a negative value and we are only looking for valid boundary values. A choice D seems very small. It doesn’t contain any 499 values. So we can also discard a choice D from our list.

Looking at choice A we notice that it has many test inputs zero and zero 1499. 99 and so on. In that case, zero one is not a boundary value. So again we can discard choice A. So the answer should be choice B. So let’s confirm this choice with the number that we have. Zero yes, 499. 99 yes, 500, 999. 99 and 1000. So choice B seems like the right choice. Again, those kinds of questions are very tricky in the world. So we have to be very cool while reading the word use your pencil or your pen or whatever us to go through word by word and dwell the boundaries, as I did. And the numbers will just pop up in front of your eyes very smoothly. Hope you get the idea of those kind of questions.

7. Specification-Based Or Black-Box Techniques : Decision Table [CC]

Hi, welcome back to another black box or specification based technique, which is decision table testing. Some specifications contain that complicated logical conditions or complex business rules. Different combinations of conditions could use different actions as testers. We need to be able to assure ourselves that every combinations of these conditions that might occur has been tested. So we need to capture all the decisions in a way that enables us to explore their combinations. That’s where decision table testing is distinguished. Let’s start by an example to understand it better. A company that sells car insurance asked you to develop a software for them. The software requirement for calculating car insurance premiums is for females between 18 and 64 years of age, the premium is $500. For males between 18 and 64 years of age, the premium is $1,000.

For any 65 years of age or more, the premium is $1500. Anyone less than 18 years of age cannot get insurance. The question is what is the minimum number of test cases needed to test this requirement? The decision table contains the triggering condition, often combinations of true and false for all input conditions and the resulting actions for each combinations of conditions. Let’s start by building together the decision table for this basic requirement. A division table lists all the input conditions that can occur at the top of the table and the actions that can arise from them at the bottom of the table. So we would have male, female, less than 18, between 18 and 65 and older than 65 as input conditions. And we also have 501,001, 500 and not applicable as possible actions to be taken by the system.

Business rules, which are combinations of conditions to reduce some actions, are arranged across the top horizontally. Therefore, each column represents a single business rule and shows how input conditions combine to reduce actions. Let’s try all the possible combinations in our example. So let’s build the vision table together. In the first column we’re going to put one in front of male, which means we are talking about males and one in front of less than 18. So for males and less than 18 years of age they will be well, it’s not applicable. So we’re going to put one in front of not applicable. In the second column we’re going to put one in front of male and one in front of more than or equal 18 and less than 65. So if we have a male and he’s in the age range of more than or equal 18 and less than 65, how much he will be? He will pay $1,000. So we’re going to put one in front of 1000 and zero in front of every other row. And we’re going to continue in the same scenario of the same sequence for the remaining columns. And we’re going to end up with six columns. We must make sure that we have exercised all possible combinations of conditions both valid and invalid combinations. In our case we have four valid combination and two invalid combinations.

To achieve fault coverage. We should have at least one test bare column in the decision table. So we should have six test cases to achieve full coverage in our example. And remember, test cases contain actual data. Here we’re going to try then 16 as representative for the first column shown 40 as representative for the second column and so on. We have sam, 70. Joanna 66. Linda, 14. Sue, 32. The decision table could be a good tool to evaluate the requirement, as during building the table we might discover some combinations of conditions have not been mentioned at all in the requirement, which in that case we should go back to the system analyst and ask for clarification. The questions in the stkb exam related to the decision table testing vary.

One example might give you the table and the situation of the specific combinations of conditions and ask you what the action should be. So if we have David who is 43 years old, so how much he should pay for premium, the answer would be $1,000. Or they might give you already made test cases and ask you what are the remaining needed test cases to achieve full coverage. The hardest one of all would be like our example here and ask you to build the table from a scratch and ask you to determine how many test cases are needed. The questions are easy, but few get lost moving around the table. So you need to open your eyes widely when answering those questions. Hope this was clear. Thank you.

8. Specification-Based Or Black-Box Techniques : State Transition Diagram [CC]

The state transition technique is concerned with systems that may exhibit a different response depending on current conditions of previous history or state. Such systems can be easily represented by what is called a state transition diagram. It allows the tester to view the software in terms of its states, transitions between in states, the inputs of events that trigger stated changes, and the actions which may result from those transitions. The system may behave differently to the same trigger or transition according to its current state. Again, let’s look at an example of a state transition diagram to learn more about it. This diagram represents a marital status system. Take a look at it for a second to see if you can get the idea of such diagrams without me telling you anything.

I think you can do it by yourself. Circles represent states and ours represent transactions or events that would happen on a specific state which will cause this state to change. To read this diagram, start with the black circle in the diagram. Wherever it is. This is usually the start point of the diagram. A person starts by being a single person, then he could only be married or stay in the single state forever. Well, I hope not. While in married state, only one of two things could happen move to the separated state or move to the widowed state. In the separated state, one of two things can happen move to divorced state or move to widowed state. While in widowed state or divorced state, you can remarry and hence move back to the married state.

Note that not all events have an effect in all states. Where an event doesn’t have an effect on a given state is usually omitted, but it can be shown as an hour starting from that state and returning to the same state to indicate that no transitions takes place.

This is sometimes known as a null transition or an invalid transition. In our example, you cannot get remarried while you are separated. Such relationship between the state and the transitions can be clear if we create what is known as a state table. A state table records all the possible events and all the possible states for each combination of events and state. It shows the outcome in terms of the new state and any albums that are generated.

So for the sake of creating the transition table, let’s give titles to the transitions. In our example, a state table, as shown in the screen, shows the relationship between the states and inputs and can highlight possible transitions that are invalid. And in our case, those invalid transitions are null. Tests can be designed to cover a typical sequence of states, to cover every state, or to execute every transition, or to exercise a specific sequence of transitions, or to test the invalid transitions.

And this is where most of the questions in the exam are about, for example, how many testing cases are needed to go through all the states. Well, look at the diagram for a moment. In our example, one test case could be enough. Single, married, without married, separated, divorced. How many test cases are needed to go through all the transitions? In our example again, one test case could be enough, but it’s different than the first one in this case, single, married, widowed, married, separated, divorced, married, separated, widowed which sequence of estates are valid and width which are not? In our example, if you are married, you cannot be single. Again, single is not a valid state after being married. Well, you wish. Thank you.

9. Specification-Based Or Black-Box Techniques : Use Case Testing [CC]

The last technique in the black boxing or specification based techniques is use cases. Use cases are one way of specifying functionality as business scenarios or process flows. They describe interactions between actors in this case users or external systems and the system itself which produce a result of value to the system user or the customer. Test cases based on use cases at the business process level, often called scenarios, are biotechly useful in exercising business rules or process flows and will often identify gaps or weaknesses. During real world use of a system, a use case usually has a most likely scenario and alternative paths, preconditions buster conditions and final state of the system after the use case has been completed.

So a single use case has different scenarios. Let’s look at a use case example to get a better idea. But you won’t need to know such a ground by heart because you will not see it in the exam. I only put it here to give you a better understanding of what is meant by use cases. This diagram is called the use case diagram for a banking system. The rectangle represents our system and the small person represents the actor dealing with our system and in this case it’s the client. Inside the rectangle system there are a few use cases, namely log into ATM, log in through the web, show parents transfer, withdraw and deposit money. If we look at the log in via ATM use case in details you will see this use case description table actually about of the real table where the upper half shows the main regular steps. Some people call it the happy scenario to log into the ATM machine and there are five steps insert card, validate card and ask for Pin number enter Pin number validate Pin number allow access to the system.

In the lower half of the table you will see alternatives, extensions or exceptions to the main scenario. First line is number two A which is card not valid. The number two A means that this step could be executed after step two. So we would have a second scenario step one, two and step two. A third scenario could be 12344 A which happens when you enter a wrong pin number. A fourth scenario would be 12344 B which happens when you enter a wrong pin number three times an hour. Therefore, this table represents one use case which is logged into the ATM machine and it has four scenarios. Again you don’t need to know more about use cases for the exam but for sure I recommend you read about it to enhance your experience.

From what we have seen here so far, use case testing is very effective in defining acceptance tests because the use cases represent actual likely use. Well defined use cases can therefore be an excellent basis for system level testing. And they can also help to uncover integration defects caused by incorrect interactions or communication between components. In practice, writing a test case to represent each use case is often a good starting point for testing and use case testing can be combined with other specification based testing. That brings us to the end of black box or specification based techniques which are equivalent partitioning, boundary value analysis, decision table testing, state position testing and use case testing. I will add more videos and will solve many questions in the discussion board about those techniques. And if you need more explanation about anything, just put it in the discussion board and I will explain it to you as soon as possible. Thank you.

10. Structure-Based Or White-Box Techniques : Introduction [CC]

Hi. As we mentioned before, structurebased test techniques or white box techniques are used when you have any kind of information about the structure of the test object or what you are testing. You might have information about how the database used in the software is built, or how the modules that comprise the system are organized, or you have access to the source code written by the developers. Any kind of internal information will sure be to your advantage. Imagine in our employee age example you overheard, the developer says that he will use a byte to store the age of the employee. A byte in computer programming can hold values in the range from zero to 255. How can this symbol information help you test the software better?

Well, as your goal is to break the software, then let’s try to break it harder. And instead of using 10, 40, 60 as tested cases to test the embry age, why not try minus one as a value below the range, 40 as a value within the range, and 256 as a value above the range. 256 is much more powerful than 70 because it’s above the range of the employee age and also above the range of the loud byte values. Same thing if you ask a developer where does he store the employee salary data? And he replied Award. And yes, you can ask the developer anything you want to help you test the software better. Allowing computer programming can hold values in the range from zero to 65,575, so it’s better to use minus one at a value below the range, any number within the range, say 12345 and 65,535 or higher as a value above the range.

So structure based or white box testing is based on an identified structure of the software or the system. Structure based techniques serve two purposes test coverage measurement and structural test case design. Test coverage is a very important idea because it provides a quantitative assessment of the extent and quality of testing. In other words, it answers the questions how much testing have we done in an objective way, not a subjective way? Depending on the personal view of the tester, it provides a way of knowing how much testing have actually been done, and it provides a way of estimating how much more testing needs to be done. So usually we use white box testing techniques to assess the amount of testing performed by test derived from specification based techniques, meaning to assess coverage. Then we use the white box techniques to help design additional test cases to increase the test coverage in the foundation level exam.

You will need to have a very basic knowledge of reading software code to be able to solve some questions. Please, please don’t panic. There is nothing to worry about at all. You only need to read and comprehend source code. You will never be asked to write any kind of code. The term code will always mean procedural code. Procedure code is not a real programming language, but it’s a very limited English language to enable software practitioners like yourself to exchange code ideas without the need to learn any specific language. So after all, it’s old in English. Let’s look at assembled code example to see how easy it is. I want you to read it as plain English. Read A read B if A is greater than zero, then if B is equal zero, then brent no values else Brent B.

If A is greater than 21, then Brent a and F and F NF. The first two statements read A and read B means that the user will enter two values. The first one will be the value of A and the second one will be the value of B. The following statement is an F statement a condition. If this condition is evaluated to true, then the following lines will be executed. If not, then the code will drop right after the end f related to that F. Notice the indentation in the code. It’s very important to notice the indentation because if it exists, it will divide the code into smaller blocks.

So let’s mark the blocks according to the indentation specified. Even if there is no indentation, we can map each F to its corresponding indef. Some if statements have an else block. This else block will only be executed if the F condition is evaluated too. False. All you need to know in Procedure code for the Istkb Foundation exam is statements and if statements. That’s all. Another way to represent the code is flow charts. I think it should be easier than booster code. In flow charts we represent a statement by a rectangle and represent the FA statement by a diamond where one branch from the diamond boring to the true block and the other branch boring to the false block. Let’s see step by step how can we draw a flow chart from the sample code we used? Very easy, right? We will see more code examples in the coming lectures. So try to experiment. Understanding the code, understanding the flow chart, drawing it if needed. And feel free to ask me anything in the discussion board on the right if you need any help.

• Category: Uncategorized