A short story:
One man worked in a start-up, as a QA he is one of the people that represent the development team. On the side, he goes to Muay Thai sessions, mostly for fun and occasionally spars. He’d pursued different types of physical activities over the recent years, such as American Football and Basketball.
One day, he decided to try another sport, boxing. If you think this is a terrible idea, you’re right. He’s had multiple injuries over the past years, he is no longer 18, and he has less time. At the same time, plenty of other people have already been boxing training for years. You might be asking - Why change when you’re already good at something? Why become a smaller fish in a different market?
He knew he had to stand out somehow. But upon doing a bit of work, he realised that that even though plenty of people are doing one sport for their whole life, he didn't want that, he wanted to try out other things.
Over the past few days, he wondered “Why aren’t the bugs I’m reporting being fixed?”. One day, he decided to try another way of thinking about Bug Reporting, he thought “Quality Offer”. Terrible idea? Probably. The thing about bug reports are: everyone calls them bug reports, plenty of other people offer articles of the same thing of varying quality. Why change the words?
One man knew he had to stand out somehow. But upon doing some google searches and slap in some BING for that matter, he realised that even though plenty of people offer “How to write a good bug Report”. When you submit a bug report – what is the title? “Bug Report” – accurate but hardly exciting.
The Quality Offer – Improve the quality of your product
If you want to maintain and improve the quality of your product and know the status of your product– here it is.
I provide quality offers to:
- Busy Managers with a jam packed schedule
- Developers who just need to know what needs to be fixed
- Product Managers who want to know the progress of the project
- Wider Business Teams who have defined what a quality product means
Recognising that bug reporting is the main deliverable he had for getting attention of his stakeholders, he decided to take more ownership, defining what the minimum product quality is, make the bug his sales tool, and understand that he is what he writes.
When you are presenting a quality offer, you need to make sure to give people all the information they need. A complete offer includes (but not limited to) the following elements:
- The Light – how will this offer change someone’s life?
- The Reason – Why this should this be fixed?
- The Price – What are the disadvantages of letting this go?
The Light – should focus on the benefit people will receive from fixing the ‘issue’. This is your headline – You want to craft a short bold statement that will grab attention and makes the benefit to your stakeholders immediately clear. Imagine an advert “The best gummy bear in the world” compared to “Tasty Gummy Bears” – the difference is night and day. Here is another example, “Critical: Updating field in Part X, requirement X is not satisfied” Compared to “Updating field in Part X, requirement X is not satisfied".
The Reason – This should provide everything someone needs to know without getting too bogged down with the finger details, the key part is urgency. Answer the all-important question “Why should they take action now?”. These will include things such as agreed deliverables for the sprint, agreed deliverables for each stage of the lifecycle, the agreed specifications, and many more.
The main point is having a reason. In the next section, I will describe how to get something fixed without questions being asked with the use of the "MPQ"
The Price – The price should tell stakeholders or clients not only the details of the bug, it also includes what the cost is of inaction. Here is an example, you find a critical bug that does not allow you to go into further testing, you will write something along the lines of “Critical bug found, testing is halted”.
Here is an example of the light, the reason, and the price combined.
Bug: User interface inconsistencies
Offer: Improvement the usability of the interface will show our clients that we have attention to detail. Inconsistencies within the interface will downgrade the usability of the platform, drive up the costs of documentation (through constant reiteration), training (training the clients on how to use a product), and technical support. Note: We also have a sales demonstration at noon in 2 days, to present this project for a prospective client.
The Foundations of the Quality Offer
The tester provides a service. Your main service is to write clear and concise reports. Most importantly, he does not waste time as time is something that we cannot take back. Imagine you are in your room, you can’t be bothered to get out of bed (Me on a Sunday) to open your blinds. You shout out loud, giving an order to your little sister “Open the blinds”. Your little sister rushes downstairs to the living room and opens the blinds. Your sister shouts “The blinds are open!” Now you are thinking “I wasn’t specific enough with my request”. Yes, the blinds have been opened but not the one you wanted. To be effective – you need to report well.
A successful tester doesn’t just show people why they need to fix the bug; it also shows them why they need to be fixed as soon as possible. Below are 5 ways to consider when you are communicating your quality offer to the developer / triage team / manager.
#1 – Understand and know your mission
First of all, understand and know your mission. Your mission compared to mine, will differ. For some companies, the deliverables in a sprint might be completed test plans, updated support page, and metrics. Other companies, you may find that there is no need for much documentation, just one or two points to improve upon based on what happened on the sprint.
Below, I will describe some of the requirements that define my mission.
Once you have finished reading the list below, think what applies to you and what else?
- Find Important Bugs Fast
- Keep track of the quality of the product
- Certify that the product meets a minimum standard
- Assure test process stages have agreed deliverables with accountability
- Help improve the software development lifecycle
If you spend time and effort on requirements that your clients don’t care about or that will waste their time, you are being unproductive. Whenever you do something, agree on the deliverables by paper, otherwise, what are you meant to be doing?
#2 – No Matter how minor the bug, report it and push for it to be fixed.
Minor errors confuse your users and reduce confidence in the rest of the product. ‘Bugs’ considered spelling mistakes, minor screen formatting problems, no error messaging, graphs drawn not to scale, errors in the online help, and many more. In this study, They classed an issue as a “cheap fix” if it would take less than 4 hours to fix an issue. This might be a code change, a change to the support page, a change to the manual. Under this criterion, they concluded that cheap fixes could have prevented over half of the technical support costs for the product. Over the next year, they cleaned up the product and have noticed a major positive impact on customer satisfaction with also the increase of the users of the market using the product.
I found this to be true, in a product that I have worked with, there are fields that are the same thing but with different labels in different parts of the product. This caused extreme confusion and the customer success team spent days per month answering emails. Once the issue was added to the sprint and completed, the number of questions about the labelling did not exist anymore for the following month. In this post, I described the ways in which a software tester thinks, forward thinking – looking into what will happen in the future if the bug goes through.
#3 – Draw the report to the stakeholder that is affected
If you think it difficult to convince a programmer or the triage team for a bug to get fixed, stop thinking this. Consider who else in the company will benefit if this bug is fixed. For example, there is an inconsistency in the user interface, missed by the specification, and the programmer missed it. When triaging about bugs with your team think about these things:
- How does this issue drive up the cost of the documentation? Notify your customer success team to give you written support and how it’s affecting them.
- Are there any sales demonstrations needed for this part of the product? Notify your sales team and they will push for this bug to get fixed. Bugs in demo costs sales.
- Thinking about accessibility – consider the laws in your country and the users. For example, in the United Kingdom, it is illegal to discriminate people with disabilities.
Write the quality offer so that it will catch the attention of the people whose resources will be used by the bug. They will argue for you that the bug must be fixed.
#4 – Define your Minimum Product Quality (MPQ)
This will be your base – a solid foundation that can never be argued. Take your smoke testing, how do you define it? It is a set of tests that aim to ensure that the most important functions work. The results of the test will decide if the product will be released.
Let’s say you have a calculator app, you have the buttons 1,2,3,4,5,6,7,8,9,0, +, =. You want to add a new mathematical symbol “ – “ that will be the takeaway sign. Initially, with your smoke test, what you do is ensure that your old functionality works but now with the addition of this feature, your MPQ will now include the new symbol.
Sit down with your product manager - Write down what the critical features are of the product, how fast should each item load, what are the base design requirements. Do this after every release, get this on paper, hold it close.
Overtime, you will find that the Minimum Product Quality is increasing. Keep track of this, sometimes people will argue with you about how the product should work and how it should look like – queue your MPQ sheet. They will not be able to argue with this document.
#5 – You are what you write
Your quality offer is your primary work product. These documents mold everyone’s perception of you. The better your reports, the better your reputation. Developers rely on you for information and weak reporting generates more work for programmers. Waste their time and they will avoid you. Remember the old post, programmers are not your only stakeholders, you have your product manager, your actual user, your wider business teams. Reports that seem blaming, poorly explained, or inadequately researched bugs will affect how your colleagues will think of you.
Take time to research and write your offers and know that what you write will:
- Alert people to defects
- Help troubleshooting with underlying problems
- Alert to problems in specifications (Test documentation, API documentation, User Documentation)
- Flag issues that will affect Sales
- Provide key information to your wider business team
- Provide information about the product quality of the product under development
Remember: You are valuable, so what you write is valuable.