Conclusion

Testing in the RUP is about continuously providing the management and the development teams with an objective assessment of the quality of the product. It is not about ticking all the checkmarks for all the requirements (even if this plays a role) in one massive shot done toward the end of the project lifecycle.

The expected level of quality and the requirements both evolve during the lifecycle, and testing should evolve with them. Testing can start early, since iterative development produces testable code early, and can therefore provide crucial feedback, both on the product and on the process so that they can evolve as required ”feedback that is sorely missing in more traditional approaches.

The role of the tester or the quality engineer in the RUP is not primarily to find defects, but to provide other team members ”developers and managers ”with an objective assessment of the quality of the product. Testing is not a complete, separate workflow, parallel to or appended to software development, but fully integrated in the iterative cycle of the RUP. Taking advantage of iterations, testing becomes an almost-continuous process that continually feeds back into the requirements, the design, and the management of the project. It is then a collaborative activity, no longer an adversarial or rubber-stamping activity. It is also more effectively automated by tools. Testing in the RUP embraces a practical and flexible notion of Good Enough Quality that takes into account the balance between the cost of testing and the desired level of quality based on the context.



The Rational Unified Process Made Easy(c) A Practitioner's Guide to Rational Unified Process
Programming Microsoft Visual C++
ISBN: N/A
EAN: 2147483647
Year: 2005
Pages: 173

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