Forum Discussion
If the AUT under test is relatively small, yes, this works well. But the more complicated the AUT, as Colin_McCrae mentions, the more burdensome creating and maintaining a POM becomes. I prefer my classes for my framework to not be based upon the page, but based upon the specific action I want to execute. The framework that I started sometime ago works with this structure but it's flexible enough to either be based off a POM or off something more low-level as Colin has designed.
One thing that I do agree with is that any good, agile-friendly framework should move away from the each test being it's own code routine/keyword test and having something a lot more modularized in the code structure. Break a test case down into component steps (as much break down as you want), write reusable code for each of those component steps that can be re-purposed in multiple test cases, and drive that code from some sort of external data source. This then abstracts the tests from the code. Tests are in the data, the code simply uses the data to determine how the test is run.
Now... this seems simple, but it isn't, because it requires a completely different way of looking at test automation than what is normally deemed "acceptable". Test Automation IS development in this paradigm because the majority of the test automation work is done via code, leaving the creation of the test cases themselves open to anyone, regardless of technical background. A non-tester person, given sufficient documentation, could add a test case simply by adding more rows to the data source. And, if the framework is written well enough, adding those rows could even be pretty plain-language. "Enter myUserName in textUserName on pageLogin" can be parsed out into the necessary parts to do exactly what it says.
Yep. My automation framework pretty much fits in with tristaanogre's final paragraph.
Once I develop all the handlers, get the name map in place (and robust) and add on any extra "stuff" that falls outwith the big two, any tester should be able to add new tests (well, test steps really ..... many steps comprise a test) to the input sheet. And it accepts as many input sheets as you want. Which can be added and removed at will. And steps within each sheet can also be switched on and off at will.
Takes a lot more setup work to abstract the code almost completely from tests. But worth it in the long run. And I would put it down more as a development task than a testing one.
Hence my job title of "Non-Functional Test Engineer". (Although automated tests do, of course, carry out functional tests, the work to actually build all this is outwith the test job remit. And I also do performance and load testing. And I'm hoping to add penetration testing, at least to some level, to my armoury at some point as well ...)
Related Content
- 4 years agoAutomation1id
- 11 years agomurugans1011
- 3 years agoMoUddin