Moduel 3: Test Techniques Flashcards

Question

Decision Tables - Intro (3.2.3) A decision table is a... Test Analysts can use decision tables to...

Answer 1

Tabular representation of a set of conditions and related actions, expressed as rules indicating which action shall occur for which set of condition values [OMG-DMN]. Analyze the rules which apply to the software under test and design tests to cover those rules.

Answer 2

the conditions at the top and the actions at the bottom. The descriptions of the conditions and actions respectively. The condition values and corresponding action values respectively.

Answer 3

limited entry decision tables. conditions having multiple values which may represent discrete elements or sets of elements. One of three possible values: “lower than 1000”, “between 1000 and 2000” and “more than 2000”.

Answer 4

Designing decision tables based on the specification. Excluded or marked as “infeasible”. review the decision tables with the other stakeholders. Consistent (i.e., the rules do not overlap), complete (i.e., they contain a rule for each feasible combination of condition values), and correct (i.e., they model the intended behavior).

Answer 5

The rules form the test conditions.

Answer 6

that the inputs of the test case might be different parameters than in the conditions of the decision table. Calculate the age from the input parameters birth date and current date. Be indirect consequences of the actions of the decision table

Answer 7

The rules need to be implemented as test cases by selecting test input values (and expected results) that fulfil the conditions and actions.

Answer 8

become very large. 2n rules. The number of combinations is called collapsed decision table testing [Mosley93]. A group of rules with the same set of actions can be reduced (collapsed) to one rule if, within this group, some conditions are not relevant for the action, and all the other conditions remain unchanged. denoted as “don’t care”, usually marked with a dash “-”. Specify arbitrary valid values for test implementation.

Answer 9

a condition value is not applicable in combination with some other condition values or when two or more conditions have conflicting values. “card is valid” is false, the condition “PIN code is correct” is not applicable.

Answer 10

A lower number of test cases and less effort. Several possible values of the condition will be tested for that rule, so a defect involving other values may remain undetected. Define separate rules for each feasible combination of the single condition values rather than collapsing the decision table.

Answer 11

Integration, system, and acceptance test levels. Component testing when a component is responsible for a set of decision logic. The test object is specified in the form of flowcharts or tables of business rules.

Answer 12

may already be defined in this format. Participate in reviewing the decision tables and analyze them before starting test design.

Answer 13

challenging, particularly when requirements are not well-defined or not documented at all. Selecting the conditions considered in a decision table so that the number of combinations of those conditions remains manageable. The number of rules will grow exponentially.

Answer 14

each rule of the decision table with one test case. The number of rules covered by the test suite divided by the total number of feasible rules, expressed as a percentage.

Answer 15

extended-entry decision tables. Be used as additional entries leading to additional rules and test cases.

Answer 16

Incorrect logic-related processing based on particular combinations of conditions resulting in unexpected results. Found in the specification document. Prepare a set of conditions and determine that the expected result is unspecified for one or more rules. Omissions of actions (i.e., there is no information regarding what should actually happen in a certain situation) and contradictions.

Answer 17

Enter and exit from defined states via valid transitions, as well as to try entering invalid states or covering invalid transitions. Transition from state to state and to perform actions. Conditions (sometimes called guard conditions or transition guards) which influence the transition path to be taken. A different transition than a login event with an invalid password. State transition diagram or in a state transition table (which may also include potential invalid transitions between states).

Answer 18

defined states and has events that will cause the transitions between those states (e.g., changing screens). At any test level. Good candidates for this type of testing. Also good candidates for this type of testing.

Answer 19

Difficult part of defining the state transition diagram or state transition table. A user interface, the various screens that are displayed for the user are often represented by states. Be dependent upon the states of the hardware.

Answer 20

the individual transition. Simply testing all single transitions will find some kinds of state transition defects, but more may be found by testing sequences of transitions. A 0-switch; A 1-switch; A 2-switch, and so forth. N+1 successive transitions [Chow1978]. Grows very quickly, making it difficult to achieve N-switch coverage with a reasonable, small number of tests.

Answer 21

Hierarchy of levels of coverage. traversed every transition at least once. Every state is visited and every transition is traversed, unless the system design or the state transition model (diagram or table) is defective. Traverse some transitions more than once in order to execute other transitions a single time.

Answer 22

Number of switches covered of length N+1, as a percentage of the total number of switches of that length. Every valid sequence of two successive transitions has been tested at least once. Trigger some types of failures that 100% 0-switch coverage would miss.

Answer 23

sequences of transitions form loops. All loops from any state back to the same state have been tested for all states at which loops begin and end. More than one occurrence of any particular state (except the initial/final one) [Offutt16].

Answer 24

all invalid transitions identified in a state transition table. Identify whether invalid transitions are included.

Answer 25

the state transition diagram or the state transition table for the particular test object. A table that shows the N-switch transitions for a particular value of N [Black09].

Answer 26

Applied for identifying the items to be covered (e.g., transitions, states or N-switches). print the state transition diagram and state transition table and use a pen or pencil to mark up the items covered until the required coverage is shown [Black09]. Too time-consuming for more complex state transition diagrams and state transition tables. Be used to support state transition testing.

Answer 27

* Incorrect event types or values * Incorrect action types or values * Incorrect initial state * Inability to reach some exit state(s) * Inability to enter required states * Extra (unnecessary) states * Inability to execute some valid transition(s) correctly * Ability to execute invalid transitions * Wrong guard conditions

Answer 28

found in the specification document. Omissions (i.e., there is no information regarding what should actually happen in a certain situation) and contradictions.

Answer 29

Enabling a graphical representation of the data space to be created which applies to the test object. Parameters within the data space for the test object, such as input parameters (which can further contain environment states and pre-conditions), and output parameters. Client, browser, language, and operating system. Any number of classes and sub-classes describing the occurrence of the parameter. Specific value within a classification. Equivalence partitions for English, French and Spanish.

Answer 30

Enter combinations as they see fit. Pairwise combinations (see Section 3.2.6), three-wise combinations, and single-wise.

Answer 31

Identify parameters (classifications) and their equivalence partitions (classes) which are of interest.

Answer 32

Possible boundary values to be identified and certain combinations of inputs to be identified which are either of particular interest or may be discounted (e.g., because they are incompatible). Support equivalence partitioning, boundary value analysis or pairwise testing (see Section 3.2.6).

Answer 33

The diagram becomes larger and less easy to use. Create complete test cases, only test data combinations. The results for each test combination to create complete test cases.

Answer 34

minimum class coverage (i.e., all values in a classification tested at least once). Cover pairwise combinations or use other types of combinatorial testing, e.g. three-wise.

Answer 35

The technique(s) which the classification trees support (i.e., equivalence partitioning, boundary value analysis or pairwise testing).

Answer 36

several input parameters, each with several possible values, must be tested in combination, giving rise to more combinations than are feasible to test in the time allowed. Independent in the sense that any option for any factor (i.e., any selected value for any one input parameter) can be combined with any option for any other factor, however it is not always the case (see a note on feature models below). A parameter value pair (e.g., if 'color' is a parameter with seven permitted values including ‘red’, then 'color = red' could be a parameter-value pair).

Answer 37

each parameter-value pair gets tested once against each parameter-value pair of each other parameter (i.e., 'all pairs' of parameter-value pairs for any two different parameters get tested), while avoiding testing all combinations of parameter-value pairs. Constructed with test cases represented by rows and one column for each parameter. Populates the table with values such that all pairs of values can be identified in the table (see [Black09]). Be filled with values by the Test Analyst using their own domain knowledge.

Answer 38

a list of the parameters and their values and generate a suitable set of combinations of values from each parameter that covers all pairs of parameter-value pairs. Input for test cases. Note that the Test Analyst must supply the expected results for each combination that is created by the tools.

Answer 39

combinations of parameters and their values to be visualized (some tools offer a pairwise enhancement). * Inputs to be used by the pairwise test technique. * Particular combinations of interest (e.g., frequently used or a common source of defects) * Particular combinations which are incompatible. This does not assume that the combined factors won’t affect each other; they very well might, but should affect each other in acceptable ways. * Logical relationships between variables. For example, “if variable1 = x, then variable2 cannot be y”. Classification trees which capture these relationships are called “feature models”.

Answer 40

two different situations related to testing. Several parameters each with a number of possible values, for instance a screen with several input fields. Combinations of parameter values make up the input data for the test cases. Configurable in a number of dimensions, resulting in a potentially large configuration space. Identify a subset of combinations that is manageable and feasible.

Answer 41

first be applied to each parameter individually to reduce the number of values for each parameter, before pairwise testing is applied to reduce the set of resulting combinations. Their values in a classification tree supports this activity.

Answer 42

component integration, system and system integration test levels.

Answer 43

representative of all tests and that those few tests represent expected usage. Go undetected with this test technique if that particular combination is not tested. Explain to a non-technical audience as they may not understand the logical reduction of tests. The results from empirical studies [Kuhn16], which showed that in the area of medical devices under study, 66% of failures were triggered by a single variable and 97% by either one variable or two variables interacting. Not detect systems failures where three or more variables interact.

Answer 44

difficult to achieve. The support of classification trees where possible (see Section 3.2.5). A certain level of coverage is difficult to do manually. Smallest possible set of combinations. Force some combinations to be included in or excluded from the final selection of combinations. Emphasize or de-emphasize factors based on domain knowledge or product usage information.

Answer 45

Pair of values of any pair of parameters be included in at least one combination.

Answer 46

Defects related to the combined values of two parameters.

Answer 47

Emulate intended use of the component or system specified by the use case. Use cases are defined in terms of interactions between the actors and a component or system that accomplishes some goal. Human users, external hardware, or other components or systems.

Answer 48

system and acceptance testing. Integration testing if the behavior of the components or systems is specified by use cases. Performance testing because they portray realistic usage of the system. Assigned to virtual users to create a realistic load on the system (so long as load and performance requirements are specified in them or for them).

Answer 49

realistic user transactions. Use case specifications are a form of system design. Users or user representatives, and should be checked against organizational requirements before designing corresponding use cases. It does not reflect real user and organizational requirements, or hinders rather than assists completion of user tasks.

Answer 50

Error handling behaviors is important for the coverage to be thorough. A guideline, but not a complete definition of what should be tested as they may not provide a clear definition of the entire set of requirements. Other models, such as flowcharts and/or decision tables, from the use case narrative to improve the accuracy of the testing and to verify the use case itself. Logical anomalies in the use case specification, if they exist.

Answer 51

one test case for the basic behavior and sufficient additional test cases to cover each alternative and error handling behavior. Incorporated into a test case provided they are mutually compatible. One additional test case per alternative behavior may be designed, although nested alternative behaviors will still require some of those behaviors to be amalgamated into a single test case (e.g., termination versus non-termination alternative behaviors within a "retry" exception behavior).

Answer 52

Mishandling of defined behaviors, missed alternative behaviors, incorrect processing of the conditions presented and poorly implemented or incorrect error messages.

Answer 53

Create test cases. Subjected to equivalence partitioning to discover multiple ways in which a condition might be satisfied. Every combination of conditions, but also, for those conditions which are partitioned, additional test cases should be generated to cover the equivalence partitions. The applicability of the technique, the limitations and difficulties, and the goals of the testing in terms of coverage and defects to be detected. Individual techniques covered in this chapter. Single “best” technique for a situation. The most effective way to achieve the test objectives set, assuming there is sufficient time and skill to correctly apply the techniques.

Answer 54

Skill and intuition of the testers, along with their experience with similar applications or technologies to target testing in order to increase defect detection. “quick tests” in which the tester has no formally pre-planned activities to perform, through pre-planned test sessions using test charters to scripted testing sessions. Aspects included in the following list of advantages can be achieved.

Answer 55

* It may be a good alternative to more structured approaches in cases where system documentation is lacking. * It can be applied when testing time is severely restricted. * It enables available expertise in the domain and technology to be applied in testing. This may include those not involved in testing, e.g., from business analysts, customers or clients. * It can provide early feedback to the developers. * It helps the team become familiar with the software as it is produced. * It is effective when operational failures are analyzed. * It enables a diversity of test techniques to be applied.

Answer 56

* It may be inappropriate in systems requiring detailed test documentation. * High levels of repeatability are difficult to achieve. * The ability to precisely assess coverage is limited. * Tests are less suited for subsequent automation.

Answer 57

Reactive to events than pre-planned test approaches. Concurrent tasks. Entirely dynamic, i.e., the tests are not created entirely at the same time as the tester executes the test. Error guessing is used to target particular aspects of the test object before test execution.

Answer 58

Do not have formal coverage criteria.

Answer 59

guess the potential errors that might have been made when the code was being designed and developed. Determines the best methods to use to uncover the resulting defects. Enter a variety of different values in the password field to verify if the error was indeed made and has resulted in a defect that can be seen as a failure when the tests are run.

Answer 60

Risk analysis to identify potential failure modes.

Answer 61

integration and system testing, but can be used at any test level. Broaden the scope of the existing test cases. New release of the software to test for common defects before starting more rigorous and scripted testing.

Answer 62

* Coverage is difficult to assess and varies widely with the capability and experience of the Test Analyst. * It is best used by an experienced tester who is familiar with the types of defects that are commonly introduced in the type of code being tested. * It is commonly used, but is frequently not documented and so may be less reproducible than other forms of testing. * Test cases may be documented but in a way that only the author understands and can reproduce.

Answer 63

Number of taxonomy items tested divided by the total number of taxonomy items and stating coverage as a percentage. The experience and knowledge of the tester and the time available. Will vary based on how well the tester can target problematic areas.

Answer 64

“guessed” by the Test Analyst, that might not have been found in black-box testing.

Answer 65

a high-level, generalized list of items to be noted, checked, or remembered, or a set of rules or criteria against which a test object has to be verified. A set of standards, experience, and other considerations. Employed as the basis for testing an application. Built from the acceptance criteria for a user story.

Answer 66

an experienced test team that is familiar with the software under test or familiar with the area covered by the checklist (e.g., to successfully apply a user interface checklist, the Test Analyst may be familiar with user interface testing but not the specific system under test). The detailed steps commonly found in test cases and test procedures, the knowledge of the tester is used to fill in the gaps. Low maintenance and can be applied to multiple similar releases.

Answer 67

Released and changed quickly. Preparation and maintenance time for test documentation. Any test level and are also used for regression testing and smoke testing.

Answer 68

reproducibility of test results. Interpret the checklists differently and will follow different approaches to fulfil the checklist items. Different test results, even though the same checklist is used. Wider coverage but reproducibility is sometimes sacrificed. Overconfidence regarding the level of coverage that is achieved since the actual testing depends on the tester’s judgment. More detailed test cases or lists and tend to grow over time. The checklists are covering the important aspects of the software under test.

Answer 69

divided by the total number of checklist items and stating coverage as a percentage. The high-level nature of the checklist, the results will vary based on the Test Analyst who executes the checklist.

Answer 70

Cause failures resulting from varying the data, the sequence of steps or the general workflow during testing.

Answer 71

The tester simultaneously learning about the test object and its defects, planning the testing work to be done, designing and executing the tests, and reporting the results. Test goals during execution and prepares only lightweight documentation. [Whittaker09]

Answer 72

Planned, interactive, and creative. Documentation about the system to be tested and is often used in situations where the documentation is not available or is not adequate for other test techniques. Add to other test techniques and to serve as a basis for the development of additional test cases. Agile software development to get user story testing done flexibly and quickly with only minimal documentation. Projects using a sequential development model.

Answer 73

any coverage measure. Can be difficult. Areas to be covered in a test session and timeboxing to determine the time allowed for the testing are techniques used to manage exploratory testing. Hold a debriefing session to gather the test results and determine the test charters for the next test sessions.

Answer 74

accurately track them in a test management system. Creating test cases that are actually exploratory testing sessions. Time allocated for the exploratory testing and the planned coverage to be tracked with the other test efforts.

Answer 75

Problems when needing to recall the steps to reproduce a failure. Capture/playback capability of a test automation tool to record the steps taken by an exploratory tester. Complete record of all activities during the exploratory testing session (or any experience-based testing session). Tedious, but at least there is a record of all the steps that were involved.

Answer 76

Don't record the expected results because they don’t capture the GUI interaction. Noted down so that proper analysis of defects can be undertaken if needed. Notes also be taken while performing exploratory testing, to support reproducibility where required.

Answer 77

Specific tasks, objectives, and deliverables. Then planned to achieve those criteria. Where to focus the test effort, what is in and out of scope of the test session, and what resources should be committed to complete the planned tests. Particular defect types and other potentially problematic areas that can be addressed without the formality of scripted testing.

Answer 78

Scenario-based issues that are missed during scripted functional suitability testing, issues that fall between functional boundaries, and workflow related issues. Sometimes uncovered during exploratory testing.

Answer 79

the type of defect sought is used as the basis for test design, with tests derived systematically from what is known about the type of defect. Lists which focus on defects. In general, the lists may be organized into defect types, root causes, failure symptoms and other defect-related data. Multiple types of software and are not product specific. Using these lists helps to leverage industry standard knowledge to derive the particular tests. Tracked across projects and even across organizations. Organization or project specific and make use of specific expertise and experience.

Answer 80

lists of identified risks and risk scenarios as a basis for targeting testing. Target a specific type of defect or to work systematically through a list of known and common defects of a particular type. The test conditions and test cases that will cause the defect to manifest itself (if it exists).

Answer 81

At any test level but is most commonly applied during system testing.

Answer 82

focused on particular types of testing, such as usability. Applicable to the software under test (if any are available). Innovative software. Their own taxonomies of likely or frequently seen defects. Define the expected coverage prior to starting the testing.

Answer 83

Used to determine when all the useful test cases have been identified. Structural elements, specification elements, usage scenarios, or any combination of these, depending on the defect list. Less systematic than for black-box test techniques in that only general rules for coverage are given and the specific decision about what constitutes the limit of useful coverage is discretionary. The entire set of tests is complete, but rather that defects being considered no longer suggest any useful tests based on that technique.

Answer 84

The defect taxonomy in use. User interface related, but other defects can be discovered as a by-product of the specific testing.

Answer 85

Most effective when used together. Achieving test objectives that result from any systematic weaknesses in black-box test techniques.

Answer 86

All situations. Understand the advantages and disadvantages of each technique and to be able to select the best technique or set of techniques for the situation, considering the project type, schedule, access to information, skills of the tester and other factors that can influence the selection.

Answer 87

the information provided in “applicability”, “limitations/difficulties” and “coverage” guides a Test Analyst in selecting the most appropriate test techniques to apply.

Moduel 3: Test Techniques Flashcards

(111 cards)