Blog

Most bugs arise from the mistakes and inaccuracies made by people in either a program’s source code, mathematical formulas, design, or errors in arithmetic calculation. Calculation error among so many defects always remains the main concern for numerous software like other defects. So testing is very important as the end users hate software glitches & severe consequences could be faced out, if error in calculation is not rectified.

Just think about the time when testing didn’t exist, what were the concerns and issues of people? Why there is really a need to address mathematical issues for business software? What was the root cause? The history provides a lot of examples of large errors arising from seemingly computer calculation errors. The following examples represent the main portrait:

• The Mars Climate Orbiter crashed in September 1999. It was caused due to wrong units in a program.

• On February 25^th, 1991, in Saudi Arabia an American Patriot Missile’s battery during the Gulf War failed to track an incoming Iraqi Scud missile killing 28 American soldiers and injuring around 100 other people. It turned out that it caused due to inaccurate computer arithmetic errors.

• Vancouver Stock Exchange Index (Rounding Error, 1983): Due to rounding error, stock exchange led to an erroneous loss of around 25 points per month. After some time, the bug was pointed out and fixed.

What approach should be used now for testing such calculation/arithmetic errors? SQA offers you not just the resolution of the error but also the reason for its occurrence.

The approaches that should be used by QA for arithmetic error testing are as follows:

• If the SQA engineer is looking for an arithmetic defect, he/she should have the knowledge of the following concepts, so that they are not ignored according to the situation:
  • Floating-Point error
  • Relative errors & units in the last place
  • Number Base conversion errors
  • De-normalized numbers
  • Unit conversions
  • Rounding errors
  • Representation errors
  • Exception handling

• An SQA engineer should have a good mathematical sense otherwise it’s necessary to Google the concept related to the formulas.

• Break the problem into pieces in order to calculate the formula correctly.

• Verify the formulas with the desired result and check whether the result is achieved or not.

• The person who is good at testing formulas knows by default how to use this quality of mind in order to gain maximum advantage. With minimum effort, maximum work can be done. It is the best way to get formulas tested more efficiently.

• It is better if the SQA engineer takes reasonably enough amount of time to test the formulas otherwise the chances of mistakes are quite high.

• Don’t think that mathematical formulas are tough/lengthy or confusing. Imagine that these formulas are interesting and thus it would be easier for the tester to test each and everything without leaving any loophole(s).

• Instead of making guesses, the tester should check the conditions related to the formulas from requirements.

• Software with complex formulae or calculations usually provide input values and corresponding output values as requirements, SQA engineer should refer to them to prepare test data.

• Keep a chart for the formulas before conducting the testing so that none of the scenarios is missed out.

• Create dataflow diagram when formula is implemented in stages. It would help in creating combinations and also in isolating the defected module.

• You also need to keep an eye on all the changes in formula requirements to minimize the risk of testing wrong formula.

If you know about any other approaches for testing mathematical formulas then do share them. 🙂