We commonly hear people talking about “non-functional” requirements. By “non-functional”, they mean quality attributes such as performance, security, accessibility, usability, operability, installability, the list goes on and on. However, we believe non-functional isn’t an appropriate name for these attributes. How “functional” would a web-based e-commerce application be if it wasn’t secure, if it was difficult to use, if its pages took minutes to load, if it wasn’t supported by monitoring and observability?
Have the conversations
Download the chapter on models about the Agile Testing Quadrants. We talk about and plan testing for all the quality attributes that may be important in the context of our team’s products. These mostly fall into the right side of the quadrants, test activities that critique the product. That doesn’t mean teams won’t start testing for them even before the production code is written. For example, a team may do a spike, write throw-away code that is unsupported by tests. They may do this to run load tests against it and verify that the architecture scales appropriately for the expected number of users.
It’s crucial to talk about all these quality attributes as soon as a team starts to talk about a new feature. Frameworks for structured conversations, such as story mapping and the 7 Product Quality Dimensions, help teams consider workflows and identify the “non-functional” testing activities they may need. Even with shared understanding using concrete examples and business rules, teams miss things. For example, who expected a beaver to chew through cable buried three feet underground to bring down the internet? Teams also need consider quality attributes like recoverability and observability to help fix unexpected problems quickly.
Start having those conversations by examining some of the risks the team might identify. Look at both business and technical risks. Ask those “what if” questions, or “What’s the worst thing that can happen? What keeps you up at night?” to get the conversations started. In her blog post about quality management, Janet shared some ideas about using quality sliders to determine what are the most important quality attributes a team should consider.
Risk vs. value
Risk is about trade-offs. For example, when Lisa needed eye surgery, the doctor was very specific about the risks and the impact of those risks if they should materialize. He also explained the consequences if she didn’t have the surgery. Risk vs. value. It is a conversation to have with your customers.
Perhaps the internet provider planning to bury that cable had thought about their nightmare scenarios. They might have considered risks such as permafrost, animals chewing through the cable, or someone accidently stepping on the cable. Burying it inside conduit three feet down may have seemed like enough to mitigate the risks. Given that the town lost connection for two days and that the story about the beavers got in the headlines internationally, a plan for backup service might have been wise. No one can predict everything that will happen in production. But teams can think about the range of quality attributes, and plan for measures to detect unexpected problems and recover quickly.
Quality – in your customer’s opinion
Testing for quality attributes is about fit and finish for your product. They are becoming more important as time passes. Customers expect more. They expect reliability, security, safety of personal data, performance, accessibility, and so on. Start the conversation with your team if you are not already having that conversation.