When I started my journey as a software tester I felt that quality was all about my ability to find the bugs in the software I was testing. I was very fortunate that some of the first developers I worked with took a healthy view on testing and were always very pleased to have problems found before they made it to the wild.

I started to write this post 9 months ago in September 2019 when the world was a very different place. Looking back today at the midpoint of 2020 provides me a chance to reflect on whether the last few months dealing with Covid-19, crashing economies, working from home and #BlackLivesMatter have changed my views at all.

The first hard thing: Defining software quality

Even Wikipedia struggles to setttle on a single approach to defining software quality, listing a least eight. I am minded however to go along with the late Gerald Weinberg‘s simple assertion:

“Quality is value to some person.”

Gerald Weinberg: Quality Software Management

The best architected and written code does not provide value, to the business or to society if is does not provide value to its prospective users.

Who is responsible for bugs / quality?

Some time ago, I remember an exchange on Twitter with a developer who felt that any bug making it through to a release was far more painful for developers than for the testers / qa working with him. I found this orthogonal to the pride that every tester that I have ever worked alongside in our passion to ensure quality in releases.

Huh! How can both views be true?

This really emphasised for me the importance of quality throughout the software lifecycle:

• Involvement of testers from the specification stage
• A culture of quality in the engineering team
• Testing as an embedded part of the development process
• A healthy mix of automated regression tests and exploratory testing.

This brought me to two of my fundamental beliefs in Quality Management:

• There can be no them and us: test specialists and developers should be on the same teams in the same sprints working towards the same commitments
• Every piece of functionality should be checked in a deployed environment by someone who did not develop it. (“Works on my machine” does not mean it is quality)

Note:

I am not directly stating that a specialist tester should be in every team, but whether a specialist is there or not, testing and quality is the responsibility of everyone in the team.

But the problem with this approach is:

“Ownership of quality by the engineering team is essential, but not enough”

Alexander Dunn – 2018

The reality is that there are many factors outside of the control of the development team that have a greater influence on quality than anything that the development team can do.

A few examples that lead to technical debt:

• Fixed deadline, fixed scope projects.
• Last minute ‘must have’ feature additions.
• Failure to plan for, and stick to a feature freeze.
• Lowering the quality bar to meet release schedules – we don’t have time to do it right, so we’ll go live with ‘something’ and do it properly when people start using it.
• Continual context switching for support, demos or side projects.

And a few that develop features that add little value to the business:

• Building the wrong feature.
• Not prioritising user (or consuming developer) experience.
• Sales or marketing promising features that don’t exist, or setting unrealistic timescales on the release of intended features.
• Failure to tie down contractual, legal or regulatory requirements before development begins.

The problem is that all of these risk significant costs to the business: immediate, longer term and often most importantly to the quality of relationships within the company.

Technical debt has to be paid back someday. The longer you try to avoid paying it, the greater the payback costs. This is often worst as it can be hard to explain the business value of dealing with it.

No I am not just bashing commercial teams

My point is not to blame non engineers. The best engineers in the world cannot make a sustainable business without people to sell and monetise their work. Few engineers fancy doing that themselves I can assure you.

My point is that quality can only be maximised where the entire business is working together to enable it:

• Business stakeholders are in the loop enough to identify that a partially developed feature has a flaw before it is ‘completed.’
• Engineers are realistic in estimates.
• Business stakeholders understand that if a deadline is fixed, scope cannot be. (Throwing more people at a software problem is rarely a solution and often makes things worse.)
• Engineering gives fair warning when delivery on time is at risk.
• Sales people only offer what already exists, or have a clearly defined road-map and delivery target.
• 1st line support / the person who answers the phone is listened to when explaining customer pain points.

Quality is a team sport.

Alexander Oliveira Dunn – 2019

If you want to really lead quality, everyone from the CEO to the receptionist have to be working together.

Looking Back:

Working in the Aviation industry: One that has been so devastated over the last few months have been incredibly tough. Reflecting on my experiences during this time however has reminded go back to basics and the Principles behind the Agile Manifesto.

In particular:

Business people and developers must work together daily throughout the project.

Principles behind the Agile Manifesto

An efficient User Experience is a key part of providing value to your customers. You simply cannot expect to get things right first time without user feedback

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Principles behind the Agile Manifesto

This is something that I guess has become much more difficult in a world where everyone is working away in their own homes. Getting the balance between the efficient use of face to face conversations to share information, and the distractions that this can cause is challenging.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Principles behind the Agile Manifesto

Again, Covid-19 and working from home make it far harder to access and even ask for support when it is needed.

TLDR

• At a time when most of us are working away siloed in our own homes, the team is every bit as important as ever
• Remember to keep face to face contact with your team and look after yourself, ask for support when you need it
• The key to quality is in being agile, you can’t build a great User Experience without consulting your users

A reminder:

If you want to ask me a question, Twitter is undoubtedly the fastest place to get a response: My Username is @AlexanderOnTest so I am easy to find. My DMs are always open for questions, and I publicise my new blog posts there too.

If you find my posts interesting:

With conferences and real world meetups on hold, if you feel that your company or virtual meetup might like my input please feel free to get in touch. I am always open to interesting offers if I can find the time.