(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.

In this smartbits video “Design for Testability& Automation” Girish Elchuri outlines how design for testability aids in test automation.
 The transcript of this video is outlined below.

There are three aspects to be looked at when we talk about test automation. The first one is running the test cases, the second, invoking the functionality that needs to be tested and the third, asserting the outcome tests as success or failure. We can talk about test automation only if we can automate all these three functions.

Test execution
Most of the time, running the test cases is perceived as automation, but ideally it has to invoke the other two as well. With reference to running the test cases, there are enough tools that can be used and invoked, but in case of invoking the functionality, a developer can make a big difference.

Backdoor invocation
Normally when a product is being developed, the product functionality is accessible only through GUI. Developers should also provide a backdoor to reach the functionality so that one can actually test the entire product functionality in a much more efficient way without having to invoke the GUI. This is how developers can help in terms of test automation.

Test outcome assessment
In the third aspect of asserting the outcome as success or failure, sometimes it is not clear whether it has succeeded or failed because of some small state changes that we do not know how to check. So a suggested way is to have extensive logs, these are also called as the structured logs. While logging we put debug messages, information messages and error messages. There is another category that needs to be added, these are called test messages. In a structured log with test messages, it becomes easy for us to go and check the log and ascertain whether a particular test case has passed or failed.

These are ways how a developer can help testability in test automation – by facilitating invocation and assistance in assertion of outcomes of test result.

by T Ashok @ash_thiru on Twitter

Summary
As much as testing is seen as a key activity to deliver quality, there are simple practices that can ensure that code developed is constantly cleansed. In current times where code is churned out at a rapid pace, it makes great business sense to contain the entropy continually. This article outlines ten simple tips to help produce clean code continually.

---

“Great quality code is not the result of intense system testing, it is result of well structured filtration of issues from the early stages. A compromised ‘unit test’ puts unnecessary strain on the QA folks who seem to be compelled to go after these issues at the expense of system test.”

Developers do not deliberately write bad code, it is just that accidents happen. Accidents happen due to a variety of reasons – unclear requirements and therefore making assumptions, just sloppy coding, brute force push of unit testing without it being simple and practical, over reliance of testing rather than prevention, not enough refactoring, not enough focus on non-functional requirements(NFR).

Here is  how I feel as a developer as a poem titled “Hug each bug”

On a quiet  night
I sat down to code
Happiness in every byte
On the keyboard, it just flowed

Sheer poetry it was
But quietly slipped in tiny flaws
Silly it was, what I found
When the code ran aground

An exception I missed
And the code really pissed
Forgot to catch the ball
The system had a mighty fall

Bugs are uninvited guests
Makes you beat your breasts
That is why you need to test
So that you deliver your best 

I say Hi to every bug
From each one I learn
Embrace with a warm hug
For perfection is what I yearn
—
If you want a lovely poster version of this, click here.

What may be some tips that I as a developer can follow to write clean code?

1. “Never assume, ask, question”
   Requirements are never complete, it just gets refined with time. Don’t assume when something is unclear.
   
2. “Think of behaviour in terms of conditions”
   Good behavior is about compliance to conditions,ensure combinations are well taken care.
   
3. “Be friends with bug(s)”
   Do not hate bugs, for they are the ones from who teach you constantly to do better. Learn from each, so that you find it and not others.
   
4. “Use smart checklists”
   While coding, be sensitive as what issues can occur. Sensitise & prevent rather than rely only on test to find issues.
   
5. “Treat code as a living entity”
   Nothing is frozen. Refactor, refactor constantly to simplify. Clean code is really never done, how much you can do is simply limited by time.
   
6. “Be sensitive to NFRs”
   Non-functional requirements cannot be ‘fitted’ in later, so pay attention to load, performance, usability scaling, security, maintainability etc. always.
   
7. “Don’t be scared to inject bad inputs”
   Checking correctness with good inputs are fine, but it is incorrect inputs/settings that create unwanted technical debt. Get these out of way early, by ensuring robustness at early stage.
   
8. “Be purposeful of issues to find via unit test”
   There are different types of issues that may be there, be clear as to what to strive to prevent, what to go after via unit test and what at higher levels of testing. Ensure clarity of what you are going after.
   
9. “Strive to understand how your code will be consumed”
   It is not meeting a spec, it is not working in isolation, it is about visualising who (i.e other code) will use/consume my code so it can take care of the situations in future.
   
10. “Unit test is not an after thought or compliance”
    The act of unit testing is not a chore or compliance to satisfy someone, it should be natural thing that we do to ensure our code does not stray. Treat this as part of coding, not as another activity post code. Write a script while doing this or jot down stuff to perform this manually. Stay lightweight so that you can repeat this continually. After all, development should be friction-less.

---

About SmartQA The theme of SmartQA is to explore various dimensions of smartness to leapfrog into the new age of software development, to accomplish more with less by exploiting our intellect along with technology.  Towards this, we will strive to showcase interesting thoughts, expert industry views through high-quality content as articles, posters, videos, surveys outlined as a SmartQA Digest weekly emailer. SmartBites is soundbites from smart people”. Ideas, thoughts and views to inspire you to think differently.

---