Blog @ Codonomics

Having recently had the opportunity to work on and refactor some of the UI automation projects, I have come across many a gotchas that creep into the automation codebase resulting in not so beautiful, a little un-manageable, random-failure throwing specs. The worst of all things to expect from an automation test suite are random  failures, because it defeats the purpose of Continuous Integration in that the team stops responding to the automation test failures saying that there always is some random test that fails. So, if there is a test that fails randomly, analyse the reason for it and fix it ASAP giving due consideration to the solution that you put in place to ensure that the spec would not fail again for wrong reasons.    To aid the folks writing ui automation specs, I list the common gotchas that you should be aware of so that you do not end up making the same mistakes. And here goes the list: 1. Loving to sleep      Liberal presence of sleep() method in the automati

     Are you spending time in unfruitful, never-ending, repeated meetings to discuss the solution - the single silver bullet - that meets all of customer requirements? And do you care to get the shit out of that quagmire? The first thing to realize is that you are not on the road to MVP. Secondly, you should seek to hit the road to MVP. Lastly, read further and digest the lesson :)      Imagine God from nowhere appears in front of you and asks, "My dear, what do you want?" Would you ask for ask for just an item or an endless list of items? Without exception, each one of you would ask for the latter. The situation is no different even in the business context of the software projects that we undertake. Thanks to the excellent efforts and works of the Sales or frontline folks. The customer looks at you as an all powerful Angels if not as God. Their business wants are limitless and they expect you to solve it magically in one go.      You and your team are now in deep shit. Y