By David W. Johnson "DJ"
SearchSoftwareQuality.com
With the advent of mature test automation tools, both commercial and open source, there is a growing perception that traditional “testers” are no longer required by IT organizations. Given the correct set of circumstances, I would certainly agree that the role of testers is being transformed, and the number of testing resources required to address any given testing challenge can be decreased. There are several forces responsible for the changing role of testers, at least for on-shore testing resources. These include:
TDD) or functional test automation. In all cases the test resource model for traditional testers is significantly reduced, if not completely removed.
Test-driven development (TDD)
Agile development processes that embrace self-testing code (instrumentation) significantly decrease the need for traditional testers. The need for testing does not go away, but as code instrumentation moves beyond simple unit testing into functional and even system testing, the need for additional testers is decreased. I would always recommend that a separate testing function test the application but the weight of this testing can be reduced, sometimes to the point of a simple user acceptance test.
Under these circumstances, where do traditional testers fit into the organization? It really depends on the current (historical) role of the “tester” and the degree of code instrumentation. Let us look at the case where the code is fully instrumented and only user acceptance testing remains. Under these circumstances the role of manual tester usually disappears, as does traditional test automation. A typically experienced tester who has been fulfilling the role of informal business analyst or SME (system matter expert) moves into the role of exploratory tester within the Agile team -- basically ensuring the business need has been met and that the instrumentation fully tests the application space. Alternately, this person may take on the role of tester as business analyst or business user. This often occurs because the business is not willing, or not able, to participate as full members of the Agile team -- leaving a gap in the Agile process that can be filled by an appropriate testing resource.
When the code is not fully instrumented, then the role of the “tester” becomes a balance between the traditional “tester” role and any new Agile development role. This can often increase the need for testers, obviously decreasing the value proposition of the Agile development process. The most effective way of mitigating this resource cost is to apply mature test automation tools and techniques to decrease the overall testing investment while increasing test coverage and overall testing velocity.
Mature test automation
Mature test automation solutions that include a fully integrated testing framework work as a force multiplier that decreases the need for traditional testers while increasing overall test velocity. This assumes the testing resources know how to effectively leverage the testing framework to harvest the maximum return.
How and what test automation framework to apply is dependent on the development paradigm being deployed and the target deployment velocity. If the development paradigm includes effective code instrumentation or effective test-driven development (TDD), then a lighter testing framework that addresses the testing gaps from an outside-in perspective would probably be an appropriate fit -- as we stated earlier, if TDD is fulfilling the need for unit, functional and system test, then no additional testing framework is required. If the development approach does not include sufficient quality checks, then a heavier (tier 1) framework would be a more appropriate fit. In either case, the number of testers will decrease and the skills required to be a “tester” will change. The tester now becomes a test designer, a test automation engineer and a tool-smith (light-weight developer).
Is automation replacing the need for testers?
Automation is certainly changing both the role and skills required to fulfill the quality verification task. In some cases the role has moved to the development team (TDD) while in other cases the focus is on mechanizing the testing process (test automation frameworks). Regardless, testing is moving beyond the creation and execution of manual test cases to:
David W. Johnson “DJ,” is a Senior Test Architect with over 25 years of experience in Information Technology across several business verticals, and has played key roles in business analysis, software design, software development, testing, disaster recovery and post implementation support. Over the past 20 years, he has developed specific expertise in testing and leading QA/Test team transformations -- Delivered Test: Architectures, Strategies, Plans, Management, Functional Automation, Performance Automation, Mentoring Programs, and Organizational Assessments.
11 Feb 2011
SearchSoftwareQuality.com
With the advent of mature test automation tools, both commercial and open source, there is a growing perception that traditional “testers” are no longer required by IT organizations. Given the correct set of circumstances, I would certainly agree that the role of testers is being transformed, and the number of testing resources required to address any given testing challenge can be decreased. There are several forces responsible for the changing role of testers, at least for on-shore testing resources. These include:
- Agile development techniques that integrate test automation into the development process.
- Mature Test Automation tools that simplify test creation, automation and test execution.
TDD) or functional test automation. In all cases the test resource model for traditional testers is significantly reduced, if not completely removed.
Test-driven development (TDD)
Agile development processes that embrace self-testing code (instrumentation) significantly decrease the need for traditional testers. The need for testing does not go away, but as code instrumentation moves beyond simple unit testing into functional and even system testing, the need for additional testers is decreased. I would always recommend that a separate testing function test the application but the weight of this testing can be reduced, sometimes to the point of a simple user acceptance test.
Under these circumstances, where do traditional testers fit into the organization? It really depends on the current (historical) role of the “tester” and the degree of code instrumentation. Let us look at the case where the code is fully instrumented and only user acceptance testing remains. Under these circumstances the role of manual tester usually disappears, as does traditional test automation. A typically experienced tester who has been fulfilling the role of informal business analyst or SME (system matter expert) moves into the role of exploratory tester within the Agile team -- basically ensuring the business need has been met and that the instrumentation fully tests the application space. Alternately, this person may take on the role of tester as business analyst or business user. This often occurs because the business is not willing, or not able, to participate as full members of the Agile team -- leaving a gap in the Agile process that can be filled by an appropriate testing resource.
When the code is not fully instrumented, then the role of the “tester” becomes a balance between the traditional “tester” role and any new Agile development role. This can often increase the need for testers, obviously decreasing the value proposition of the Agile development process. The most effective way of mitigating this resource cost is to apply mature test automation tools and techniques to decrease the overall testing investment while increasing test coverage and overall testing velocity.
Mature test automation
Mature test automation solutions that include a fully integrated testing framework work as a force multiplier that decreases the need for traditional testers while increasing overall test velocity. This assumes the testing resources know how to effectively leverage the testing framework to harvest the maximum return.
How and what test automation framework to apply is dependent on the development paradigm being deployed and the target deployment velocity. If the development paradigm includes effective code instrumentation or effective test-driven development (TDD), then a lighter testing framework that addresses the testing gaps from an outside-in perspective would probably be an appropriate fit -- as we stated earlier, if TDD is fulfilling the need for unit, functional and system test, then no additional testing framework is required. If the development approach does not include sufficient quality checks, then a heavier (tier 1) framework would be a more appropriate fit. In either case, the number of testers will decrease and the skills required to be a “tester” will change. The tester now becomes a test designer, a test automation engineer and a tool-smith (light-weight developer).
Is automation replacing the need for testers?
Automation is certainly changing both the role and skills required to fulfill the quality verification task. In some cases the role has moved to the development team (TDD) while in other cases the focus is on mechanizing the testing process (test automation frameworks). Regardless, testing is moving beyond the creation and execution of manual test cases to:
- A fully integrated testing solution within the development process -- developer as tester.
- As separate automation implementation program -- tester as test designer, test engineer, test manager and as tool-smith.
David W. Johnson “DJ,” is a Senior Test Architect with over 25 years of experience in Information Technology across several business verticals, and has played key roles in business analysis, software design, software development, testing, disaster recovery and post implementation support. Over the past 20 years, he has developed specific expertise in testing and leading QA/Test team transformations -- Delivered Test: Architectures, Strategies, Plans, Management, Functional Automation, Performance Automation, Mentoring Programs, and Organizational Assessments.
11 Feb 2011
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/11379785/viewspace-690494/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/11379785/viewspace-690494/
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
