DEV vs QA: A Conversation about Quality

Yesterday the Ministry of Testing - Boston held its first dinner-and-discussion event, a "Lean Coffee" at John Harvard's Brewhouse in Harvard Square. The discussion was centered on automation. How can we tell if automation is improving quality? What is your favorite automation tool? How can we get training? Most of us were new to automation -- until the past few years, coding knowledge wasn't really a requirement, so it was good to be able to network with one another and talk about the problems we were currently facing as we navigated this brave new world.

One question kept coming up that we couldn't quite answer ... how do coders measure quality?

A working definition of quality I have had since grad school:  To meet or exceed the expectation of the stakeholders, from the project manager (on time, on budget), to the customers using the product (intuitive design, good user experience).

Are you a software engineer? What metrics do you use to measure the quality of your code, your project, and your team?

... In spite of holding a BSCS / Theater Minor and Masters of Software Engineering, I have only been coding on-the-job for the past two years. From what I have seen, when a software developer thinks about of "quality", they may first think of the quality of the code:

• Is the code as readable as it can be? (See Uncle Bob Martin's Clean Code)
• Is the code as refactored as it can be? (see Martin Fowler's Refactoring)
• Is the code written as simply and efficiently as it can be?
• Are there unit tests and integration tests set up? Are they run before checking in code into the master branch? Do the tests all still pass? 
• If creating a web app, how does it look in the bare minimum of browsers and platforms: Chrome, Firefox, and Safari for the Mac? 

When a QA Engineer thinks about quality, they first think about the quality of the end-user experience, and the quality built into the software development process:

• Who are the people using this product? What are the different levels of the customer base?
• How are they using this product? Test all major browsers, platforms, or mobile devices they will use!
• Are the requirements testable? Are there acceptance criteria listed that indicate the "definition of done"?
• Are there any assumptions that need to be spelled out in the requirement? Is DEV and QA on the same page on what the product should be?
• How are the quality of the tests? Do they match the requirements? All of them? Have they been peer reviewed? Have you looped in the rest of the team: Product owner, DEV, user experience and checked to see if there is anything missing? 

To me, the relationship of DEV and QA shouldn't be the relationship between an artist and an art critic. Instead, it should be like that of a writer and a copyeditor, both working together to create a quality product. 

Software development is a partnership of DEV and QA. With DEV focused on the bottom up, from the code to the UI, and QA focused from the User Interface on down, the team can increase its chances to create a quality product.

Now that QA Engineers are expected to code, they now have to do double duty, incorporating both the DEV and QA definition of quality into their work. 

Are you a QA Engineer? Are you a Software Engineer? What does quality mean to you? Write your comments below! 

Happy Testing!

-T.J. Maher
Twitter | LinkedIn | GitHub

// Sr. QA Engineer, Software Engineer in Test, Software Tester since 1996.
// Contributing Writer for TechBeacon.
// "Looking to move away from manual QA? Follow Adventures in Automation on Facebook!"