SmartQA Community

To express well, choose the right medium

The medium that we choose to express our thoughts that emanate from our language-driven thinking is key to expressing well. Good expression is key to being clear and ensuring clarity in communication to others.

Any friction that can impede the free-flowing thoughts is very unwelcome, hence the medium of expression plays a vital role in the final transformation of thoughts to actionable ideas. A loose frictionless paper medium is very suited for early-stage ideas whilst a strict template/tool is more suited for capturing ideas fully and clearly.

Click here to read the full article published in Medium.


Three communication approaches to brilliant clarity

Clarity is often a reflection of the mind and great clarity implies an uncluttered mind. The style & structure of sentence matters to the way we think, understand, design, act and analyse. How we string the sentences and communicate is key to seeing everything and spotting the missing.

A judicious mix of unstructured human friendly(descriptive) storytelling approach with structured action-oriented prescriptive (rule/criteria based) approach and fact-rich visual approach expands the cognitive abilities enabling us to see the expansive full picture and also allowing us to swoop down as necessary.

Click here to read the full article published in Medium.


High-performance thinking using the power of language

This is the first article in the series of twelve articles “XII Perspectives to High-Performance QA”, outlining interesting & counter-intuitive perspectives to high-performance QA aligned on four themes of Language, Thinking, Structure & Doing.

In this article under the ‘LANGUAGE’ theme, we examine how language helps in enabling a mindset of brilliant clarity to ‘High-Performance Thinking”. Here I outline how various styles of writing, various sentence constructs & sentence types play a key role in the activities we do, as a producer of brilliant code from the QA angle.

Click here to read the article published in Medium.


3 failures of poor system operationalisation

Summary
Successful large system deployment failures is not merely due to poor testing of software. It is about poor operationalisation of software. This article outlines three major failures – Poor transition of software to end users, messed up business procedures and Data issues, the result of poor operationalisation. These have been curated from two articles.


FAIL #1 Avon : Poor transition of software to end users

In 2013 Avon’s $125 million SAP enterprise resource planning project failed after four years of work, development and employee testing.

ERP software can brag all it wants about functionality and all of the magical modules and apps you can use to make your business processes easier, but that won’t mean anything if your software isn’t actually usable. It’s all about aligning your software to your business processes, and if you can’t get staff to use your ERP, they won’t be carrying out the processes necessary to keep your business running. Make sure your employees are properly trained and transitioned into the new software, and that they want to use that system in the first place.

Read about this in detail at https://blog.datixinc.com/blog/erp-failure-stories

FAIL #2 Woolworth : Business procedures messed up

The Australian outpost of the venerable department store chain, affectionately known as “Woolies,” also ran into data-related problems as it transitioned from a system built 30 years ago in-house to SAP. 

The day-to-day business procedures weren’t properly documented, and as senior staff left the company over the too-long six-year transition process, all that institutional knowledge was lost — and wasn’t able to be baked into the new rollout.

Read about this in detail at https://www.cio.com/article/2429865/enterprise-resource-planning-10-famous-erp-disasters-dustups-and-disappointments.html

FAIL #3 Target Canada : Data issues

Many companies rolling out ERP systems hit snags when it comes to importing data from legacy systems into their shiny new infrastructure. The company’s supply chain collapsed, and investigators quickly tracked the fault down to this supposedly fresh data, which was riddled with errors -items were tagged with incorrect dimensions, prices, manufacturers, you name it.

Thousands of entries were put into the system by hand by entry-level employees with no experience to help them recognise when they had been given incorrect information from manufacturers, working on crushingly tight deadlines. It was later found that only about 30 percent of the data in the system was actually correct.

Read about this in detail at https://www.cio.com/article/2429865/enterprise-resource-planning-10-famous-erp-disasters-dustups-and-disappointments.html


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.


Role of Abilities, Checklists & Tests for Accessibility

Curated by T Ashok @ash_thiru

Summary
Evaluating accessibility by using only able-bodied people(testers) or by enabling accessibility only via use of checklists are not useful. The simplest tests to ensure a complex application is well covered via ‘only testing using the keyboard’, ‘relying on the spoken word to navigate’, ‘using high contrast mode of display’ & ‘disabling certain options in the browser’ (for web apps). This article is curated from four interesting articles.


Valid experience is vastly more important than mere simulations. Accessibility testing really isn’t so different than surgery in this regard. You want a team chock full of people who are “native users of assistive technology” (which is the nice way of saying “disabled”), and not people simulating disabilities.

says Sheri Byrne-Haber in her interesting article “Make People with Disabilities Part of your Accessibility Testing Program”.


Why would that be? Here are some of the key reasons:
Running an accessibility testing program without people with disabilities is disrespectful “..at the end of the work day, those non-disabled testers get to go back home to their abled lives. They do not experience the day-in, day-out 24×7 frustration of someone with a disability slamming head first into either digital or physical barriers every single day.”
Running an accessibility testing program without people with disabilities is neither inclusive nor diverse “…no one can legitimately claim that testing with completely able bodied testers will give you the equivalent experience of a population of people with varying degrees of disability.”
Running an accessibility testing program without people with disabilities is neither inclusive nor diverse “…not considering or using people with disabilities in your accessibility testing program is deliberate and discriminatory exclusion, the opposite of being diverse and inclusive. ”

Do read the full article here (5 min read)

In the article  “Accessibility Checklists — Just say No”,  Sheri Byrne-Haber says in the long run, general accessibility checklists do far more harm than good in establishing a good accessibility program as:

  • Checklists are part of a reactive, not proactive accessibility practice
  • Checklists are a black and white solution in a sea of gray
  • Checklists do not motivate people to think neutrally or positively about people with disabilities
  • Checklists are a crutch
  • Checklists put blinders on users
  • Checklist items open to interpretation create more problems than they solve
  • Checklists don’t lead to an inclusive culture

“Design for accessibility, train everyone who touches the content and infrastructure, and include people with disabilities in every step of the path including research and testing” is what the author concludes at the end of the article.

In the article “Three tests for accessibility“, Jonathan asks the question “given that there are so many criteria for good accessibility, and that the application itself may be complex in many ways, how do we verify that all parts of the application are accessible?” and outlines three simple tests to accomplish this:

  1. Screen-reader-only test : Try to use the application, relying only on hearing the spoken word.
  2. Keyboard-only test : Try to use the application, relying only on keyboard input. Put the mouse away or disconnect it, or disable your trackpad.
  3. Automated test: Run an automated testing tool on your application, analyse the output and address all major errors detected.

The 6-min read of this article is time well spent.

Continuing on this same train of thought is another interesting article by Karl Groves that outlines the six simplest web accessibility tests. The author outlines these as :

  1. Unplug your mouse and/ or turn off your trackpad- Interact with the site using only the keyboard. 
  2. Turn on high contrast mode- Colors on the site are essentially removed entirely.
  3. Turn off images – Images shouldn’t be required to understand the page and shouldn’t be relied upon for important UI controls
  4. Check for captions or transcripts- If you have media on your site, check for captions, transcripts, and other possible alternatives
  5. Click on field labels- Issues with forms tend to fall into three main categories: Missing or incomplete labelling, ineffective error handling, and poor focus control.
  6. Turn off CSS – Presentational methods cannot be overridden by users who’ve created custom style sheets.

Read the full article The 6 Simplest Web Accessibility Tests Anyone Can Do

Click here to read a summary of six interesting articles in accessibility..


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.



Interesting articles on Accessibility

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

Dos and Don'ts for 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.


15 Facets to Problem Solving

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.

Crisp definition of the 15 facets as a table

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

15 facets depicted as a picture  inspired by “Matrushka 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.


3 Ideas to Staying Agile – “Compass, Cadence, Ownership”

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/industrySudhir 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. 


“Use a compass. Stay in a rhythm with high cadence. Own, see the big picture.”


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.


Role of human intellect in the digital age

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.



10 things to be sensitive to deliver brilliant code

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″/]