In western movies, whenever a suspicious stranger blows into the bootstrapping town of good folk, the local sheriff makes a point to interact with the stranger early. “We’re a law-abiding people,” the sheriff says, instructing the stranger on the town rules and his enthusiasm for law enforcement. The stock makes for interesting cinema, my fellow quality assurance sheriffs, and it also makes for a good idea in your workplace; educate your new co-workers during their orientation process with a speech about what quality means to your organization.
Educating your co-workers about quality and laying down the law about what they won’t get away with in this territory offers the most benefit for time spent. Often, this education comes through rote training if at all. The designers and developers create something, and the quality assurance team finds problems and sends it back for correction. The next project, cycle, or version comes through, and the designers and developers send their work to QA, who then feels much like Bill Murray in Groundhog Day as they log the same issues and send the new work back. Eventually, the designers and developers glean a set of best practices that they can follow to make their work’s passage through QA easier and more efficient.
Sadly, this particular methodology occurs frequently when organizations bring new employees or contractors into projects or developments only when the deadlines loom and the team’s back is against the cliff. Hence, orientation may include only a brief sit down perhaps with a representative of HR and immediate supervisors and co-workers. However, by joining this orientation process, the QA staff or representative can immediately introduce the new person to a broad spectrum of best practices and best peccadilloes.
In the past, I have conducted these short introductions to new employees either individually or, after the company has accumulated a few new hires in rapid succession, in small groups. I have conducted the brief meetings informally in a cubicle or more officially within a meeting room. Either I alone or with a couple representatives of the team have ganged up to offer insights into the following:
- The best practices used by the organization as QA understands them. If the company has a best practices document, you can present it to the new person at this time.
- A rundown of the types of testing your QA staff provides. Give a quick overview of functional testing, regression testing, load testing, compatibility testing, and environments in which the code should work or in which the deliverable should look pretty.
- Any de facto requirements or understandings not typically covered in your organization’s basic requirements documents. Sure, someone could pose a business case for allowing the user to enter a blank space into the password, but until that person does, we prefer an understanding that this is banned, whether the requirements say so or not.
- The basic copy/text style guide and/or interface guidelines. Some of these are available off-the-shelf (such as the Microsoft Manual of Style), but if your company has one, everyone needs to be familiar with it. Even the lowliest developer has to create ad hoc labels, validation messages, or error messages, and you can help make sure that they’ll do so in the proper grammar and approved spelling. If your company doesn’t have these things, you as quality assurance have fallen down on your job.
- The defect resolution process. No matter how successful your orientation is, these people will proffer defective deliverables. You can provide them a roadmap that shows exactly how your organization will behave until they fix the problems.
This orientation will not only provide the overview of your QA department and processes, but can also give you a sense of who the individual is. Simply make that contact and it could be a highly worthwhile encounter, particularly if your organization is highly segmented.
Plus, by participating in a new employee’s orientation, you get to interject that your organization takes quality seriously. You can educate the newcomers not only to the standards you expect, but also how to meet those expectations without trial and error. If this only stops the user from making five mistakes, a half hour or hour of your time at the outset will pay for itself in issues that don’t crop up later.
About the Author
Brian J. Noggle Brian J. Noggle has worked in quality assurance and technical writing for over a decade, working with a variety of software types and industries. He currently works as a freelance software testing consultant through his own company, Jeracor Group LLC and has recently published a novel set in the IT world, John Donnelly’s Gold.