Setting the environment (especially in cases where you might be orchestrating one on the fly) for the AUT and automation can save lots of debugging time waste. Examples include setting browsers to use with settings like unblocking popups, clearing cache, browser restore settings, autocomplete features and more. OS settings like opening required ports \/ firewall settings, any installations needed might be as well.<\/p>\n

Patching<\/h3>\n

The patching and deployment process of your AUT. While this might not strictly come under the automation team\u2019s \u2018dominion\u2019, but can have a great impact on automation test runs. Errors in patching can happen especially where the process is not seasoned enough.<\/p>\n

Tools \/ Libraries<\/h3>\n

Tools and dependencies used for automation also need to be vetted. I\u2019ve seen tool\u2019s \/ library\u2019s bugs causing problems. For instance, tools crashing or giving unexpected errors. It\u2019s best to test for such possible issues during the selection process and test scalability of solutions to be used.<\/p>\n

Selection of scenarios to automate<\/h2>\n

Some tests are inherently going to cause problems during execution and be hard to maintain. Such tests are best not automated. This again is a separate subject on selection of tools to automate, here we\u2019ll mention only a few important ones.<\/p>\n

Features expected to go through major change can be put off until the feature is reasonably agreed upon and implemented. In case of rapid changes specifically around UI elements can cost more in maintenance than doing it manually the first few iterations.<\/p>\n

We talked about code complexity, AUT features can be complex as well which would also create similar problems to complex code. A very long test, or lots of different features being tested in one flow, or an inherently single complex feature can all have this effect. In many cases such scenarios can be broken down into multiple smaller cases reducing the complexity. In cases where that\u2019s not possible, might be best not to automate such scenarios, or have a strong strategy to do it.<\/p>\n

Debugging will live on<\/h2>\n

Taking all precautions to reduce code complexity and automate less complex features, following design principles, environment stability and choosing the right scenarios to automate might all reduce the number of problems you\u2019d have to debug, but will never reach the point where no maintenance or debugging would be needed. In the next post will go over tips on how to efficiently debug problems without growing a fat tumor worrying about fixing broken code.<\/p>\n<\/div>

<\/div><\/div><\/div><\/div><\/div>\n","protected":false},"excerpt":{"rendered":"","protected":false},"author":3,"featured_media":13803,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[54],"tags":[],"yoast_head":"\n