In the Module 2, talked general about the notions of quality, the notions of testing, the notions of quality categories, and then we burrowed down to test design and the bottom up view of test design lets us come up with test ideas. Those concepts give us a nice background to look at the workflow in RUP. All of the modules after this go through the workflow of the RUP. In Module 3, we look at a broad overview of the testing related workflow of RUP and how general testing is handled in RUP.
This will be a quick familiarization.
The first workflow for testing in RUP is the one that defines the evaluation measures.
So what we’re going to do in this outline is to go very quickly through the definition of the workflow.
Notice the definitions of the activities and the artifacts. When I say notice, I mean those are in your text notes. I’m not going to through all those in detail.
In general, the structure of these modules is a RUP transition in each module. Basically what we have is a quick peek at RUP followed by statement – let’s focus on one or two things in this workflow and I say
– let’s focus on…, then I start focusing. The place where people should have understood that structure was either in in Module 3.
The instructor is going to have to make it clear that there is a pattern we see with every workflow. The pattern goes like this. The workflow talks about all sorts of activities done by all sorts of people. We can’t begin to teach all those things in a 3 three-day class. What we can do is take the one or two things within this workflow that we think face-to-face instruction might really help you understand what’s special about that workflow and work on those.
What I’m going to do is focus on the specific most important question in this workflow: How do we figure out what the mission for test group should be? The rest of the stuff people can get as guidance from RUP and there are ideas in the course notes for them. And certainly there are lots more in Lessons Learned in Software Testing.
So Workflow Define Evaluation Mission is defined in terms of identifying the appropriate focus for the testing effort and gaining agreement with stakeholders. The other key piece to recognize is as well every else in RUP, this is an iterative process.
You want to check every iteration – is the mission the right mission. We will see as we go through, that the mission for the test group in fact changes throughout the release and it should. Yes.
Even if you say, “We don’t develop software iteratively so that won’t work for me,” this ocnsideration still applies. The short answer I’m going to give you is that test groups end up facing changes in their mission over the life cycle of the product whether that’s explicit or not. We will see that in an example, but I’m going to defer that and come back to until after we see the example. I hope you will say, oh yeah, I see that. If not, then we should talk about it then.