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

11. Structure-Based Or White-Box Techniques : Statement Coverage [CC]

We will learn a few white boxy techniques statement testing and coverage, decision testing and coverage and other structure based techniques. Notice that Boss ‘statement and vision testing and coverage are of type care so you will see a lot of exercises in the exam which will need more effort from you. Let’s start by statement testing and coverage. The sample code in the right is if experience greater than five and title equals Jr then bonus equals bonus plus 200 and some code we’ll use N. Some code will use NF so it doesn’t matter for us. If experience equals 20 all bonus less than 500 then bonus equal bonus multiplied by two end and then another end. The first F statement contains an end which means that both conditions must evaluate to two to consider the whole decision true otherwise it will evaluate to false.

The second F statement contains an or which means that if either conditions is true then the whole decision will be evaluated to true, otherwise it will be evaluated to false. If we try to draw the flow chart with this code, it will look like this you will notice that there are four statements in the code and those four statements are represented by four shapes in the flow charts on the left the then and end keywords they don’t count as statements.

You don’t need to worry about numbering or knowing how many statements you need because most of the time they will number the statements for you in the exam. So you would do know how many statements you have. Now the question is if we want to exercise all the statements at least once, meaning if we want to execute all the statements in the code at least once, what would be the values for experience, Title and bonus? Meaning if we want to put values for experience, Title and bonus so we can walk through as many statements as possible what the value should be. Look at the code and slowly try to imagine if you want to go through statement two. For example what would be the values for experience and title?

And if you want to go through statement four what would be the values for experience and bonus? If we can go through this path of the code then we could exercise all the statements of the code, bow the video and think about it for a minute. Correct, if experience equals 20 and title is junior then it would make us go through all the four statements and the value for bonus in this case will not matter. So you need only one test case experience equals 20 and title equals junior to get 100% statement coverage. Why 100%? Because our test case went through the four statements out of the total four statements of the code so it’s 100%. So statement coverage is determined by the number of executable statements covered by or designed or executed by the test cases divided by the number of executable statements in the code under test.

If we test every executable statement, we call this full or 100% statement coverage even though we reached 100% full statement coverage. But still statement coverage is the weakest wide box technique and we will know more about that later. Let’s try one more example for the same code. How much statement coverage will we achieve if we use experience equals five and the title equals CEO and Bonus equals 700? Again bought the video and think about it for a second. Well with Experience equals five, then the first F statement will go through its false branch because one of its conditions is false. Now with Experience equals five and Bonus equals 700, the second F statement will also be evaluated to false. So with Experience equals five and title equals CEO and Bonus equals 700, the code will go this path. So this test case will exercise two statements out of the total four statements of the code. So it will give us 50% coverage. Hope that makes sense. We will look at more example later.

12. Structure-Based Or White-Box Techniques : Decision Coverage [CC]

Let’s talk now about the second technique in white box testing, which is decision testing or decision coverage. First, what I want you to do is forget everything about the statement coverage. Don’t get confused between the two techniques. They are completely different. This is a completely different technique that doesn’t look at the code from the statement point review, but rather it looks at the code from the decision point of view. Decision coverage related to branch testing is the assessment of the percentage of decisions outcome. For example, the true and false options of an FA statement that have been exercised by a test case suite. In decision coverage, we look at how many if a statements we have and we know that each if a statement has two branches representing the true and false branches. So we multiply the total number of F statements by two to get the total number of branches.

So, if we look at the same sample code, you will see we have two F statements and hence four branches. So, how to calculate decision coverage? Decision coverage is determined by the number of all decisions outcomes covered by a test decay divided by the number of all possible decision outcome in the code under test. So, in our example, what is the branch coverage? If we try experience equals 20 and Title equals Junior. The execution of the code using this data will go through this path. So we see from the graph that we passed through two branches only. So two branches divided by four total branches equals 50 per cent. So the one test case, Experience equals 20 and Title equals Junior gave us 100% statement to coverage, but it also gave us only 50% decision coverage. Another question could be if we want to achieve 100% decision coverage in Z code, how many test cases would we need? If we already exercise the branches at the red path with one test case, experience equals 20 and titles equals genuine, then we need to determine the test cases or test case that would make us go through the dream path. Pause the video and think about it for a second.

Okay. The first test case would be experienced equals 20 and titles equal junior. We mentioned that before. The second test case would be experienced equal to and bonus equals 700. Those values would lead us to go through the green pass. So those two test cases would go through the four branches out of the total four branches.

So we achieved 100% decision coverage using those two tested cases. As you have noticed, 100% statement coverage required only one test case, while 100% decision coverage required two tested cases. And the two test cases needed by the decision coverage included the one test case required by the statement to coverage. So decision coverage is stronger than a statement to coverage. 100% decision coverage guarantees 100% statement to coverage, but not vice versa. Remember that it’s a question that you might face in the exam. Again, 100% decision coverage guarantees 100 centiment coverage, but not vice versa. Thank you.

13. Other Structure-based Techniques [CC]

Let’s talk now about the second technique in white box testing, which is decision testing or decision coverage. First, what I want you to do is forget everything about the statement coverage. Don’t get confused between the two techniques. They are completely different. This is a completely different technique that doesn’t look at the code from the statement point review, but rather it looks at the code from the decision boarding. To view decision coverage related to branch testing is the assessment of the percentage of decisions outcome. For example, the true and false options of an FA statement that have been exercised by a test case suite. In decision coverage. We look at how many FS statements we have and we know that each if a statement has two branches representing the true and false branches. So we multiply the total number of F statements by two to get the total number of branches. So, if we look at the same sample code, you will see we have two F statements and hence four branches.

So, how to calculate decision coverage? Decision coverage is determined by the number of all decisions outcomes covered by a test decay divided by the number of all possible decision outcome in the code under test. So, in our example, what is the branch coverage? If we try experience equals 20 and Title equals Junior. The execution of the code using this data will go through this path. So we see from the graph that we passed through two branches only. So two branches divided by four total branches equals 50 per cent. So the one test case, Experience equals 20 and Title equals junior gave us 100% statement to coverage, but it also gave us only 50% decision coverage. Another question could be if we want to achieve 100% decision coverage in Z code, how many test cases would we need? If we already exercise the branches at the red path with one test case, experience equals 20 and titles equals genuine, then we need to determine the test cases or test case that would make us go through the green path. Pause the video and think about it for a second. Okay.

The first test case would be experienced equals 20 and titles equal junior. We mentioned that before. The second test case would be experienced equal two and bonus equals 700. Those values would lead us to go through the dream pass. So those two test cases would go through the four branches out of the total four branches. So we achieved 100% decision coverage using those two test cases. As you have noticed, 100% statement coverage required only one test case, while 100% decision coverage required two tested cases. And the two test cases needed by the decision coverage included the one test case required by the statement to coverage. So decision coverage is stronger than a statement to coverage. 100% decision coverage guarantees 100% statement to coverage, but not vice versa. Remember that it’s a question that you might face in the exam. Again, 100% decision coverage guarantees 100 centiment coverage, but not vice versa. Thank you.

14. Experience-based Techniques [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 bosses flows and will often identify gaps or weaknesses during real world use of the system. A use case usually has a most likely scenario and alternative passes preconditions both the 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 diagram by heart because you will not see it in the exam. I only bought 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 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 are actually about of the real table where the above 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 numbered 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 123448, 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 artistic 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.

15. Choosing Test Techniques [CC]

In addition to three roles which we talked earlier, and those roles were client, auditor and audit. And we also talked about the lead auditor. So in addition to those three key roles, there are few other participants also in the audit process. These are technical experts, observers and guide. Let’s look at the role of these three participants of the audit, starting with the technical expert. Technical expert is a person who provides the specific knowledge or expertise to the audit team. So earlier we said that in audit we could have number of auditors.

And then once you have number of auditors, you will have a lead auditor to lead this team. But in that group of auditors, you might want to have a technical expert. So for example, if you’re doing an audit which requires some specific technical knowledge, in that case you need to have a technical expert as a part of audit team. So, technical expert is also one of the auditors in the team which provides the specific knowledge which is required to conduct the audit.

So the second role which is listed here is an observer. Observer is a person who accompanies the audit team but does not audit. This person is just watching the audit being done. I have done a number of audits where I am doing the audit of a supplier contractor, but then I have a client representative which acts as an observer. So observer as an observer, this client representative will just look at the audit process, how audit is being conducted, what are the evidence is being seen. But then this person who is the observer doesn’t interfere in the audit process. So his or her role is only to observe and comment later on whether the objective was to his or her satisfaction or not, whatever purpose this observer might have. But the role of observer will be just to observe and not to interfere in the audit process. And then you have a third role which is listed here, which is the guide. Guide is the person appointed by auditing to assist the audit team.

So if this facility where the audit is being done is a large facility, there are a number of departments, there are a number of production sites, then you would need a guide who can help you to take you from one place to another place, one department to another department. So guide helps the audit team to conduct the audit. And guide is generally the representative of the auditing group audit organization. So these are three additional roles which I wanted to discuss here. So with this, we complete the discussion on the roles in audit. So we talked about the client, we talked about auditor, lead auditor, audit and here we talked about technical expert, observer and guide. In the next video, we will talk about audit planning and implementation. Let’s look at that in the next video.

• Category: Uncategorized