SessId032

Analysis And Testing: A Dialogue

In flight, the two most critical events are takeoff and landing. Software projects mirror this: the two most critical events are completion of requirements analysis and completion of system testing. In flight, the same crew executes both takeoff and landing. In software -- unfortunately -- the requirements crew and the system test crew usually don't interact. If they did, wonderful things could happen.

Becky is an analyst. James is a tester. We propose a dialogue to explore the differences and similarities of these isolated disciplines. We invite participants -- analysts, testers, and anyone who has ever been anywhere in the middle -- to join in. Perhaps we'll discover something about the optimum involvement of analyst and tester.

When Becky and I were exploring our respective roles, I learned that she is a UML expert. She showed me some of her models, and I got the idea of teaching a special testing class to help testers read and use formal models. Our dialog is already bearing fruit! -- JamesBach

James and I discovered misconceptions about analysis and testing that we had -- and anyone might have. This exploration will be part of our dialogue. For anyone interested in this exploration, we are curious about your view of a discipline that is not your strength. What do you imagine is going on in that world and with those people? -- BeckyWinant

Wow. This is interesting. When developing requirements, I always insist that we establish criteria for how we are to demonstrate that the requirements have been met. This is the first, and most crucial, step in developing test criteria and a test plan. If we can't define how we will meet the requirements, then we probably don't understand them. You are correct about the two most critical events. They "close the loop." I also insist that all definitions at this stage are in "business" terms. The disciplines can't be isolated. Are we still talking about "throwing it over the wall?" JamesWard

In my world, market-driven software, testers usually don't see requirements. Requirements don't exist in written form. And there are no analysts in view. That's one reason why I'm interested in learning about what analysts do, and how they might help the testing role. -- JamesBach

One of the really wonderful things about this business is that we all get to act as surrogates for our users/customers. JamesWard

Yes, and surrogates for each other, too. JamesBach

Analysts often have little contact or knowledge of a good testing process. After talking with James, I'm convinced that the critical eye of the tester is a perspective that would serve the analyst well. I find that the momentum at the start is too often towards loose and comfortable words. Soothing, but not very useful to a discipline that ultimately requires precise statements. The challenge at the front-end is balancing the critical with the reassuring. I hope many client surrogates will provide feedback. - BeckyWinant

James and I presented to Philly SPIN (Software Process Improvement Network) last Thursday (Sept 28th). Not only did we have a great time, so did the folks from SPIN. We heard the feedback forms from about 40 people gave us mostly perfect 10s - maybe the ferver of Olympics was hitting, too - who knows. One person paid us the compliment that ours was the best presentation she'd ever heard at SPIN. Needless to say, we were psyched! James and I both agreed that our participants at AYE could be even better - plus we'll have more time to explore ideas with you.

Our session starts with a demonstration and evolves the specific discoveries we uncovered. We expect to solicit the help of our audience for points of view and possible paths of resolution, plus shared stories of similar conflict-resolutions.

See you in AZ!

Return to NewSessionDescriptions

Updated: Sunday, October 1, 2000