We all need to be able to reevaluate issues and concepts. We have also all heard it said that adapting to change is harder for older people. Dr Joseph Juran is one of the significant figures in quality and he changed how he defined quality when he was over 95 years old.
In the third edition of his Quality Control Handbook, which was published in 1979, he defined quality as “fitness for use”. The fifth edition of the Handbook was published in 1999 and still used “fitness for use” as its definition of quality. In the sixth edition of his Quality Handbook, which was published in 2010, he changed his definition of quality to “fitness for purpose”.
Juran was born in 1904 and died in 2008. He was 95 years old when the fifth edition was published and it must have been after the publication of the fifth edition that he reasoned that “quality means fitness for use” was no longer applicable because “more and more service industries use the methods of managing for quality, the prior definition is not applicable enough” [1].
The new definition of quality is in the section called “How to think about quality” in the sixth edition of Juran’s Quality Handbook. This section is worth reading for its insights on understanding quality. The sixth edition of his Handbook was published in 2010 two years after his death at the age of 103, so Juran’s contributions to the Handbook were written when he was aged between 95 and 103.
Being mentally flexible is something to value. That Juran could reassess and redefine a core concept when he was over 95 years old should make us think that we all should be able to reassess and redefine important issues and concepts such as quality and also that age is not a barrier to mental flexibility.
“Architect of Quality”[1] is the autobiography of Dr Joseph Juran. Juran’s autobiography is the moving story of a Romanian immigrant to the USA who rose from poverty to being a world leader in quality and receiving honours from the Emperor of Japan and the President of the USA. Those of us who work in quality have much to learn from him.
Juran worked at Bell Telephones Hawthorne works at the same time as Walter Shewhart was working there and while W. Edwards Deming was an intern there. That three of the giants of quality were working at the same plant at the same time has always seemed remarkable to me. I learned from “Architect of Quality” that this occurred when Bell Telephones were building the first national telephone system for the United States of America. Bell Telephones Hawthorne plant would, at that time, have been the electronics hub for the USA. It would seem that these three giants all came to work at the plant due to the scale of the engineering task that Bell Telephones were undertaking.
Bell Telephones used statistics to develop their systems. Juran describes how Walter Shewhart invented Control Charts at Bell Telephones as a way to improve quality and how the use of statistics at Bell Telephones led to the creation of Statistical Quality Control.
Juran found his knowledge of mathematics extremely valuable in several different ways. There is an entertaining section in the book where he describes how he used his knowledge of mathematics to win on roulette tables that were run by Al Capone.
Writing was important to Juran and he describes how he came to start to write editions of Juran’s Quality Control Handbook. The Handbook is a reference book for all who are involved in quality, and each edition of the Handbook has sold tens of thousands of copies. I have three editions of the Handbook and find them to be useful books to consult when I want to consider an issue more deeply.
He, along with W. Edwards Deming, helped to rebuild the Japanese economy after World War Two and in his autobiography he describes the lectures and courses he gave in Japan. He also writes about Deming’s work in Japan. Lloyd Dobyns and Clare Crawford-Mason’s overview of Juran and Deming’s work is more valuable because it is written from the viewpoint of a third party who is trying to understand the work of the two men[2].
Universal methods were something that interested Juran. This interest came from his knowledge of mathematics. He describes how this led to him creating universal methods in management planning and control.
If you work in “quality” then I would recommend this book to you and would also recommend exploring Juran’s work.
Quality metrics can be like measuring the wobble on spinning plates.
The engineering teams are merging to the main branch, code is being deployed and you need metrics to show if there are issues with this process that require your attention. The teams working are rather like spinning plates. The teams are working and management needs to know if something is going wrong that they need to address. You can see that the plates are spinning and wobbling. You need to know if the plate is wobbling too much and will fall. If it is going to fall then you need to intervene.
Walter Shewhart created control charts to solve this problem at Bell Telephones. He saw variations in how the telephone production line worked and wanted a method to show when he needed to intervene. He plotted the metric he wanted to measure on the chart and then used the standard deviation to calculate the Upper Control Limit and Lower Control Limits. If the curve went above the upper limit or below the lower limit he needed to intervene. If the chart remained between the upper and lower limits he did not need to intervene.
Control charts are now used in many industries and can help us in software engineering.
John Willis recently wrote in his blog about how he used control charts. He used them to track his teams’ deployments to help him understand whether the team was improving.
I had a friend who was testing the work of two teams. One team was releasing new features and moved from making monthly releases to continuous delivery. The other team made monthly releases and needed developers to work extra hours to fix bugs when a release was made. In order to find out the difference between the two teams my friend decided to use control charts to analyse the work the two teams were doing. He created control charts that showed the number of unit tests added by each team each week. He found that the team practising continuous deployment created a fairly consistent number of unit tests each week and the curve on its chart was between the upper and lower limits. The chart for the team making monthly releases was quite different. There were weeks when the team making monthly releases added unit tests, there were also weeks when the team deleted unit tests and there were weeks the number of unit tests did not change. The curve on their chart often went below the lower limit. The control charts showed that a difference between the two teams was that the team practising continuous delivery were writing unit tests every week and the team making monthly releases frequently were not writing unit tests. The charts helped my friend to understand what was happening; the team that was making monthly releases were not writing unit tests. The understanding gained from the control charts enabled my friend to start a conversation with management about the team making monthly releases.
Control charts are a useful tool that can help us understand quality. If the ‘wobble’ on a spinning plate is within the lower and upper limits you do not intervene. You only need to intervene if the ‘wobble’ goes outside the lower and upper limits.
Thank you to Krizia Cureg and Nick Smith for the conversation that led to this blog post.
I use the Five S’s to create a disciplined structure that helps me create and maintain automated tests. Mary and Tom Poppendiek recommend using the Five S’s to create the discipline necessary to develop quality software. They wrote that “the five S’s are a classic lean tool to organise a workspace” [1].
Mary and Tom Poppendiek describe the Five S’s by translating the original Japanese words into English and give examples of using each of the S’s in the kitchen, in the workplace and for a java development project. I have taken their idea and created a table showing the translation of the Japanese words and examples of using the Five S’s in the kitchen, workplace and test automation.
Japanese
English
Kitchen
Workspace
Test Automation
Seiri
Sort
Sort through kitchen tools and throw away any unused tools.
Sort through the servers, and find old files that will never be used. Delete or back them up.
Remove dead code, unused imports, and unused methods.
Seiton
Systemise
Find a place for everything and make it easy to find.
Craft desktop layouts and file structures so that things are easy to find
Organise projects and packages so that everything is easy to find.
Seiso
Shine
Clean the kitchen.
Clean whiteboards and desktops.
Resolve TODOs and improve performance.
Seiketsu
Standardise
Fill and run the dishwasher every night
Put automation and standards in place.
Reduce complexity and improve ease of maintenance.
Shitsuke
Sustain
Keep up the discipline
Keep up the discipline.
Use and follow standard procedures.
I am sure that you can think of additional examples of how to use each of the S’s to aid your test automation.
Test Automation is software development and benefits from the disciplines that are used in software development. The Five S’s can help improve test automation that uses test frameworks such as Selenium and Playwright. They also can help automation projects that use low code tools such as Ghost Inspector.
I have found that sustain is the most important of the Five S’s because if you do not sustain the standards and practices that you have created with the other four S’s you can not improve. Sustaining standards and practices is a practice where value is gained.
My thinking about how to automate tests and maintain the tests has been shaped by the Five S’s. This is because the Five S’s enable me to view the issues I encounter, such as how to maintain a library of functions, through a framework that helps me improve the tests.
The Five S’s help me keep my automated tests in a state where they are easy to maintain, have no flaky tests and are easy to read. I hope that the Five S’s can help you do the same.
I have recently automated some tests using Playwright. It is a free-to-use Node.js library created by Microsoft that is designed to be used to automate end-to-end testing.
Playwright supports chromium, WebKit and Firefox, and, by default, all tests are run on all three browsers. Tests can be run in headless mode. It supports, Java, .Net, JavaScript, TypeScript and Python. I am writing my tests in TypeScript and have used FrontendMasters TypeScript Fundamentals, v3 course to help me get up to speed with TypeScript.
Its first-party test runner is Playwright Test, although a number of test runners such as Jest\Jasmine and mocha can be used. Playwright Test feels familiar because it has describe blocks skip and other familiar functionality.
There are good resources for learning Playwright, which include free courses provided by both LambdaTest and Test Automation University.
One of Playwright’s strengths is its support for iframes. Playwright contains functionality that enables tests to interact with elements inside an iframe, giving it an advantage over many test automation frameworks. To explore how to test elements inside an iframe you can use Jonathan Thompson‘s blog post about how to use Playwrights support for iframes[1]. You can use `frame.getAttribute` and `frame.$$` to get the values of attributes in elements within an iframe, which helped my test automation. It is really helpful that you can wait for events inside an iframe, for example with frame.waitForFunction().
Playwright has good easy-to-use documentation, however, you may not find what you are looking for. If you can’t find the item you want in Playwrights documentation, search in google for it. I wanted to find a way to have some tolerance for changes in screenshots. When I searched for tolerance in the documentation I found nothing, but when I searched for it in google I found the PR for the change that created the functionality I wanted. The PR gave me all the information I needed.
Playwright is a useful addition to your test automation tools.
Testers and developers can use the Deming Cycle to improve the quality of their testing. The Deming Cycle was initially used in the manufacture of telephones and has had a big influence on software development. The cycle has four steps:
Plan – plan what you are going to do
Do – execute the planned work
Study – what went well, what went wrong, what did you learn?
Act – act on what you have learned and take this learning into the next planning step
The cycle should be repeated with the knowledge accumulated.
The Deming Cycle can be described as a flow diagram and the Deming Cycle is shown in the flow diagram above.
This cycle is used by testers and developers in their testing for example in TDD and in exploratory testing.
An example of using the Deming Cycle in testing is Test Driven Development (TDD). Adam Hawkins Small Batches podcast has an episode about the cycle[1], during the episode he describes how the Deming Cycle is used every day in TDD. He describes TDD’s use of the cycle as:
Plan – write the test
Do – write the code
Check – did the test pass?
Act – green tests refactor, red test repeat loop
How TDD uses the Deming Cycle is shown in the flow diagram below:
Elisabeth Hendrickson’s Test Heuristics sheet[2] includes “Demings Cycle” in its list of resources for testing. She is known for her book “Explore It!” about exploratory testing and it is useful to look at how exploratory testing uses the Deming Cycle:
Plan – write a test charter
Do – execute a test
Study – analyse the result of the test
Act – act on the result of the test, maybe raise a bug card, re-run the test or make another test
How exploratory testing uses the Deming Cycle is shown in the flow diagram below:
Deming was keen that the cycle was understood as plan-do-study-act and not plan-do-check-act. One of the reasons for this was that if you only checked what had been done you might miss something[3]. The study part of the cycle is important because we need to consider what we have learned from the test before we can decide on our next action. It is also important that we are given time to think about the result of the test, this is because which other tests we execute and how we report on the test depend on how we understand the result of the test.
The Deming Cycle can help us improve our testing because it enables us to study and learn from each test we make.
Creating your first performance test can seem daunting, but it need not be so. This blog post is a guide to resources that you can use to create a simple automated performance test.
A good tool to use to create a performance test is Puppeteer. Puppeteer is a node.js library that can be used to automate chrome. There is good documentation for puppeteer both on its website and helpful posts on discussion groups and other websites such as stackoverflow. There is no need to buy a load testing tool as puppeteer can be downloaded for free.
Puppeteer is a node library so if you have not already done so, you will need to install Node. Node can be downloaded from here: https://nodejs.org/en/download/
Puppeteer contains functions such as await page.click and page.waitForSelector which you can use to create an automated test. You should use puppeteer to automate the steps that you want a performance test for. You could use the puppeteer example of a functional test on GitHub to help you automate these steps, and you could also use the tutorials on https://pptr.dev/ to help you.
Once you have automated the steps that you want to test for performance, you then need to add code to the test that will give you a timing for the steps that you are interested in.
For a simple test you can also get the start time and end time of the steps in the test by using new Date() to create timestamps and then calculate the difference between the two timestamps to show how long the steps took:
let beginTime = new Date();
// steps for the test
let endTime = new Date();
let duration = endTime.getTime() – beginTime.getTime();
The node app that you have created with puppeteer can be deployed to the platform that your team uses and scheduled to run however often you require.
You will want to share the results of the performance tests. You can write the results of the performance tests to a Geckoboard dataset and this enables you to create a dashboard to display the results of the tests. Geckoboard dashboards can contain a range of visualisations and can be sent to either a Slack channel or an email address on a schedule or displayed on a TV.
Creating an automated performance test creates data that enables you to ask questions about why the performance of your application is as it is and explore further the performance of your application. I hope that this blog post helps you to create a performance test and explore the performance of the application that you are testing.
I have just been the Programme Secretary for BCS SIGiST’s conference “Testing, Diversity, AI”, and it seems useful to share some of my thoughts on organising the conference.
Firstly it was a rewarding thing to do. I have worked in testing for twenty years and it was good to give something back to the testing community. It was great to give a platform to testing professionals who want to speak at a conference. It was great to hear so many fantastic speakers. I also learned about publicity, conference organisation, and met great people through being Programme Secretary.
Networking is an important part of attending a conference. It was important to make time in the conference schedule for networking as it was good to network with attendees and speakers at the conference.
It is important that the speakers are representative of the population. I had aimed to have 50% women speakers and missed that target on the in-person stream. Next time I am Programme Secretary for a conference I will view 50% of the speakers’ places as for women and will only fill those places with women speakers.
It helped to have themes for the conference as this grouped talks, signalled to attendees what they would hear at the conference and helped publicity.
You should avoid clashing with other testing conferences as we are all trying to help the testing community and no one gains from two conferences happening at the same time.
Don’t get downhearted if things go wrong and obstacles appear, with your team you can overcome these issues. Due to the Queen’s funeral, we had to reschedule the conference, which had eighteen speakers across two streams, and we did so successfully.
The British Computer Society is a not-for-profit and its Specialist Interest Group in Testing is run by volunteers like myself. It was great to work together as a team to organise the event. My membership of The British Computer Society is really useful as it enables me to connect with so many people from across the tech sector, such as those I worked with to organise the conference: Kerry Wear, Nicola Martin, Adam Leon Smith, Jonathan Wright, Paul Mowat, and Andy Shaw. I would encourage you to join BCS too: https://www.bcs.org/membership-and-registrations/become-a-member/
The conference went well and I enjoyed the presentations and conversations.
I also have to say a big thank you to all the speakers, and to the BCS staff who helped put on the conference.
The main lesson learned was that being the Programme Secretary for a testing conference was a really positive experience!
If we want to make good quality software we need to remove barriers to good work.
Dr Deming‘s 14 Points for management were the basis for lessons for top management in Japan. Dr Deming said that “the 14 Points apply anywhere, to small organisations as well as to large organisations[1]”. Point 12 is to “remove barriers that rob people of pride of workmanship”. I would reword this point to be that “we need to remove barriers to good work”.
He believed that employees being able to take pride in good work improved staff retention, and improved the quality of the products being created.
One of the things that Deming described[1] as a barrier to good work was that employees can sometimes be made to feel like a commodity. He also wrote about how employees complained about being required to ship products that they knew were substandard. He was writing about employees who worked in factories. From reading testers what testers write on Twitter and LinkedIn I can see that, from time to time, these issues still occur in software development today.
Silos within companies that stop one group of employees from knowing about another group of employees’ work can lead to one team’s work creating problems for another team. Good teamwork across the company is another way to remove barriers to good work as teamwork will break down silos.
The annual merit rating was also something that Deming saw as a barrier to good work. He said that it “builds fear”[1]. Managers should be working to support and develop their staff rather than judging them once a year. Dr Deming recommended the work of Peter R. Scholtes as an alternative to performance appraisals.
There are other barriers to good work. In order to remove barriers to good work we need to support inclusion and diversity. Two examples of how lack of diversity creates a barrier to good work would be: if we work in teams that do not include women engineers then those teams are missing out on working with some fantastic engineers, and if teams are working with women engineers who do not feel that they are listened to then those teams are missing out on great engineering skills. I am pleased to say that where I work we actively address this issue.
Cause-effect diagrams are a useful technique that can be used to improve quality. Glenford J. Myers wrote that “a weakness of boundary value analysis and equivalence partitions is that they do not explore combinations of input circumstances”[1]. A technique that can be used to explore and describe combinations of inputs to an issue is a cause-effect diagram.
A type of cause-effect graph I have found useful is the Ishikawa or Fishbone Diagram. The diagram takes its name from Professor Kaoru Ishikawa who invented the diagram[2]. It is also known as a fishbone diagram because it looks like a fish’s bones. An example diagram is shown above. The effect that you are concerned about is shown in the diagram on the fish’s head. The effect shown in the diagram could be a bug or a production incident that you want to analyse. The causes of the effect are shown on the fish bones, and sub-causes are shown as branches of the fish bones.
The diagrams were named Ishikawa Diagrams by Joseph Juran [3], and are an example of how he and W. Edwards Deming brought ideas from Japan to North America and Europe.
Ishikawa categorised the causes of the issue, that is being analysed, into five groups called the Five Ms:
Material. Everything that is consumed by the project such as raw materials.
Method. Existing procedures and information flow.
Mother Nature. The environment and context.
Machine. The necessary equipment for the project.
(Hu)manpower. The human resources involved in the project.
An Ishikawa diagram can be used to find the root cause of a production incident or another complex issue. A root cause of the effect being analysed should be written on a bone in the diagram, and each root cause should also be analysed to find its root cause. The root cause of one of the causes should be written as a branch to the bone.
Ishikawa diagrams can be used to improve quality as they can be used to identify the causes of an issue, and countermeasures can then be identified to remove the causes of the issue.
The diagram may be created when you are working with a team or when you are working alone. The team can create a diagram by suggesting causes which are then added to the diagram. To help find the causes of the effect being analysed, the Five Ms can be used as prompts to consider the factors they represent. An example would be to consider material, this could be used to consider all the third-party components used and (Hu)manpower could be used to consider what training people working on the project have had and need.
An advantage of using an Ishikawa diagram is that it is visual and so it is easy to review by looking over the causes identified on the diagram. This can make it easy to work iteratively on finding the causes of an issue. The diagram is easy to share as it is one diagram rather than a long document. Another advantage is that there is also no need for notes that have to be written up after a team creates a diagram as the diagram explains itself.
Two disadvantages of Ishikawa diagrams are that they can be unfamiliar and may not look like diagrams that people are used to using. The success of teams and individuals, who have not used Ishikawa diagrams previously, relies on their wanting to learn how to use fishbone diagrams. If you want the team to use Ishikawa diagrams then it is your role to persuade them to do so.
Learning how to use an Ishikawa diagram is a useful skill. If a team or individual learns how to use Ishikawa diagrams, they will likely use them again later in their career. Ishikawa created fishbone diagrams in 1943[2], so they have been in use for a long time and it is reasonable to expect them to be used for the foreseeable future. Fishbone diagrams are useful and are used widely. Janet Gregory and Lisa Crispin suggest using Ishikawa diagrams to visualise your way of thinking and to help with identifying risks[5]. Masaaki Imai lists fishbone diagrams as one of the Seven Statistical Tools involved in Kaizen problem-solving[4].
There are many templates available for creating Ishikawa diagrams, to find them just google “Ishikawa diagram templates”. You should be able to find a template for an application that you use.
It would be great to hear of your experiences of using Ishikawa diagrams to improve quality
How a company responds to a complaint about quality needs careful consideration. A model that we can use to explore this issue is Dr Deming’s Red Beads Experiment. We can extend the Red Beads Experiment to include a complaint from customers. I explored the Red Beads Experiment in a previous blog post The blog post explained the steps in the experiment and the effect of the experiment on testers and quality.
In the Red Beads Experiment, the White Beads Company makes white beads and struggles to reduce the number of red beads in the white beads it sells. We can use the Red Beads Experiment to help us explore how to deal with complaints about quality by extending the Red Beads Experiment to include customers complaining to the White Beads Company’s Chief Executive about quality. The customers are unhappy with many red beads being delivered in their orders of white beads.
The White Beads Company holds its staff responsible for their performance in a process that they can not influence, so I would expect them to respond to customer complaints by blaming the staff. This will not help improve quality as the staff do not control the production process at the White Beads Company and cannot improve quality. Blaming the staff will also create an atmosphere of fear in the company which will make it harder to improve quality. If there is fear in the company people will not answer questions honestly as they will want to protect their job and their friends’ jobs and so quality will not improve.
The White Beads Company should use Deming’s System of Profound Knowledge (SoPK) to improve quality. Deming wrote that SoPK “provides a map of theory by which to understand the organisation that we work in”[2]. SoPK has four components:
An appreciation for a system – systems thinking should be used to understand the problem and find a solution to it
Knowledge of variation – there will always be variation in quality, and the company must learn to understand it
Theory of knowledge – the company should develop a theory of what will happen in the future based on their actions to improve quality
Psychology – the White Beads Company should understand individuals and how individuals interact as this will have an effect on the quality of the company’s output.
An understanding of psychology and systems thinking will help the White Beads Company move from being a company where managers “find and record failures” to one where they “remove the causes of failure”[1].
The White Beads Company can use systems thinking to identify that the company and its suppliers are a system that makes white beads. It can then work to improve the quality of its white beads by working with its suppliers to improve the quality of the raw materials being supplied to the White Beads Company.
Knowledge of the number of red beads in the raw materials will enable the company to evaluate the success of its initiatives to improve quality.
Improving the quality of white beads by improving the quality of raw materials, rather than blaming the staff, will help the company to drive out fear from the company. This will help people to work more effectively. Working with suppliers will also break down barriers which will create teamwork that will improve quality.
The company should then implement this plan using the plan-do-study-act cycle; first, it would plan the initiative, then it would carry out the plan, next, it would study the results of the planned work, and then act on what it found by taking its findings into another plan-do-study-act cycle.
Using SoPK, and working iteratively with a plan-do-study-act cycle will enable the White Beads Company to improve the quality of its product.
Are there other useful ways to extend the Red Beads Experiment?
Note:
I wrote a longer post about the Red Beads Experiment for LambdaTest Blogs, and John Willis, one of the founders of DevOps, wrote a positive blog post in response to my post. He said in his post that Deming would be disappointed that people had not extended his Red Beads Experiment. This blog post is a suggestion on how to extend the experiment in a way that sheds light on how to deal with complaints from customers about quality and how Deming’s philosophy can help.
The Five Whys is a technique for finding the root cause of a problem. Toyota developed this technique and it is now widely used, including in software development. I was introduced to the Five Whys by Tom Gilb as part of a course he ran on Lean QA and have used the Five Whys in several places where I have worked. Testers want to improve quality, the Five Whys is a technique that improves quality so it is useful for testers to be able to use it.
The Toyota engineer Taiichi Ohno would ask why five times to find the root cause of a problem as this would enable him to create and implement appropriate countermeasures[1]. Asking why five times usually will find a “soft” issue as the cause of the problem, for example:
Why did the customer’s file fail to load in production? Because there was a bug in the loader
Why was there a bug in the loader? Because a feature branch that contained the bug was deployed to production
Why was the feature branch with the bug deployed to production? Because it passed all the automated tests
Why did the feature branch pass all the automated tests? Because the database used by the integration tests had not been updated
Why was the database not updated? Because there was no process to update the database
In this example, the root cause of the problem is that the database used by automated tests had not been kept updated. The countermeasure is to create a process that keeps the database updated.
The Five Whys can be used to find the root cause of a problem. The example above shows it being used to find why a bug was introduced into production, the technique can also be used to find the cause of an incident in production or it can be used to find the root causes of multiple problems such as when Toyota used the Five Whys to reduce the noise of the Lexus engine[2]. Teams should use the Five Whys to keep asking until the root cause(s) are identified. In one of the examples in The Toyota Way[2] why has been asked six times. When using the Five Whys you may find the root cause after asking why four times, five times or more times.
A development team can meet and work through the Five Whys together as a team. It can be useful to vary how the team uses the Five Whys and a team can also work through the Five Whys individually and then discuss their findings as a team.
Finding the root cause of a problem is a constructive way of dealing with problems that does not involve blame and so helps teams to grow. When using the Five Whys individuals can feel that they are having to admit to a mistake and find this difficult. In order to give people confidence, it can be hopeful to read the prime directive when starting a Five Whys meeting. When first using the Five Whys it can also be helpful if senior members of the team l say that they make mistakes as this can empower other members of the team. It can be unhelpful if senior managers want to join a Five Whys meeting as people may feel inhibited from talking about errors that have been made if a senior manager is present.
The Five Whys is a positive way of dealing with problems that can contribute to creating psychological safety because it enables team members find a way to deal with problems without blame. A blame culture prevents a team from finding the real issues behind problems as people will want to protect themselves and their friends. People who have been working in a blame culture can find using the Five Whys invigorating and empowering.
Once a team has found the root cause of a problem they should adopt a countermeasure so that the problem does not re-occur. Implementing a countermeasure to prevent a problem from reoccurring will improve quality.
I would be very interested to hear your experiences of using the Five Whys.
When we test we think about the users of the functionality and we include their needs in our testing. Creating categories of customers, such as internal and external, can help us understand our customers’ uses of the functionality.
Dr Joseph Juran advocated viewing customers as either internal or external customers. Juran was born in Romania and emigrated to the USA. He, like W. Edwards Deming, worked with Walter Shewhart and helped the Japanese economy recover from World War Two. He also taught quality control at New York University and worked with Steve Jobs.
Dr Juran said that identifying customers is the first step in planning for quality[1]. He defined a customer as “someone who is impacted by the product”. He also said that customers may be external or internal.
An external customer is a customer who is external to the company or organisation. They may be a paying client, government regulatory bodies, international regulatory bodies or the public.
Departments and people within a company often supply products to one another, these are internal customers. They are not customers in the traditional sense as they are not paying clients, but they are often called customers.
Juran recommends creating a flow diagram to help identify customers. The flow diagram can show the steps involved in the process and help identify customers[1].
He says that customers can also be divided into classes. If there are many customers the Pareto principle can be used to classify customers into the vital few and the trivial many as this helps you to focus your efforts where it will have the most impact.
It is important to consider how the functionality we are testing impacts internal customers as the functionality we are developing will impact others within the company. Examples of this would be that the functionality could create additional work for the customer service team if functionality is complex.Sales and marketing are also impacted by the features a team is working on and it is useful to view sales and marketing as customers so that they are kept informed of new features.
Juran’s way of looking at external customers is useful too as maybe a playing client uses your product to provide a service to someone else such as “the public”, and your testing can then also take that other person’s needs into account. The success of the application that you are testing may depend on the quality of the service being provided by your paying client to hi/her paying clients.
I find that this categorisation of customers is useful because it provides a structure that enables me to think about external customers like clients but also about internal customers like customer service.
TestAndAnalysis 