T Ashok @ash_thiru on Twitter

Summary
Smartness is a brilliant combination of knowledge and skill. Skill is acquired by intense practice. Intense practice happens when you have good habits. In this article I look at SEVEN habits that are key to SmartQA.

Habit #1
Visualise well, see the big picture of the system.
Who uses, where, when, using what interface. See the big picture of how it is structured/architected, visualise the flow of control and data and the technologies used(aka tech stack). Appreciate the environments it should run on the dependencies of external systems and changes/modifications done.

Habit #2
Question well. Question to know. Question to know what you do not know. 
Ask about users and their expectations ask about the how it is constructed, ask about conditions a behaviour should satisfy.
Ask, ask… The limit to questioning is unbounded. Note you may not get all the answers, the key is to question.

Habit #3
Prove with facts. 
Show proof of adequacy of tests, hypothesise potential issues and prove that they may be detected.
Understand changes done and prove why an entity(ies) need to be regressed, after all you do not want to more that needed.

Habit #4
Iterate continuously. 
SmartQA is about experimenting, exploration.
It is about iterating with minor changes to understand better, to observe better.
Chew well to digest.

Habit #5
Unlearn. 
Revise what you know.
 Understanding is not about knowing more, it is also discarding what you know. 
Chew to digest and spit out the rest.

Habit #6
Empathise.
Put yourself in others’ shoes and feel them.
Get inside them to understand what they expect, what they will dislike, their constraints, what value they expect of the system. SmartQA is not testing the system technically, it is about delivering value.

Habit #7
Simplify the problem solving.
End users use systems to solve their problems. Great software solve them well.
Good testing is about ensuring systems do just enough i.e. simply.

T Ashok (ash_thiru on Twitter)

Summary

Inspired by how the world is handling Covid19, this article as a SlideShare lists actions taken and criteria met to contain the pandemic and correlate this to how we can deliver clean code for large scale software systems. This article focuses on the process flow and criteria for delivering clean code. 

Check out the previous article COVID19 and Clean Code Part 1: Techniques,
that outlines techniques to deliver clean code, inspired by Covid19.

(In this SmartBits, Tathagat Varma outlines “ How to reduce waste(bugs)?“. The video is at the end of this blog)

It
is a holy grail of software development. We have seen from CMM days that defect
prevention has been the holy grail. We fail to recognise that a software in
itself is not isolated and independent. The context in which it is operating is
changing all the time. Be it evolving systems, hardware, software, network or
the evolving user behavior.

Ten
years back when iPhone was launched, people found pinch and zoom feature very
novel to use. Today it is a standard. The context in which people are changing
is changing all the time. Definitely that makes sense. It is a good old saying
a stitch in time saves nine and we have seen during the waterfall days how the
cost of defect amplifies if not prevented. Today, even if we say we are agile,
if we were to fix a defect in the production, it still costs  a lot. Definitely prevention will have its
own role to play.

We
are doing a lot of software reuse, whether it is third party or open source. We
don’t always have control over a lot of components which we use. We get a
component from somewhere and just use that. Do we really have insight into what
went into when it was being designed? Do we have control over what kind of
defect prevention steps were taken into that? This may or may not be known. We
will still need some way of qualifying the components and putting them together
and the speed at which we are aiming to really push our systems into
production, it will require a lot of us to reuse.

In
some sense software construction is being reduced to plumbing the whole thing.
It is like the job of an architect when constructing a hundred storey building.
We don’t make brick or steel pipes anymore. These just get sourced and are put
together and then a system gets created in which we are able to perform
incoming check criteria whether this is of the acceptable quality to us. Here
some level of a component testing is done to see whether they meet our
requirements.

Secondly,
we put them together and see whether they really don’t burn each other
out.  If we put this into the context
that we have to release this into production hundred times a day, it’s kind of
inevitable that we will end up doing a lot of automated testing. At some point
we have to understand that if we are blindly relying on automated testing to
solve or uncover every problem, that might be a little dangerous statement to
make. We should use it really to make sure that whatever was the behaviour in
the last build remains unchanged and unbroken and that becomes a very good
verification. If new features/behaviour have been introduced, delegating
that  to automated testing at the first
instance might need a lot of subjectivity. We need to be a little careful.
There is no definite yes and no answer but “a balance” probably is the best
answer.

T Ashok @ash_thiru  on Twitter

Summary
SmartQA is a beautiful combination of thinking styles, a mindset of brilliance and minimalism,  tech prowess, heightened clarity and  great design and meaningful pauses, outlined as ten suggestions in this article.

#1 Embrace multiple thinking styles
Inculcate the deductive ability of a mathematician, creativity of an artist, mind of an engineer, value perception of a businessman, technical savviness, empathy, doggedness and nimbleness.

#2 Have a mindset of brilliant engineering
Step into end user’s shoes, architect/design robustly, inject code to aid testability, strive to test minimally, do test related tasks lightweight.

#3 Analyse well, exploit tools for doing
Much like the skill of a doctor to diagnose with exploiting the machines in the process. “Doing SmartQA”s a brilliant combination of “human powered and machine assisted” . The WHAT to-do is human while HOW-to-do is powered by machine/tools.

#4 Do minimally
Strive to prevent issues, embed testability, review code carefully, use smart checklists, write minimally, regress intelligently.

#5 See better, cover more, test less
Continuously see and assess product from multiple views – USERS, ATTRIBUTES, ENVIRONMENT, CODE, ENTITIES

#6 Pause to speed up
Periodically pause and analyse to be sure that you are staying on the right track, reflect on outcomes to ensure you are doing it right and efficiently.

#7 View system from multiple angles
View the system from internal, external, regulatory/compliance, operations, maintenance and release like code structure, architecture, technology, terms of behaviour, end users, environment, usage, standards.

#8 Be sensitive and aware
Be sensitive and aware to issues you encounter and potential causes of issues, after all issues creep in due to untold expectation, accidental omission, quiet assumptions, incorrect implementation,inappropriate modifications,interesting side effects ,deliberate abuse , and innovative usage.
Sharpen your senses  to smell better!

#9  Design for robustness 
Don’t just test, design system robustly. Codein firewallsto be disaffected by inputs, configuration/settings, resources or dependent code.

#10 Design for testability
Hook in code to be able to inject inputs to stimulate, check status, create traces/logs  to debug/check-for-correctness, even embed ‘self-test code’.

You may want to read a detailed version of these in these two articles FIVE thoughts on ‘Doing SmartQA’and FIVE *MORE* thoughts on ‘Doing SmartQA’.