What does quality mean to your stakeholders?

Questions
#1

A really interesting conversation popped up on Slack last week talking about quality and the perceived presence or lack of quality in products. This spun off a really interesting thread asking:

what does quality mean to your stakeholders?

From bugs to cool features to usability, quality can mean different things to different people and sometimes it can be difficult to articulate what it means or find out what others think it means.

Do you know what quality means to your stakeholders? If not, do you know how you would approach finding out?

#2

in my current office, quality is about having automation scripts instead of manual. also, the impression is more automation is better.
It would be better to have goals ie defect containment in requirements phase, dev phase, testing phase e.t.c. because it gets more costly as the defect is found later phases in the project. Perhaps 0 critical defects leaked into the next phase

1 Like
#3

I hate to have to admit it, but in our company the definition of quality is TBD. This is because, alas, we have not got a clear document on same, not much beyond some soundbytes like ‘quality is paramount’. The reality is the pressure to deliver for customers means that quality is paramount, but delivery is, erm, paramount-er. :smiley:

This leaves me as a tester maybe a slightly uncomfortable position as I haven’t, for example, got a quality policy to use when making a case for fixing a defect. It also means that quality, rather like beauty, is in the eye of the beholder.

Having a quality policy is something I think it may be useful to have so will follow the thread with interest to see what others think, especially those with policies to see ow they help testers in their jobs


2 Likes
#4

Hi everyone
I want to appear for ISTQB foundation level exam. Can you please guide me from where to do the preparation. I am a fresher so this certificate will help me in getting my 1st job in Newzealand, so it is very important for me.
Thank you

#5

@aatisha there are quite a few posts on here to help you with preparation :slight_smile: https://club.ministryoftesting.com/search?q=ISTQB

#6

Quality means bug free output and no deviation from the expected behavior. Other than this there is no other alternative to quality. What is required is required by our client or stakeholder or end users. If there is any discrepancy in the product or any fault then the quality is failed. This is the job of a QA or tester to verify and validate various quality metrics and make the product or application as per standards.

In a software testing company , any application is tested from various point of view, for example, application functionality workflow, transactions flow, invoicing approval workflow, application security testing, UI, application performance under varying users or data load. So, if any of the factor is malfunctioned at user end then definitely user will not use it. Stakeholders also face the losses due to poor quality.

A STLC has defined parameters to make sure that the output is 100% as per expectation and there will be no flaw. Any lacking from QA perspective surely lead to capital loss, bad impression in the competitive market, and loss of project too.

Thus quality mean perfection with defect-free workflow to stakeholders.

I hope above notes will be explanatory of what quality means to stakeholders.

#7

vishaldutt Have you talked to, or worked with your stakeholders?

In one of my last positions we had about 5-6 stakeholders for our product, each of them holding a different position within the company: CEO, CTO/CIO, VPs of sales, marketing, or budget holders/presidents;
I’ve met most of them and worked directly with some.
Not each of them has equal power over the product, not all of them have the budget or the right people to lead. Someone’s request can be used as an opinion, other’s is treated like a demand.
Their desires are negotiated among themselves or with the development team / Product Manager/Owner and change with time, or with other aspects.

Again the quality demand is never static. Some examples of random requests at random times from some stakeholders:

  • the fast release of the basic feature that can help them or other departments improve their job;
  • a quick adjustment that they feel it’s urgent feature/bug;
  • fast delivery(with bugs incl.) of money bringing features - bugs can be dealt with later if they are not seriously impacting the customer;
  • a process that is based on their view of things(not necessarily useful);
  • reports of expenses, product progress, matching of the planning with the actual product releases;
  • no noise - they are happy when things go smoothly under them, and no disagreements appear constantly;
  • costs decrease - if you can build features or fix bugs that would help other departments - you get bonus points with some stakeholders; E.g. I managed to dig/find/evaluate/investigate/find-solutions for 3 years of bugs in the system(targeted a specific module) - and with help from the team we decreased the Call Center cost by about 1.5 persons;
  • little to no reports of major bugs in production from their friends or colleagues within the company; This doesn’t mean any bugs in production - we had hundreds, but always focus on what’s important and guess how that might impact a stakeholder;
  • as little as possible of money spent on things that you can’t explain the value of to the stakeholders in terms of revenue/profit; e.g. don’t fix all bugs, don’t do too much technical debt reduction, don’t add all the features requested, don’t spend too much time on a fancy solution;
  • a team that shines - makes little trouble, has a great outcome on a constant basis, listens to them, and tries to find solutions to their problems, responsive and polite;
#8

@ipstefan Yes, I have worked with some stakeholders and they play crucial role to propose new features. Our Stakeholders added a positive influence on the project. They have got some expectation and objectives which basically thrives the growth of the organization that provide functional testing services.

Yes, I agree not all stakeholders are easy to handle. Few things we followed to handle the same:

  1. Document the communications took place in stakeholders meeting.
  2. Make sure that process is transparent, so everyone knows what to expect. This includes project requests or feedback, and how you will document and respond to those requests needs to be subject to a formal process of review and approval.
  3. Provide status reports on what is achieved so far which will keep them updated about the project completion. Provide real time data so you’re stakeholders are always aware of the latest action.
#9

I have worked really closely with stakeholders and also with those that are just referred to as ‘the business’, but the best way of getting a picture of what quality means to a stakeholder in either situation is via the wonderful world of RiskStorming.

I cannot recommend it enough

It was one of the first things I introduced when I started my current role. Overwhelmingly the response from the dev team and stakeholders has been positive. The online version is a triumph as well!

1 Like
#10

Really agree with @christovskia on Risk Storming, it is a hugely beneficial activity which I am pushing to use in my current role.

I had an interesting discussion with some stakeholders recently about quality when they were trying to push a new initiative out. I posed it as this question:

Would you rather a bug free feature which no one uses or a buggy feature which the customers love?

This caused a debate for over an hour, initially, they all said the bug free feature, but then when i suggested that Quality is directly related to a customers satisfaction, they started to turn towards the buggy feature, this brought us to making sure the features are usable and accessible, more than having lots of “bells and whistles”.

So in answer to the original question, quality should mean something which brings customers back to use your system time and time again and not be directly correlating to number of defects left unfixed.

2 Likes
#11

Not just sometimes, but many times, it would be difficult for many people to articulate what Quality means to them :slight_smile:. Because it’s subjective and context-sensitive. Even within a product team, Quality would mean different things to different stakeholders, e.g. the Test managers, the Product Manager, the customer, and the Development Team.

The best thing would be talk to the different stakeholders, and try to prioritize the Quality requirements based on the order of importance. For example, the organizational Quality requirements will be the top priority - in terms of adhering to strict benchmarks and KPIs for their standard certifications, followed by the customers’ asks that are passed on through the Product Manager, followed by the Test organization’s priorities (typically service-based companies) having their metrics on the number and severity of defects, and so on. It’s tough to be all things to all people, so as a team, we would all agree to a few benchmarks and set our goals on them.

I hope that helps.

1 Like