ISTQB Foundation Level Exam Crash Course Part-10
This is Part 10 of 35 containing 5 Questions (Q. 46 to 50) with detailed explanation as expected in ISTQB Foundation Level Exam Latest Syllabus updated in 2011
Deep study of these 175 questions shall be of great help in getting success in ISTQB Foundation Level Exam
Q. 46: Describe some example of Decision Tables
A supermarket has a loyalty scheme that is offered to all customers. Loyalty cardholders enjoy the benefits of either additional discounts on all purchases (rule 3) or the acquisition of loyalty points (rule 4), which can be converted into vouchers for the supermarket or to equivalent points in schemes run by partners. Customers without a loyalty card receive
an additional discount only if they spend more than $100 on any one visit to the store (rule 2), otherwise only the special offers offered to all customers apply (rule 1).
Rule 1 |
Rule 2 |
Rule 3 |
Rule 4 |
|
Condition: | ||||
Customer without loyalty card |
T |
T |
F |
F |
Customer with loyalty card |
F |
F |
T |
T |
Extra discount selected |
“-“ |
“-“ |
T |
F |
Spend > $100 |
F |
T |
“-“ |
“-“ |
Actions: | ||||
No discount |
T |
F |
F |
F |
Extra discount |
F |
T |
T |
F |
Loyalty points |
F |
F |
F |
T |
From the decision table we can determine test cases by setting values for the conditions and determining the expected output, e.g. from rule 1 we could input a normal customer with a $50 transaction and check that no discount was applied. The same customer with a $150 transaction (rule 2) should attract a discount. Thus we can see that each column of the decision table represents a possible test case.
<<<<<< =================== >>>>>>
Q. 47: What is the purpose of State Transition Testing the specification-based test case design technique
The decision table testing, is useful in systems where combinations of input conditions produce various actions.
State Transition Testing is also a similar technique, but this is concerned with systems in which outputs are triggered by changes to the input conditions, or changes of �state�; in other words, behavior depends on current state and past state, and it is the transitions that trigger system behavior.
This technique is known as state transition testing or that the main diagram used in the technique is called a state transition diagram.
A state transition diagram is a representation of the behavior of a system. It is made up from just two symbols.
The first symbol is a circle as shown below
This is the symbol for a state.
A state is just what it says it is:
1) The system is �static�
2) The system is in a stable condition from which it will only change if it is stimulated by an event of some kind.
For example, a TV stays �on� unless you turn it �off�; a multifunction watch tells the time unless you change the mode.
The second symbol is an arrow
This is the symbol for a transition, i.e. a change from one state to another. The state change will be triggered by an event (e.g. pressing a button or switching a switch). The transition will be labelled with the event that caused it and any action that arises from it. So we might have �mode button pressed� as an event and �presentation changes� as the action.Usually the Start State will have a double arrowhead pointing to it. Often the Start State is obvious anyway.
If we have a state transition diagram representation of a system we can analyze the behavior in terms of what happens when a transition occurs.
Transitions are caused by events and they may generate outputs and/or changes of state. An event is anything that acts as a trigger for a change; it could be an input to the system, or it could be something inside the system that changes for some reason, such as a database field being updated.
In some cases an event generates an output, in others the event changes the system’s internal state without generating an output, and in still others an event may cause an output and a change of state. What happens for each change is always deducible from the state transition diagram.
<<<<<< =================== >>>>>>
Q. 48: What is the purpose of Use Case testing the specification-based test case design technique
Use cases are one way of specifying functionality as business scenarios or process flows. They capture the individual interactions between �actors� and the system. An actor represents a particular type of user and the use cases capture the interactions that each user takes part in to produce some output that is of value. Test cases based on use cases at the business process level, often called scenarios, are particularly useful in exercising business rules or process flows and will often identify gaps or weaknesses in these that would not be found by exercising individual components in isolation. This makes use case testing very effective in defining acceptance tests because the use cases represent actual likely use.
Use cases may also be defined at the system level, with preconditions that define the state the system needs to be in on entry to a use case to enable the use case to complete successfully, and post-conditions that define the state of the system on completion of the use case. Use cases typically have a mainstream path, defining the expected behavior, and one or more alternative paths related to such aspects as error conditions. 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 interaction 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.
The above figure alone does not provide enough detail for testing, so we need some textual description of the processes involved as well.
Use case testing has the major benefit that it relates to real user processes, so it offers an opportunity to exercise a complete process flow. The principles applied elsewhere can be applied here: first test the highest priority (highest value) use cases by taking typical examples; then exercise some attempts at incorrect process flows; and then exercise the boundaries.
<<<<<< =================== >>>>>>
Q. 49: What is the purpose of Structure-Based (White-Box) Testing Techniques?
Structure-based test techniques are used to explore system or component structures at several levels. At the component level, the structures of interest will be program structures such as decisions; at the integration level we may be interested in exploring the way components interact with other components (in what is usually termed a calling structure); at the system level we may be interested in how users will interact with a menu structure.
All these are examples of structures and all may be tested using white-box test case design techniques. Instead of exercising a component or system to see if it functions correctly white-box tests focus on ensuring that particular elements of the structure itself are correctly exercised. For example, we can use structural testing techniques to ensure that each statement in the code of a component is executed at least once. At the component level, where structure-based testing is most commonly used, the test case design techniques involve generating test cases from code, so we need to be able to read and analyze the code.
As code analysis and structure-based testing at the component level are mostly done by specialist tools, but a knowledge of the techniques is still valuable. You may wish to run simple test cases on code to ensure that it is basically sound before you begin detailed functional testing, or you may want to interpret test results from programmers to ensure that their testing adequately exercises the code.
<<<<<< =================== >>>>>>
Q. 50: What is a Pseudo Code & what are its advantages?
In ISTQB Foundation-level examination the term �code� will always mean pseudo code. Pseudo code is a much more limited language than any real programming language but it enables designers to create all the main control structures needed by programs. It is sometimes used to document designs before they are coded into a programming language.
Real programming languages have a wide variety of forms and structures so many that we could not adequately cover them all. The advantage of pseudo code in this respect is that it has a simple structure.
Part – 11 of the Crash Course – ISTQB Foundation Exam
Access The Full Database of Crash Course Questions for ISTQB Foundation Level Certification
An expert on R&D, Online Training and Publishing. He is M.Tech. (Honours) and is a part of the STG team since inception.