The Duckworth Lewis method of resetting targets in rain-affected one-day cricket matches has been adopted by the International Cricket Council as the standard 'rain-rule' in the test playing countries and in many associate member countries. The method is the invention of Frank Duckworth and Tony Lewis.

This method considers two resources with which a team can make as many runs as they can. They are the number of overs they have to receive and the number of wickets they have in hand. From any stage in their innings, their further run-scoring capability depends on both these two resources in combination. When a match is shortened after it has begun, the resources of one or both teams are depleted and the two teams usually have different amounts of resource for their innings. In this case a revised target must be set.




How to Use:
# The 2 bars indicate the innings and the bar is split into 300 parts indicating the balls.
# Fall of the wickets (red line) - Left click
# Rain interupped overs (blue block) - Left click and drag
# Restricted overs (black block) - Right click on the green bar
# Revised overs after rain (yellow block) - Right click on black block

1. Mark the fall of wickets on Team2 bar by clicking on Team1 bar.
2. Enter the total runs scored by Team1 
3. Mark the fall of wickets on Team2 bar by clicking on Team2 bar.
4. Left click and drag on the Team2 bar to mark the rain interupted  overs.
5. To mark the revised overs, first right click on the Team2 bar next to the end of the rain interupted  overs. Then right click and drag over the black block to mark the revised overs.
6. Enter the total runs scored by Team2 till rain interuption.
7. Revised target will be displayed.

Example:
Team1 scored 300/4 in 50 overs.
Rain interupted when Team2 was 145/2 in 19.2 overs.
6.3 overs had rain and second innings restricted to 35 overs.
Result: Team2 has to score 82 in 9.2 overs by D/L method.

Known Issues:
The actual target computed by this is pretty close, but sometimes the values are out by a few runs.

Credits: Nemesis.com | sport.omani.ac

Comments (0)

A software bug is an error, flaw, mistake, failure, or fault in a computer program that prevents it from working correctly or produces an incorrect result. Bugs arise from mistakes and errors, made by people, in either a program’s source code or its design.

In software development process, the bug has a life cycle. The bug should go through the life cycle to be closed. A specific life cycle ensures that the process is standardized. The bug attains different states in the life cycle.

Comments (0)

After being an software tester for nearly 5 years, thought of writting down my views on writing an effective test case for a software application.

To say in a single line, the test cases irrespective of the complexity of the application being tested should be SELF-EXPLANATORY!

As a test case designer, you should always remember that it's not 'You' who will always test these cases, but need to be thinking of the future as well. Anyone else from your team, especially new comers should also be able to start testing these cases without any prior training on the application. It even can reduce the time required for the initial knowledge transition.

Test only 1 functionality per test case and do not combine multiple functioanlities in a test case. The details on test name, description and steps given below.

Test Name:

• It's all in the name. 
• When we have a well defined name, it will help us a lot in the future especially when trying to add the cases to the test set at the start of the test cycle.
• It also helps those who reviews the test case.

Test Description:

• Detailed info needs to be provided in the test description. It should include any pre-requisites, required installations, assumptions, info on environment to be tested, any specific configurations need to be done, test data required, acceptance criteria etc.

Test Steps:

• Steps should contain very detailed information on the user actions.
• Which entry to select in down down, text to enter in text box, which button to click, username, password to be used etc.
• Each step should contain only 1 action. Do not include multiple actions per step.
• Use terms consistently across the test cases and do not use variations. Eg: If you refer something like GMail, continue to use it till the end instead of gmail, GMAIL etc.
• Do not point to previous steps. Always type in the required steps once again.

# Test case should be designed in such a way that the same test case without even a minor change should be repeatable back to back and the should be successful both times i.e. the result should be the same in both runs.
# Always return the system to the initial state. If you have created a new user, add new steps at the end of the test case to delete the user created. This would help in achieving the repeatability of the test case.
# As a good practise, always write a single test case and share it with a friend preferrably not a tester and for sure not in the same test team and check whether he is able to follow the same steps without any help.

The above mentioned were desirable attributes for a test case, if everything is incorporated it can add up to the quality of the deliverable.

Happy Testing!!!

Comments (0)