- 1 How To Migrate To Booming Automation From Script Creeping??
- 1.1 Overcome Automation Challenges:
- 1.2 Common Misbelief around Automation Testing
- 1.3 Requirement Gathering Issues:
- 1.4 The critical parts for Test plan:
- 1.5 MindSet of Manual tester a great resistant of Automation
- 1.6 Maintenance of automation Script:
- 1.7 Framework in Automation:
- 1.8 Issue Related to Coding standard:
- 1.9 Share and Enjoy !
|image credit : http://www.athleteinstitute.ca|
How To Migrate To Booming Automation From Script Creeping??
The booming automation is necessary for every successful project. Automation testing will shorten development cycles avoid cumbersome repetative tasks and intern helps software quality.
If organized to see how manual QA can not catch complex defects , the percentage of getting such problem is higher where there is no automation support as QA spent most of the time during each release in regular testing.
The software testing group generally yields positive results early on. It is an evidence that the method of testing product has to change. With increasing project complexity and manual testing is inadequate to cover all testing,automation is the only only solution. We have one more way to cover the same by increasing manual tester.
It is not a good technique tough. Automation can reduce the human error factor completely. One of the easiest mistake to make when writing a scenario for an automation script is to fall prey to what is deferred as script creep.
Script creep begins when automator find himself armed with easy to use modules and functions and begins thinking,while I am validating the configuration settings of this functionalities,why don’t I just go to the user interface and validate the object by manipulating it with data and while I am inputting data ,why not do a little analysis testing by running a few reports and knocking those tests out too? Looking out for things which are done manually that could be automated even if not everything can be. One more issue is with the offshore testing practice is that the development of scripts are cheap but the hidden charge comes in the form of maintenance.
This becomes nightmare to troubleshoot ,especially if something at the beginning of the scripts is the cause of the failure at the end of the script. So fast response is necessary.
Here is an article to check how to make automation faster.
Every methods you use to prevent or find bugs leaves a residue of bugs against which those methods are inefficient now.So a problem can often be a catalyst for change provided that the change is seen to address the problem.
Overcome Automation Challenges:
To overcome is below are the techniques we can adopt:
- Keep the scripts small.
- Focus on one area of the product at a time.
- Take a strategic call to determine the major area of testing.
- Easy and small scripts are easy to maintain keeping maintenance costs low and automation success is high.
- We can develop our own tool and configure it such a way so that it can do what we want.
- Give testers a say in the choice and design of embedded diagnostics within the software to aid test verification.
- Don’t afraid to change based on the test scenario but also venture the anomalies that results.
- logging of fault diagonals.
- Automators and their manager must understand the timeline and set realistic expectation.
- It is always a good idea to automate bug testcases.
- Always put one function or component with only one objective in that case failures can pin point the issue directly.
If automators are assigned to a different manager who can not think broad except the deliverable(s) creates tension between team as opinion differs. Those who own the tests feels that they have hardly anything to say out the test so as the automators. This leads to creeping of testing process and eventually body wants to own it and the process fails. A clear goal which is measurable is the best starting point for automation. Realigning the roles surely helps to mitigate the risk of ownership.The creeping problem can be overcome.
Common Misbelief around Automation Testing
The second belief among management that the box states “Automatic” software testing not automated.So purchasing an expensive tool will never give us a quality test. Human effort is needed to make the tool work according to our need.Automation can really boom if the following factors are gained.
- Nature of quality management
- Maturity of quality process
- System specifications
- Test strategy process
- A clear Test plan
- A Matured system under Test
- A great automation capability
- Tools availability
- Quality test process.
All these components need to work together to achieve a great success with test automation.If one or two lacks , it will go for a toss. Automators has to take this great pain to ensure that everyone’s concern is taken care for this critical harmony.
Requirement Gathering Issues:
Requirement related problems also put brakes in automation.Ambiguous words,undefined technical term ,use of acronyms,in complete ,non complete ,non measurable quantity are inherently used that stop automation to perform at a very fast pace.Apart from these quality requirements like- availability, interoperability, maintainability, performance,portability,reliability,robustness,safety and security,usability are missing in requirement. There could be off normal behavior of the application like-fault,error and reaction, that needs to be specified in the requirement. Requirements that are constantly changing is also not good for automation.
The critical parts for Test plan:
The critical parts for Test plan: In most of cases, there is no separate test plan available or it is kind of overview (high level). it not is not very clear or specific. It is mostly One-Size fits to all document.
- Development Notes: The scope of what is to be tested and what are to be agreed and disagreed,all signed noted and dated. we can also design around dead links,incorrect file upload
- History notes-Who,what,when details. The customer has to rely on system. A faulty system is a nightmare to its client,business and to all
- Objective details
- Details test methods and techniques
- Testcase priority and selection criteria
- Shared information-Lookup tables,data,tables design and product description
- Test data
- Expected result what the system is suppose to do
- Product bug information
- Entry and exit criteria . Divide the system into small chunk and set entry and exit criteria for them basically divide and win.
- Training needed and schedule for the testing
- Tests must be executed into multiple environments.
MindSet of Manual tester a great resistant of Automation
One more contributor to the creeping automation is the resistance from manual testers,who does not have intention to write code,or help the automator thinking his job is on risk. As a result support from manual team slows down, resulting automation to creep for existence. Manual needs to understand automation is a helping hand and they will get more time to test going out of the box and find more bug. Automation on the other hand needs to look for areas of improvement that really helps manual to test other aspect of the application.
Maintenance of automation Script:
Here is an article to cope up with Sync failure.
When we run automation tests for a new release,there are two tests. one to test the real application and other ti test the suite itself. Yes , we need to test the test suite also.As it is a software for testing another software,it needs to be examined thoroughly.This paradox gives us the flexibility to test over test suite to make sure that we have a confident automation suite.It measures that how much it is realistic too.Testing the test suite should not be underestimated for a rocking automation.
For a reliable coding avoid xy coordinate based coding,We need to avoid position independent identifier. Recovery is very important for automation.
Framework in Automation:
Developing new framework or migrating to a new framework does not mean we need to scrap all our existing tests,functions or objects. All these should be retained. Even we can retain the structure too. It is only the wrappers that need to be updated. The control wrapper approach will give major advantages.It will not only minimize the cost but also becomes highly maintainable.High reliability can be achieved as all actions are performed by a small measure of reusable function with greater usage of functions. With these highly safety net bugs can be caught and reliability can be achieved.
The control wrapper has another advantage too.Once the control wrappers are built in. We can create more tests without coding the actual tests.sometimes the application responds in keystroke given by human,but fail to respond to automation test. In this problem we need to trigger or fire events via tool.A wrapper function can be even helpful to cope up with this issue.However Framework is a mechanism that gives ability to find tests , assemble them into a suite to run,execute each tests,verify expected result,collect report and finally cleans up when they are done.We can reduce the entry cost of any test design by providing a framework significantly.
Issue Related to Coding standard:
Developers tend to give same name for many objects or does not give name at all.This lead to failure such as no object found, no such element etc.Educating developers about the fact that automation greatly depends on the naming or unique identifier for the objects in application will surely help automation.
robot framework is simply the record play back framework comes free with any tool for unit testing we have Xunit testing like Junit for java,Sunit for smalltalk, CppUnit for C++,Nunit for .net and rUnit for ruby.
We need to execute our testset as often as possible.It is observed, when tests fail at a intermittent issue, real bugs is found.Test automation needs to be reliable to look at the failures.It is a good idea to run a set of tests everyday to maintain both application and test hygiene. We need to follow a 3R principal (Run->Run->Run)
When we are working on a large project, there might be scenarios, where we need to use a functionality which is already coded in another script or in a separate class. Or may be we need few functionalities in our current script or current class. This happens when our process is matured. though the functionality is same but we need to create two copies of same function. This is a real challenge for automation . The redundant code ,functions, variables not only eat up our resources but also become an overhead for JVM.
The easiest solution to overcome this kind of issue is to create public reusable functions wherever possible. Second good method is to use generic functions given by oracle(Sun).
Automation needs to establish a true confidence before relaying on them in production testing.Use of different tool to compare results will help automation to gain confidence.