Every organisation that builds a product, has its own view of quality and what it means for the product they are building. To identify what quality means for an organisation it is useful to have a manifesto. While Quality Strategy encomapsses quality aspects in software development, Quality Manifesto helps an organisation define what quality means for them strategically. Based on what is set-out in the manifesto, software delivery teams can derive their everyday practices and principles. Quality Manifesto, can also help an organisation with the type of people to hire, metrics to measure quality, and define lines of responsibility.
Quality Assurance is where a person asserts the behaviour of a system and ensures it is meeting business standards. Whereas Quality Advocacy is when the person spreads the awareness of quality in the organisation and ensures everyone is thinking about it from ideation to when the customers start using the product. Thought processes differ from person to person. Organisations that encourage Quality Advocacy contribute to making a better product with new ideas of innovation.
While it is easy for engineering teams to build a product to a set specification, customer needs should always be at the forefront. Businesses choose to build products based on user needs, user research, and market conditions. Teams put themselves in the user’s mindset and question “Is the product providing value?”. Organisations that encourage this behaviour can provide products that are fit for purpose and avoid costly rebuilds.
Every organisation has some quality measures in place. Most of the organisations have “Quality Gates” where certain people are accountable for maintaining quality. Peltzman effect suggests that 'When safety measures are implemented, people actually tend to increase their risky behaviors'1.This means that people developing the product will have a false sense of confidence that any faults in the product will be caught by people who are testing it. Moreover some organisations may have a blame culture more than retrospecting any issues caused. To improve overall quality, set-up processes that make the whole team accountable for what they are building and maintain a safe environment where people can learn from their mistakes.
The value of a QA is their creative mind and ability to think about edge cases. Testing for quality is about investigating and exploring the product to learn and uncover the unknowns. This helps the team better understand the product better and exercise their curiosity to gain a holistic view of the product. In contrast, a scripted approach is where a document is to be followed for testing a product. Here chances are that people may limit their thoughts to the document provided. Exploratory testing can help in evolving the product by gaining insights into how it could be used and the consequences of using it in a way that was not originally intended.
Testing should not be left as an afterthought. The idea is to build quality into the product and identify the risks from the beginning rather than testing for quality at the end of the lifecycle and find flaws once it is developed. This would help the organisation to minimise the cost of re-development based on the feedback. This mindset enables teams to collaborate towards building a quality product. Common patterns to help achieve this are:
Manually checking the application for every change becomes pretty time intensive. People sometimes overlook when there are repetitive tasks of checking the same functionality over time. Rather this time could be valuably used for checking the product which automation is unable to cover. Automation helps organisations deliver faster with greater confidence that existing product features are still functional while new functionality is being developed. Automated checking can range from automated tests, monitoring , alerting or any other form that would make the manual tedious tasks redundant. This is to ensure that teams can spend most of the time building new functionality rather than spending time to fix existing features.
Footnotes:
1. As a result, the phenomenon predicts that mandatory safety measures actually experience a lower benefit than we would expect, because the safety benefits brought about by these measures are offset to some extent by increases in risky behavior*
Quality Advocacy over Quality Assurance
Quality Assurance is where a person asserts the behaviour of a system and ensures it is meeting business standards. Whereas Quality Advocacy is when the person spreads the awareness of quality in the organisation and ensures everyone is thinking about it from ideation to when the customers start using the product. Thought processes differ from person to person. Organisations that encourage Quality Advocacy contribute to making a better product with new ideas of innovation.
Customer Needs over Requirement Specifications
While it is easy for engineering teams to build a product to a set specification, customer needs should always be at the forefront. Businesses choose to build products based on user needs, user research, and market conditions. Teams put themselves in the user’s mindset and question “Is the product providing value?”. Organisations that encourage this behaviour can provide products that are fit for purpose and avoid costly rebuilds.
Team Responsibility for Quality over Tester’s Responsibility
Every organisation has some quality measures in place. Most of the organisations have “Quality Gates” where certain people are accountable for maintaining quality. Peltzman effect suggests that 'When safety measures are implemented, people actually tend to increase their risky behaviors'1.This means that people developing the product will have a false sense of confidence that any faults in the product will be caught by people who are testing it. Moreover some organisations may have a blame culture more than retrospecting any issues caused. To improve overall quality, set-up processes that make the whole team accountable for what they are building and maintain a safe environment where people can learn from their mistakes.
Exploratory Testing over Scripted Testing
The value of a QA is their creative mind and ability to think about edge cases. Testing for quality is about investigating and exploring the product to learn and uncover the unknowns. This helps the team better understand the product better and exercise their curiosity to gain a holistic view of the product. In contrast, a scripted approach is where a document is to be followed for testing a product. Here chances are that people may limit their thoughts to the document provided. Exploratory testing can help in evolving the product by gaining insights into how it could be used and the consequences of using it in a way that was not originally intended.
Bake quality in over breaking it
Testing should not be left as an afterthought. The idea is to build quality into the product and identify the risks from the beginning rather than testing for quality at the end of the lifecycle and find flaws once it is developed. This would help the organisation to minimise the cost of re-development based on the feedback. This mindset enables teams to collaborate towards building a quality product. Common patterns to help achieve this are:
- Early Involvement over Late Inspection: Get involved from the beginning of the product development, understanding business context and priorities, ensuring thorough analysis of the requirements and identifying additional scenarios for a feature that could be embedded during product development thus bringing the effort ahead in the process.
- Continuous Testing over Testing at the End: Testing for Quality does not lie just in the product but also associated parameters such as the ideas, artefacts and processes which support the product. Continuous Testing is about continuously evaluating these parameters across the product lifecycle.
- Short Feedback Loop over Delayed Feedback Loop: Providing faster feedback of product quality reduces project costs. Fast feedback helps you to respond quickly and make changes when you need to. You can spot risks before they develop into bigger problems that are more complicated and expensive to fix. Feedback could start from the product ideation stage itself to ensure we are building the right product.
Automated Checking over Manual Regression Testing
Manually checking the application for every change becomes pretty time intensive. People sometimes overlook when there are repetitive tasks of checking the same functionality over time. Rather this time could be valuably used for checking the product which automation is unable to cover. Automation helps organisations deliver faster with greater confidence that existing product features are still functional while new functionality is being developed. Automated checking can range from automated tests, monitoring , alerting or any other form that would make the manual tedious tasks redundant. This is to ensure that teams can spend most of the time building new functionality rather than spending time to fix existing features.
Footnotes:
1. As a result, the phenomenon predicts that mandatory safety measures actually experience a lower benefit than we would expect, because the safety benefits brought about by these measures are offset to some extent by increases in risky behavior*
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
