Download Presentation

Loading in 3 Seconds

This presentation is the property of its rightful owner.

X

Sponsored Links

- 72 Views
- Uploaded on
- Presentation posted in: General

TEST POINT ANALYSIS

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

TEST POINT ANALYSIS

MOHAN SINGH

B.TECH(CSE

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.

- TPA Philosophy
- The effort estimation technique TPA, is based on three fundamental elements.
- Size of the information system to be tested.
- Test strategy.
- Productivity
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.

- Calculation of static test points :
- St depends upon total FP of the information system and static quality characteristics of the system.
- ISO 9126 has listed the following quality characteristics as static :
- Functionality
- Usability
- Efficiency
- Portability
- Maintainability
- Reliability
Method of calculation of Static Points:- ST= (FP * Qi)

- Calculation of dynamic test points :
- DT = FPf * Df * QD
- DT = Dynamic test points.
- FPf= Number of function points assigned to the function .
- Df= Weighing factor for function dependent factors.
- QD= Weighing factor for dynamic quality characteristics.

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).

- Step - 1
- System study by KR V and V company : KR V and V requests a 2 day systems and requirements study to understand the scope of testing work and assess the testing requirements to arrive at TPA estimate.
- User important : it was observed that 20% of the functionality of the product is of low importance to user, 60% is of medium importance and 20% is of high importance.
- Usage intensity of the functions : 10% of functions are less used, 70% are medium used and 20% are extensively used.
- Interfacing of Functions with other function : 50% of function are almost independent and do not interface with other functions. The remaining 50 % are highly dependent .

Step -2

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.

- Total test points (TP):
- TP = DT + ST = 2444.4 + 160 = 2604.4
Productivity :

1.4 Test hours per test point

Environment factor : = (Rating on 6 environment

factors)/21

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:

Basic Course

Alternate Course

Exception Course

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.

- In order to have adequate test coverage, and minimize the risk of not testing while balancing the resources there is a need to follow some guidelines. They are as follows:
- Always select flow for testing as
- It is a critical functionality
- If basic flow fails; there may not be much of a point in testing other paths
- Basic flow should be included in sanity test suites and also in Acceptance testing

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.