The build trap is when organizations become stuck measuring their success by outputs rather than outcomes.
I guess this relates to a point made in Accelerate about measurement models. It’s preferable to use a capabilities model of measurement to continuously know if your product is where you want it to be, rather than a maturity model that tells you if your product has reached a certain state.
Product management is the domain of recognizing and investigating the known unknowns and of reducing the universe around unknown unknowns.
Observability is also about unknown unknowns and deep down it all goes back to testing. But hey, I might be biased here.
Read More »
Collaborative testing practices that occur continuously, from inception to delivery and beyond, supporting frequent delivery of value for our customers. Testing activities focus on building quality into the product, using fast feedback loops to validate our understanding. The practices strengthen and support the idea of whole-team responsibility for quality.
This is the authors’ definition of Agile Testing. To me, the biggest differentiator from other testing definitions is that this one promotes to actively improve quality rather than only inform on the status of quality.
When the whole team is responsible for quality of the product as well as quality of the process, each team member needs to be proactive in solving problems.
Quality coaches might educate, prepare or motivate team members to become proactive.
There are many things to consider around your product domain. It is not only the software you are testing; it is the product that your end users depend on.
I find this advice needs to hold true for anyone working in software development.
Read More »