TestAndAnalysis

The Quality Trilogy helps discussions with your team

We want to create quality features, products and services. Using a framework to think through how to achieve this is helpful as the framework ensures that vital points are covered. Testers can provide value by understanding these frameworks and using them to shape their own thinking in order to be able to prompt and/or lead discussions in their team that help to improve overall quality.

Joseph Juran was an American who helped Japan’s economy recover after World War 2 and later worked for companies such as Apple. He created The Quality Trilogy which is a framework that can be used for discussions with your team. The trilogy consists of:

Quality planning

This part of the trilogy can be described as designing the feature including the team understanding the customers needs. Quality planning helps me test because I want to understand the customer and for this reason I find it useful to have a discussion about what job the customer will be “hiring” the feature to do. It also helps to have a discussion at this early stage about what support for accessibility is appropriate for the new project.

Quality control

Tracking metrics and periodic checks are an important part of quality control because they tell us whether or not the feature we released is “working”. If there are no periodic checks in production that check that features are “working” then quality in production can fall without the company knowing. If quality in production falls this will affect customers who may leave or complain.

It is useful to discuss with the team how the new feature will be tested, including how we know the feature is working once it is deployed. Testing once the feature is deployed to production I think of this as “shift right” testing. As testers we need, not only, to “shift left” to identify issues before they become bugs and we also need to “shift right” to ensure that we know the feature continues to work after it is deployed. We need to ensure that the released product “is working” in production and continues to work in production. “Shift right” testing helps reduce the number of times a customer will surprise us by reporting bugs, reduces the time that bugs are live in production, enables us to plan fixes for bugs we find and will control quality by ensuring that the released feature “works”. If the discussion on testing does not happen then a new feature can be deployed to production that either does not work in production or starts to fail soon after it is deployed to production.

Quality improvement

Identifying areas where processes can be improved to improve quality is an important part of a team’s work. It is constructive to have a conversation about how the team could be improving quality, and it is also useful to have a conversation about what we can do to improve the quality of the new feature.

It is useful to have discussions within teams about quality and Juran’s Quality Trilogy gives a management framework in which we can have these discussions.

Thank you Jason Liggi for reviewing this blog entry

Further reading: Juran’s Quality Handbook

Testing Stories: Test Lead in an agile transformation

I am looking forward to speaking about my story in the ebook Testing Stories at the BCS SIGiST webinar on the 12th October because I want to show how Test Lead’s have an important role to play in making agile transformations successful. I will be speaking with three of the other testers who contributed stories to the ebook. We will all be speaking about the stories we contributed to the ebook. I am going to speak about the lessons learned from the transformation such as the importance of building relationships and that there is much to learn from change. During the transformation I found that the role of the tester can become more interesting and can contribute more value in an agile environment. Before the transformation the testers were in a separate test team which tested functionality to see if it “passed”. After the transformation the testers are part of a development team and work with their team to build quality into products. The testers role in an agile team is varied and I found that the role can be structured to enable the tester to gain and maintain a range of skills.

The premise of the ebook, Testing Stories, is that every tester has a story. Over 30 testers from around the world have each contributed a story to the book. All the stories are about testing and the subjects of the stories vary greatly from the story behind “Tester of the Day” to “My Journey Testing Internet networking Devices”. I am very pleased that my story “Test Lead in an agile transformation” was included in the book. The team that created the book was led by Melissa Fisher.

The book is available from lean publishing https://leanpub.com/testing_stories/ and the team decided that all proceeds of the book go to the mental health charity Open Sourcing Mental Illness (OSMI). The book has so far raised over $1000 for the charity.

Please buy the book,and please join me and the other authors, Andrea Jensen, Louise Woodhams and John McGee to hear our stories at the webinar. Book your place here: https://www.bcs.org/events/2021/october/webinar-testing-stories/

Added to the blog after the webinar:
You can now watch a video of the webinar: Webinar: Testing stories

Team Activities to Better Understand Your Customers and Team

We all need to understand our customers and the teams we are members of. Customers need to be understood as they keep the business alive. The team(s) we are members of need to be understood so that we can work with them to improve quality.

The best tool that I have found to understand customers is the Theory of Jobs to be Done. This is an innovation framework that asks what job did someone hire that product or service for? In “Competing against luck”[1] job is defined as “The progress that a person is trying to make in a particular circumstance”. Looking at the progress that a person is trying to make and the circumstances can help you understand your customers. It can help you and your team think of all the jobs that are done with the product or service that you are building. Jobs to be Done can be contrasted with personas. A persona describes the person, but does not give you the circumstance. I find the Theory of Jobs to be Done a useful way to focus on customers. and gave a presentation at SkillsMatter to share this.

In some ways teams are rather like families and I have recently found that the ideas of Victoria Satir are often referred to in books and articles I read. Katrina Clockie[2] and Lena Wiberg[3] both refer to the Satir Interaction Model. This model describes the process that happens internally when we communicate. Looking at the model can help us understand how our team communicates. Satir says that there are four steps:

Intake
Meaning
Significance
Response

Gerry Weinberg has pointed out that the first three steps all occur internally. It is useful to consider this in terms of remote communication. If we are with someone when we communicate with them we will see non visual signs of how they are reacting when the first three steps occur, but if we are remote we will only see their response. This is particularly important to consider when we are communicating bad news such as “I think I have just found a bug!” We won’t see the rest of the team’s non verbal communication while they are going through the first three steps, we will only see their response. It could be useful to discuss this model with your team to improve team communication and understanding.

I hope that these two ideas for activities are useful in helping you understand your customers and your team.

References:

[1] Competing Against Luck: The Story Of Innovation And Customer Choice by Clayton M. Christensen, Taddy Hall, Karen Dillon and David S. Duncan

[2] http://katrinatester.blogspot.com/2014/10/satir-interaction-model.html[3] Would Heu-Risk it? by Lena Wiberg

Introducing me

Hi, I have been working as a testing professional for twenty years and have been a member of a test team, a Test Lead and a lone tester. I have started this blog to share what I have learned and am learning about testing and quality.

I have automated tests with Playwright and carried out exploratory testing. I have also set up and led a Testing Community of Practice and been part of a successful agile transition.

I am Vice-Chair and Programme Secretary of the British Computer Society’s Specialist Interest Group in Software Testing. In this capacity, I help to organise software testing webinars and conferences.

I am one of the co-authors of the e-book “How Can I Test This?“. I also contributed to the e-book Testing Stories and have had articles published by the Ministry of Testing, LambdaTest, DZone and The QA Lead.

I have a B.Sc.(HONS) from Middlesex University and am an Associate of the University of Hertfordshire. I am also a Chartered Fellow of the British Computer Society.