Testability & Collaboration

Do you ask your developer often “Hey, How do I test this ?” If yes, then here are some inputs to you.

Every piece of software must have interface to test it. As illustrated in the picture — although bicycle is ready, without a handlebar it would be extremely difficult to ride it. In the same way every story or piece of requirement must have an interface to test it.

Building “Testability” into the software is neither outside of development scope nor optional.

The invest principle is a constant remainder of this. Where “T” stands for “Testable”.

So what should a QA engineer do ?

1. In your sprint planning meeting always make sure that — every story that gets discussed is testable
2. If a story is not testable, highlight the same & make it as scope of the story.
3. If you are too late, then collaborate with team to make it testable. Test it and automate it :)

I faced a weird problem while automating a mobile app. Realised that it is not testable and solved it by collaborating with team. Here are the details.

We are in the process of creating an automated test harness for a “hybrid app” using Optimus. Hybrid app means you have both native and web contexts. We need to keep switching between native and web contexts to automate a scenario.

Well, this is pretty easy, as Appium has good support for this.

public void switchToWebContext() {

    Set<String> handles = driver.getContextHandles();
    for (String handle : handles) {
        if (!handle.equals("NATIVE_APP")) {
            driver.context(handle);
        }
    }
}
public void switchToNativeContext() {
    driver.context("NATIVE_APP");
}

However, I ran into a problem as there were multiple Web-Windows when switched to WebView as shown below

Multiple web windows in webView

Multiple web windows in webView

Firstly, you might ask why there are multiple web-windows in first place ? Well this is by design. The application has multiple web-windows for caching & performance reasons. This is to avoid any possible lag in user’s experience, when switched between multiple windows or questions in this case.

The problem I faced is that, the actions I was performing on web-window (after switching to web context) was happening on a random web-window, as there are multiple web-windows available. All of these web-windows are visible and active. The Appium commands were picking some window (not necessarily which is on top) and hence the actions were not happenings on the intended window or window on top.

So, I need to switch to correct window before I perform the action. We have below methods to switch between windows in web-view. This is not a problem at all.

Set<String> windowHandles = driver.getWindowHandles();

&

driver.switchTo().window(handle);

Problem is, how do I determine which one is the correct window ( or window on top, or the one being shown to User ) ?

This can only be determined by introspecting the content of the web-window. Either its title or some specific element in the window. The approach is to iterate over all the web-windows and find an object which we are looking for. But the problem is that, the content of the web-windows are dynamic and we can not depend on the data to identify the window on top.

This closed all the doors for me to automate the scenario. All that I was needing is mechanism to identify a window which is on top (which user is seeing). The “testability” aspect was limiting to automate this scenario. Next step is to “collaborate” with the team to make the app testable.

We discussed the problem in detail with developer. He understood the problem and we made a tweak. As part of this tweak we appended a piece of text to the title of active window. This helped us to identify window on top with below code.

private void switchToActiveWindow(String activeText) {

    Set<String> windowHandles = driver.getWindowHandles();

    for (String handle : windowHandles) {

        driver.switchTo().window(handle);

        if (driver.getCurrentUrl().endsWith(activeText)) {
            return;
        }
    }
}

In summary, when “Testability” is missing use “collaboration” to build it. :)