How Can the UML Help Me in Testing?

Many people do not associate the UML with testing activities on a project. This is not surprising. For decades, the commitment to rigorous testing has received spotty support, usually in favor of meeting the schedule commitments on projects. This mindset arises from decades of de-emphasizing the importance of testing. Although there have been various industry-wide quality initiatives such as Total Quality Management, Six Sigma, and so forth, testing often takes a back seat to the other activities in systems development. One of the main factors causing this is timing—people focus on what they perceive is urgent. As Alexander Kossiakoff and William N. Sweet say in Systems Engineering Principles and Practice, “Test planning is seldom allocated adequate priority in either staffing or funding in the early phases of system development.” [KOSS1] Testing is often thought of as an activity that happens later in the development lifecycle, after coding. Early in the development lifecycle, teams focus on the more immediate issues, such as architecture, design, and so forth. By the time the team gets to the “testing phase” of the project, schedule slips have already occurred, so this time is made up by shrinking the time allotted for testing. This typical scenario illustrates how the importance of testing is compromised for other “urgent” project issues.

We contend that testing should not be relegated to the tail end of a project. We believe people involved in the testing effort should be involved at the beginning of the project through to the delivery of the final product. Involving the test personnel at the beginning, as early as the business modeling stage, will help prevent errors from being introduced into your system in the first place. As Stephen Covey said about focusing on what is important (in our case, testing) over what is urgent:

Your effectiveness would increase dramatically. Your crises and problems would shrink to manageable proportions because you would be thinking ahead, working on the roots, doing the preventive things that keep situations from developing into crises in the first place. [COVE1]

From the Real World—Hey Joe! Where You Goin' with That Plan in Your Hand?

During my software development career, I have managed and otherwise worked alongside many test (a.k.a. “quality assurance”) people. Of all these folks, one gentleman stood out as the absolute best testing person I have ever met. I was a software engineer on a large, real-time system development project when I met Joe. Joe was assigned to be our test guy. He had a couple of decades on all of us young hot shots. He was not an expert on our particular domain area, but he had worked in other areas of the program.

Joe was quite different from other test people our team had encountered. Besides the age difference, Joe was a real high-energy guy—always curious, always asking questions. Joe injected himself in discussions regarding what we were doing even before we had our requirements established. Throughout the development, Joe was there looking for ways to help us, asking about changes we were making, how the software should operate, and otherwise steeping himself in our part of the development.

As we approached code completion, Joe was ready. He always asked us if we had an early code build that he could “play with.” He would sit for hours learning how our subsystem operated. With his earlier knowledge of how the software was required to operate and his hands-on involvement, he provided a number of valuable services to our group during the “traditional” testing phase. His input improved the quality of our test plans and procedures. As he “played” with the software, he “scrubbed” the test data, improving its quality, and he questioned why things operated as they did, which led us, in some cases, to actually change the designs. He did all this prior to actually executing formal tests.

When he did run the tests, we could be sure that if he wrote a defect against our software, it was a valid one. When he would find a problem, he would investigate it with a few more trials instead of just immediately submitting a defect. His preemptive investigation of problems saved us a great deal of time on our subsequent technical investigation of the defects. His depth of knowledge, gained by being involved at the beginning of the project, not only enabled all this but also made him very efficient. He could get multiple test runs completed in the time that an average tester could run a test once. We taught him. He taught us. And our defect counts during system testing were typically the lowest on the project.


Lessons Learned

  1. Get your test folks involved as early as possible in your development. (And when using UML, ensure they are involved early so they can understand your models, be immediately productive, and leverage the models you build.)


So, how exactly can you as a test professional (or software developer) use the UML to help your test activities? The good news is that the UML models developed by the analysts, architects, and designers in the early phases of a project can be directly used to jump-start testing activities.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset