Auteur: Kees Blokland ● kees.blokland@planet.nl
Redactie: Frits van Iddekinge en Eric Spaargaren
Two years ago, I made a career switch back to high tech. In the past two decades test process assessment had become a kind of occupational deformation, so while onboarding my new job I automatically was on the lookout for issues in the test process. I found some, but how important is test improvement in my new context actually?
High tech test process in the nineties
I learned software testing on the job. Being member of a large R&D community there were a lot of examples at hand. After each large release we evaluated our way of work, discussed problems and frustrations and experimented with improvements in the next release. We were practicing continuous improvement: learning and putting ideas in practice. My high tech story pauses here. Due to the implosion of the internet bubble I had to find another job in 2003: I became test consultant.
Test improvement in business software development
The job change led me to a completely different world: one of developing and testing software used by organizations to support their business process. Together with colleagues I went to dozens of organizations to support them improving testing. With the use of models, we assessed their test process to identify improvement opportunities. This led to sometimes surprising outcomes that shined light on the importance of test improvement for an organization. Please read about three test improvement cases in business software context and one in my renewed high tech context.
Example result of model-based test assessments
Case 1: You’re fired…
One organization asked us to help improve the testing process because of serious problems with their deliveries. The investigation results showed a clear relation between the lack of a well-defined and well-followed test process and their problems. I entered the room for my end presentation with the findings. The development manager was there too. We shook hands and she told me it was her last day: the organization had decided to let her go… I never heard if this was due to our findings, but it would fit the conclusions quite nicely…
Case 2: Well done…
The second case was a large governmental organization that was implementing a huge test improvement program. We were an independent party to assess their progress and we found that the improved test process was followed well enough for the organization to be in control of their testing. This positive conclusion was shared with a room full of managers including the CIO. They relaxed a bit, and we were thanked with a well done!
Case 3: Thanks, but no thanks…
The third example was an organization developing and selling financial simulation software looking for ways to improve testing. The number one opportunity we helped them finding was the introduction of a transparent product risk-based test strategy. During the proof of concept of an improved way of working – again with our support – something surprising happened. They decided not to implement it, although they recognized the logic behind it. They preferred to keep their way of testing – because that simply was effective enough. Learning: their context did not require them to improve… They still were happy and said goodbye to us with thanks, but no thanks!
Case 4, High Tech: never ready…
The high tech R&D requires a high maturity test process, which in a well-known test improvement model is called ‘optimizing’. To reach this level is already one thing, but keeping it requires continuous focus on improvement. Back in this context I had to adjust my focus: instead of implementing several distinct test improvements to reach a certain test maturity level I need to keep the organization into a continuous test improvement mode. This ‘relentless improvement’ is required to keep up with the pace in the competitive R&D environment.
Takeaway
It is important for an organization to understand the need for test improvement to a certain maturity level and to act accordingly:
- In the first business software example test improvement was picked up way too late;
- The second case showed an organization that was successful in improving testing to the required level;
- The third case showed an organization that took the initiative to improve, but found out it was already at the required level;
- Finally: high-tech R&D requires continuous test improvement: you’re never done!
High tech: happy to be back!