Automating Without Access To The Application

I had the opportunity to be a part of a Corporate Banking project recently. I was involved in leading the functional automation testing part of the project. I found it to be a very exciting and challenging form of testing since our automation engineers did not have access to the application under test.  I wanted to share my experience in this post.

How can one automate an application without accessing the application? Confused?

The problem was that the client did not want to provide application access to the offshore team because of security concerns. We suggested setting up an isolated environment offshore, but unfortunately, that could not happen.

The deadlines were looming closer and we still did not have access to the application, so here’s what we did.

  1. We arranged a WebEx session with our onsite team member and asked him to record the functional flow using HP Unified Functional Tester (HP UFT) with the “record active screen” option “ON”.
  2. The recorded scripts were then transferred offshore.
  3. We opened these scripts offshore and started identifying objects with the existing recorded repository and also captured objects using active screen.
  4. Thus, our Object Repository was ready.
  5. After this, we started creating functions using the object repository and created test flows.
  6. After completing an automated flow, we transferred it to our onsite team member and ran the flow (without accessing the application).
  7. We were surprised that our entire flow executed successfully in a single run without any errors.
  8. We understood exactly what we needed to do in order to complete the project on time.

Completing this task was very easy for us since we already had a corporate banking repository of 4000 automated test cases and our own framework (ZenFRAME). We created Object Repositories and functions, attached those to the framework and updated the test flow in the framework …that was it! We delivered and deployed the framework in the client’s environment, setup the application URL and were ready to run our complete test suite.

The execution of our first test suite for a specific module in the onsite environment was very smooth. All the test cases executed successfully, and the result log was created in the framework.

So, this was the issue I faced and the solution I came up with. Please feel free to share any other solutions you know of for the issues mentioned above. Also, please feel free to share other issues that you faced and if possible provide the solutions that you came up with. It would be great to know other people’s experiences. Happy Testing! 🙂

Hemant Jadhav | Zen Test Labs


2 thoughts on “Automating Without Access To The Application

  1. Thanks for sharing. I would assume the same concept can be applied to other tools (for desktop and web testing) like with Selenium IDE recordings and converting/refactoring as code.

    One thing I’d like to add is that without a recording capability to facilitate initial creation of object repository and test flow, one can still build from scratch effectively basing on screenshots and/or mockups of the GUI along with knowing the UE/UX navigation flow between pages, etc. using page object modeling or similar techniques. The only thing you don’t have at your disposal in that case is readily identified element/object locators/identifiers on the screen. Therefore those may need to be filled in or tweaked later on. But when well designed from good code modeling, the flow and action logic will work flawlessly provided the eventual object locators are correct.

    This mockup/screenshot modeling approach I mention is also useful when the system/application under test (e.g. or specifically it’s UI) is not available for testing yet. As using this approach, one can start automation development early and/or in parallel with actual application development rather than wait for the application/UI to be ready to start automating. Taking this approach, we would only need to fill in and tweak object locator values after the UI is done. In other words, the object repository is already built (based on mockups), except it’s values are to be defined at a later point in time when UI is available.

    • Hi automnator,

      Yes, I agree with you. The same concept can be applied to other tools such as Selenium.

      I like your idea of facilitating the initial creation of object repository and test flow using the same approach. Yes, with this approach one can begin the development of automation scripts in parallel to application development. Also, taking screenshots and using the page object model approach for scripting is a good point. The object repository can be tweaked later when the actual application is available.

      Based on my experience, the only issue is that some objects look different on the UI (For e.g., I have seen applications where the text box is displayed as a dropdown combo box) which can be confusing while scripting. Also, some iframes and light popup boxes have to be identified using object spy. However, I like your suggestions. 🙂

      Hemant Jadhav

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s