What’s The Difference?

Quality Assurance and Quality Control are often used interchangeably. Many development teams have one or two members designated as “testers” or “QA/QC.” Unfortunately, this is a symptom not knowing the difference between Quality Assurance and Quality Control. Most likely, these teams have a consistent bottleneck between development and testing activities. This causes frustration with the customer because they’re only getting new functionality delivered every few months vs. after each iteration.

Quality Assurance – It’s Everyone’s Responsibility

Quality Assurance are the processes and activities that ensure something is built well. This means it’s something everyone practices. Test-driven development (TDD) is an example of “baking in quality.” Instead of creating something and then testing it, we test and build at the same time.

I like to think of quality assurance like safety in a factory. A factory may have a “safety officer” who’s in charge of the overall program, but safety is everyone’s responsibility. It’s not the job of the safety officer to make sure you’re not misusing any equipment; the safety officer is charged with teaching practices about safety and creating a culture of safe practices. This is because the safety officer can’t be everywhere at once. Instead, it’s everyone’s responsibility to enforce safety and call out violations when they see them. It’s not to punish or harass, but to save lives and save the company from liability.

The same goes for your QA people. They shouldn’t sit over the shoulder of developers like hawks, inspecting every line of code. They don’t have the bandwidth or technical knowledge to carry out that task — and it’s not effective either. Instead, QA should be inspiring a culture of quality and encouraging creativity. QA should be helping with process improvement and identifying ways to remove waste and promote quality.

They shouldn’t sit over the shoulder of developers like hawks, inspecting every line of code. They don’t have the bandwidth or technical knowledge to carry out that task — and it’s not effective either.

Quality Control – Marking The Checkbox

Where Quality Assurance relates to “how” the software was made and making it everyone’s responsibility, Quality Control is the activities related to formally documenting and inspecting the product. This is where standardized documentation can help. Use just enough documentation as it makes sense, to ensure conformity to the

inspect — Inspect and test at the same time. Photo Credit

specifications of the client. This can be baked into the quality assurance process as well. Returning to our example of test-driven development, once a component is complete, saving the results of the unit test can be used as evidence of functionality. The combination of multiple components and testing their functionality is an integration test. Again, saving these results is evidence of interoperability via integration testing. Pushing new code into the existing code set and examining how the system reacts is called regression testing and we can save these results as well. I think you’re starting to get the idea though

Thanks for taking the time to read. I’d love to hear your thoughts on quality management. If you’d like to have a discussion, leave a comment below or contact me. I’d love to connect on social media as well!

Photo Credit: Pixabay

Quality Is Anti-Fragile

The People And Process Balancing Act

Improving Agile Retrospectives With SMART Goals

Quality Systems Are Anti-Fragile

So what’s quality? It’s one of those things we know we need. But, what are we talking about when we say, “bake in the quality?” There’s so many definitions that exist today, but I like to think of quality as “anti-fragile.”

What do I mean by “anti-fragile.” It’s a concept developed by Professor Nissim Nicholas Taleb in his book called Antifragile. He describes “systems,” whether those systems are processes, organizations, software, or even cultures, that can withstand the stresses of the environment which act upon them. Anti-fragile is much more than “resilient,” meaning it stays the same despite what the environment throws at it. In software development, we strive to produce more with less effort. We strive for business agility. We pivot and adjust our processes as the environment throws things at us and we are anti-fragile. We use feedback loops, like retrospectives, Six Sigma, and Continual Integration.

We give developers freedom and autonomy by giving them “what” needs to be done, they tell us the “how.” Antifragile means being adaptive. Selection of the right tools and technology for the right job — versus prescriptive.

Anti-Fragile As An Analogy

Professor Taleb uses a great analogy in his book. He asks you to picture something in your home that you’d consider “anti-fragile.” This might be something like the remote control for your television or even your sofa. Of course they can break, right? But, they’re designed to take a bit of punishment. They’re designed to conform and adapt as they are used — they are serving a function and withstanding inputs from the environment. In fact, your sofa tends to feel more comfortable over time as it conforms to your body.

Now picture something in your home that you’d consider “fragile.” This might be something like your grandmother’s china or an ancient grandfather clock. They’re usually tucked away in the safest part of the house and are rarely touched. Why? Because we’re afraid we’ll break them. They’re designed to be aesthetically pleasing — serving a function and withstanding stresses from the environment were not considered in their design. These objects are fragile and saved for “the special occasion.”

Beauty In The Anti-Fragile

So what approach should we take to software development? Should we design something that’s large and complex but liable to break whenever a code commit is pushed? When there’s a tight schedule, should we spend our effort designing something beautiful to the eye but doesn’t serve our purposes? No, we shouldn’t.

I contend that there’s beauty in software when it just works. There’s beauty in software when it serves our users and solves their problems. There’s beauty in software when it gets better over time — not when it falls apart.

Thanks for taking the time to read. I’d love to hear your thoughts on quality or anti-fragile. If you’d like to have a discussion, leave a comment below or contact me. I’d love to connect on social media as well!

jeremy brien

If you're in complete control, you're probably not going fast enough

Quality

The Difference Between QA & QC