Fixing What's Not Broken

Many engineering teams look at change as a bad thing, something that will disrupt their work.  And granted, changing for the wrong reasons, or making changes for the right reasons but too many of them too quickly, can be disruptive and affect productivity.  But you should also be careful about being too stagnant as a team.  If you have a smooth running team that produces constant results at a reasonable quality, why change?  And if change is suggested, why adhere to it?  Well, there is actually a very good reason for that.

For teams, or even people, who are set in their ways, there is this concept of "don't fix what's not broken".  Things are going well so leave it alone.  Changing something may cause it to get worse.  Sure, that makes sense.  But I suggest you look at things a little differently.  Consider the fact that you may still need to fix what's not broken.  To some extent, that attitude is what gets a good team to become a great team.  It's what gets Test organizations to become Quality Assurance organizations.  Why is it good to fix a team, process, or technology that's not broken?  Because it reduces risk.
As a QA team or an individual tester, your job is not about finding bugs.  Finding bugs is an activity you perform to help reduce risk in the product - to reduce the risk that the customer will find a problem and not like your product.  A true QA engineer will go through many different activities to reduce risk.  Besides finding bugs, they will review architecture, determine performance of the system, and prove the quality level is high.  It's not just about breaking things.  It's about proving things aren't broken.  And sometimes that means implementing changes that don't necessarily fix something specific, but instead just improve on what already works well in order for it to work better, and to have less risk of breaking in the future.

This idea holds true not just with code and feature sets, but even with engineering processes within the team.  My team recently introduced some changes around what we measure as a QA organization.  One such item was what we call EVT/IVTs.  These are environment and installation verification tests.  Many people questioned why we would spend the time writing these tests.  There are never any problems with the environment, according to some people.  Never?  Prove it!  The main reason to do these tests is to reduce risk.  Maybe the environments are always in a good state before we start our test passes, but that one time when something doesn't get installed correctly (yet everyone starts their testing), and time gets wasted as we find the problem that has now stopped the whole test team from moving forward with testing, is a perfect case of why we should fix what's not broken...because someday it may break.  Problems like this may not happen often, but when they do, they cause schedule slippages and wasted time for many.  Another reason for changes such as introducing EVT/IVTs, is that you may actually be compensating for a problem area that you don't even recognize anymore because you have been doing that for so long, you just don't even see it as a problem anymore.  It may be normal for it to take <enter large number here> hours to install a new build and have an environment ready for testing.  But what if I can prove that this can be done faster?  Then isn't that improvement worth it?  Granted, your situation may not have been "broken", but by accepting a change to your process you've now fixed it even more so that you are in a better state.  If it's not broken, it may still need fixed.  You just need to redefine what broken really means.

To get to a state of higher quality, always assume entropy is going to happen (that things will tend towards chaos), from normal actions like people leaving a team, from new processes being mandated, or from people forgetting things that they learned about the project but never wrote down.  Most of the work we do, especially if we are on teams that are trying to sustain or maintain an exist product or deliverable, is focused on reducing our trend towards chaos.  Some of that work will be new changes in how things are done, maybe not only to reduce risk of a deliverable, but to reduce further chaos from occurring once the product has shipped.  There are always things we can improve on in any engineering project, process, or team.  Don't disregard an idea or improvement because you dislike change or because you think things are good enough.  If you truly believe in engineering entropy and that things will tend towards chaos, then you should welcome appropriate changes that fix what's not broken, because potentially on a second look, they may be more broken than you think.