We are developing Page Object Model Framework for our web application test. The problem is we are having three different structure for the same page type. We want our automation to work in all cases. What is the best way to handle these scenario?

  • 1
    Are you saying (1) by design, your pages have three different structures, or (2) your developers change the page structure frequently? – user246 Jun 7 '14 at 0:12
  • Developers change the page frequently. And different environment has different version of the page for testing the backward compatibility – user2680325 Jun 7 '14 at 1:50
  • Do you mean a layout of a page changes frequently or even elements are moved between different pages? – dzieciou Jun 7 '14 at 3:43
  • 1
    I am not sure I understand your real problem, maybe you can give more context why the Page Object model is not working for your case. What problems do you run into with these three different structures? (maybe you can provide examples) As a side note, do the developers update the tests if they change the page? – Niels van Reijmersdal Jun 7 '14 at 11:09
  • You should always automate your test for the shipable version of application only. Those under RND shall not be automated, as you need to understand the cost of automation is very high. – cL83 Aug 15 '14 at 9:55

My first advice is to not write automated tests for pages that change frequently. You may be better off testing those pages manually.

If you insist on automation, think about which aspects of the pages do not change, and write classes to model those aspects. For example, if forms always consist of text fields and a submit button, you can write a class to model that. Or if your submit buttons always have the same CSS class, or always have the same ID, you can write a class to model that.

| improve this answer | |
  • 6
    A solution somewhere between automate and not automate would be to automate tests of an API, if that's a layer that is more stable. – dzieciou Jun 7 '14 at 3:44
  • yes I agree, Until meaningful amount of features are stable, your efforts will not go in vain. – Siva Jun 7 '14 at 8:21
  • 2
    Not automating sounds like a good choice here - if you try to automate something that changes that much you'll spend all your time trying to catch up to the latest changes and never really have any meaningful automation. – Kate Paulk Jun 9 '14 at 11:11
  • 2
    Automation makes the most sense when the interface stays the same but the implementation changes. It makes the least sense when the interface is always changing. – user246 Jun 10 '14 at 2:01
  • 2
    @user2680325 - automated testing will consume more time than manual when the interface changes constantly. Automate against the pages that don't change as much as you can and wait until the others stabilize before you automate against them. – Kate Paulk Jun 10 '14 at 11:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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