Static Testing
OK...
Looks like blogBuddy is good for quick-posts, but doesn't put titles on posts.
Forunately Blogger allows for editing posts, so I can always add them later.
Meaningful post for this week:
Static Testing:
Careful review of requirements and design for anything that is vague, unclear, or ambiguous may appear to consume too much time when trying to get a project going, however, taking more time up front to eliminate faults in the requirements or design will save time and money as the project gets closer to the target release date.
It's faster, easier, and cheaper to fix your product before code is written than it is when Sales and Marketing are screaming because the date slipped and they've already promised the product to someone.
It costs far more to go through test/rework/retest cycles because the requirements, specs, and/or design are vague, unclear, or ambiguous. With poor or no Static Testing at the front-end, the faults found in test tend to be more severe, costing time and money to fix and retest.
If your development process doesn't currently include your Test Team in review of requirements, specs and design, SPEAK-UP! When you explain the value of up-front static testing - if you do a good job of it, that is, people will listen.
posted by Joe Vincent @ 1:49 PM
1 comments
1 Comments:
This is more of a "If only we had done static testing" experience...
A little history first:
Actually... the company I work for started out primarily designing and manufacturing hardware with some very limited embedded firmware. Over a short period of rapid growth, our products have grown more and more complex, and software has gone from a small portion of what we make, being a major part.
Back when firmware was a small part of the overall product, some ad-hoc (try to break it) testing by the tech support team was sufficient to find the majority of bugs. We've grown as a business so rapidly over the last four or so years, that the concept of software being a major component of our product, kind of snuck up on us.
About a year and a half ago, we realized that the software portion of our products had gotten huge, so the company formed a dedicated software test team. We all came from tech support and development backgrounds, and had to climb a steep learning curve to become familiar with "formal testing". We started out by creating some basic processes. Unfortunately, our group was formed at the tail end of the development cycles for several new products. We developed test plans and test cases on-the-fly (which we documented while executing the tests), and have been stuck in a never ending loop of test execution ever since (gotta keep adding features!).
There have, however, been weeks, here and there, where things have slowed down enough for us to take some time to explore our development model and our test processes. One of the things we did, was an "after-the-fact" analysis of the requirements and design documents, in the same manner we would/should be looking at them as part of the development process. What we found was that roughly 40 % of of the bugs we found in final test cycles could have been prevented had we been involved with the requirements and design phases of the development cycle. Some of these were major faults that took a lot of rework time to fix - and touched on many parts of the overall system (lots of regression testing). We estimated that the three week slip in release would have actually been cut to one week due to the nature of faults we identified by analyzing the requirements and reviewing the design - from a "Test" perspective. Since we make devices, not just programs, we took a look at the hardware development/test process and found that the hardware requirements and design undergo extensive analysis and review before we start prototyping circuit boards, housings, etc. Needless to say, we have far fewer hardware problems at the end of the project - compared to software problems. Moving forward, we're re-vamping our development model to put as much emphasis on the software side of our products, as we already have on the hardware side. We expect to find fewer bugs at the final test stage, reducing the number of rework cycles, and getting our product to market sooner.
I hope this example was helpful!
Joe
Post a Comment
<< Home