We’re going on a journey to understanding and exploring what Continuous Quality is.
Do you understand what is meant by Continuous Quality?
- Yes
- No
- More or less
- Something else
0
voters
Bonus points for community commentary!
3 Likes
I assume that it’s connected to things like continuous delivery, deployment and integration. Those are things that have a big impact on testing and changes the testability of the product when it comes to availability, schedule, toggling (controllability, complexity) and so on, so anything to advise on those situations has a lot of value, I think.
Or, less likely, it’s about testing throughout the lifecycle, which is another worthy topic.
Either way, learnin’ to be had, can’t lose.
3 Likes
I’ve tried to learn about it these past few days from available resources online.
As Chris highlighted it’s somewhere linked to the delivery/deployment/integration.
It seems to be mostly about automation of things like:
- dashboards - quality metrics
- production metrics and user insights
- monitoring, alerting and recovery systems
- unit, integration, ui, api checks
- analytics to make data-driven decisions
- test data scrub/protection from real data
- security, performance scanners/analyzers
Generally whatever one automates that would help to understand the product state (quality) at various points during the CD/CI.
3 Likes
To me, this means having a continuous process to improve testing quality. For example, each defect found in production should lead to the creation of a specific test to “catch” that defect, which is then added to the next set of regression tests.
4 Likes
In my opinion, in agile, when the product is deployed continuously through the CI/CD pipeline, it is important to maintain quality, and that too continuously. Hence, continuous quality is a journey of maintaining quality while the team introduces or modifies features, fixes bugs, refactors code, etc. in every sprint.
2 Likes
I don’t know anything about Continues Quality and have the impression that it something to do with so called Quality Engineers. Which I also don’t fully understand, despite that I have tried it multiple times.
Or maybe I understand QE, but don’t find appealing. If not problematic.
3 Likes
As with most terminology, I think it’s up for discussion and probably used in different ways in different contexts.
To me, it’s more or less about baking in quality from the start, always having an eye on the state of an SUT and how to improve it as you go along. This would be in contrast to building a thing entirely before thinking about whether or not it actually solves a problem or adds any value or whether anyone would actually want to use it.
2 Likes
Where did the term originate? Why? Do we need it, or is it just a new label for existing ideas (seems to happen a lot in testing)?
I assume it’s intended to be parallel to terms like “Continuous Integration”, “Continuous Deployment”, or “Continuous Delivery”, but all of those include a verb, while Quality is a noun and an attribute/perception of a system, so it isn’t clear to me what adding “Continuous” to it means in practice.
3 Likes
Continuous Quality is for sure a new term that I am hearing. But what I understand is, it is about maintaining the quality of the product right from when you are developing it until you deploy it to Production. When a feature is developed in the Development environment, you ensure the quality by writing and executing Unit tests and Integration tests. When it moves to a QA and other higher environments, you ensure quality by executing Functional and End to End tests. This makes quality a continuous process throughout the development lifecycle.
There are many other terms linked to this like Continuous Integration, Continuous Deployment, etc. This is where Automation of Unit tests, Integration tests and E2E tests play a major role. As the code is deployed in every environment, a set of automated tests are triggered automatically which will certify the build. This is possible only when we have automated tests.
4 Likes
I think the existing CI/CD terms already imply having automated tests in your pipeline.
3 Likes
Last week, a friend shipped some new software, well released actually the hardware and the software together in a working state, and it reminded me of when I worked in mobile phones, we could write bug-free code, but if the firmware and the hardware was not right, there was always going to be a problem. It reminded me of the big strategy of testing we had to adopt, to test the hardware literally to death first, and only then have the software drop and adapt to any last minute changes. We always released on Wednesday for example to allow integration to have 2 more days of checking before shipping. Now those are pretty rigid business constraints, and lately I see a lot of debate around things like releasing on a Friday for example. We had nightly test suites that ran on real hardware and took hours, It used to take me about 2 hours just to go over all the results, looking at failing as well as passing checks as well. All tactics.
None of the usual conversation is IMHO Continuous Quality. And reading the response from @kinofrost reminded me of a conversation I had yesterday in a really tiny woodland which is held in trust as a green buffer. We try to clear invasives and keep things under control, I’m an ecology and conservation volunteer, quite a mouthful. It’s always worrying when people use acronyms, but it’s a good feel when your job has a nice detailed title. What a small group of volunteers can accomplish in a woodland is really maintenance only, although someone inspects every year, but it’s really maintenance, because the trees are often too big for us, nature is pretty muddy and moves constantly.
A volunteer asked me what it is a do, I replied, “I try to find bugs before customers do!” But we know that for every 10 tests we run, our customers will run 10 million tests on the day we release, so we have to devise and deploy tactics that actively work to catch those before they escape. So for me, Continuous Quality is a separate feedback activity using Security scans, Analytics, AB testing, Phased Release and other processes.
1 Like
Not really to be honest 
2 Likes
Thanks for all the replies.
If you can make it, I recommend joining this online event. We’ll explore the world of continuous quality.
2 Likes
It could just be a reification of something we are not sure of.
@rosie Yes, I understand that Continuous Quality is a proactive and integrated approach to ensuring software quality throughout the development lifecycle. It involves embedding quality practices into every phase of the software delivery pipeline, including continuous integration (CI), continuous delivery (CD), and monitoring in production.
This approach leverages automation, real-time feedback loops, and robust testing strategies to identify and address issues early, ensuring the software meets high standards for functionality, performance, security, and user experience consistently. Continuous Quality shifts the focus from reactive defect resolution to building quality into the development process itself.