As you are a manager, let me use an analogy. Assume, we are creating a dessert from a given recipe, a chocolate cheesecake, with hot cherries and vanilla sauce.
What plan would you create to make sure the result is yummy?
The Process Model
In this case you know what you want to achieve, and you generally know how to do it, the only insecurity is if you are able to follow a recipe. So I would take this as a simple problem, with some possible complications – calling for a „just do it“ approach, with possible iterations for feedback, if possible. No agile, really, this is not complex enough.
The Architecture
The dessert consists of several components: the dough for the cake, the filling, the little baking pans, the vanilla sauce, the cherries. These components are made of ingredients, like butter, sugar, curd cheese, vanilla, cocoa – here is a nice recipe with the complete list for the cake, plus eggs, cream, cinnamon etc. for the other components. The components are then integrated into little cakes, and later into cakes sitting on top of a bit of vanilla sauce and enhanced with hot cherries.
The Test Plan
What do I need to test? Functionality is obvious: does it taste well? Does it look appetizing? Is the smell seductive?
But then you would have to decide what to test else:
- Usability: how easy is it to eat the desert, without spilling the red sauce on your white shirt or without having it fall apart while eating -> Yes
- Maintainablility or operationability: hm, I guess it got a rather short life span, so here we could take the risk of not testing it: -> No
- Efficiency: well if you find someone who wants to do a load or stress test – I guess, go for it. This way you could also test, if the dessert is good for your health -> maybe
- Reliability: is the dessert fault tolerant? Is it still good, if one of the components fails? Can I recover it to a full scope dessert? -> Yes, you could.
And When Will You Test What?
Here the standard means to help decide is the testing pyramid. From here you easily read your test levels:
Unit Test
Check if all ingredients are good and well suited. Is that fine crystal shaped stuff really sugar or is it salt? Is the butter soft enough to be processed, are the baking pans clean and a little warm?
- Test tools: your fingers, a spoon, your tongue,
- Test methods: taste, touch, …
Component Test
are the components fulfilling the correct expectations? In component test you test what you have not been able to test before. So even if you still would find out now that that crystal shaped stuff was salt, it would be rather annoying to find out now. You’d have to throw everything away. So now you would want to only have to test the component in total only: is it the right amount of sugar, do you have enough better to grease the complete pan? Is the vanilla sauce fluid enough to be poured? 
- Test tools: your fingers, a spoon, your tongue, your eyes….
- Test methods: taste, touch, …
Integration Test
Now you get to the level where testing is sexy. Why? Because you know you have done all the boring details before! And now the culmination of your knowledge starts: what is different on this level of integration? What have you not been able to see before? What do you have now because of integration? I mean, you get the chance to test, if you got enough butter in the pan so that the dough does not stick to it while not yet baked. You get the chance to see if there is enough filling to get all pans with dough filled….
Test tools and Test methods as before. Only on a different object.
System Integration Test
On top after integration there is the baking and cooking. To make it short: the new test here is: do you still get the cake out of the pan? Does the cake survive sitting in the vanilla sauce? Would the hot cherries cover all the beautiful chocolate dough pieces in the filling or can you still see something?
- Test tools would have to be extended by a knife, a plate, …
- Test methods: some kind of business process test could help here: the process would be for example putting everything together…
Actually, this would be the level for load test and usability test. You got all you need for it. But you also can consider who could do it. In this not so very complex situation, you could decide that you skip this at this point in time, but do it in the next level:
User Acceptance Test
EAT IT.
- Test tools: fork, mouth, tongue, eyes, fingers, …
- Test methods: for example, put yourself into different personas, who would eat the dessert: the manager, the rookie, the long-term team member… invite all your family and friends for the load test.
The final product
Retrospective
Not a standard test level, but a good practice. What could you have done better in process? Maybe first prototype one little cake, and then lead through the whole process to see if all is fine? To make sure you got enough butter in the pan? Or you got enough filling for all the dough? I guess this would have to be evaluated in the specific situation.
So…
dear M. now you know how you could approach the test of the dessert. Want to know more? Test methods in detail, or testing in agile, or… that could be part of a next letter…