Mindset Shifts For Engineers to Achieve Higher Software Quality

A very special thanks to Jeffrey Fredrick and Peter Zsoldos for their careful and insightful review of this article.

Fresh out of university as a junior engineer, I was eager to learn as many tools and programming languages as I could. It’s a common feeling when you’re new to engineering — you want to build things and see them work. This excitement of bringing something to life is often what drives us early in our careers. I was no different and spent most of my time doing just that. However, I often wondered why my more experienced colleagues seemed more interested in finding better ways to work than learning the latest, hottest technology. Now, having journeyed through a span of 12 years in my career, I understand their perspective. And here I am, writing my article about how changing our mindset can make a bigger difference in our projects than learning countless programming languages.

This article is about changing how we think as software engineers. It’s about looking at the big picture — not just writing code, but delivering a product that makes customers happy. It’s about growing from just coding to creating products that people want and enjoy using. The following mindset shift ideas are presented as short, to-the-point sentences. Take your time to think about them. They require some reflection to fully understand.

Photo by Olav Ahrens Røtne on Unsplash

Let’s dive into the mindset shifts we should aim for in our work. We’ll denote the desirable mindset with 👍 and the mindset we need to distance ourselves from with 👎.

Which way of working?

Continuous Delivery 👍

• Software is always in a releasable state.
• Releases can happen at any given time, not restricted by schedules.
• QA is front and at the center of the development.
• Test early to avoid bugs and analyze the quality of the product.

Waterfalled Agile 👎

• The software needs effort to reach a releasable state.
• Releases are scheduled for specific dates or weeks, typically towards the end of the development cycle.
• Quality assurance (QA) comes into play predominantly at the end of the development process, closer to the release date.
• Test later aiming to find the bugs in already developed features.

When to test?

Start With Test 👍

• Start with the test to increase the predictability of the end result.
• Implement exploratory testing during the development phase.
• Development and testing cross the finish line at the same time.

Test Last 👎

• Testing is conducted at the tail-end of the process, right before deployment.
• There is a presumption that bugs might have been introduced during the development phase, and the goal of testing is to discover these.
• The traditional approach of ‘develop first, test later’ is followed.

Who holds the responsibility for quality?

Everyone is responsible for quality 👍

• Quality should be a priority from the outset, not just at the final stages. The entire team should have a quality-focused approach.
• Error detection is built into software creation. No QA bottleneck!
• Fewer resources can accomplish more.

Only QA team is responsible for quality 👎

• Quality is considered as the last line of defense, primarily handled by the QA team.
• There’s a higher risk of creating a QA bottleneck as the responsibility falls on a specific team.
• Higher and higher resources are needed to address the quality issues, which can be inefficient and costly.

When should delivery take place?

Deliver Faster and Smaller 👍

• Aim to deliver smaller chunks of code more frequently.
• Higher quality can be achieved by working in smaller, quick, definitive steps, which allow for easier monitoring and modification as changes are made.

Deliver Larger and Slow 👎

• Large amounts of code are delivered all at once.
• Validating the quality of the software becomes more challenging due to its large size, complicating error detection and resolution.

Quality Assurance or Quality Control?

QA over Quality Control 👍

• The emphasis lies on improving work efficiency and fostering unity within the team.
• Quality is always in mind when working on anything.
• A continuous feedback mechanism is in place to enhance the SDLC (Software Development Life Cycle) process.

Quality Control Only 👎

• The primary focus is on examining the final product.
• Quality concerns usually arise when problems or errors are detected.
• Feedback is typically received during the final stages of testing.

What does QA stand for?

QA as Quality Assistance 👍

• The QA team acts as an advisor throughout the entire development process.
• The emphasis is placed more on maintaining quality rather than just finding bugs.
• Bugs are easier and cheaper to fix.
• QA should not find bugs. When a bug is found, it is not only supposed to be fixed but the root cause should be investigated.
• Bug means there is a problem in the SDLC process, the process needs to be fixed.

QA as Release Gatekeeper 👎

• QA team is a tester and bug-finder.
• No room for quality improvement.
• Issues are more expensive and risky to fix.
• QA should find the bugs and then bugs should be fixed without further investigation.
• A bug is treated merely as a software issue, not as a process issue.

Conclusion

To wrap things up, it’s clear that elevating Quality Assurance from a bug-finding role to one of proactive quality assistance can profoundly impact the quality of our software products and the efficiency of our development processes. This mindset shift promotes an environment where QA acts as an advisor right from the start of development, fostering a proactive approach to maintaining quality. This shift not only mitigates the risk, cost, and effort associated with late-stage bug fixing, but also cultivates a culture of continuous improvement and shared responsibility for quality.

Moreover, redefining our view of bugs as process indicators, rather than mere software glitches, can be a game changer. Bugs are symptoms of deeper issues within our Software Development Life Cycle. Acknowledging this allows us to approach bug prevention more efficiently, leading to increased software quality and agility.

This mindset shift towards a more integrated approach to software development and quality assurance should not only help to deliver high-quality products but also enhance the agility of our teams, enabling them to respond swiftly and effectively to changing requirements and conditions.

As we move towards a culture where quality assurance is woven into every step of the process, and where bugs are seen as opportunities for process improvement rather than just software defects, the ultimate winners will be our customers, who receive superior software products, and our teams, who experience a more efficient and satisfying work process.

Your opinions?

I’d love to hear your thoughts on these proposed mindset shifts. How do you think these ideas would work in your own company? Do you have additional insights or experiences to share? Please join the conversation and let us know in the comments section below. Together, we can continue to learn from each other and elevate our craft.