TEST POINT ANALYSIS. MOHAN SINGH B.TECH(CSE. Introduction. The goal of this technique is to outline all major factors that affect testing projects and to ultimately do an accurate test efforts estimation.
TEST POINT ANALYSIS
The goal of this technique is to outline all major factors that affect testing projects and to ultimately do an accurate test efforts estimation.
On time project delivery cannot be achieved without an accurate and reliable test effort estimate.
TPA is one such method which can be applied for estimating test effort in black box testing. It is a 6 step approach to test estimation and planning. We believe that our approach has a good potential for providing test estimation for various projects.
Size denotes the size of the information system to be tested.
Test strategy implies the quality characteristics that are to be tested on each subsystem.
Method of calculation of Static Points:- ST= (FP * Qi)
It implies how important is the function to the users related to other system functions.
Rule : “about 25% of functions should be placed in the high category, 50% in normal category and 25% in low category.”
It implies how much does one function affect other parts of the system. The degree of interfacing is determined by first ascertaining the logical data sets which the function in question can modify, then the other functions which access these LDSs. An interface rating is assigned to a function by reference to a table in which the number of LDSs affected by the function are arranged vertically and the number of the other functions accessing LDSs are arranged horizontally.
The complexity of a function is determined on the basis of its algorithm i.e., how complex is the algorithm in a specific function.
The complexity rating of the function depends on the number of conditions in the functions algorithm.
It checks the reusability of the code. A uniformity factor of 0.6 is assigned in case of 2nd occurrence of unique function, clone and dummy functions. Otherwise in all cases a uniformity factor 1 is assigned.
Method of calculation of Df : the factor is calculated by adding together the rating of first-four functions dependent variables i.e., Up, Ui I and C and then dividing it by 20 (sum of median/nominal weight of these factors).
Environments Assessment by KR V and V company : KR V and V carried out environment assessment and noted the following:
KR V and V would use query language, records and playback tools in testing.
Development test plan is available from DCM data systems Ltd. But the test team is not familiar with the earlier test cases executed and results.
Product is developed in 4GL with integrated databases
Test environment is now for KR V and V but is similar to earlier used test environment.
Dynamic test points Dt: from Eqn. 2, we have:
DT =FPf* Df* QD
Where FPf = Transaction FP = 600
Df = dependency factor = weighted rating on importance to user, usage
Intensity, interfacing of functions, complexity of functions.
1.4 Test hours per test point
Environment factor : = (Rating on 6 environment
Planning and control allowance :
= Rating on team size factor + Rating on management tools factor
= 6% + 2% = 8%
Total test hours :
= primary test hours + 8% of primary test hours
= 2953 +8% of 2953 = 3189 hours
For this case study, the breakup is an follows:
Path analysis is a process specially developed for turning use cases into test cases. This is a tool for the testers, who are required to test applications that have use cases as required to test applications that have use cases as requirement.
Each use case path is derived from a possible combination of following use case elements:
Extends and Uses Relationships
The advantages can be summarized as
Better coverage through scientific analysis
Both positive and negative test cases can be easily identified through path analysis
Easier coupling of path and data
Reduction of test cases.
Better management of testing risks
Extremely effective in identifying and correction use case errors.
The path analysis process consists of following four major steps:-
Draw flow diagram for the use case
Determine all possible paths
Analyze and rank the paths
Decide which paths to use for testing.
Use case is a textual document and hence cannot be easily analyzed. The first task is to convert this into a graphical format called flow diagram. Let us define some concepts
Flow Diagram : Graphical depiction of the use case
Node : the point where flow deviates or converges
Branch : connection between two nodes. Each branch has a direction attached to it.
Node is also where more than one branch meets.
Beginning from the start each time, list all possible ways to reach the end, keeping the direction of flow in mind.
Path ID designation : each path should be suitably designated as P1, P2 etc.
Path Name : this is the sequence of branch numbers that the path comprises of. For the example given above path ID P2 has a path name of 2, 3, 4, 5.
Path Description : this is a textual description of the complete sequence of user actions and system responses taking place in that path.
For simple use cases, which have about 10 separate paths, it is straight forward to select all paths for testing and hence this step can be skipped. However for some complex use cases, the number of possible paths can easily exceed 50, in which case it may be necessary to select only limited paths for testing.
Frequency : this attribute can have a value of 1 to 10, with 1 being least frequent and 10 most frequent.
Criticality : this attribute describes how critical the failure of this path could be with 1 being least and 10 being most.
Some other paths are too important to be ignored from functionality point of view. These are generally obvious from the table of paths.
The path factor should be used for selecting a path among several possibilities that do not meet the above criteria.
The aim here is to select a minimum set of paths which would adequately test the critical functionality while ensuring that all branches have been included in at least one path.
The table of paths provides us with adequate information for testing a use case.
The path description is in fact a summary description of the test case itself and even a tester with very little experience can write test cases from that description.
Before proceeding further, let me introduce one more concept here called test scenario.
Any paths with a specific test data becomes a test scenario. Each path is generally associated with number of test scenarios, to adequately test the data width.