Informal Review – a review not based on a formal (documented) procedure.Walkthrough – a step-by-step presentation by the author of a document in order to gather information and to establish a common understanding of its content.Technical Review – a peer group discussion activity that focuses on achieving consensus on the technical approach to be taken.Inspection – a type of peer review that relies on visual examination of documents to detect defects. The most formal review technique and therefore always based on a documented procedure.Control Flow Structure– a form of static analysis based on a representation of unique paths (sequences of events) in the execution through a component or system. Control flow analysis evaluates the integrity of control flow structures, looking for possible control flow anomalies such as closed loops or logically unreachable process steps.Data Flow Structure–aform of static analysis based on the definition and usage of variables.Data Structure- aform of static analysis based on the organization of the data itself, independent of the program.
Statement -A testing aimed at exercising programming statements. If we aim to test every executable statement we call this full or 100% statement coverage.Decision -A white box test design technique in which test cases are designed to execute decision outcomes.Condition -A white box test design technique in which test cases are designed to execute condition outcomes – the evaluation of a condition to True or False.Multiply Condition -A white box test design technique in which test cases are designed to execute combinations of single condition outcomes (within one statement.
Test Planning Test Planning – the process of definingand documenting the strategy that will beused to verify and ensure that a product orsystem meets its design specifications andother requirements. Test Plan document should be created byQC management (QC Analyst/QC Lead/QCManager) and answer on the followingquestions:– How the testing will be done?– Who will do it?– What will be tested?– How long it will take?– What the test coverage will be, i.e. whatquality level is required?
According to IEEE 829 (Standard for SoftwareTest Documentation ) Test Plan consists of:– Test plan identifier– Introduction– Test items– Features to be tested– Features not to be tested– Approach– Item pass/fail criteria– Suspension criteria and resumption requirements– Test deliverables– Testing tasks– Environmental needs– Responsibilities– Staffing and training needs– Schedule– Risks and contingencies– ApprovalsTest Plan Structure
Test AnalysisTest Design TechniquesSelectionTest Design SpecificationTest Case SpecificationTest PlanSRSMock-upsTest DesignSpecification…Trainings’ Content
Test Design Specification Test Design Specification– It is a document thatdescribes features to betested and specifies list ofall test scenarios or testcases, which should bedesigned for providing thetesting of software.– The test design does notrecord the values to beentered for a test, butdescribes the requirementsfor defining those values.
Test Design Specification StructureAccording to IEEE-829 standard template structure of Test DesignSpecification looks in the following way:1. Test Design Specification Identifier1.1 Purpose1.2 References1.3 Definitions, acronyms and abbreviations2. Features to be Tested3. Approach Refinements4. Test Identification4.1 <Test Item 1>4.2 <Test Item …>4.3 <Test Item N>5. Feature Pass/Fail Criteria
Test Design TechniquesTest Design TechniquesStatic: The fundamental objectiveof static testing is to improve thequality of software work productsby assisting engineers to recognizeand fix their own defects early inthe software development.Dynamic: Testing that involves theexecution of the software of acomponent or system.
Dynamic TechniquesDynamicTechniquesStructure – BasedExperience – BasedSpecification-BasedEquivalencePartitioningState TransitionDecision TablesUse CaseTestingBoundaryValues AnalysisError GuessingExploratoryTestingStatementDecisionConditionMultipleConditionTesting, either functional or non-functional, without reference tothe internal structure of thecomponent or system. These arealso called black-box techniques.
Equivalence Partitioning Equivalence partitioning (EP) – A black box test design technique in which testcases are designed to execute representatives from equivalence partitions. Idea: Divide (i.e. to partition) a set of test conditions into groups or sets that can beconsidered the same (i.e. the system should handle them equivalently), henceequivalence partitioning. In principle test cases are designed to cover each partitionat least once. Example: Bank represents new deposit program for corporate clients. According to theprogram client has ability to get different %, based on amount of deposited money.Minimum which can be deposited in $1, maximum is – $999. If client deposits less than$500 it will have 5% of interests. In case the amount of deposited money is $500 andhigher, then client gets on 10% of interests more.
Boundary Values Analysis Boundary value analysis (BVA): A black box test design technique in which testcases are designed based on boundary values.Boundary value is an input value or output value which is on the edge of anequivalence partition or at the smallest incremental distance on either side of anedge, for example the minimum or maximum value of a range. Idea: Divide test conditions into sets and test the boundaries between these sets.Tests should be written to cover each boundary value. Example: Bank represents new deposit program for corporate clients. According to theprogram client has ability to get different %, based on amount of deposited money.Minimum which can be deposited in $1, maximum is – $999. If client deposits less than$500 it will have 5% of interests. In case the amount of deposited money is $500 andhigher, then client gets on 10% of interests more.
Decision table – A table showing combinations of inputs and/or stimuli (causes)with their associated outputs and/or actions (effects), which can be used to designtest cases. Idea: Divide test conditions into constraints, which could get positive or negativemeanings, and rules which identify output based on values of conditions. Whileanalyzing each possible variant of positive and negative meanings identify output orset of outputs for each variant based on the rules. Only combinations of thesepositive and negative meanings, which uniquely identify decisions that aremade, should be covered by tests. Example: If you hold an over 60s rail card, you get a 34% discount on whatever ticketyou buy. If you hold family rail card and you are traveling with a child (under 16), you canget a 50% discount on any ticket. If you are traveling with a child (under 16), but do nothave family rail card, you can get a 10% discount. You can use only one type of rail card.Decision Tables
- over 60s rail card – 34%- family rail card and traveling with a child – 50%- traveling with a child, but do not have family rail card – 10%- only one type of rail card can be usedDecision Tables
State Transition State transition testing – A black box test design technique in which test casesare designed to execute valid and invalid state transitions.State transition – A transition between two states of a component or system. Idea: Design diagram that shows the events that cause a change from one state toanother. Tests should cover each path starting from the longest state combination. Example: Client of the bank would like to take money from bank account using cashmachine. To get money he should enter valid Personal Identity Number (PIN). In case of 3invalid tries, cash machine eats the card.StartAccess toaccountEat cardWait forPin1st tryEnterPin Ok3rd try2nd tryPinNOT OkPinNOT OkCard insertedPin OkPin OkPinNOT Ok
Use Case Testing Use Case testing - is a technique that helps us identify test cases that exercise thewhole system on a transaction by transaction basis from start to finish.– Use cases describe the process flows through a system based on its most likelyuse– This makes the test cases derived from use cases particularly good for findingdefects in the real-world use of the system– Each use case usually has a mainstream (or most likely) scenario and sometimesadditional alternative branches (covering, for example, special cases orexceptional conditions).– Each use case must specify any preconditions that need to be met for the usecase to work.– Use cases must also specify post conditions that are observable results and adescription of the final state of the system after the use case has been executedsuccessfully.
Structure-Based TechniquesDynamicTechniquesStructure – Based Experience – Based Specification-BasedEquivalencePartitioningState TransitionDecision TablesUse CaseTestingBoundaryValues AnalysisError GuessingExploratoryTestingStatementDecisionConditionMultipleConditionProcedure to derive and/orselect test cases based on ananalysis of the internal structureof a component or system.These are also called while-boxtechniques.
Statement Testing Statement – an entity in a programming language, which is typically the smallestindivisible unit of execution. Example:
Decision Testing Decision is an IF statement, a loop control statement (e.g. DO-WHILE or REPEAT-UNTIL), or a CASE statement, where there are two or more possible exits oroutcomes from the statement. Example:
Experience-Based TechniquesDynamicTechniques.Structure – Based Experience – BasedSpecification-BasedEquivalencePartitioningState TransitionDecision TablesUse CaseTestingBoundaryValues AnalysisError GuessingExploratoryTestingStatementDecisionConditionMultipleConditionProcedure to derive and/or selecttest cases basedon the tester’sexperience, knowledge andintuition.
Choosing A Test Design Technique Which technique is best? This is the wrong question!Each technique is good for certain things, and not as good for other things. Some techniques aremore applicable to certain situations and test levels, others are applicable to all test levels. The internal factors that influence the decision about which technique touse are:– Tester knowledge and experience– Expected defects– Test objectives– Documentation– Life cycle model The external factors that influence the decision about which technique touse are:– Risks– Customer and contractual requirements– System type– Regulatory requirements– Time and budget