The topic is about what constitutes a good automation script – its content and style and structure.
Takeaways from your topic
The benefits of a test automation framework cannot be over-emphasized. A good automation suite serves to make testing easier by reducing (manual) testing time, minimizing human errors, making the tests repeatable and thus increasing efficiencies.
In addition to all of the above, it is also important to ensure the test scripts are robust and effective. A well-written automation script should have the following features:
A good script should have plenty of comments written in simple language. The code should also be indented appropriately, so that one can visually segregate different functional units of code (loops, switch statements, etc.). Using meaningful names for classes, methods and variables makes it easier for the reader to understand their purpose.
When a problem occurs during execution, the test code must be capable of handling it gracefully and also communicating that error to the user properly. In some cases, the user needs to catch the exception and react to it, instead of just exiting the program.
A good test script should allow for extension and scaling in future. As new features are added or existing features modified in an application that is being tested, it becomes important to modify the test code accordingly. This can be achieved by adding/modifying child classes, each doing its own specific task, with common tasks in the base class.
Like said above, having different pieces of functionality separated into their own classes or methods is important, as it makes the code easier to understand and troubleshoot. It also makes it more maintainable.
A good test script should write out the progress of the test execution to an external logging application or at least to a text file. This is very helpful to see the extent of the test execution, the results generated and also any errors or exceptions, thus making it easier to troubleshoot. If a real bug is found, the contents of the log that are relevant can be attached to the bug ticket and helps the developers get more clarity and context.
More often than not, applications have several form fields that have to be filled with data like addresses, phone numbers, names, email addresses and so on. So a test script capable of taking in data from an external CSV or Excel file makes it very convenient to excecute tests over and over again with various values and formats, thus making the test more robust to handle field validations.