(In this SmartBits, Zulfikar Deen outlines “System deployment architecture and testing“. The video is at the end of this blog)

it’s extremely important to understand system deployment architecture. Let’s say we are delivering the same system and as an organization we decide to deploy it in the cloud. It requires a completely different way of testing and we need to show whatever was appropriate works correctly.

If we decide to do a hybrid for various reasons, the solution remains the same, but as an internal decision-making, we may have to make a decision based on compliance. In India, we could take the data into the cloud without much of an issue, especially when the data centres are hosted here, but the same may not be the case in other countries. 
The same solution deployed differently in a different country implies testing has to be different. If it is a hybrid we are trying to work with the two different system fidelities, where part of the system sits on-premise, some of them on cloud. We need to be sure that the data flows through properly and it is secured.

We may not worry about system security between two systems if the entire system is deployed at one place, whereas if it goes through public and private clouds then testing has to be slightly different. If it is completely on-premise then deployment and  testing differs.

If we decide to use a part of it even in the cloud and using only infrastructure as a service the testing would be different. Again if we use a part of a service, say using a data factory from Azure, the testing has to be different because we are using a service provided by the cloud in a different way. We need to make sure it works, if we decide to use advanced services. If we were to use it as part of a whole system, it can’t be tested on-premise. Definitely we need to understand the deployment architecture, how we are planning to deploy and the testing therefore has to be appropriately done for that.

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, Yuvaraj Thanikachalam outlines “ What is Blockchain? “. The video is at the end of this blog)

The way we move files from one system to another system via copy and paste “Ctrl-C & Ctrl-V” is very popular with every computer savvy professional. On similar lines can we Ctrl-C and Ctrl-V the money? Why can’t we move the value in a digital format?
A gentleman by name Satoshi Nakamoto wrote a white paper on Bitcoin. He was trying to decentralize the internet, by creating a mechanism in the digital world to move the value from one pocket to the other without any central authority in place. To do this, he took this problem and solved it by using peer-to-peer technology, encryption technology, and database technology. Bringing all this together he created a solution called Bitcoin which everybody referred to as a Blockchain.
Bitcoin is one of the applications of Blockchain, it is not the Blockchain. Underlying technology which powers the innovation of moving money like a copy of a file from one pocket to another pocket solving the double-spending issue was revolutionary.

T Ashok (ash_thiru on Twitter)

Summary

Corona virus aka COVID19 is a global talking point now. What is being done to contain the COVID19? Well, there are THREE actions in terms of Prevention, Detection, Containment being aggressively pursued. Three targets of young children, old people and sick persons are the most vulnerable as of now. In this article we take a look at the actions being taken to contain the pandemic and relate to what to do deliver clean code.

Corona virus aka COVID19 is a global talking point now. A pandemic now, it has shaken the entire population of the world, busted the business and the world economy. The major stock markets are taking a massive beating driven by the sentiment that there is no medicine for this as of now.

Interestingly the suggestions posed by experts are pretty basic stuff related to good hygiene and this seems to be the only way to go given that there is no medicine as of now.  What can we learn from COVID19 to deliver clean code?

So what is being done to contain the COVID19? Well, there are THREE actions in terms of Prevention, Detection, Containment being aggressively pursued. Three targets of young children, old people and sick persons are the most vulnerable as of now.

What is being done in terms of PREVENTION that we can relate to code?

1. Cover when you sneeze/cough => USE ASSERTS, HANDLE EXCEPTIONS
2. Wash hands frequently => SIMPLIFY, REFACTOR
3. Don’t touch surfaces => STRIVE FOR LOW COUPLING

What is being done in terms of DETECTION that we can relate to code?

1. Check for fever => DO BASIC TESTS
2. Check for other symptoms =>  USE SMART CHECKLISTS, DO DETAILED TESTS
3. Check if contact with affected => DO STATIC CODE ANALYSIS
4. Check origin on arrival (for travellers) => WRITE DEFENSIVE CODE
5. Check travel history => ANALYSE CODE COVERAGE

What is being done in terms of CONTAINMENT that we can relate to code?

1. Quarantine affected/suspected persons => REWRITE POOR CODE, DON’T FIX
2. Use masks use asserts/ EMBED TESTABILITY
3.  Publish routes travelled by affected people => PUBLISH CHANGE LOGS SO THAT OTHERS MAY ASCERTAIN IMPACT, CREATE INTERACTION MAPS, REGRESS CODE

Now who are the TARGETS that could be most impacted in COVID19  that we can relate to code?

1. Young children => NEW CODE
2. Old people => OLD CODE WITH MINIMAL DOCUMENTATION/CK COMMENTS
3. Sick people => CODE FRAGMENTS THAT HAVE BEEN BUGGY

Here is the entire learnings summarised in the full mind-map.

Check out the current article COVID19 and Clean Code Part 2 : Process & Criteria,
that outlines techniques to deliver Process & Criteria, 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’.

(In this SmartBits, Shivaji Raju outlines “ Role of human intellect in QA“. The video is at the end of this blog)

Tools & technology certainly bring in a lot of efficiencies and improves user experience, but I believe that human intellect is definitely required for SmartQA. Let’s take an example of test coverage. We definitely require intellect to validate coverage to ensure that we have the optimal set of test cases. If we were to relate this to automation, we need intellect to ensure that we have an optimal distribution of test cases across different layers as tools would not be able to do it. We as a human or an engineer would validate what is a right fit, what is the right distribution between UI or services testing.

The second example is that we need human intelligence to devise strategies to build frameworks. When we build frameworks, usage of design patterns or best practices, human intellect is required. The third example is exploratory testing, where we uncover some really interesting defects in addition to the running the scripts.