Why using Points in test schedule/report?

Thanks for your reply.

I can understand the weights of the test cases, but still don't know how to use points. e.g. in the test plan/test schedule table/Execution Progress Planning/Plan Details, how to assign points to Points attempted, Points Completed, etc.

Thanks again,
Jirong

Hello Jirong Hu,

I know this is a old question, but maybe this is still a actual topic or can can provide more actual content for that topic. 

Overview

Weight Points helping and provide a possibility to define more a gray progress state instate of a green or red.
So it depends what you want as a test manager  to show, as the test execution progress state to your project  management, to help to make the decisions for Ship or NOT Ship.

Sample Picture:

The “red and green” test execution progress

The “gray” test execution progress

  

  

  

  

With the availability of your own usage definition, (like story points in agile) you can define what does one point represent and you have to define how this points are used in your team.

Make your own definition and guideline for weight points!!

You have to define the planning usage and the distribution usage when a test execution has finished, and you spend you point for attempted (representation for your “actual work” have done) and complete (“actual work” finished successfully).

Your Team Weight Point definition

With the availability of your own usage definition, (like story points in agile) you define what does one point represent and define how this points are used in your team.

You have to define the planning usage and the distribution usage, when a test execution has finished and your team will spend your the weight point for attempted (representation for you have done) and complete (successful).

Possible definition variants for using Weight Points in your Team:

Here are some  sample definitions of methods using weight points provided from the old rational "Rational Test Manager Tool"  help:

 1. Unnamed variations  

            This is the simplest usage of points. There is a single test case with multiple points, each representing a variation of the test case. This usage allows for fewer test cases to enter and track. With the unnamed variations method, the test case should test a single aspect of a single function and it should be unimportant exactly which variations fail and which pass when presenting status.  

2. Measurable action  

            Each step in the test case represents an action that is measured and is assigned a point value. For example, one step equals one point. This method is used for large test cases that have many steps, may take a long time to execute, and some steps can pass while others fail. By using points to represent steps, you can show partial progress against your testing goals.  

3. Unit of time  

            A point represents an amount of time that a long running test is planned to execute or an amount of time that the test case is expected to take to execute. For example, four hours equals one point. If the test is planned to run for 72 hours, the point value is 18.  

4. Importance or weight  

            Total points represent the importance of a test case. A test case of high importance might be worth 100 points, medium importance might be 50 points, and low importance might be 1 point. 

Sample for combined own team usage definition for the weight points:

a) Definition and Planning for a single Test Case

How does one come on the number of 100 for test Cases and on one entirely plan estimation, for completely implemented tests and successfully executed tests?

e.g. Will the following acceptance made, for a case of test case assign we 100 points, these points to become at the end of a test execution distributed.

This means for our team:

–       The case of test lasts from planning, production up to the successful conclusion approx. 2 days

–       The case of test does not have or only small risks.

–       The Test Steps count at the inside a test script does consist not of more than 10 to 20 test steps

–       During the test execution takes place no large data inputs

–       Importance of the test related to the functional requirements is middle .

Now we can distribute these 100 points on our entire test remarks. This tremble-interprets that we, if we e.g. 3 sets of remark TER at a case of test have, distribute we the points 33, 33 and 34 for the test execution records. These are distributed at the end of a test.

b) Planning the weight points to be reached for the whole Test Plan based a single milestone iterations

Following Assumption:
We have approx. 1 week time (5 Days) for a test plan and then we set for this period 250 points, since we are only alone in the team and count on average problems and low risk.

Sample own team usage Weight Point distribution  in the Planning for  the Test Case and test case Executions

TestCase	Pt.	Count Execution Records	Distribution of the Weight Point to the different executions
Application Login (simple)	050	3	020+020+010=50
Order Entry (a little more complex)	110	2	055+055=110
Process Order (very complex and high risk)	190	1	190=190
Application Logout (simple)	050	3	015+015+020=50
Total 4 Test Cases	Total 250	Total 9	Total 250

Sample Planning Schedule and Reporting dependency for Weight Points

Picture Using weight point distribution for the Test Case and your planned TER

Picture 2 Using weight point distribution for the Test Case and your planned TER and dependencies

Hi Jirong,
Not all tests are created equal. Weight is often used to determine the complexity or duration of a test. Some even use it to weigh relative importance of one test vs. another but I'd say duration/effort is the more common use.
Reference:
http://publib.boulder.ibm.com/infocenter/rqmhelp/v2r0/topic/com.ibm.rational.test.qm.doc/topics/t_size_testeffort_all.html

http://publib.boulder.ibm.com/infocenter/rqmhelp/v2r0/topic/com.ibm.rational.test.qm.doc/topics/t_add_weight.html