This post is one of a series examining the role of test in various software development processes. Today we'll look at the Rational Unified Process (RUP).
How I got here:
I worked for a while in a consulting firm, and a lot of our clients used RUP. Think Fortune 1000 companies; they'd spent the time and money on the tools, training, etc. This was The Way They Built Software.
The role of test:
In many ways, RUP is the process I've worked with that most accounts for testing. Testing is a phase in this process, very explicit, and can rely on specifications created earlier in the process. Taken to an extreme these specifications even include verification and valdiation criteria. This process was also the most likely to produce non-functional requirements that made any sense. With RUP, load requirements were "support 1 million users simultaneously performing use case X". Most other processes had load requirements like "handle a lot of users" or my personal favorite "do load testing".
Having test be an explicit role certainly helped make the process easier for testers. The test phase is explicitly accounted for when creating the project schedule, defining requirements, allocating resources, even designing the code. This also provided a great way to get test throughout the process - in requirements and design reviews, not just testing of the code.
By today's standards RUP is very slow. The release cycles were typically 18 months, and selling that to upper management is pretty well hard - who knows what your competitor will do that you simply can't react to. It also takes a lot of resources, and the 50 person companies I've seen try to implement it simply crumble under its weight, even if they're skipping artifacts and taking other shortcuts.
In the end:
Please note that if I were building a medical device or writing software that powered cars, I would consider RUP. If I'm building a consumer website or a series of Flash games, I'm not going to go with RUP. Sometimes the overhead is necessary because the tolerance for error is that low. The lesson for me here is this: how do we get the thoughtfulness of RUP with the speed and flexibility of some other processes? How do we consider test explicitly without relatively arduous processes that wind up being seen as overhead?
All thoughts on processes are my own and are meant as reflections of my experiences with them, not with the theory of the process itself. No flamewars, please. Also, RUP and a lot of associated templates and tools are copyright IBM.
Other Posts in this series:
Test in Process: A Series (http://blog.abakas.com/2007/08/test-in-process-series.html)
Test in Process: RUP (http://blog.abakas.com/2007/08/test-in-process-rup.html)
Test in Process: XP (http://blog.abakas.com/2007/08/test-in-process-xp.html)
Test in Process: SCRUM (http://blog.abakas.com/2007/08/test-in-process-scrum.html)