The Web Testing Companion: The Insider's Guide to Efficient and Effective Tests

Lydia Ash

Forms and Templates: Check-in Mail

When changes are made to the code base, there must be some sort of notification. This notification could be through a Web site tracking product changes or through email to the team. This section contains a suggestion of what needs to be covered for information to be effectively transferred.

Bug Number(s)

Include the number of each bug and possibly the bug title.

Build Number

Include the number of the build that contains these changes.

Description of Problem(s) Fixed

Bug number: Description of problem.

Description of Change

Bug number: Description of change implemented to fix the identified problem.

New Feature(s) Implemented

Give the name and description of new feature(s) implemented, as well as a comment if these features are complete and ready for full testing or if they are only partially implemented.

Potential Destabilization

Give a short description of the potential problems or risk areas that have been identified.

Performance Impact

Give a short description of the potential problems or risk areas that have been identified.

Source Files Affected

List all source files touched by this change. Even if some files were not touched, they may need to be rebuilt. Include those here.

Build Instructions

Include any special instructions for building this.

Binary Files Affected

List built files that are altered by these fixes.

Tests Run

List BVTs, unit tests, smoke tests, or other automation that was run here, and the pass or fail results from that. Potentially, changes will break automation. Potential automation breaks, such as changes to the tag IDs or other hooks that have been provided, need to be listed here if they are known. You can also list testers involved in testing if this was submitted to test first.

Code Reviewed By

List the name of developer who code reviewed the changes.