One of the most important aspects of any team effort is communication. Even a baseball team has their own set of hand signals for pitchers, and phrases to yell when a pop fly is on the loose. The same principles are true for anyone working in software development – making sure everyone is using a shared language is of the utmost importance, especially for quality assurance. Though we may think of certain terms as being black and white, the truth is that too much is usually left to interpretation. Developing a shared language will only be successful if there are executive sponsors behind it and enforcing it. The executive sponsor – normally a CIO or CTO – needs to ensure all teams know why they’re doing the work and what an acceptable outcome looks like. Let’s take a look at how to lead a team to creating a shared definition for some common words and sayings in software quality assurance.
What Is Quality?
Think about how you use the word “quality” in everyday language. Does it always mean the same thing? Does a quality sandwich have the same characteristics as a house with quality construction? No, these terms are defined based off the intended usage of the item. The same goes for software quality. The executive sponsor knows why the work needs to be done with quality, but the rest of the team isn’t guaranteed to share their definitions and expectations. Before a team develops or tests code, or even installs off-the-shelf products, they need to understand the requirements for that application.
What is a Defect?
In general discussion, the word “defect” is used to describe any issue with a piece of software. It’s often used interchangeably with “bug,” or “error.” However, in modern agile methodology, the meaning is a bit more complex. Rather than being any problem with the software, it’s sometimes only considered a defect if the problem is uncovered after functionality has been approved by a Product Owner. However, if you have team members used to a waterfall method, they’re going to consider any coding error to be a defect. The truth is, some defects are acceptable for a product release if the impact is minimal. Having a shared understanding of what defects need fixing will prevent your team from wasting time on an unnecessary fix, as well as from releasing products with unacceptable defaults.
What Does “Done” Really Mean?
This is another term that may seem binary, but can have loads of different meanings based on your workflow. Waterfall methodology says that the project is done once it’s been analyzed, designed, coded, and tested. However, in an Agile workflow there are multiple components created during each step of a sprint. Because everything is being done with continuous integration and deployment, we use the concept Definition of Done to confirm whether something has been completed and is ready for delivery. Each task will have its own Definition of Done, meaning that the team could deliver something they think is finished when the Executive Sponsor knows it’s nowhere close.
Your team works best when everyone is working together. No matter how many team building exercises, outings, or pizza parties you have, if you’re lacking a shared language, you’re dead in the water. An Executive Sponsor must take the expectations they know about and use them to inform a shared language for every step of software development, integration, and deployment. Otherwise, you all might end up letting that pop fly to center turn into a loss in the ballgame.