Here is a simple, but powerful quote worth reading again and again, to unearth the deeper message that it conveys: “Best practices exist for any activity – identifying them and extracting them from our experience to frame a set of easy-to-use guidelines is very essential and significant”. This wonderful quote applies to Test Scripting techniques as well. This paper is an attempt to share some of the lessons learnt in the area of Test Scripting techniques.

With very tight schedules and short deadlines always around the corner, a test script writer does not get enough time (or the motivation) to even think about writing a nicer code. His aim would most likely be to develop a test suite which works just fine, rather than aiming for a code that is flexible enough to adapt to future changes. However, if there are some easy-to-follow tips and design patterns that make one’s life easy, then any one would be more than willing to implement them while developing test suites.

This paper answers the following questions:

• What are the best practices in test suite design?
• How can I write future-proof test suites?
• Will the tester find it easy to troubleshoot when something goes wrong with the test execution?
• How can the test suite help the tester differentiate, if a runtime problem is due to test code bug or a product defect?
• How do I design test suites that are self healing, which don’t require tester’s intervention to resolve runtime problems?
• How do I tackle the common challenges with GUI test scripting?
• Should my test script be based on a test automation framework?
• If so, how do I make my test suite adapt to changes to the underlying test automation framework?
• Is there a checklist that I can use to verify if my test suite is designed well or not?
• What are the considerations to focus on, while developing a custom test script automation framework?
• How to design my test suite such that it can act as a building block to build more complex test suites?