Just enough process: the checklist

Following processes is important for ensuring quality, but often processes become an end in themselves. Therefore, one of the stock statements you’ll hear from me is: we need just enough process and no more.
checklist.jpgIn one company where I worked, we had a couple of developers on our project who were inexperienced at doing UI work. Every time one of them delivered a UI screen, the QA engineer would immediately find numerous UI defects. It would then take quite some time for the QA engineer to document the defects, then more time for fixing and verifying them.
After we’d gone through this a few times, we realized we needed some process in place to try to prevent these defects in the first place. The problem was, the UI defects related to assumed requirements. Our requirements stated, for instance (not a real example), that the user needed to be able to specify the following information when adding a contact to the address book: first name, last name, street address, city, state, ZIP, etc. However, the UI defects that the QA team was finding lay in details at a lower level than our specifications: tab order, various types of form field validation, consistency of error messages, etc.
The obvious solution would have been to make our requirements more detailed. This approach, however, would have taken as much or more time than the defect process was taking and nobody wanted to deal with that level of requirements.
Instead, I noted that the types of data we were working with were common (actually, I think basic contact info was in fact one of our areas of functionality) or at least well understood by our team members for the domain of our application. The problem lay not so much in the requirements but in the fact that the inexperienced UI developers were not used to thinking about all the little ‘gotchas’ in UI work.
My solution was a UI checklist for each type of UI screen. For a data input form, for instance, it included things like:

  • tab order
  • UI widget is appropriate to data type
  • hot keys on field labels
  • data validation: required fields
  • data validation: min and max length
  • data validation: allowed characters
  • etc.

I presented the checklists to the developers as follows: we would like to ask you to make a good faith effort to address all of the items on the appropriate checklists before delivering UI screens to QA. We all understand the domain and data well, so I figure that, for example, the QA engineer will agree with 80% of your choices on how you implemented these details, 10% of the time the QA engineer will disagree, and 10% of the time there will just be a bug.
After that point, the UIs that these developers delivered to QA were noticeably more mature first time around, and my 80/10/10 example turned out to be roughly correct.
I think that the last part–making it clear that we trusted the developers–was the key in the success of this program. Instead of focusing on the fact that these developers were inexperienced, we gave them some guidelines and showed them that we trusted them to do the right thing–both in just following through on their verbal commitment to make a good faith effort to address these details in the choices that they made in doing so.