Sailing with Testers (part VII)
Everything needs maintenance. We do, machines do, transportation vehicles do, and software solutions do. Everything. it’s just that no one likes to do it.
Take yachts and boats for example – to get them to operate regularly and for many years, they need constant maintenance. There are many types of work that need to carry on, in different time intervals (daily, weekly, monthly, yearly). For example:
- Boat washing
- Washing and checking sails
- Tightening of rails
- Plumbing devices and water tank maintenance
- Engine inspection and care
- The operation status of manual and automatic pumps
- Electricity, and electronics (devices such as navigation)
- Rescue equipment validation
And this is just a small part of a very long list.
So how do we usually perform this work? Well, the same as we did last time. OK, how did we do it last time? same as before….
That’s the thing – we do it exactly in the same way as we did it when we learned how to do it. And we never stop to think if we’re doing it right, or if we’re covering all that needs to be done. Maybe we’re doing things we shouldn’t be doing anymore (or shouldn’t be doing in that specific time-frame). We might be missing better ways to do what we’re doing, new knowledge emerged, new technologies can assist us.
Are we just comfortably numb?
Pink Floyd and Software Testing
Being comfortably numb is a common danger in software testing as well. Testing groups tend to get used to testing in the same way, the same approach, for long periods. They test using the same tests over and over. The same testers are responsible for the same features, parts of the code and software. These groups might be using the same (old? out-dated?) testing tools, and the same methodology that doesn’t fit the project anymore.
Consistency and working with what was a success before, has its advantages of course, but it comes with the danger of unchecked paradigms, and testing management that does not challenge itself to try and find better testing ways, a better testing approach, and new testing ideas, all in the constant journey to develop better software (solutions).
We’re afraid to change habits, and it takes time and effort to explore new options, risking not finding any. So we go back to what we know and has worked for us until now. However, we might be wasting more time, putting greater effort in our overall testing work, and doing what we always did instead of looking for improvements.
Take automation testing for example. We all want to use it, but since we still don’t, it is always pushed back. We test first with what we have and know (e.g. manually), hoping “we’ll get to it” in the future. We probably won’t, unless we change the way we look at it.
This is exactly where a test manager should understand the difference between managing the daily routine, the on-going work, and planning the future of their software testing projects. Time should be allocated for thinking, exploring and experiencing new methodologies, tools, workflows, means of testing. A manager should be busy considering if the team is not only capable of performing the current work, but is also up to the future challenges and the changes they will enforce.
Avoid conceptions
Did you consider if it’s better to replace the propeller rather than fix it (again)? Is it easier to dive in order to do the job, or perhaps it’s better to get the boat out of the water? Is there a new type of propeller that should be considered – different material, shape or size? Don’t just do what you did last time.