Now a days, tools that help programmers quickly create applications with graphical user interfaces have dramatically improved programmer productivity. This has increased the pressure on testers, who are often perceived as bottlenecks to the delivery of software products. Testers are being asked to test more and more code in less and less time. They need to dramatically improve their own productivity. Test automation is one way to do this.
Software testers, under pressure to do more testing in less time, often find themselves rushed and eager for anything that will give them a hand. Their fear and desperation lead them to seek a "silver bullet" that will help them regain a rational pace to their work. Test automation is often this silver bullet. The fantasy is that it will make their job simpler and easier and help them contend with unrealistic schedules.
Some testers even try to develop test automation in their spare time. I have rarely seen this deliver test suites that can bear much weight.
Major challenges for GUI test automation are maintainability and reliability. These challenges demand that a software engineering approach be taken to address them. Different teams define the software development process differently. This is fine. The important thing to remember is that this process should be used with test automation as well.
Many testers do not have strong programming skills. This combined with the repetitive nature of much testing, leads people to use record and playback techniques. There indeed are many tools that allow scripts to be recorded and then played back, using screen captures for verification. The problem that always crops up is that the layouts are changed, invalidating the screen captures and then the interface controls change making playback fail. Now the scripts must be re-recorded from scratch. Record and playback tools provide an easy way to create throwaway test suites.
It is particularly hard for people who have had so much success using these techniques with character-based interfaces to understand the difficulty of using them with graphical interfaces.
Recording tests and reviewing the created code is an excellent way to learn how to use a test tool. But most successful test automators move on to more generalized testing methods.
Someone using a test tool, whether she/he has the title of tester or developer, needs to understand how to design, develop and maintain software. Test automation systems will need to be tested themselves and should be subjected to frequent review and improvement to make sure that they are actually addressing the testing needs of the organization.
Software testers, under pressure to do more testing in less time, often find themselves rushed and eager for anything that will give them a hand. Their fear and desperation lead them to seek a "silver bullet" that will help them regain a rational pace to their work. Test automation is often this silver bullet. The fantasy is that it will make their job simpler and easier and help them contend with unrealistic schedules.
Automating tests for a graphical user interface presents significant difficulties not found in character based interfaces, much less command line interfaces or programming interfaces (APIs). Graphical user interfaces tend to be made of complex components and tend to be constantly redesigned during the development process. Significant successes have been made in delivering test tools that are able to identify and manipulate graphical user interfaces.
Most experienced software testers have excellent insights into the kinds of practices that are critical for software development. They see the consequences of their developers coding before designing, neglecting code reviews or ignoring feedback: more bugs and slipped schedules. However, testers' clear insight into the development process often fades when they undertake test automation. They fail to realize that test automation is itself a software development activity and that it therefore needs to adhere to critical development practices. Like developers who are stressed for time, testers are prone to skipping steps, taking the big leap, and blindly hoping to come out with a success at the other side. But frustration and disappointment are more likely consequences. Some testers even try to develop test automation in their spare time. I have rarely seen this deliver test suites that can bear much weight.
Major challenges for GUI test automation are maintainability and reliability. These challenges demand that a software engineering approach be taken to address them. Different teams define the software development process differently. This is fine. The important thing to remember is that this process should be used with test automation as well.
Many testers do not have strong programming skills. This combined with the repetitive nature of much testing, leads people to use record and playback techniques. There indeed are many tools that allow scripts to be recorded and then played back, using screen captures for verification. The problem that always crops up is that the layouts are changed, invalidating the screen captures and then the interface controls change making playback fail. Now the scripts must be re-recorded from scratch. Record and playback tools provide an easy way to create throwaway test suites.
It is particularly hard for people who have had so much success using these techniques with character-based interfaces to understand the difficulty of using them with graphical interfaces.
Recording tests and reviewing the created code is an excellent way to learn how to use a test tool. But most successful test automators move on to more generalized testing methods.
Someone using a test tool, whether she/he has the title of tester or developer, needs to understand how to design, develop and maintain software. Test automation systems will need to be tested themselves and should be subjected to frequent review and improvement to make sure that they are actually addressing the testing needs of the organization.
All the Best
No comments:
Post a Comment