Home › Knowledge Center › Industry Insights › Functional Testing Automation - Myth Versus Truth

Functional Testing Automation - Myth Versus Truth

The top 10 Myths of Functional Test Automation
 
Myth 1:  Automation will reduce head count
Truth: The value of automation is not reduced headcount but in finding defects faster, greatly expanded test coverage with the same number of testers and the ability to uncover defects that manual testing cannot.
 
Myth 2: Automation is just another management control
Truth: While it is critical to have buy-in from management on the value of automated testing it should not be perceived as a management tool. This is a surefire strategy for failure.
 
Myth 3: Automate it all
Truth: It is impossible. It is important for organizations to recognize that not every scenario is suitable for automation, and that automation isn't always the most effective way to find all software defects.
 
Myth 4: My automation process has 100% code coverage, all the tests pass; therefore, there are zero defects
Truth: Automation or otherwise zero defects is something that is utopian. The fact is also that functional test automation is just one of the tools available to assist in software delivery it is not the only tool.
 
Myth 5: Goals for all testing projects are the same
Truth: Goals will vary based on the type of project, just as the type of testing will vary.
 
Myth 6: Successful testing and test process automation happens in giant leaps and bounds
Truth: It is an incremental approach that necessitates the maturation of all three – people, process and technology.
 
Myth 7: Having a broad collection of individuals involved in testing especially automation testing will only complicate it and is not a successful strategy
Truth: While developers, product architects, analysts, and engineers may all have the same basic educational background, it is only natural that they all tend to have different strengths that will make them try to break the software in as many different ways.
 
Myth 8: Automation can be put off to the end of SDLC
Truth: be it testing automated or not it should go in tandem with development. In short involve test process throughout the SDLC. The trick is to be agile with your testing. Also a  key value of automation is to create regression tests to retest the functionality that was broken and this is possible only if started early (unless the project deadline is a mirage!).
 
Myth 9: One-tool-fits-all
Truth: Multiple tools work for multiple organizations and there is no such thing as a one-tool-fits-all. The dependencies include technology, organization process, culture and the people that will be using it — their skill sets and technical know-how.
 
Myth 10: It is OK not to involve users in testing
Truth: While there is no substituting the fact that the team carrying out testing should have individuals who have been trained specifically on testing it is valuable to involve users in testing.