Tim's whitepaper was originally published in 1999 and it's reproduced here with his permission.
Built to Grow
We began our discussion with the premise that the true value of a business management system is in the product’s functionality. Our “Built to Last” architectural value allows us to “plug in” new technologies, giving end users access to leading edge technologies while also protecting the functionality from changes in technology.
We have established an architecture that allows our product to be “Built to Last,” which allows us to turn our attention to the task of ensuring we can add new functionality to the product. We call this value “Built to Grow.” At Great Plains, we ensure our product is built to grow in three primary ways.
A software developer can’t add new functionality if they are always busy fixing the old functionality. Dynamics has exceptional product quality levels. This high-quality
product gives a solid foundation on which to base new functionality.
Great software doesn’t happen by accident. This is especially true for very large and technically complex software like business management systems. You can’t simply
throw hundreds of developers into a room and expect robust, high-quality software to come out.
Great software requires a comprehensive strategy from requirements gathering at the beginning to testing and product shipment at the end. With this in mind, Great Plains has a corporate commitment to promoting the best practices for software development.
Great Plains bases its process effort on the Capability Maturity Model (CMM). Pioneered by the Software Engineering Institute at Carnegie Mellon University. The Capability Maturity Model provides a framework to guide and measure software engineering improvement efforts by enabling organizations to assess their software
engineering capabilities. You can learn more about the work of the Software Engineering Institute on the CMM at http://www.sei.cmu.edu/
Established processes are a must for great software development, but a “paper process” is only the beginning. Companies must act on those best practices by investing in supporting systems. Great Plains has a long history of making these important investments. Let’s begin by taking a look at just one area where Great Plains has invested in supporting systems: testing.
Since the first day Dynamics shipped back in 1993, Great Plains has committed to test each and every product feature. Before any feature is implemented, the SQA
staff defines a paper-based test plan. This plan is then put into action by recording an automated test (called a macro). As the Dynamics product has grown over the years, the test cases have also grown. Today the testing suite has grown to more than 4,000 unique cases, all backed by automated macros.
If performed by hand, this suite of test cases would take an estimated minimum of 3,000 hours of testing time to complete, equivalent to two months of work for a 10-person team. Because we’ve recorded these tests as macros, we’ve reduced the workload by a factor of 100, to around 30 hours of machine time.
But we want to be able to test our product even faster, more often, to make the code as clean as we possibly can. In response, Great Plains has increased its investment in supporting systems to build a distributed testing environment. Before development team members go home for the evening, they indicate that their machines may be used for testing by running a small application. This application communicates with a central testing server, and the result is that hundreds of machines can be used for testing. The testing server automatically downloads the version of Dynamics to be used for testing to the team member’s machine, enabling us to run tests all night on hundreds of machines simultaneously. At 7:00 am, the tests automatically stop running, the results are uploaded to a central database, and the copy of Dynamics is deleted from the team member’s machine. This distributed testing environment allows us to test many features in Dynamics in a single evening.
You may be thinking this is nothing special. “Of course all business management system vendors fully test their software.” I can assure you this is not the case. Customers cannot simply assume their business management vendor fully tests the product. Due diligence during the product evaluation phase should absolutely include
an evaluation of the vendors’ testing methods.
When you perform this evaluation, you will be shocked to find out that some vendors have no formal testing process. The product is tested by throwing a few support
people into a room and letting them “play with the software” for a few days before the new version is released. Other vendors rely on Beta releases to customers to
ensure product quality. At best, this is the vendor making the customer test the product. In reality, most customers don’t really exercise a Beta product, and the
product is simply not tested.
Some vendors have begun to realize the disastrous consequences of releasing products that are not fully tested. These vendors are engaged in a “catch-up” phase where they are trying to retrofit automated testing into an existing product. Keep this in mind when evaluating a vendor. If they tell you, “We use automated testing,” you need to follow up and ask them how much of the product is tested with these automatic tools. In reality, many of these vendors have just started, and only a few tests are actually in use. This perspective shows what an impressive asset the 4,000 existing Dynamics macros are to the customer’s productive use of the software. It has taken a software quality assurance staff of more than 50 people working for over seven years to build this test base. During this time, the testing staff also has continued to grow to support new initiatives and technologies. Vendors who are starting from scratch today will never catch up.
In the next article Tim reviews "Built to Leverage".
Until next post!
Mariano Gomez, MVP
Maximum Global Business, LLC