Progressive Mobile Test Automation

Progressive Mobile Test Automation
PREPARED BY:-
Rakhi Jain

1. Contents
......................................................................................................................1
......................................................................................................................2
8.About the Author..................................................................................................10
I want to share a synopsis for the implementation of Progressive automation in mobile testing area
which is supporting browser based or native application testing.
2. Motivation for this Research
Mobile testing comes with a package of challenges in which testers need to cope up with device
variations, OS specific testing, application versions, security and a huge test bed.

Mobility does need more testing effort for the same set of functionalities which are pretty easy to test
on a non-mobile application. Automation can ease the life to a certain extent but in long run when
multiple modules and different builds are available to test on various devices & platforms, even
automation testers feels that it is challenging to automate regression test cases.
Usually the mobile application development follows Agile methodology which adds more hassles in
life of functional and automation testers due to strict and short QA cycles.
Due to all these pain areas I thought why mobile automation can’t go hand in hand with development
sprints. This will eventually help retiring manual testing effort at greater extent. Also it will make the
automation simple & current and scripts can also bear the variety of builds, OS versions, devices and
platforms. As the testing progresses with the development sprint, I thought of naming this testing as
Progressive Mobile Automation Testing.
I recommend progressive automation in mobility as it’s a well-known automation method which is very
close to application development. If changes occur in application UI during various sprints, automated
scripts remains least impacted when the said approach is followed.
3. Traditional Agile Based Mobile Automation Testing
A regular agile development project includes various releases which are further divided in different
sprints. Sprints are usually followed by a “Release Planning” phase in which the release backlog is
generated from the product backlog. Creation of release backlog is usually done by product team and
business analysts (BA).
Once the release backlog is ready, sprint starts. In sprint planning developers, QA (functional) takes
part along with product and BAs and create the sprint backlog. Here developers and QA decides
about the stories which they are planning to pick in the current sprint. In this traditional modal,
automation QA does not play any role and they never take part in release or sprint planning meetings
as well.
During various sprint developers and functional QA works hand in hand and retires the stories which
are pickup in sprint backlog.
Automation QA starts the work after the completion of one sprint and always remains behind at least
one sprint in a release. This difference of number of sprints varies and depends on project as well. He
continues the script creation and execution for prior sprint stories in current sprint.

Figure – Traditional Agile Automation Testing
Benefits for traditional agile automation testing are as follows:-
1) Automation QA gets ready made functional test cases on top of which they can do scripting
2) Functionality gets stable for a prior sprint stories
3) Ease of automation
Main drawbacks of tradition agile automation methodology are as given below:-
1) With the increase in number of parallel sprints, builds, devices, platforms this methodology fails
miserably. Automation usually falls back couple of sprints behind even after adding more
resources
2) More and more script maintenance is required as the application evolves
3) Can’t target emulators, devices and desktop browsers all in one automation suite
4) Usually suites only to desktop browser automation

4. Recommended Progressive Mobile Automation Testing
I recommend automating the functionality in same sprint in which its development and functional testing is
going on. The only difference which needs to bring in is that automation resources will be aligned in project
team right from very beginning. From Sprint1 itself the automation of stories will start.
Figure – Progressive Mobile Automation Testing
Following are the key points which need to be considered which will make the mobile (or any application)
automation – “Progressive”.
1) A functional tester should be part of automation team which will guide automation QAs what
exactly needs to be automated. As functional test cases won’t be available in the starting of
sprint, this functional tester will guide the automation resources to write meaningful automated

test scripts. He will also work hand in hand with application’s functional QA resources so that he
can give timely inputs to automation resources about the test cases related changes in any story.
2) The function tester aligned in automation team and an automation person will take part in sprint
planning meetings so that they are aware what is developing the current sprints. In this way that
dependency to get the functional test cases from manual QA can be avoided
3) Automation stories will also be taken out from sprint backlog in the sprint planning meetings to
better track the testing progress
4) Creation of automation scripts and C# DLL (which will talk to automated test script) will start write
from the starting of each sprint. How this approach needs to work out, we will see this in
subsequent sections
5) At the end of sprints in each release when there is a lead time to start the further release,
automation QA will stabilize all the automated scripts by doing multiple executions.
6) Desktop browsers, emulators and devices with different platforms will be tested in the same sprint
in which they have been planned for
Benefits which we will reap from the recommended Progressive Automation model is that automation will
remain current to the present sprint. There won’t be any lag. Hence in case of mobile automation number of
devices, OS versions, and platforms etc. won’t harm the test scripts.
Functional QA can concentrate on other different functionality or ad hoc testing which automation won’t take
care in current sprint. This will give functional QA to test extra scenarios and provide greater coverage.
Maintenance of the test scripts will be fairly easy. The approach, about which I am going to talk in below
sections minimize multiple changes in test scripts or DLL based upon the application UI changes. If the
changes happen on screen UI, C# DLL is also bound to change but the actual script will still work without
throwing any error.
Main drawback of using the said progressive automation is that one need to depend on a C# developer for
DLL creation which will feed the automation test script. Although this dependency can be eliminated by adding
a C# developer directly in the automation team who can give 100% productivity.
5. Approach Progressive Mobile Automation Testing
I recommend using the “Selenium .NET bindings and implement the 'PageBots' pattern for 'write once, test
anywhere' concept” to achieve the progressive automation in mobile area.
In layman language it means that Selenium (an open source tool) does come with two types of mobility
implantations 1) .Net Bindings 2) Java Bindings. We need to use the Selenium .Net bindings to create a C#
DLL for mobile testing which can further be used in any test tool say UFT/QTP. The C# DLL will directly
interact with the application under test (AUT) to test the mobile application. Screen interactions (data filing
and retrieval) will be done by C# DLL. UFT tool will just be used by automation testers to draw a unique report
which is readable by automation and functional testers. Moreover all validations against screen will be done
using the UFT tool.
In case there is any change in UI in certain sprint, changes has to go in the automation suite as well to make
the test script error free. In the said approach, most of the changes will go in the DLL but the UFT scripts will
remain intact. This is because screen interactions are being covered in DLL and not in UFT script.

In this approach DLL will take care about the devices, platforms, browsers information. UFT script will just
manage the flow of any functionality.
Once the implementation is done, one can reap benefits that with the same DLL and UFT script he can test
on desktop browser, emulator and device respectively.
Below is the pictorial representation which shows how the C# DLL will talk to UFT script. It will be using the
references of Selenium .Net implementation.
Figure –Automation Approach for Progressive Mobile testing
6. Progressive Mobility Automation Process
In Progressive automation approach automation QA is working very closely with developers to
automate those test cases which will be found out on the fly by functional tester in team by taking part
in sprint planning meeting.
Given below is a snapshot of the script automation process in progressive mobile automation.

1) Automation and functional QAs are being involved in the sprint planning phase itself. Once the
business requirements are finalized, developers start doing the code and unit tests
implementation. During this time automation QA lead will also create an automation backlog and
will track the progress of automaton stories during the sprint
2) There are developers assigned to automation team who gives C# contracts in form of DLL files to
automation QA. At the time when developers are busy in writing application code, automation
developers will write the contracts and XMLs (dummy or actual) and will hand them over to
automation QA team
3) Automation QA comprise of the QTP/UFT savvy engineers who then work on DLLs passed by
automation developers and then they will create UFT scripts from them. These UFT scripts are
ready to execute as a when any functionality is available for testing. Basically testers are doing
the scripting work when development is going on. Hence to do scripting, they are not dependent
upon the application UI
4) For all interim builds, automation QA will execute the test cases. This gives an opportunity to both
automation QA and automation developers to make certain changes in DLL or in UFT scripts if
required. This will eventually help the team to detect the defects early in the game
5) Once the final build will be received in QA environment, automaton QA will then execute all the
test scenarios on the given build. Functional team will analyze the failures and will guide the
automation people if at certain places script flow need to be changed
6) If the test executions are succeeded, team will move to handle the new set of business
requirements
7) In case of failures, they will be logged as defects and will be assigned back to concerned
developer for further resolution

7. Progressive Mobile Automation – Benefits
Following are major benefits which teams have seen as an outcome of Progressive Mobile
Automation
1) Minimize time to Market: - QA teams don’t need to wait for the code to be present in QA
environment to start the test case creation. They can create and the test cases even when UI is
not available for functional test creation or execution.
2) Better Coverage:- With the same test script a large set of devices, OS versions, browsers,
platforms etc. can be targeted for the testing
3) Agile Automation: - QA, developers and BAs are working together in each sprint. There is a tight
collaboration between these teams. As testing is not following the development in this project and
as testers are doing the test creation and execution in the same sprint cycle, it won’t be incorrect
to say that the testing teams are also Agile. Both functional and automation teams are working in
iterative or sprint modes
4) Faster Suite Creation: - Regression Suite is being created with the automation of each sprint
story. There is no separate exercise required to build up the regression suite separately.
5) No Automation Backlogs: - Automation works is going on for each current sprint. Hence there is
no backlog for the automation stories. All testing work is proceeding concurrently with the
development cycles
6) Compatibility Testing: - DLLs which are compiled for a specific release can be used to test the
screen compatibility of another release.
Following picture depicts clearly how the team can come up with Regression test cases in various
sprints.

8. About the Author
RAKHI JAIN - DA LL AS, TX , UN I TE D S TATE S
I am currently working as a project Manager or Test Automation Manager. Have working experience in
few of the top elite companies like Sapient Corp, Adobe Systems and Wipro Technologies previously.
Well versed with functional testing automation tools like QTP/UFT, Eggplant and Selenium etc. For
your queries, you can reach out to me at Rakhi_Rohatgi@yahoo.com.

Progressive Mobile Test Automation

More Related Content

What's hot (20)

Viewers also liked (15)

Similar to Progressive Mobile Test Automation (20)

Recently uploaded (20)

Progressive Mobile Test Automation