P2P

57 I L T A N E T . O R G test data and utilizing results to improve software quality. Automated testing is most often used for regression testing or functional testing where there is a repeatable process that can or needs to be performed over and over. Myths of Test Automation • It always results in improved software quality. • Test automation is simply the capture and replay of a manual test process. • Every application is ripe for automated testing tools. • Test automation is an all or nothing proposition. • Once automated, no manual execution of tests is required. Realities of Test Automation • It only supports execution of testing and only automates what you tell it to. • Higher initial investment is needed, ROI is achieved long term. • Skills and training are required to implement efficiently. • Some manual testing is still required - user acceptance testing, test cases that require manual intervention, exploratory testing. Even the best automation will never completely replace manual testing, because automation is about predictability and repeatability, where users are inherently unpredictable. We use test automation to verify what we expect and use manual testing for what we don't. • Continuous investment is required, maintenance as applications and environment evolves. • It can be targeted to one specific application or suite of applications or monthly Microsoft patch testing. Test automation takes advantage of all the years invested in process test refinement out in the industry, it's not as simply as simple as copy and paste. Even in the most mature testing projects, you have to ask a lot of questions to understand how the team executes the tests manually and the parameters of the test itself. You have to know what you are testing for before you automate it. T all goes back to quality assurance fundamentals – know your business problem, write requirements to solve that business problem. In this case, you have to match your testing requirements when you automate, not just duplicate existing test cases. Test Strategy and Plan Test Automation is fundamentally different than manual testing, there are completely different issues and varying opportunities when considering it. Step one is to align to your larger IT goals. Then, as with any testing, you need a clear test strategy and plan, understanding the goals of the application(s) you are testing, the scope, depth and breadth of testing you need and how you will remediate problems. Your test approach and tool selection will be different if you are automating the testing, and the timelines in the plan will reflect the changes in test engineering and execution. Test Design Test design practices need to be followed for test automation as with manual testing. The design identifies what makes the most sense to automate and will lead to successful execution. The more experience you have with testing as a discipline, the more successful your automation project will be. Test Process and Execution Test Automation follows the same process flow, from strategy to execution, you can reuse a lot of the test processes in place. The goal is to replicate the test execution process, generating a number of benefits. This is the main area where things differ for test automation, as the tests will be executed by a tool instead of an individual. It is important that the tool executes to same level of quality and tests are refactored so the cadence of quality is maintained. Test Follow-Up Again a similar process to manual testing, even though results are generated automatically. Review of the test summary and defect analysis still required, and remediation of defects follows.

• Cover