There was a time when software releases came slowly--perhaps even annually for some projects. But in today's fast-paced world, where computers are everywhere and software has to keep up, some teams are promoting software daily or even more frequently. If you feel like a storm cloud of change is unleashing its fury upon you, Linda Hayes has some suggestions to give you hope and help you gain control.
I've been in the software industry long enough to remember when one release a year was the norm. Except for emergency fixes, which were clustered shortly after the release, intended changes proceeded at a stately annual pace. But recently, the QA director of a major electronics manufacturer calculated that they promoted software into production multiple times per day .
This fire hose effect is attributable partly to the overall decrease in cycle time brought about by new techniques and technology, partly to the sheer complexity of the operating environment, and partly to the frequent emergencies caused by unexpected change impact. As each day goes by, there are more applications, more functionality, and, especially, more risk.
What makes this extra scary is that every tester I know is struggling just to skim the surface of the latest additions; comprehensive regression testing is a distant dream. Even if they knew what all the accumulated requirements were--and they don't--they don't have a fraction of the time and resources to get it done and no prospect of getting them.
The situation screams for automation, but historically automation has not been able to keep pace with rapid change. There is often inadequate (if any) notification of changes well enough in advance to update test scripts, and the maintenance effort itself is typically too time-consuming to keep up.
It seems hopeless ... but it doesn't have to be.
The key to managing constant change on a daily basis is to streamline the process by targeting your efforts based on potential risk and then to automate everything you can. This allows you to devote your limited time and resources to removing as much risk as efficiently as possible. Of course, it sounds easier than it is, but it is achievable if you follow these steps:
- Identify critical functionality . Granted, the odds are slim to none that you have anything approaching comprehensive, current requirements, but that is no excuse for not taking steps to start collecting the most critical ones. The best place to start is by analyzing production: What business processes drive operations? Which are the most common, the most important, have the highest exposure? Use system logs to glean what processes are running when and how often. Talk to the business and gain an understanding of which functionality--or lack thereof--keeps them up at night.
Don't let the scale of the problem deter you from doing the best you can--there is no time like the present to get started. The problem is only going to get worse as time passes. Set yourself an achievable goal--say, the top five or ten most critical processes--and get a handle on that first. Then, systematically work your way down the list. You'll probably never reach the bottom, but removing some risk is better than none.
- Implement change detection . The reason software is promoted into production is because something changed. The critical question is, what changed and where? Was it a business process, the code, the data, an external interface, security settings, the operating environment, or all of these?
The best case is to automate, because relying on human intervention is tricky at best. Developers may not think the code they tweaked poses any risk, or users may not realize the master data they changed has far-ranging impact. Depending on your application and technology landscape, there may be tools that can compare before and after environments for you. Generally available commercial database tools can be used to look for changes to schemas or content. Source-control systems can flag code modifications. Search for these tools; they are worth finding and