In this blog post
By Bouchra Gallucio
Vice President QMO – Healthfirst
Quality Shift Left (QSL) may be a new terminology but by all means it’s not a new concept. This is nothing but inserting quality controls and checks early on in a software development process. But what’s new is really the tools and the software development frameworks like Agile and CI-CD that are making QSL happen, easier to implement and even critical to the overall success. In this article, I will attempt to go over how QSL fits in the Agile and CI-CD delivery pipeline, and how is QSL different from Continuous Quality.
In a traditional waterfall process, the idea of SQL is always to get-in early and quality review/check business requirements and technical designs, even writing test cases and scripts early on, but testing is always delayed both QA and UAT are left till the end, which still provides a late feedback, and then you are faced with making tough decision based on quality vs timeline.
In an Agile and CI-CD environment, quality is embedded in the iterative process from backlog refinement to defining acceptance criteria, to testing small pieces of functionality and code early on (stories validation) and early business review and approvals. This is QSL on steroids. In fact QSL becomes also part of the iterative process and it’s hard to stay anymore where it starts and where it stops, those the concept of Continuous Quality. Agile teams are building quality in as part of their process. Concepts like BDD/ATDD, TDD, Code Peer review/Pair programing, early code scanning, …etc are nothing but ways to make sure we produce a quality product in the first place not 6 months or a year later.
Continuous Quality
In the world of Release Early, Release Often, with Higher Confidence, you need to shift left but you also need to be able to do it fast and repeat it in shorter cycles, this is where Continuous Quality comes in. It is about a quality though out the continuous delivery pipeline at the Dev but also at the Ops readiness and user experience after deployment. This is Quality 360 as I call it not just left. The “It works per requirement” is no longer enough, product’s quality is also now looking at:
- Experience:
- Continuous experience.
- Ambient experience.
- Massive scale —highly automated.
- Exploratory testing —shifting roles
Based on my 20 years’ experience promoting software quality through new ideas and approaches, I found that there are some main ingredients that will make your journey successful:
- Changing perspectives and cultures
- Leveraging the right tools
- Shift from traditional QA metrics to something like a Quality Science
- Helping your team upgrade their skills and manage their anxiety
Changing perspectives
In order to achieve Continuous Quality, some of the traditional QA and delivery perspectives need to change
- Shift to focus on decentralized Program Teams vs more isolated Center Of Excellence
- Don’t wait for “perfection”, take a test measured risk approach
- Automation is your starting point, not end point.
- Build teams based on Test engineers that understand code.
Tools
Look for a set of tools that align with a set of strategic planning assumption like:
- Often a shift from commercial to open source
- Code-oriented solutions with integration to DevOps tool chain (i.e., CI)
- Code: Review, static analysis, unit tests
- User experience —responsive design —visual
- Cross Browser Testing, BrowserStack, Applitools, Ivity Labs
- Desired response
Gartner predicts that “By 2020, Selenium WebDriver will become the standard for functional test execution engine, and this will marginalize vendors that can’t provide strong, higher-level test functionality.”
Automation
Strong Drive for Automation Doesn’t Remove a need for manual testing of course, but in a Continuous Quality and CI-CD world, repeatability and speed are important so without a strategic automation planning, CQ is impossible to achieve. But automation here is a lot more than your usual regression automation, it’s looking at automation in everything testers do from designing test cases and scope all the way to validating deployments and everything in between.
Quality as Science – Better ways to measure Quality
Where do Bugs come from? Can you exactly pin point to the specific area(s) that are causing more defects? Real value of QA and test is generally misunderstood; we focus on cost of quality, rather than value of quality and the cost of poor quality. This why the old QA metrics and dashboards of defects leakage, pass rate, Sum of defects… is not helpful anymore, executives are asking for more insightful data analysis of Quality like:
- Driven by questions:
- How frequently does it occur?
- How many people/processes are affected?
- How much time/revenue has been lost?
- Share information:
- Customer observations. (QC feedback loop)
- Test/Controls that are useful.
- Anomalies you found and how.
