Blogs

Fishing and Software Testing - An Analogy

5/31/2016

Original: I am a fisherman. I mostly work in waterfall.
Translation: I am a software tester. I mostly work in waterfall.

Original: My goal is to catch all fishes in a pond.
Translation: My goal is to identify all defects in a software application.

Original: I aim to catch the bigger fishes first.
Translation: I aim to identify the critical defects first.

Original: I plan to navigate through all geographical coordinates of the pond.
Translation: I plan to cover all business functions of the application as part of my testing.

Original: I don't know how deep the pond is at various geographical coordinates.
Translation: I don't know how critical the various business functions are.

Original: I met with Department of Natural Resources and created a depth map of the pond.
Translation: I met with the Business Users/Analysts and created a criticality map of the business functions.

Original: I looked at the list of fish species present in the pond to determine my fishing strategy.
Translation: I looked at the various requirements of the application to determine my testing strategy.

Original: I have created a plan on how deep I will place my bait in each coordinate.
Translation: I have created all my test cases with expected results.

Original: I have collected various baits required for fishing.
Translation: I have arranged for various test data required for fishing.

Original: I have reached in front of the pond to start fishing.
Translation: The application under test has been deployed to the test environment.

Original: I made sure that my boat is in working condition.
Translation: I made sure that I have all required access to the application.

Original: During test execution, I often change my directions to coordinates where fishes are more probable.
Translation: During test execution, I often re-prioritize my testing to focus on defect-prone business functions.

Original: I inform my captain about the number of fishes caught on an hourly basis.
Translation: I publish daily/weekly test execution status reports during test execution.

Original: Sometimes fishes move from one coordinate to another coordinate that has been covered by me earlier.
Translation: Sometimes one defect fix breaks a functionality that has been tested by me earlier.

Original: So, I keep an eye on coordinates that I covered earlier while moving to new coordinates.
Translation: So, I assess the need for regression testing of functionalities tested earlier after each defect fix.

Original: Sometimes I catch turtles by mistake that I eventually return to the pond and thus waste my time.
Translation: Sometimes I waste my time on non-defects that eventually get rejected.

Original: When I am done, I move to another environment.
Translation: When I am done, I move to another environment.

Should there be quality assurance for functional requirements?

5/27/2016

Based on a recent survey, 68% of software development projects are considered 'failed' by the respective project sponsors. Moreover, as per the root cause analysis, 53% of these failures are attributed to poor functional requirements.

In the context of quality, the difference between quality assurance and quality control is that one is defect prevention and the other is defect remediation. However, no structured process is followed in the current industry to assure the quality of functional requirements before it is used by the developers.

Some organizations follow strong approval processes for the functional requirement document. Some others perform ambiguity review of the requirements as well. But, how objective, complete and thus reliable these processes are, is the question.

Testing Algorithms, LLC. have come up with a research based approach to perform quality assurance of the functional requirements first. This process uses various business modelling concepts to identify requirement gaps during the requirement gathering phase itself. Moreover, once the requirements are captured, they are processed through a proprietary algorithm to automatically convert to test cases with expected results and 100% requirement traceability. These test cases can be integrated with standard test management and test automation tools.

What is unique about Testing Algorithms?

5/24/2016

Struggling with software quality? Not having a dedicated testing team? Testing processes are not standardized? Many requirement defects found during testing?

Testing Algorithms is not a QA outsourcing company.

It is a research based organization that aims to improve requirement gathering and test design processes across industry, in collaboration with top Universities of USA.

We help you create the most effective & efficient testing approach that drastically reduces overall testing time and effort and increases test coverage using optimization algorithms!

Share your requirement documents to try out our innovative service for free.

Want us to sign an NDA? Contact support@testingalgorithms.com.

Is the software testing game over yet?

5/17/2016

"Its a machine, and you know that it is stupid!"

These were the exact words that Gary Kasparov said before his games with Deep Blue!

Do you think the same way about requirement analysis and automated test case design?

Try our unique solution at www.testingalgorithms.com before answering the question!

Is software testing a different game of poker?

5/11/2016

As per the ISTQB study material, the definition of software testing is "a process of executing a program or application with the intent of finding the software bugs."

But to me, software testing is a different poker game where a tester 'pokes' an application under test using various input actions and data combinations and compares the observed behavior of the application with its expected behavior. The primary dilemma in determining a test strategy is 'how to intelligently poke the application considering limited resources and time?’ To me, this sounds more like an optimization problem.

I have seen many testing teams come up with test cases for an application without giving much attention to the optimization aspect of the problem. Traditionally, the complete set of functionalities of the application under test is broken down into transactions, then into test scenarios and then into test cases with steps and expected results. However, this manual exercise often leads to a big number of repetitions and missed requirements in the test suite created. This is because a structured thought process and an effective optimization technique is usually missing in the process.

If we look at software testing as a special case of the poking game mentioned above, a mathematical optimization problem can be formulated that will generate minimum number of test cases that eliminates all gaps in test coverage.

We, at www.testingalgorithms.com, have come up with a process that makes software design process much faster, better and cheaper.