INSIGHTS

Curate, Not Inspect

Bharat Sangekar

Practice Director - Assurance

Defects, as it turns out, can be spotted by an algorithm. Throw a skilled critical investigator (tester) in the mix and teams are getting better at writing code to inspect, detect and report on the quality of the software. Do it for new functionality, do it for every change, do it across the units and the system as whole and as far as inspecting for defects is concerned, there’s quality assurance for you right there. Or is it?

July 7, 2017

The good news is, tools to detect, inform and report are getting better, so are the adoption of the processes. From Sonarqube to Selenium, from Agile Testing to DevOps.

However, the reality on the ground is, effective use of these tools and processes is directly proportional to the maturity of the teams and the organisation. From independent testing sprints before release (you know you have them) to dividing the test automation itself into progression/ integration/ regression/you-name-it phases.

If you leave aside those who have matured enough to be able to deploy to production multiple times a day, the focus everywhere else largely remains on someone at a later stage in the release cycle, in some automated/semi-automated/manual form to assure low risk before going into production.

Truth is, there is no of way of getting Continuous Delivery right if you don’t get Continuous Testing right. Yet it is often overlooked. Steps that should have been implemented at the start of the project are often added later creating inefficiencies in the DevOps adoption.

Thanks to the Agile fail-fast, fast feedback, shift-left movement, more and more testing discussions are happening earlier.

But we need to do more than just highlight the process improvement, maybe we need to redefine quality assurance in the mainstream software development to bring the focus back to where it should be, craftsmanship.

And now that we, the industry, are at this beautiful cusp of evolved quality mindset and tools adoption, there was never a better time to redefine Quality Assurance as a set of engineering practices and frameworks adopted to continuously curate applications for quality.

Curate. Not inspect. Not detect.

Why Curate you ask?

Isn’t curation about choosing, presenting and preserving items of value?

It is, but it also is about the care factor, about truly taking care of something original or valuable.

Who should care about quality? Should the tester alone care? Should the CEO care? Is quality everyone’s responsibility? If your bacon is on the line, and one way or the other it often is, IT IS.

Testability becomes an easier conversation when you talk about curation. You don’t just build applications and hope to find a way of testing it later.

So, you have decided to harness the power of AWS to code, build and deploy? How do you test an Amazon Step Workflow? How do you test a lambda function? How do you verify SNS is going meet your NFR of sending notifications to 10 million mobile apps per minute?

The product owner, the analyst, the architect, the developer who make the business and technical decisions are the curators at each stage of the SDLC and become the gatekeepers of quality, not the tester.

You want to get that MVP out first? You want more features to demonstrate the potential of your application before you find the time or money to invest in quality? Sure. But what happens if the MVP you have out there is of a quality that has your users delete the app minutes after installing it? What happens if your sponsor judges your future potential by the quality of your MVP?

If your developers are forced to build monolith after monolith without getting the time to refactor the core that needs to reflect the new learnings, you are building technical debt. And if your technical debt is creeping in, you are sweeping quality under the carpet.

It’s as much about what’s not there as what is. It’s not as much about aggregating as it is about sifting, sorting and curating as we go.

Software development is not similar to building a house. You don’t get to lock down the foundation before laying the bricks. You need to be able to rework and reinforce the foundation as you learn about the changing expectations on the configuration of the house or the new levels you want to build on. Unless of course you would be prepared to knock down the house every time the expectations on the usability change. Would you?

Ultimately, what your business cares is about a quality user experience, and that’s exactly what a curator of an art exhibition does.