ISTQB CTFL-2018 – 2018: Test Design Techniques Part 3

7. Use Case Testing

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 is based on use cases at the business process level, often called scenarios. 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 or system there are a few use cases, namely log in to 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 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 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 represents 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 equivalents 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 discussion board and I will explain it to you as soon as possible. Thank you.

8. White-Box Techniques : Statement Testing and Coverage

As we mentioned before, structurebased test techniques or whitebox techniques are used when you have any information about the structure of the test object or what we 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 surely be to your advantage. Imagine in our embryo age example you overheard, the developer says that he will use a byte to store the age of the embry. A byte in computer programming can hold values in the range from zero to 255.

How can this symbol info help you test the software better? Well, as your goal is to break the software, then let’s try to break it harder. Instead of using 1040 and 60 as test cases to test the MB age, why not try negative 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 itself and also above the range of the allowed byte values. Same thing if you ask a developer where he does 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. Award in computer programming can hold values in the range from zero to 65,535, so it’s better to use negative one as a value below the range. Any number within the range, say 12345 and 65,536 or higher as a value above the range.

So structure based or white box testing is based on and identify the structure of the software or the system. Common characteristics of white box test techniques include the following test conditions test cases and test data are derived from a test basis that may include code, software architecture, detailed design, or any other source of information regarding the structure of the software. In white box testing, the concept of coverage is heavily used. Coverage is measured based on the items tested within a selected structure, for example, the code or interfaces or menu items, and so on. Specifications are often used as an additional source of information to determine the expected outcome of test cases. White box test techniques can be used at all test levels, but the two code related techniques discussed in this section are most commonly used at the component test level.

There are more advanced techniques that are used in safety critical, mission critical, or high integrity environments to achieve more through coverage, but those are not discussed here. For more information on such techniques, you can look at the Istib Advanced Level Technical Test Analyst syllabus. So usually we use white box testing techniques to assess the amount of testing performed by tests derived from black box techniques to calculate coverage. Then we use the white box techniques to help design additional tests to increase the test coverage. Now, starting from Syllabus 2018, white box questions are only k two questions. So there are no obliging or analyzing questions in the exam. So no more coding questions. You will see a lot and a lot of coding questions on the web, so please ignore them.

You will not get such questions in the exam anymore. You only need to understand the basic concepts of two white box techniques statement testing and coverage and decision testing and coverage statement Testing and Coverage statement Testing exercises the executable statements in the Code. Again, you will not be asked to calculate a statement coverage in the exam, but I will give you an example to get the idea. The Sandbag Code on the right is the first if a statement contains an end which means that both conditions must evaluate to true to consider the whole decision true, otherwise it will evaluate to false. The second if a statement contains an or which means that if either is true, then the entire decision is true, otherwise it will evaluate to false.

If we try to draw its flow chart, it will look like this you will notice that there are four statements in the code and those four statements are represented by the four shapes in the flowchart on the left and then the end keywords which are not counted. Now the question is if we want to exercise or visit or execute all the statements at least once, what should the values of experience, Title and bonus be? Meaning we want to put values for experience, Title and bonus so we can walk through as many statements as possible, look at the Code and slowly try to imagine if you want to go to statement two. For example, what would be the values for experience title should be? And if you want to go to statement four, what would be the values for experience and bonus should be? If we can go through this path of the code, then we could exercise all the statements, both the video and think about it for a minute.

Correct? If experience equals 20 and title is junior, then that would make us go through all the four statements and the value for bonus doesn’t matter in this case. So you need only one test case experience equals 20 and title is junior to get 100% statement coverage. Why 100%? Because our test case went through 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 designed or executed test cases divided by the number of all 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 a steel statement coverage is the weakest wide box technique and we will know why later. Let’s try one more example for the same code. How much statement coverage we will have or we will achieve? If we use experience equals five and title equals CEO and bonus equal 700. Well, with experience equal five, then the first F statement will go through its false branch or false pairs because one of its conditions is false. Now with experience equal five and bonus equals 700, the second F statement will also evaluate to false. So with experience equal five and title equal CEO and bonus owners equal 700. The code will go through this path. So if it’s the case, we’ll exercise two statements only out of the total four statements. So it will give us 50% coverage. Hope that makes sense to you. Again, you will not be required to calculate statement coverage in the exam. Just get.

9. Decision Testing and Coverage

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 testing. Decision testing is an entirely different technique that doesn’t look at the code from the statements point of view. Instead, decision testing exercises the decisions in the code and tests the code that is based on the decision outcomes.

To do this, the testing cases follow the control flows that occur from a decision point. For example, for an if a statement one for the true outcome and one for the false outcome, or for a case statement. These cases would be required for all the possible outcomes, including the default outcome of the case statement. In decision coverage, we see how many FS statements we have and we know that each if a statement has two branches representing two unfolds. So we multiply the number of FS 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 decision outcomes covered by test cases divided by the number of all possible decision outcomes in the code under test. So in our example, how much would experience equal 20 and title equals the Junior give us branch coverage. The execution of the code using this data will go through this path. So we see we have passed through two branches only. So two branches divided by four total branches equals 50% coverage. So the one tasty case exbeeus equals 20 and title equals junior gave us 100% statement coverage, but it gave us only 50% division coverage.

Another question could be how many district cases would you need to achieve 100% decision coverage? You will not get such questions in the exam. We’re just learning about decision testing here. To get an idea, if we already exercised the branches at the red path with one tester case, experience equals 20 and title equals Junior, then we need to determine the district case that would make us go through the agreement path, both the video and think about it for a minute. Correct. The first district experience equals 20 entitled equal Junior as we have said before. And the second district case could be experience equals two and bonus equals 700. Those values would lead us to go through the green path.

So those two district cases would go through the four branches out of the total four branches. So we would achieve 100% decision coverage. Again, you would not be required to calculate decision coverage in the exam, but you just need to understand the concept of decision and statement coverage, the value of a statement and decision testing. From the previous example, 100% statement coverage required one test case, while 100% decision coverage required two test cases. As the two test cases needed by the decision coverage included the one test case required by the statement coverage.

Therefore, when 100% statement coverage is achieved, it ensures that all executable statements in the Code have been tested at least once. But it doesn’t guarantee that all decision logic has been tested. Of the two white box techniques discussed in this service, statement testing may provide less coverage than decision testing. That’s why I said statement testing is the weakest white box testing techniques. When 100% decision coverage is achieved, it executes all decision outcomes, which includes testing the true outcome and also the false outcome, even when there is no explicit false statement. For example, in the case of the F statement without an else in the Code, just like our example, statement to coverage helps to find defects in the Code that were not exercised by other tests. Decision coverage helps to find defects in the Code where other tests have not taken both true and false outcomes. So decision coverage is stronger than a statement to coverage. 100% decision coverage guarantee is 100% statement to coverage, but not vice versa.

10. Experience-based Techniques: Error Guessing

When applying experience based test techniques. The test cases are derived from the users and testers’skill and intuition and their experience with similar applications and technologies. These techniques can help identify tests that were not easily identified by other more systematic techniques like white box and black box techniques. Even when specifications are available, it swallows supplementing the structure. Tests with some that you know by experience have found effects in other similar systems. Depending on the tester’s approach and experience, these techniques may achieve widely varying degrees of coverage and effectiveness. Coverage can be difficult to assess and may not be measurable with these techniques. .

These techniques are often combined with black box and white box test techniques. Common characteristics of experience based test techniques include the following test conditions test cases and test data are derived from a test bases that may include knowledge and experience of testers developers, users and other stakeholders. This knowledge and expertise includes expected use of the software, its environment, likely defects, and the distribution of those defects. There are different kinds of experience based test design techniques, but the most commonly used are error guessing, exploratory testing and checked list based techniques. Let’s start by the error guessing. Error guessing is a technique used to anticipate the occurrence of mistakes, defects and failures based on the testers knowledge, including how the application has worked in the past what types of mistakes that developers tend to make failures that have occurred in other applications.

A methodical more structured approach to ever guessing technique is called fault attack. It’s where we create a list of possible mistakes, defects and failures and design tests that will expose those failures and the defects that cause them. These mistakes. Defect failure lists can be built over time and be based on experience, defects and failure data and form common knowledge about why software fails. Error guessing is not intended to be used by itself, but rather it should support other techniques. The effectiveness of the aerogazing techniques varies heavily upon the testers experience. I have seen companies capture their testers experience by booting such best practices or best test cases or commonly mistakes okay in a spreadsheet and share it with each other.

Also, I have seen testers use error guessing based on their knowledge about the developer who wrote the code. They know that John always gets confused on boundary values. They know that Ashok makes a lot of its spelling mistakes. These lists can be used as starting point and it can be expanded by using the testers and users experience of why the application under test in particular is likely to fail. Even if your company doesn’t have such a list, you can create one for yourself. Its purpose is to simply not to fail for the same bug again and again. You should learn from your mistakes.