Page Object Pattern: Smart, and…
From our considerable experience in software, we’ve learned the great value of leveraging industry best practices and patterns – because the industry at large has even more considerable experience, and has a learned a thing or two! One such best practice for automated testing is the Page Object pattern.
As software engineers, we saw this best practice as excellent in its own right. But we also saw an opportunity to manifest a philosophy into a toolkit. If done well, the separation of Page Objects responsibilities (by, say a Test Architect with development experience) and the actual “test scripts” responsibilities (by someone with less or even no development experience) provides an opportunity to separate roles. By separating roles like this, organizations are able to invite people into automated testing that may not be considered for that role now.
…Leverages Your Organization
By combining a good choice in a programming language and writing excellent Page Objects for each application, it gives a team an opportunity to make the test scripts themselves as human readable as possible – ideally becoming something like a domain specific language. We believe that Python is a great language for making the most of human readability, power, and elegance. And sure, we’ve had our own internal debates about whether Python’s necessarily better than Java or .NET for learning and readability. But no matter where we’ve landed in that, Python still does well for manifesting this philosophy.
This allows organizations to consider leveraging non-developers for writing the test scripts, by migrating from written manual test scripts to simplified Python code. Sure, it won’t work for everyone. But it does open up the possibility for some organizations and project teams – and we believe the prospect of that is pretty exciting, all the way around.
Python? What About Tech Consolidation?
Why did we roll out the initial version of E-gAT in Python? What about organizations that are focused on technology consolidation efforts, to trim their platform portfolio for easier management? These are valid and immensely valuable concerns. We recognize some organizations are going to be more focused on consolidation than others. A recent article from ThoughtWorks, Implications of Tech Stack Complexity for Executives, captures one alternate line of thinking.
There’s little incentive now for large technology corporations to consolidate except, and here’s a killer irony, when the technology is dying out…
One mantra of efficiency-driven managers has been standardization, standardization, standardization. In today’s world standardization may be a direct path to calcification.
Some clients and their representatives we’ve asked have said that Python would be difficult or impossible to bring into their organization. But some clients have expressed a willingness, even excitement about introducing Python into their automated testing processes. So your mileage may vary – always do what’s best for your organization!
Coming Up Next…
In our next post we’ll cover more of the technical aspects of the toolkit. (Part 3)