We've had an initiative within the department to have a group of "certified" test planners.....I've now got a group of people who passed the home-grown test and are competent in things like standard BB test types, equivalence class partioning, test case rotations, etc. Much of what we've covered has been focused on function coverage and in Phase1 I just wanted to focus on identifying equivalence classes by functions in the system. That's of course only half the story though....decision paths in the software must be examined in order to properly identify equivalence classes. In phase2 of the training we're going to start looking at path coverage.
Historically I've used flowcharts (decision flow diagrams) to map out 0 and 1 paths in the app We then look at the decisions the software has to make, evaluate it from a code-level perspective and the high-level functions that execute when a decision has to be made and then define equivalence classes as appropriate. We use Visio to write flowcharts.
Identification of integration tests.....well, those have mainly been done from user reqs/use-cases/and just our knowledge of the software
Question.....what do you guys do to ensure you have reasonable path coverage? What techniques and/or tools do you use for path identification?
Reserve a few months every so often and preview retirement throughout your career. You won't regret that a 35 year career was reduced to 34 years to take vacations measured in months in order to remember what a stress and care-free life is all about.
Books and hard work will get you anywhere you want to go.
I like using user stories, actor tables, and even personaes as a way to work out the actual process flow. Theoretically the PM should have done most or all of this work before you see it, but often they haven't because they're working too hard just getting the customer to tell them what "fast" and "better" mean.
Once I've worked out the various pathways, I can apply the workflow charting in order to identify areas of possible performance, security, and recovery risk.
Usually I have done the usual User Stories, and checking with the Customer Advocate (if we have one), in addition we have done code reviews that also review flow. Taking the code review flows with the other information I've been able to put together high and low level flows of the application to make sure we walk the various code paths and make sure we are not duplicating too much.
Nothing learns better than experience.
"So as I struggle with this issue I am confronted with the reality that noting is perfect."
One of the method to cover this path coverage is Mutation Testing(Error Seeding.) This is a method whereby errors are purposely inserted into a program under test to verify that the test can detect the error.
A complex change in the programme code to estimate completeness and correctness of that programme.But this is totally a white box testing technique.
Basically for paths coverage the initial steps we do is as a black box tester we test whether the expected output is coming or not and also make sure that application is running without runtime errors.For this some times we mock data to make sure for completeness and correctness.
OK...let's start at the top, and use the correct terminology so as not to confuse new folks in the discipline.
Path coverage is a white box testing technique designed to test the structural integrity of control flow through an algorithm. Complete path coverage of even simple algorithms can consist of trillions of possible paths, so Thomas McCabe proposed a method called basis path testing based on his theory of cyclomatic complexity.
Also, just to be clear, mutation testing is not synonomous with path or state transition testing. Mutation testing entails modification or "mutation" of the source code. Error seeding is also a different type of testing which involves deliberate injection of defects into non-production code. Both error seeding and mutation testing are usually used in academic research and too costly to use in most commercial software.