How can automation be done from Sprint1 in agile environment, since there is no UI from which we can identify objects with different locators?

  • This question is garbled -- would you mind cleaning it up? It's better for you to do it than for us to guess at what you meant.
    – user246
    Jul 19, 2016 at 1:27
  • Done....pls check
    – DexterMe
    Jul 19, 2016 at 1:38
  • Why would their be no UI in Sprint 1? How else would the user interact with the system? And if the user can't interact how do you finish any user stories? Jul 21, 2016 at 12:52

3 Answers 3


Some of the things you can do:

  • create a documentation page for the project with best practices ( automation flow, code review standards, automation framework structure, coding best practices, CI process, execution and debugging )
  • setup the automation repository
  • setup for how the data is generated
  • review and add improvements in the automation framework
  • create jobs for CI if you plan to use it this way
  • you can start with a mapping of the objects if you have some documentation(like wireframes or acceptance criteria)
  • you can even start to define tests if you have any kind of documentation
  • you can start plan the automation and think outside-in, start high level and set a base to build upon
  • estimate if you will have any additional costs that the management team should know ( mailing service, execution of the automation suite using services that provide cloud solutions like SauceLabs, BrowserStack, AWS)

For example if you are using a framework with support for BDD then you can define your scenarios at first and start implementation later.

  • +1 for defining scenarios first, then implementing them later. The majority of the value of writing acceptance tests early comes from the definition of the scenarios. It doesn't make much difference in practice if the implementation is done before development starts, one hour before development finishes, or 4 hours after development finishes. If you have sufficient product definition, you could also implement the tests, but leave tidy configuration parameters for IDs to be filled in when the UI is completed. Jul 20, 2016 at 0:18

It is notoriously hard to automate a UI that does not exist yet. In theory, if you and the UI designer work closely enough, you may be able to at least spec out your tests before the UI exists. I have never seen this happen in practice.

There are other kinds of automation, though. For example, you could write automated tests against APIs, or automation for installing software, or automation for creating test data.

  • +1 for mentioning other forms of automation - especially since UI tests should be the minority of your testing, and as many tests as possible should be pushed to lower layers of testing. Jul 20, 2016 at 0:20

Automation is not limited to the UI.

Developers can start automating unit tests from the very beginning.

The team could automate constructions towards Continuous Integration.

Then, when the project is on a posterior stage you could start automating UI and Acceptance tests.

  • Thanks for your answer, so that means by the time developers come up with UI deployment, we can create framework and write code, leaving object identification blank?
    – DexterMe
    Jul 19, 2016 at 1:51
  • Not necessarily. If your team know you're going to automate the UI in the future you could agree on a "standard" to identify objects since the beginning. Jul 19, 2016 at 1:54
  • Also. Have in mind that UI automation is really hard to make and harder to maintain through time. So, think deeply if that is what your project need? Jul 19, 2016 at 1:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.