5. 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 one $500. 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 a 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 piece of requirement. A decision 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 produce 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 zeros 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, zone 40 as representative for the second column and so on. We have sam 70, joanna 66. Limba 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 Http exam related to the vision 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 a ready 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.
6. State Transition Diagram
The state transition technique is concerned with systems that may exhibit a different response depending on current conditions or previous history, which is its state. The previous history can be summarized using the concept of states. A state transition diagram shows the possible software states as well as how the software enters exits and transitions between states. A transition is initiated by an event, for example, user input of a value into a field. The event results in a transition state. Transition diagrams allows a tester to view the software in terms of its states, transitions between states, the inputs or events that trigger state changes which are transitions, 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. Let’s look at an example of a state position 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 by yourself. I think you can do it by yourself blindly. Circles represent states and ours represent transitions or events that would happen on a specific state that will cause that change of the county state. To read this diagram, start with the dark 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. I hope not. While in married state, one of two things can happen move to separated state or move to widowed state. In 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 estate, it’s usually omitted, but it can be shown as an hour starting from the state and returning to the same state to indicate that no transition 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. State transition diagrams normally show only the valid transitions and exclude invalid transitions. Such relationships between the state and the transitions can be more clear if we create what’s known as a state table. A state table records also possible valid or invalid transitions, guard conditions and their effect on all possible states. For each combination of event and state. It shows the outcome in terms of the new state and any outputs that are generated.
So for the sake of creating the transition table, let’s give titles to the transitions in our example. Whether you are dealing with state transition diagrams or tables, tests can be designed to cover a typical sequence of states to cover every state, to exercise every transition to exercise a specific sequence of transitions or to test invalid transitions. And this is where most of the questions in the exam are about, for example, how many test cases are needed to go through all the transitions. In our example, also, again, one taster case is enough, but it’s a different one than the previous one. Single, married, widowed, married, separated, divorced, married, separated, widowed.
Which sequences of estates are valid and which are not? In our example, single, married, single is not a valid transition. You cannot be single again, ever you wish. Estate transition testing is used for menu based applications and is widely used within the embedded software industry. Yeah, just remember, state transition testing is widely used within the embedded software industry. The technique is also suitable for modeling a business scenario having specific states or for testing screen navigation. The concept of a state is abstract. It may represent a few lines of code or an entire business process.
Coverage is commonly measured as the number of identified states or transitions tested, divided by the total number of identified states or transitions in the test object. Normally, it’s raised as a percentage. The syllabus indicates that to know more about state transition coverage, we can look at the test advanced level syllabus. So let’s keep it this way and leave it for the advanced level. Estate position diagrams are much more than that. You can learn more about estate transition diagrams from my UML course. You can find a cob one for it in the last lecture of this course. You.
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 are biotech 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 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 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 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 description discussion board and I will explain it to you as soon as possible. Thank you.
