Customer Best Practices: Coding and Testing Phase

CodeGuru content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

According to the Standish Group, the primary contributor for project success (projects delivered on-time and on-budget) is great customer involvement. Knowing that, it makes sense to define best practices for dealing with customers. In the coming months, you will look at best practices for customer involvement that deal with all phases of the software life cycle:

1. Planning: Getting the customers involved in the planning process is critical. Gathering, analyzing, and evaluating requirements is key to ensuring that your project meets the needs of your customer.
2. Design: Good designs are key to ensuring that changes the client requests require minimal changes to your framework.
3. Iterative Coding and Testing: Customers play a major role in Quality Assurance and User Acceptance testing prior to production releases.
4. Production: Having good release management and support ticket management procedures in place will ensure quality releases and great customer support as issues arise.
5. Post Mortem: Upon completion of projects, it is of paramount importance to involve your customers in the project review process. Post Mortem reviews can aid in discovering and document common issues that arose during the project and allows for others to better plan for those risks in upcoming projects.

Design Phase

Good designs are key to ensuring that changes the client requests require minimal changes to your framework. The Design Phase is used to determine the technical solution and to provide preliminary estimates for delivering the solution. For the project manager to provide correct estimates, the development team must spend time architecting a technical solution that meets the demands of the functional specification. Additionally, the testing team must develop a Master Test Plan as to allow them to estimate their effort. Upon completion of this phase, a project plan that details the costs, effort, and timeframes in which the solution may be delivered may be developed. As a final step, the client may decide to add, omit, or delay functionality to fit within their timeframe and budget.

Below are some best practices to aid project management during the Design phase:

Step 1: Create Detailed Designs

The detailed design document allows your development team to thoroughly think through the development approach, and to determine the effort involved in delivering each functional specification item. Below are the keys to successfully creating detailed designs:

1. Document your Architectural Roadmap: If your company has not done so yet, document your architectural roadmap for delivering solutions. If you wish to see a template for doing this, go to http://www.pragmaticsw.com/Pragmatic/Templates/ArchitectureOverview.rtf.
2. Create a Prototype: If a prototype was not created during the customer requirements phase, create a prototype for the feature to ensure that your developers and your project manager agree that the technical design meets the customer requirement. You can quickly create a prototype using FrontPage or any other HTML editor. If there are buttons on the page, explain in detail what will happen (from a technical perspective) when the buttons are clicked.
3. Specify the details of each function: For example, if you are creating a detailed design for a logon screen, you should have a section that describes exactly what will happen when the Logon button is clicked. It may describe that you will call a business object to validate the userid and password and if it is incorrect, an error is raised (specify the exact error message). It may further specify what objects will be used (like common objects to validate e-mail addresses, and so forth).
4. Specify “Other Design Considerations:” When implementing solutions based on customer requirements, you should specify whether there are design considerations outside of the norm. For example, you may specify that the software under the current design will work with IE and Netscape versions 6 and higher. You may also specify that no localization will be done; the user interface will support only the English language. These are examples of “other design considerations.”
5. Break the Design into Tasks and Provide Estimates: As the developer specifies the design for each feature, a list of tasks that must be performed to complete each technical function must be identified, along with an estimate of how long (in hours) each task will take to complete.
6. Have a Team Design Review: Once the detail design is complete, have the technical team review the design (and estimates) to ensure that the developer covered all the bases. Many times, these design reviews bring up ideas that allow you to reduce the effort with a more elegant approach. This approach also allows “other design considerations” to surface and be discussed.
7. Get Developer and Project Manager Signoff: Have your developer and project manager sign the detail design document so that you can later refer back to it, showing that both parties agree to the approach.

Detail Design Template: http://www.PragmaticSW.com/Pragmatic/Templates/DetailedDesign.rtf

Step 2: Create Master Test Plans

The test design document allows your testing team to thoroughly think through the testing approach, and to determine the effort involved in providing adequate test coverage for each functional specification item. The test design document should contain the following sections (you may consider skipping some of these sections for smaller projects):

1. Introduction: The introduction should explain a why you are testing the product included with these items. It includes Background, References, Code Freeze Dates, and Change Control procedures.
2. Items to be Tested: This section identifies not only the items to be tested, but also the level of testing in different functional areas. It includes sections on the level of testing, features to be tested, test case matrix, and features to exclude from testing.
3. Testing Approach: This section defines the overall testing strategy and iterates the deliverables for each phase of the project. It also specifies the tools that you plan to use for defect tracking and issue management.
4. Release Criteria: This section describes the procedures for allowing the project to enter the production phase. It contains test case pass/fail criteria, testing suspension rules, testing resumption rules, procedures for release to user acceptance testing, and procedures for release to production.
5. Hardware: This defines the hardware in which the testing will be performed on. This includes your client and server configurations.
6. Project Plan: Defines the deliverables, budget, and dates for the testing activities.

Master Test Plan Template: http://www.PragmaticSW.com/Pragmatic/Templates/TestDesign.rtf

Step 3: Design Database and Object Models

Once your development team has created a detailed design, it is time for them to begin determining what database tables are needed to match the design. There are two types of data models:

• Logical Model:This is a roadmap of all the data structures in your design, with relationships among objects clearly defined. It includes the attributes of each entity and allows you to normalize the data for your specific purpose.
• Physical Model: This is an implementation of a database on a specific database engine. Based on the Logical Model, the entities become database tables and the attributes become fields in each table.

When creating your logical model, you will draw diagrams that explain the relationships between the data entities. From here, you create an ERD (Entity to Relationship Diagram) that shows those relationships. For example, if you are creating a billing system, you may have an Invoices entity that has a relationship with Invoice Line Items. In this relationship, an Invoice must have one or more Invoice Line Items. There are many great tools that allow you to draw these diagrams, such as Erwin ERD. Some databases come standard with ERD drawing tools; an example is Microsoft SQL Server. It has an Enterprise Manager that contains an Diagram modeler.

The Physical model’s purpose is performance. Designing databases for performance requires an understanding of the underlying DMBS and normalization techniques. In most instances, the database should be designed relationally and properly normalized. In cases of historical reporting, it is often a good idea to create de-normalized summary tables to quicken the generation of these reports. Most often, it is good design practice to keep only the amount of information necessary to run the business on a day-to-day basis on the operational system and have a separate data warehouse for storing historical data. The data warehouse can produce historical reports or may feed data marts to perform specialized reporting.

When designing tables, make sure you index the fields that will often appear in where clauses. This will speed data retrieval. Use tools like Oracle’s Explain Plan or SQL Server’s Show Plan to determine the execution path of your SQL statements. This will let you know whether you are scanning the entire database or scanning an index. If scanning the entire database, consider adding indexes to prevent this from happening.

If you have a frequently used operation (such as search for Agent information), consider using a stored procedure to return the results. Because stored procedures are pre-compiled, their execution path has been predetermined and is generally faster than simply issuing an SQL statement.

An important part of the data modeling process is to establish clear standards. For example, your data model should have consistent abbreviations, and should have standard naming conventions. For example, you may decide to name all your tables as plural (Invoices instead of Invoice) and you may decide to always abbreviate number as nbr. If you document your standards ahead of time, this will ensure that all members of your team build a cohesive product.