Quality Intelligence Feedback Loop - A QI Concept

Quality Intelligence Feedback Loop - A QI Concept

• 1.
  Quality Intelligence FeedbackLoop - A QI Concept Introduction At the core of Quality Intelligence [1] is getting the right quality information [2][4], to the right person, at the right time, to make an informed decision. Often this means we want the quality intelligence as soon as it is feasibly possible to get it - we want the feedback loop to our stakeholders to be as short as possible, to allow for prioritized problems to be fixed as soon as they can be, so that we can shorten time-to-market and increase efficiency. This is valuable to have in mind when we set out QI strategy, and plan and define the purpose of our different QI activities [3]. Shortest feedback loop feasibly possible? If we could do a full system test for every code change a developer makes, and it cost nothing and was almost instantaneous, I am sure everyone would be happy. I don’t think we will get to that state anytime soon, or ever. But at this stage you want the developer to have quality information about their code change, with a focus on speed, since there are many code changes in a day. Maybe automated component/unit and service tests [5] is a good option in this case - you get the most important quality information to the developer, in the quickest way possible. Generated using ChatGPT 5 Depending on your context, maybe you have a subsystem branch which the changes are merged to. You probably want continuous information about the quality of your subsystem. Maybe you have a suite of automated nightly integration tests that are run to ensure that all the component changes have not broken anything on a subsystem level. Because these tests
• 2.
  probably take longerto run, you don’t want them to run for every pull request to different components in your subsystem, so this would be the shortest feasible feedback loop you can have on a subsystem level. If your subsystem has a UI and/or good testability another way would be to have QI Specialists run daily exploratory testing on the subsystem branch - but this is most likely slower and more costly if you have a good test automation framework in place, even if the value of the quality information would be higher. Then we probably have something like a system master branch. Depending on context we may want this to be “always releasable”, but either way we need quality intelligence about the full system every day if we want to keep the feedback loops short. This can either be done through automated UI tests, which is hard and costly to implement and maintain, or through exploratory testing by QI Specialists. For master branch system tests, one possible and interesting option could be using agentic AI bots to run system tests, and having a QI specialist transform the quality information generated into quality intelligence [4]. The most efficient solution depends on context. So where do we land with all this? ●​ A developer makes a code change - an automated test suite runs unit and service test to give quality information about the component ○​ We are testing as soon as we can, but our test scope is limited by time ●​ It is merged to the subsystem branch, on which we run daily integration tests or exploratory testing ○​ We are testing daily because our tests take longer to run, so this is the first time we can feasibly test on a subsystem level ●​ The subsystem branch is merged daily to the system master branch, and on the master branch we have QI Specialists running risk-based exploratory testing and/or test automation or AI to provide quality intelligence that enables us to be “always releasable” ○​ This is the first time we can test all the code changes on a system level - we are trying to have as short a feedback loop as we can We can and will have additional QI activities in our QI strategy, but with this as a core engine for generating quality information/intelligence to different stakeholders we have a good start. Conclusion We want to generate quality information as soon as it is feasibly possible, so that our stakeholders can make informed decisions as early as possible. We do this to reduce time-to-market, and improve efficiency. When it is feasibly possible depends on context - but trying to run a full system test for every code change probably isn’t. We don’t want to find prioritised problems late in the production cycle, when we could have found them much earlier if we had just looked for the quality information in an effective way.
• 3.
  References [1] Quality Intelligence https://www.slideshare.net/slideshow/qi-not-qa-68042026/68042026 [2]Quality Information Coverage​ https://www.slideshare.net/slideshow/quality-information-coverage-a-qi-concept/253813624 [3] Purpose-Driven Quality Intelligence https://www.slideshare.net/slideshow/purpose-driven-quality-intelligence-a-qi-concept/283910819 [4] Turning quality information into quality intelligence https://www.slideshare.net/slideshow/turning-quality-information-into-quality-intelligence-a-qi-concept/27669 7283 [5] Practical Test Pyramid https://martinfowler.com/articles/practical-test-pyramid.html