In the mid-90s I was privileged to be on a team building a service-oriented middleware architecture (Datagate), which I have mentioned before. We used an underlying library that implemented XDR, for which we had no unit tests. Since much of our software was built on this and a couple other core technologies, it was important that they be as solid as possible. Make the foundation solid, and the rest will follow. I decided to build a suite of unit tests against this software, suspecting that there were some bugs in there. Using a coverage tool, I wrote tests that covered the entire XDR library, and we found that the suite would not run on one of our twenty or so supported platforms. We fixed that bug in the library.
After that, we found that one of our nagging bugs went away in our Directory Service. It turns out that the two were related. I took some time to build the test suite, but not that much. It saved us time in supporting the Directory Service. It probably saved application and service developers time, too, but we didn't research that.
After that, when it came to the value of testing, I told everyone who would listen, "We don't have time to skip that step." And it's still true today. Can you afford the extra time it takes to skip testing?
3 comments:
This year I've had the privilege to work on a non-service-oriented application. The application has a custom web framework with spotty unit tests that are run as part of the build, but haven't completed successfully in months. The email we get ever morning from the continuous integration system that we may have broken the build has become a joke. There are regular regressions that occur. The project is 50% tested by the QA team, and it's due in 3 weeks. I guess my project management believes we have time to skip that step.
@Heath: Ouch. Yeah, it's better to work for management that "gets" software development, knows what it takes to deliver a production system, hires good people and places trust in them to deliver. Not that any place is perfect, but we need to find you something better. Or, maybe we need to go make something better.
The positive side is that since I'm just a consultant, I don't have to be part of the death-march, and I have a very good concept of the technical aspects of the application, so I can fix bugs that come up pretty quickly. Apart from the fundamental managerial problems the project is pretty easy. At least the it's over in 3 weeks.
Post a Comment