Why test automation projects seems graveyard

Why Test automation fails?

·         Unrealistic Expectations
Whenever a tool or a product fails to perform as per the expectations, it is quite obvious that we blame the tool. However, we need to check if our expectations of the tool has been correct/accurate. Here are some typical unrealistic expectations heaped on automated testing tools –

• Now that we have invested in this tool, we will get immediate ROI.
• We have purchased a leading pre-scripted testing tool that will do everything at the click of a button
• With this software, we can automate the entire process.

It is very important to understand that implementing an automated testing tool is another software project and it requires lots of planning, thoughts and experimentation's to make it work across various testing environments.

You cannot run automated scripts without the knowledge of software coding, so it is extremely important to allow your team to master and perfect their coding skills before using these scripts.

·          “One size fits all” mindset
Another major reason for test automation failure is a prejudice that one condition suits all. Test automation is not a “one size fits all” operation and it should be updated to address changing parameters. Eye for detail and patience are two traits required for making testing automation work as per your expectations, and it requires continuous improvement.

·         No understanding of manual testing process
Automated testing is perceived as a magic bullet that will function even if you don’t have an understanding of manual testing. It is important to know that automatic testing is actually a continuous extension of manual testing. If you don’t how the tool will fit in the grand scheme of testing, you cannot automate the testing, believes Mike Kelly – a leading software expert with a Fortune 100 company.

·         Automated Testing is Easy and Doesn’t Requires Inputs
The key misconception about the automated testing is that it is extremely easy and doesn’t require any inputs. You cannot simply automate an existing test process, instead you have to rethink and reconsider the whole approach. Which tests should be manually tested? Which tests should be automated? This differentiation will definitely help you to seek benefits from automated testing.

      Automate tests when

§  Business critical paths – the features or user flows that if they fail, cause a considerable damage to the business.

§  Tests that need to be run against every build/release of the application, such as smoke test, sanity test and regression test.

§  Tests that need to run against multiple configurations — different OS & Browser combinations.

§  Tests that execute the same workflow but use different data for its inputs for each test run e.g. data-driven.

§  Tests that involve inputting large volumes of data, such as filling up very long forms.

§  Tests that can be used for performance testing, like stress and load tests.

§  Tests that take a long time to perform and may need to be run during breaks or overnight.

§  Tests during which images must be captured to prove that the application behaved as expected, or to check that a multitude of web pages looks the same on multiple browsers.

More repetitive the test run, the better it is for automation.

Not to automate tests when

§  Tests that you will only run only once. The only exception to this rule is that if you want to execute a test with a very large set of data, even if it’s only once, then it makes sense to automate it.

§  User experience tests for usability (tests that require a user to respond as to how easy the app is to use).

§  Tests that need to be run ASAP. Usually, a new feature which is developed requires a quick feedback so testing it manually at first

§  Tests that require ad hoc/random testing based on domain knowledge/expertise – Exploratory Testing.

§  Intermittent tests. Tests without predictable results cause more noise that value. To get the best value out of automation the tests must produce predictable and reliable results in order to produce pass and fail conditions.

§  Tests that require visual confirmation, however, we can capture page images during automated testing and then have a manual check of the images.

§  Test that cannot be 100% automated should not be automated at all, unless doing so will save a considerable amount of time.

Not enough specifications : Software solution providers concern

“Man invented language to satisfy his deep need to complain.”  Lily Tomlin

Software Engineering community's most evident complain: 

" The client doesn't want to write the specifications"

Most common complaint from QA , development and design teams is:  .

“The client / product owner must write the detailed specifications by himself”

This complaint is based on certain assumptions; we assume that the client is expected to propose a solution to his or her own problem - the very problem that your software was supposed to address.

If the client writes the specifications he won't benefit from something called diversity. Cognitive diversity comes from groups of heterogeneous people working together. For instance, Client / Customer needs the advice of engineers that know the technical aspects of the problem that he wants to solve. Client also needs a QA to spot edge cases that no one else noticed. Else, he may come up with a solution that is much more complex than it needs to be.

Alternatively if client can propose a solution, do we really need such big engineering teams to solve the problem?

It's unfair to complain about something that we, as the development team, are supposed to help our clients with.

Agile development if implemented with honest effort, this problem may be resolved up to certain extent.

This story to continue.....

 I shall appreciate you addition or improvisation.

Inception of a Dream AAP

 

Should AAP face the challenge and form the government in Delhi? As a common man: 'Yes', if you participated in electoral politics, why not? We Indians are highly impressed by talkers, irrespective of whether they have intension to do. Here AAP got opportunity to prove that they are not only talkers and can be doers if assigned a task. AAP has chance to live upto dreams of Indians lesser corrupt system.
A dream within a dream:
The movie "Inception" captured the imagination of audiences world-wide . The whole concept of planting of an idea that is nurtured in the mind was something new . While the concept is exciting it raises the question as to when and how do some things really begins.
One such thing, that is real today AAP gave hope to common Indian citizen who at least want to see someone working differently. Success of AAP raises two important questions
1. Traditional parties lack at some vertical and unable to provide solution to the problems where are expected.
2. Awareness of people is getting better.

During my writting process now it is clear that AAP is forming government, we all must congratulate them, they are better aware that outside support is a honey trap but whatever obstacles are, people have faith in them. With limited understanding as of mine I fail to understand what purpose is solved by practicing over simplicity (read declining Beacon Vehicle’s and official allowed residence) , I feel it is easier for system to support in case you follow procedures. Most of common Indian don’t want to see AAP fail, you have created HOPE at time when people started feeling disaffiliated from government functioning.
One of the most important behavior of both main stream political parties in India is : they never appreciated any good deed by their opponents, if someone call you always wrong ,  you should not listen him, he is dishonest.


We hope that AAP be active in Indian political scenario with their original tannest and values, hope to see changes in functioning of older political entities and how they transform themselves to face AAP challenge.



Thanks you all for reading , hope you help me to write better.
Satyakam