In college we are taught the most basic software development models: V-model, waterfall, agile etc. When we start working we are presented with new models or variations of the old ones left and right. And as technology moves forward even more models are added to the mix. As a new employee in a company it can however be quite a task to figure out which variation of a model the company uses. I have yet to see anyone uses a single model in its purest form.
I was assigned as Test manager to a large government project running over several years. The supplier was a large international and experienced supplier in software development. They have extensive knowledge of their client and the work processes that the system had to support.
The contract type stipulates that the development process has to be waterfall, the supplier suggested V model but used an agile approach in the development phase. The result was a mix of all three development processes. In an attempt to uniform the project ITIL, Prince2 and ISTQB was added to the mix as well.
To ensure that the system was what the project needed a few different things was introduced. On the test side we introduced two tests to be run during the development phase. First the supplier had demonstrations of the development progress and second a client-test to be run every three months. Both types were based on of the most important business processes. They were great examples of introducing early testing in a waterfall project while taking advantage of the agile approach.
The project did not at all go as planned. Delays upon delays caused constant changes for test. In order to cope with these changes – either proposed changes or actual – we found that sticking to what we know was the best way forward. We based our efforts on the product risk analysis, used the test design techniques that was required to test in the right depth for each risk class and discovered that the good old: “Plan-Do-Check-Act” can be quite useful to keep in mind when dealing with a project where processes, tasks and goals change every other week. Plan your tasks according to either the projects development process, do what you planned to do, check if your plan worked – did the test basis, test goals, test data or anything else change over time and then adjust your plan accordingly.
Testers and test managers have a large toolbox at hand, adding general project management tools only increases our ability to plan-do-check-act. It really doesn’t matter if the development model is waterfall, agile, V model or whichever model or variation of a model is used. Tools like test design techniques, product risk analysis and others we use in test are like puzzle pieces and the models are where you fit the pieces in. The tools are basically the same and if we know our tools well enough it is more a question of how the piece fits rather than IF it fits.
We went back to the basics – used the product risk analysis to ensure that we focused on the most important requirements. We looked at the test basis and chose test design techniques that fit both test object, risk class and test basis. We kept in mind that we were only supposed to do acceptance test. And if something wasn’t working we adjusted the technique – instead of doing a full scale product risk analysis we “just” focused on the requirements and instead of determining a test depth level for each test object we gave a list of what we expected to use and then used what made sense in the specific situation.
All our efforts resulted in a situation where we regardless of the development model were able to do our job: Making sure that the client received what they asked for in the quality they expected.
