Curated by T Ashok @ash_thiru

Summary
This article is a collection of interesting aspects on accessibility curated form a set of SIX articles covering “What is accessibility”, “Six steps to create accessible designs”, “Ethical design”, “Dos and don’ts on designing for accessibility”, “Ten tips for making website accessible” and “How to create interfaces that benefit all”.

(1) From Accessibility in Design
What is accessibility?
Accessibility describes how many people can use the interface. This usually involves designing for people with various types of disabilities, such as vision, hearing, mobility, cognitive, etc.

There are many obstacles in designing for accessibility, and the only real tool for finding solutions is empathy. Understand people’s needs as much as possible. Make yourself open to worlds unlike your own. It’ll make your product more accessible, but also more human.

(2) From How to Create Interfaces that Benefit All: Accessibility Testing and Inclusive Design Principles
Smart designs aren’t created to impress your peers. Smart designs (and smart designers!) use design elements like colour, placement, and interaction in very intentional ways to help site visitors accomplish their goals — while giving the user the most enjoyable experience possible.

Six tips to create accessible designs 
1.Start with wireframes that includes people who are colour blind, or have poor vision, those with hearing impairments, or cognitive limitations, older users, younger users, power users, and those who just want a great experience.
2. Ensure accessible layouts by:  
– avoiding“staggered” layout of images and text
– display most important information first
– consider screen size especially small monitors
– think about menus especially when convert to hamburger
3. Design for keyboard accessibility
4. Test your colours and fonts are for readability
5. Create accessible forms
6. Learn how major sites work for keyboard or assistive technology users

(3) From “Ethical design and accessibility” 
“If your design is providing a benefit to one group of people at the detriment of another, it may not be ethical.”

Design is not about expressing yourself.
Design is not about following your dream.
Design is not about becoming a creative.
Design is about keeping people from doing terrible things to other people
— Mike Monteiro

Ethical design means thinking about your product in the context of its users and their environment. Designers need to learn how to think about ethical issues, and ask themselves:
– What are the issues facing the users I am designing for?
– Is there a social or environmental cost to my approach?
– How do I keep my product from discriminating against its users?

 (4) From Dos and don’ts on designing for accessibility

(5) Keen on making your website accessible? Here are“Top 10 Tips for Making Your Website Accessible”

(6) Here is an interesting article on “How to Create Interfaces that Benefit All: Accessibility Testing and Inclusive Design Principles”

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.

T Ashok @ash_thiru

Summary:
We use many terms like philosophy, mindset, framework, models, process, practice, techniques etc in SW dev/test. This article attempts to simplify and put together a nice image of how they all fit in, to enable clear thinking for brilliant problem solving.

Given that the act of developing software is “problem solving”, we are bombarded by very many interesting terms like philosophy, mindset, framework, models, process, practice, techniques etc.  I am sure we have encountered these terms – Deming philosophy, CMM Model, Scaled Agile Framework, Lean process, White box techniques etc.

What are these? Are they just jargons that complicate our thinking? Well these are really different facets of problem solving. A crisp definition of these are listed below, picked up from dictionary.com.

And here is the simple depiction of these inspired by “Matryoshka doll” !

Problem solving philosophy requiring a mindset nurtured by good organisation culture, via model, framework, methodology, applying a set of processes/procedures using guidelines, principles, techniques, heuristics  and aided by tools, templates, checklists

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.

T Ashok @ash_thiru

Summary:
In today’s world of constant change, staying agile is paramount to meaningful response. This article outlines how a Compass tool, the practice of Cadence and mindset of Ownership can help you stay agile.

We all know that change is constant. We also know that adapting to change is hard. We resist change. An adaptive system responds. Responds rapidly to change. In nature, this is key to survival. And also key to delivering high performance. Change is challenging and worrisome. We resist because we are typically afraid. Afraid of possible bad outcomes. Afraid the risk it puts us in.  To adapt to change requires information. Information that we can use confidently to respond well.  

What is agility?
“If we take a very pure sense of what agility means, it is actually an organization’s innate capability to survive and thrive in the long run” says Tathagat Varma  in the SmartBites video “Agile  What is it really?…”

Change in Business, Career : Compass vs. Maps
Anuj Magazine in the SmartBites video “Reinventing yourself in these changing times” says:

“A extremely successful company like Nokia was wiped out when Apple launched iPhone. Why? My hypothesis is that companies that followed a compass approach as against a map approach survived. 

Compass is something that gives a sense of direction of where you should be headed to and that sense of direction comes from knowing what is happening in your vicinity, whereas Maps tell you to go from point A to point B and not worry about what’s happening around it. 

The same analogy works very well with careers as well, when we talk about careers, it is if you follow compass approach, we will be encouraged to figure out what’s happening in our ecosystem and define the next step accordingly. If we follow the map approach the career paths tend to be more map-like ‘move from SW Engineer to Sr Software Engineer’ whereas the world around is changing and you’re still happy, scaling probably the wrong ladder.”

Change in the Organisation Structure
In the SmartBites video”The changing facet of our discipline/industry” Sudhir Patnaik says:

“There is a tremendous shift towards a customer-backed approach. Everything that we do is keeping our customers in mind , the extreme mindset of product ownership and the one scrum team mindset is driving phenomenal change in how we deliver product. 

I think days are gone, when you have to develop, somebody else has to test and  somebody else has to deploy. It is evolving in such a way that every single member of the team owns every responsibility. So if I am a developer or test engineer, I own development, I own testing, I own deployment, I own support. That’s the team extreme ownership. That’s a disruptor.”

Change in SW Dev Practice
“The trends which are taking over software development, the whole software space, is in being Agile. People want to be able to deliver faster and with a lot more flexibility.

So what the tester needs to understand is that he has one big constraint and that is time. So you can try and reduce, squeeze as much time as you want if attention is being paid in the right places, you’ll still get the best bang for the buck. So I think that’s where we need to look at. We need to understand what’s happening in the world outside. We need to be able to focus, plan our work and execute to the plan in whatever limited time we have”,  says Vivek Mathur in the SmartBites Video “The changing landscape of dev – What does this mean to SW testing?”

Cadence
In cycling/running there is an interesting concept of cadence. In the case of cycling, cadence is about how many times/minute you rotate the pedal. When you move from a plain terrain to a climb (change), the speed will drop. So the natural response is expend more power by pedalling harder to maintain the speed. The challenge is that leg muscles work harder and tire out quickly. 

This is where cadence comes handy. Instead of expending higher energy, shifting to lower gears and rotating the legs (pedals) faster results in maintaining the same speed on the incline. So it is typically recommended to spin at a higher cadence to compensate for the change. Cadence is about continuous motion to enable a good response to the change. High cadence implies nimbler movement and using information about the terrains as we ride enables one to respond  well. 

How does this relate to what we do? Break the problem into smaller chunks (lower gear) and keep the problem solving rhythm going good. 

Stay agile to respond, be alive
Constant adaptation is wonderful as it results in fluid continuous motion. A beautiful feeling of aliveness. And that is what nature is about. Continuous morphing, resulting in improvements. 

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.

T Ashok @ash_thiru

Over the last few months, as a producer of SmartBites for the SmartQA channel, I asked a question to EIGHT senior software folks spanning across the roles of management, technology& architecture, QA and development.

“In this digital age, what do you believe is the role of human intellect in QA?”

The answers were different and very interesting, summarised as :

• Increased need for QA intervention at back end
• Intelligent UI automation requiring less human intervention
• Focus on back end
• Intelligent systems will augment our capabilities
• It is QA as a mindset that will prevail, may not be the department
• AI/ML may not understand business context, be the voice of customer
• Tools cannot come up with negative scenarios
• Intellect systems will foster more test innovations
• To suspect everything, think like Sherlock Holmes
• Intelligent systems will assist in making decisions
• Intellect is needed to judge adequacy
• Behave as first client
• 1000s of configuration, 1000s of customer varieties

Now continue reading in-depth from the horse’s mouth!

Sudhir Patnaik says:
With the way AI & ML coming into the play, my instinct says that there will come a time where a developer doesn’t need to write code. You just tell the chat bot the business logic and it spits out the code. In fact, to some extent it’s happening today – where the template code is ready  and you just plug in the business code. I think even in the testing world that is going to happen. Someday automation is going to be SO intelligent, point it to the URL (UI) and it will do everything. There is no need for human intervention. It self-corrects whenever the things change in the website or URL!

I think that’s where it is headed. Sometimes when we say test automation, we unfortunately focus only on UI automation. A big work piece is platform automation and companies around the world are transforming themselves to be known as platform organizations. There is more technology on the platform side. I think the human interface on the UI side will minimise, and this is where the transformation is. I see it more on the back end, as the front end is going to be driven through intelligent systems. So, our intervention as quality engineers on the front-end side will get minimised over a period of time. 

With respect to a piece of code, unit testing requires you to focus on code. And it is not easy for any computer system to understand the piece of code and magically spit out unit test code.

An intelligent software can write positive and negative test cases, but that may be about 50% of the coverage with the remaining 50% from a human. I think that is where the intellect is still needed. I don’t think chatbots will take over. Click here to watch this smartbits video.

Anuj Magazine says:
That’s an interesting question and I’d like to answer this with an analogy. Playing chess is often associated with great deal of mystique as someone having a great deal of intelligence. Garry Kasparov who was the world champion in chess for a long time wrote a very insightful book titled “Deep Thinking”, where he captures a part of his journey. He talks about his experience when he decided to play with computers for the first time despite being a world champion on a public stage in 1980s. The first match was a walkover, the first series he won without much effort and that proved that humans are still superior to computers. He played a few public matches till around 1988 and 1989 and then a computer named “Deep Blue” beat Kasparov. People wrote obituaries of Kasparov, his skill as a chess player and also of chess as a sport . We are twenty years from that time and we have the champion Magnus Carlsen who is winning almost everything that chess has to offer and a lot of people are terming him as the greatest chess player of all-time. 

If you rewind this whole sequence of things, first humans fought with the machines and won, and machines kept getting better and then machines were able to beat humans at that time. And then we are at a stage where especially in sports like chess where Magnus Carlsen, Vishwanathan Anand use computers to augment their already supernatural abilities that they have. Machines and humans are working together to make the whole sport better with lot of invincibility and lot of new people players are emerging. So this really tells a lot about what is going to happen in the existing professions as well. 

So the role of human intellect is not going to go down in any way. What will happen is, with all the automation that is happening (my hypothesis), it will return more time back to the human beings and it is up to the human beings to utilise that time to make them more better at what they do,  their professions. 

Interestingly from what I have read and observe like machines don’t need to mimic human beings to get better than them. If you look at aeroplanes, they don’t need to flap their wings, helicopters don’t need wings at all. So they will find numerous ways to get better than what we do. The engines replacing bullock cart was another example so we don’t need to have someone pushing the engine like the bullock used to do earlier. In order to stay relevant, human intellect is going to be really important. 

Even from QA standpoint it is very important for QA professionals to adapt QA more as a mindset than a department. Let me give you an example gleaned from interacting with one of the departments in my organisation hat takes care of FedRAMP certification a security certification needed to sell to the Federal Government in the US. If you look at the structure of FedRAMP certification, there are criteria that are stringent, criteria that has to be met and the people who do the certification for you are the people who are well read and well aware of the criteria and what happens around it and they follow the procedure as well as apply their knowledge to certify.

They do a lot that a QA person will do in a different context, but they are not called as QA Engineers, they are called as the enablers of certification. People should be using their intellect to enhance the QA mindset and apply that while going in different direction that QA mindset is not going to get extinct, may be department may get overhauled depending upon the way the different organizations think about the value of it. Click here to watch this smartbits video.

Vivek Mathur says:
Understanding the business context, acting as the voice of the customer are things that are not reproducible as yet and ultimately may never be because AI, ML will depend on the quality of the data that you get. What we get is a biased data, that is not representative sample of the world, but a sample of a certain subset of people and if you try to extrapolate that to everybody, you end up pushing that bias into the system and into the results of the AI as well. So it’s that human understanding, the ability to say whether this is the right thing, it is ethics of the situation, it is the humanness, it is the empathy, the emotional connect with the end user , which is the problem that we as intellectuals need to solve and that’s what we need to propagate, and that’s what we need to be the as spokesperson for, as part of the QA function. Click here to watch this smartbits video.

Srinivasan Desikan says:
Human intellect cannot be replaced at all. We talk about negative testing, we talk about positive testing, and the plethora of tools & processes can assist in positive testing, not the negative testing.  None of the case tools cannot give you the negative test scenarios. If we look at the Boeing crash that had happened, it was not a testing failure. It was only a failure of a negative scenario, which was not explored while developing the product itself. It was a nose problem, the autopilot that was running the aeroplane was trying to adjust the nose so that it gets the elevation. Rather, it put the nose too much down, and it went into a crash.

So the testing is something which should be left to 90 percent automated and at least 10% manual so that we can catch those kind of errors. So the human intellect in QA will continue to grow and we are going to have more and more automation. We are going to have more and more innovative testing that may not be in an ‘automated way’, but in a ‘manual way’ because innovative testing happens only once in a while. It is not something which is mundane that you will repeat, for if you repeat it is not termed innovation. So from that perspective the human QA intellect will continue to not only survive but grow. Click here to watch this smartbits video.

Jawahar says:
Our industry is not like other parallel Industries where after the design and validation, pretty much things can be manufactured . Machines can do this job. There are predictions that quite a few things will be taken up by machines  even in the software industry, but I strongly believe that  the ultimate deliverable of our industry is something still produced by humans and it has to be validated by humans. Pretty much the validation team will have to behave like Sherlock Holmes and the kind of intellect that he has is what I would expect the teams to have – “to suspect everything”.  It is not a lack of trust , it is trust-but-verify principle there. So I think intellect plays a very important role in both teams – construction as well as for validation teams for a long time to come. Click here to watch this smartbits video.

Arun Krishnan says:
I always maintain that analytics is a platform, AI or ML is a platform that is going to enable humans to make decisions. For example, there are already models that can predict based on looking at X-rays, the propensity of somebody having a cancer for instance, but would we  completely stop using human intellect? I think that would be a mistake, in any field. 

Recent case in point is the air crash that took place in Ethiopia, where the plane completely controlled by an algorithm. If only the humans had disengaged this, the crash may have been averted. A recent Twitter spat between Elon Musk and Mark Zuckerberg was if AI will be beneficial or pose an ethical issue. Well I am the side of Elon Musk, while Zuckerberg has a very rosy vision, which I don’t think it is at all. 

I grew up reading Asimov, the robot series, and the three laws of robotics got into me when I was a kid.  In the book the those laws of robotics were circumvented in very unique ways in certain circumstances. I read that  Google is starting to think about the ethics of AI, which means you do not only build in the ethics programmatically, but also have the human override.

 While I am all for AI helping testing, I think it still is a role for human intellect.  It might sound a little wishy-washy but I think you still have to ensure that human intellect has a veto power so that you can shut off the AI switch if you think it is isn’t telling, if it can be catastrophic. Click here to watch this smartbits video.

Sriramadesikan says:
It is always needed, it plays a great role irrespective of whatever be the level of automation, people are talking bringing in a lot of machine learning, artificial intelligence and so on, but in the end as ultimately one needs to put their brains to see what the adequacy is,  how much of the flexibility is needed in the given time with the accelerated development. Click here to watch this smartbits video.

Raja Nagendra Kumar says:
Today’s products are used by thousands of folks, here the QA role has become 10X.  QA has to start behaving as a first client themselves. It is not just about getting into the requirement, it is about wearing the customer which in this digital age which could be 100s of different varieties of customers. It is not more about “I have complied to SRS”.

Second, the cloud has given us too many configuration approaches. How do you deploy? How do you scale? How do you perform? we need to consider both the software side and the hardware side. Now all these configurations are not easy to be done,  even by QA if they want to do it manually, they have to become coders. So basically, DevOps are QA.

Need to use one’s intellect to handle so many varieties of deployment ,so many customers intent to bring to developer’s notice.. If they have any problem in testing it they have to communicate to development saying that, this is a requirement I am not able to test. Make sure that the developer addresses it because that is a good input for a great developer. If it is not testable, if it is not maintainable  which means it is not verifiable, which is not a good way to say ‘I have done’, as a developer. 

Lot of information in enterprise is coming from various sources, one is the QA, one is the support, other is production, all  they are supposed to do is the first level of filtering . “Why they were not able to capture that” and then give it in a way where developers are able to consume it faster. If they can really do that well, they are fulfilling not just a QA job, they are  representing 1000s of varieties of customers, 1000s of configurations in the cloud. All this complexity requires a lot of intellect. Need to have a dev mindset, know to comfortable with  coding. Click here to watch this smartbits video.

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.

by T Ashok @ash_thiru on TwitterS

Summary
Great code is not result of mere unit/dev testing at the early stage. It is really a mindset that is key to producing brilliant code. This article outlines ten things that a developer should be very sensitive to enable the delivery of brilliant code.

 1.Be focussed
In each code fragment, do one thing well.  Attempting to do many things can become messy! Stay single-minded in what you are solving with this code.

2.Be defensive
Accidents happen, inputs may be tainted. Prepare for eventualities, be defensive in your style of coding. After all, it is your responsibility to stay safe!

3.Be clean
Reduce clutter in code, it is just about somehow getting the code to do work. Organisation, structure matters.

4.Be malleable
Avoid magic numbers, hardcoding. Be soft and pliable so that you can modify, extend easily.

5.Be expansive
Strive to understand the larger context where your code will be used, so that your code delivers value. ‘See the forest for the trees’ too.

6.Be a good citizen
Respect the environment in which the code runs, consume resources only what you need and release them when you need don’t them.

7.Be maintainable 
Code begs changes to be done the minute you execute it. Make it maintenance friendly. Also, remember that it may just be you who will maintain the code. Well with time, one also forgets why some things are, the way it is.

8.Be efficient..
It is not just about the functionality, it is about all other ‘-ities’, like security, reliability, compatibility, performance etc. Be sensitive to these aspects while you are coding.

9.Be testable
The ability to ascertain if the code is behaving correctly is paramount. Putting it hooks to enable testability enables you to write great code.

10.Be beautiful
Finally great code is not just text that when executed, works correctly. Treat it as a work of art that you produce. Let the choice of names, the structure, the organisation have a sense of aesthetic appeal. After all brilliant engineering becomes art.

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.

Signup to receive SmartQA digest that has something interesting weekly to becoming smarter in QA and delivering great products.

[grwebform url=”https://app.getresponse.com/view_webform_v2.js?u=hzsfs&webforms_id=BxdSM” css=”on/off” center=”on/off” center_margin=”200″/]

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.