Testing and Quality Assurance Documentation

Chapter 6 - Documenting the Project
byAndrew Filevet al.?
Wrox Press ©2002
Team FLY

Testing may be the single most under valued stage of a development project. To be done correctly, testers must be included early in the project and invited to as many requirements and high-level design meetings as possible. In many ways, lead testers should be treated the same way lead developers and designers are treated. Keep them on the inside of the core project team, not the outside as so often happens, and make sure they have access to as much information as any developer. In fact, the one group that probably cannot be given too much background information, particular use cases and other user requirements, are testing and quality assurance team members.

Here's how a testing group might use all of the UML diagrams likely to be built during the course of a typical software project:

Use Cases (Requirements) - if testers don't have a fundamental understanding of the needs of users then they shouldn't be testing the software. If they are testing without understanding how and why users will use the software, then the project is headed for trouble. The use cases and other documents produced during requirements development are ideal for testing. From those requirements, a test group can write scripts and implement other testing devices to increase the overall quality of the software we produce.

The testing group also helps ensure that the software that's been developed actually addresses and solves the true issues of end users, and not the issues development team members think need to be addressed. This is a point I made earlier in the chapter and it bears repeating: give your test people access to the requirements that came straight from end users and give those testers the ability to double-check even the most basic of assumptions regarding what it is that the software is attempting to do. The tester will be role-playing as the user, so the more insight we can give testers, the better our software will be in the end.

Class Diagrams (Architecture and Detailed Design) - there is some benefit in exposing class diagram information to testing groups, although it's probably limited only to conceptual class diagrams in most cases. Illustrating relationships between major application objects to help testers understand how the software is constructed is certainly useful.

In some projects with particularly adept testers, detailed class diagrams can be useful to help explain some complex procedures or to help troubleshoot difficult situations where more powerful background information can help. Detailed class diagrams often accompany sequence diagrams in those situations.

Sequence Diagrams (Architecture and Detailed Design) - if it wasn't clear during our previous discussion of sequence diagrams, I'll say it again: I really like them. I think they have a great deal of benefit for system architects and developers throughout detailed design and coding. They also serve a role during the testing stages of a project. Similar to detailed class diagrams, sequence diagrams help illustrate particularly complex portions of the code, but they add an important extra dimension that class diagrams don't have - time. Sequence diagrams show an order of operations that could be very useful for testing. First of all, the order an application does things may not be the order users always want those tasks done. Secondly, the order of tasks within an application might result in serious errors or failures if one of the operations fails and other subsequent operations don't detect that failure. A good test group will see the sequenced nature of kcy operations and arrange testing scripts to expose any potential flaws.

Activity Diagrams - whenever some process occurs and the order of events is important and the conditional routing of process flow is important, then we'd expect to see activity diagrams, right? Of course we would. One of the nicest diagrams I have personally given to a test group was an activity diagram that showed the process flow of a complicated transactional process, including all of the exceptions I accounted for in my design and code, with a clear illustration of what the application was supposed to do with each exception. Without an activity diagram, I could have gotten the testers to understand how the code worked, but not as quickly nor as well. That test group found several flaws in the code, which ultimately made the product very stable and very useful once it made it to production.

Team FLY


Professional UML with Visual Studio. NET. Unmasking Visio for Enterprise Architects
Professional UML with Visual Studio. NET. Unmasking Visio for Enterprise Architects
ISBN: 1440490856
EAN: N/A
Year: 2001
Pages: 85

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net