Can software test automation ever replace manual software testing? Dion Johnson says no, but he does think it’s time that test automation is recognized as a mature discipline with its own body of knowledge. This ABOK allows test-automation professionals to hone their skills and provides organizations wishing to automate a pool of able resources from which to hire.
Can software test automation replace manual software testing? My answer is no, and my research suggests that other software quality engineers agree. Test automation will forever be connected to manual testing because ultimately it is the offspring of manual testing. Some level of manual logic is developed and implemented prior to the implementation of test automation, therefore test automation is a child born to support manual testing. As with all children, automation is growing up and becoming its own individual discipline. And if automation were a person, it would be screaming, "I'm an adult; stop treating me like a child!"
This tantrum would be justified, because the industry as a whole does not treat software test automation with the respect that it deserves—and we are all suffering for it. When software testing was itself a child, it went through some of the same growing pains. Testing used to be addressed simply as debugging and was treated as just an extension of its parent, software development. But testing has finally grown up and is garnering some respect through widely accepted models, bodies of knowledge, and industry-standard certifications.
Chaperones
One of the signs of a discipline's maturity is a widely accepted body of knowledge. But the test automation discipline currently is featured only as a minor player in existing testing bodies of knowledge and tool-driven certifications, much like a child being chaperoned on a field trip. With general testing and automation tool bodies of knowledge babysitting automation, it's extremely difficult—if not impossible—for automation to expand as a profession and likewise for organizations and individuals to grow.
When an organization is looking to hire a test-automation professional, there is little to distinguish one potential resource from another. A testing body of knowledge only reveals that the potential resource may know a little automation vocabulary; it does not show that he has demonstrated the ability to effectively and efficiently employ automation knowledge in a real-world, software-testing environment with complex applications, resource constraints, and process challenges.
Freedom
Test automation has its own body of knowledge, and the acknowledgment, acceptance, and growth of this automation body of knowledge (ABOK) will give automation the freedom it needs to expand as its own discipline. The ABOK is composed of the following skill categories:
Automation's Role in the Testing Lifecycle— Includes planning-related items that are often overlooked—yet extremely important for test automation success—such as addressing automation misconceptions, automation scope, and calculating automation ROI.
Automation Types— Identifies some of the basic types of test automation (functional, unit, integration, performance, etc.) and the fundamental differences among them, which are important even if you don't specialize in all of them.
Automation Tools— Expands the vision for test-tool implementation by identifying several options—commercial and non-commercial—and by revealing steps for performing an effective evaluation of these options.
Automation Approaches/Frameworks— Di scus ses the different approaches/frameworks that may be used for test automation, including data-driven, functional decomposition, and keyword. Awareness of these approaches, together with their pros and cons, is pertinent for building maintainable automated tests.
Automation Framework Design Process— Addresses an efficient, repeatable process for building a suite of automated tests, which will allow for faster, more effective automation over time.
Programming Concepts— Covers fundamental programming concepts—such as variables, control flow statements (if ... then ... else, for … next, etc.), and modularity—that can increase system coverage and test flexibility.
Automation Objects— Addresses key object terminology—object maps, models, and properties—and the understanding of object dynamics. If the tool or script can't access objects, the application can't be automated.
Debugging Techniques— Addresses techniques, such as backtracking and problem simplification, that will aid in identifying and
| Attachment | Size |
|---|---|
| 1.55 MB |







