Agile, an iterative development methodology to incrementally build product or service. Agile methodology does list the phases of SDLC to accomplish product development goals. It is considered as one of matured models, a tested means to accomplish software development with customer requirement and product agility in focus. This way the process is Porous enough to allow scope correction at early development life cycle and provides ease of incremental task consumption. There-by we avoid any development plans which favors working backward or follow delivery based on success/failure binary assessment model. ’Agile’ is one other pathway milestone of evolving software development methodologies; & better methods are yet to be invented. With proposals to improve the existing agile methods, Shift-Left is one such agile improvement process. It tries to address the testing phase as early as possible.

To implement the shift-left process in agile methodology we need to understand the agile turf not only from a product & development angle but from a quality perspective as well. This article will dive through quality metrics that need to be looked at as part of SDLC while implementing shift left, goals we should plan to achieve, and value adds gained as part of looking at shift-left from a quality angle. In this article we will be addressing QA engineers as quality owners than addressing them as test engineers who usually create & close test-plans/bugs [Fig 1]

Goal for any software product development is to have quality software delivered in the required timeline. Definition of quality is usually mis-understood. When deliverable meets requirement without any gaps then we proclaim it has an ideal state of quality, i.e. 100%. Some common outliers to this theory are; over-loaded features, multi-folded goals for performance, scalability metrics … occurs due to over-engineering. Not achieving required feature parity or performance would have a similar effect on quality. The cost to quality can be seen [Fig 2], increasing over phases of SDLC. A bug found at an early stage incurs less cost.

Quality is something we need to bake it into a product rather than externalizing it as a process or phased activity. Hence we need to consider phases like requirement definition, planning, design and development, all pre-testing phases as important phases to measure and embed quality. When we think of shift-left it is these 4 phases we need to re-looked at.

Before shifting left lets under the previous four SDLC phases a bit more ….

Requirement analysis is a phase where product requirements are listed and documented. PRD is one of the deliverables of this phase. Other deliverables are Wire-diagram, UX mock, prototypes etc. As a quality owner, we need to define the end deliverable and the quality indices the delivered product needs to adhere to. Some of the metrics are

Functional: quality owner should be verifying the prototype/model UX with the ‘in test’ status development product deliverable. If there is no UX mock then quality owners can use the wire-diagrams to compare the deliverable with what was agreed with product owners.

Security: the design should include security vulnerability checks, ‘SQL/XSS embedded’ vulnerability. Authentication and Authorisation for a given service request. Access of Microservice with in a given vpc / vnet or CIDR or security config.

Performance: volume (in rpm) , Latency-milliseconds are some of the performance success metrics.

Planning phase includes modules, epics needs to be planned first and risks mitigated. Usually a Sprint board/Kanban Chart/Gantt chart of planned work items are few of the deliverables. Reference to document templates, ways of working (process) documents, document selection of tools, frameworks, Infrastructure selection all comes in this phase. We also perform grooming sessions on the epics in this phase and evaluate story points to each task. The sprint board is in ready state at the end of this phase.

During development phase the core development using pull requests, merges and git checkin are few common deliverables. Unit test & results and regression test suite run are few other tasks covered during this phase.

In the QA phase, usually major efforts go in creating a test plan/suite and raising bugs for the Development team to fix with quite an unaccounted time on Dev/QA bug resolution interaction. This happens more often since QA effort increases iteratively for every incremental deliverable from Dev, as shown in [Fig 3].

The above metrics are means for quality owners to either understand the quality from previous phase SDLC or measure quality for current phase of SDLC.

Shifting-left for QA is currently implemented across many engineering teams with a mindset of shifting (aka rescheduling) the testing to earlier phases of SDLC and making dev owners of test plan automation. But Shifting-left in quality means more than just adopting early testing. Few of the examples are …..

decide success indices/metrics (KPI & KPM) during ‘Planning’ phase which could then be used by quality owners as a metric to assess success of a deliverable both in functional, security, infrastructure and performance terms. A common test framework for continuous testing; that allows running of regression test suites and also allows developers to include new test suites for new features currently in development. That’s right the System test / API test needs to be automated by Dev in this case rather than by QA themselves. This will avoid multiple back-&-forth on test bug creation/closure and increase ownership, through discussion. Here the Quality owners will communicate problem statements clearly with developers and create an environment accountability as far as quality of deliverable is concerned. This also means Quality owners will be more of process facilitators and focus on wider quality metrics than just being a testcase-coder. The recommended model can be seen as shown in Fig 4.

In the above recommended model of working you can see quality owners cover the breadth of SDLC cycle. This gives them a good opportunity to have an understanding of quality of service at an early stage and the KPIs provide means to measure quality. Most important of all quality owners drive the process rather than playing one restricted part in complete SDLC.