When is it ready?


There are three perspectives on when the product is complete and ready for deployment: the engineering viewpoint, the quality assurance check, and the customer determination that it meets the documented requirements.

The engineering viewpoint is comprised of the project leader (the customer ‚ s representative to the development staff), the project ‚ s developers, and other developers in the company. In a smaller shop, one person may be playing all the roles; in larger shops or corporate environments you may have someone different in each role. It should be obvious the product is not ready until all the features have proven to meet the customer ‚ s stated requirements. This is unit tested by the original developer, and system tested by the other developers and the project leader (if available). This proves the interface supports the business rules, which are implemented in data, and they all work together to manage the information correctly. Further, this proves all company guidelines and standards have been implemented in the code developed to support the solution that is ready to ship. These guidelines include proper coding standards, proper implementation of frameworks, proper use of third-party tools and controls, and proper implementation of industry standards if appropriate. The way to enforce these standards and guidelines is to either have a team walkthrough ( ‚“Defending Your Life, ‚½ as Whil Hentzen calls it in Hentzenwerke Publishing ‚ s The Software Developer ‚ s Guide, Third Edition ), or a simple desk check by one other developer. The goal of these review sessions is to make sure the code matches the requirements, is readable, and is understandable. A one-person shop has to do it all, but even one person shops typically have contacts they can call on for review of code if needed. If not, take some time to print code off and review it when you are away from the computer.

The quality assurance (QA) perspective is almost self-explanatory. A quality assurance team strictly enforces the correct implementation of the customer ‚ s requirements. We know it is a real issue that many software shops really don ‚ t have a staff dedicated to quality assurance. We are not talking about hundreds of people dedicated to the testing of all developed products. This could be one person who knows how to be the ‚“unknowledgeable user ‚½ and the ‚“knowledgeable user ‚½ at the same time. This role can be filled by another developer(s), and is best filled by people who were not involved from a coding aspect. A key to success with a QA department/person is to have them involved from the start of the project. By having them review the functional specification and prototype, they can start building the test cases for the test plan.

The customer ‚ s acceptance testing is critical, otherwise you may not get paid and it will be time to concentrate on another hobby that can be turned into a paying job. On the other hand, do not rely on the customers to find your bugs. It is important to note that customers are usually not trained in finding bugs in software. The best you can hope for is they are business experts and find all the process bugs and miscalculations. They will likely point out every flaw in the interface (labels misspelled and unaligned by a pixel on a form). We always suggest you watch them struggle to add a new thing-a-ma-jig into your latest software creation. See how they use it ‚ or more importantly, how they fail to use it. They may not even point out missing features for months. A thing like end of the month processing does not get tested until the end of the first production month even when you step them through the process during ‚“testing. ‚½ Little used features typically get their attention months down the road. The key to a successful user acceptance test is to give them a test plan when delivering a test version. Make sure every requirement is somehow tested by the test plan.

Testing

All software developers understand the importance of testing. The fact is we all learn the importance of testing and usually the hard way. The hard way is usually moving an application into production just after implementing a last minute feature and shortcutting the testing. This section is not going to step you through a complete system test, rather it points out a few things you can do after generating the golden executable so you can save some embarrassing last minute problems when you deploy it to your customers.

Testing is not complete unless you make sure all reports are printed (to various printers if possible), previewed, and output to various file formats (ASCII, Excel, HTML, etc.). Fire each and every menu option. Make sure the reindexing works (and the Stonefield Database Toolkit (SDT) metadata was validated if used), and the backup and restore processes function without incident. Two other issues we find developers frequently miss during testing is to verify the system conforms to the Windows ‚ Color Scheme and the application conforms to the customer ‚ s minimum screen resolutions .

If delivery includes an EXE, always test the EXE standalone. There is nothing worse than having a major feature fail in front of the customer because one of the developers forgot to remove a SUSPEND from the form you want to show off. "Error 1001 - Feature not Available" errors are unacceptable because it shows the developer never tested the new functionality standalone. We always use the built-in EXE version numbers to differentiate between builds that go to the customer. This way we know when the customer asks why a feature is not working in the version they are using (1.0.235), the answer is because it was added in the next version and they need an upgrade (to 1.1.59).

Is there a difference testing when shipping different types of applications? Is there a difference between shipping a bug fix, a complete new system, or upgrade when it comes to testing? What is the difference between delivering standalone components and a standalone app? Nothing, other than the amount of testing physically required. The same intensity used to system test a new app should be used to verify the latest bug found by the customer was squashed. The key is to test everything affected by the development completed. Maybe the engineering testing calls for you to desk check a bug fix and walkthrough a major change, but all of it gets tested by the QA group and the customer before it is declared ready for implementation.




Deploying Visual FoxPro Solutions
Deploying Visual FoxPro Solutions
ISBN: 1930919328
EAN: 2147483647
Year: 2004
Pages: 232

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net