A programmer’s pledge to Quality Assurance

I recently took some time to review the list of bugs we completed in the last year. I noticed that the majority of bugs found during development and entered into our tracking system were similar to this list:

• “Change the dropdown list to be sorted…”
• “Change the fields on the form to have the correct tab order…”
• “Change the fields on the form to move and resize appropriately if the form is resized”
• “Change this to be spelled correctly…”
• “Change … to be consistent…”

Each of these items takes time away from our development in many ways:

• for a tester/QA to recognize it,
• for a tester/QA person to record it,
• for a development team member to confirm it,
• for a development team member to assign it a priority,
• for a development team member to assign it to a person to fix it,
• for the assigned person to make the change,
• for the assigned person to mark it complete in the tracking system,
• for a tester/QA to retest it after the next build  for a tester/QA to mark the item as done.

That is a lot of Project Management for items that are just the result of sloppy programming.  We should strive to reduce these cosmetic “bugs” from ever being included in code that is “ready to test”.

Here is my idea.  Create a pledge that a programmer makes to QA because these are not the kind of “bugs” that QA should need to waste time on testing and tracking. I don’t think this pledge should be formalized and signed by each developer. I hope that it motivates programmers to pass code along to QA only after it is free of cosmetic bugs.

Our team held a meeting to discuss the items on this list. I was surprised that there was little agreement about any items, even items I thought would be non-controversial such as sorting listboxes alphabetically by default. I only led the discussion, I did not try to dictate or persuade, and in the end, after much arguing back and forth, most our of programmers did come to accept most of the items on the list as best practices. I provide our list as a starting point. I hope you can suggest other items to add to it. I realize that this list is very similar to coding standards, but by phrasing it as a pledge, I hope to increase the adoption of these tenets.

Expectations from developer (I pledge to):  (This is a pledge a programmer makes to QA because these are not the kind of “bugs” that QA should need to waste time on testing and tracking)

1. The code will not error right away for all users when they try to run it
2. The messages visible to users will not have any misspellings
3. The tab order on forms will be correct (reasonable)
4. The first field to receive focus on forms will make sense (be optimal)
5. When a form is resized, controls should move or resize appropriately
6. Form colors should be consistent across forms.
7. Form elements (button captions and placement) should be consistent across forms.
8. Keyboard shortcuts should be consistent per policy
9. Form icons and captions, including popup messages should be consistent.
10. Don’t ask testers to start testing until all these above items are correct.
11. Captions will fit on buttons, text won’t get truncated on screen.
12. Code runs fast
13. When you run my code, I would be surprised if you can find any “syntax” errors such as cases where null values were not handled
14. If an error does occur, it will be gracefully handled with a user friendly message and helpful debugging details will be logged.
15. If there are any conditions/scenarios I have not tested, I will let you know what those are. (I didn’t test on Vista, or against Oracle db)
16. Error messages will be complete sentences.
17. All data in lists will be in alpha order