Blog

Created on Thursday, 29 December 2011 20:51

Written by larry

Implementing a mobile deployment of PeopleSoft has a unique set of challenges and considerations.  As we've been working with our customers on 4 active mobile implementations, I thought that this would be a topical blog entry to write.

What's different and Whats' the Same

When implementing mobile, there are a number of areas to consider as you plan your implementation:

• End-user Feedback
  
• PeopleSoft system access
• Testing and troubleshooting

End-user Feedback

For most organizations, self service is the set of transactions that are initially targeted for implementing.  Although Self Service is nothing new from a  PeopleSoft perspective, with delivered transactions for students, employees, and managers.  However, the challenges created by user expectations on usability, access location, device platforms, and screen real estate size means structuring your project plan to gather end-user feedback on an incremental basis is imperative.

So far, all of our customers have structured their mobile projects as follows:

• Milestone 1 - Implementation and testing within IT group
• Milestone 2 - Implementation and testing with a small trusted group of power users
• Milestone 3 - Testing with a small group of standard end-users with assistance from power users
• Milestone 4 - Performance testing
  
• Milestone 5 - Roll-out in multiple phases
  

This allows the project team to gather feedback, manage expectations, and find issues in both infrastructure and usability.

Environment Considerations

Because much of your testing is going to occur on mobile devices, your PeopleSoft environments need to be accessible to them early in the process.  For many organizations that have had a good amount of control over the browsers (devices) and the way that those devices are accessed, this can become a significant wrinkle.  Therefore, the first question you need to answer is "how are the mobile devices going to access my PeopleSoft environments at each stage of the release process?".

This differs from a standard self service model because in self service, you can go through almost the complete release cycle with standard equipment connecting inside your corporate firewall with wired connections before opening things up to the public internet.  With Mobile, the devices must either connect using WiFi or using the phone carrier's network.  In both circumstances, your PeopleSoft web servers must be accessible to the segment of the network that the device is accessing which can add complexity to the process very early in the implementation.  For our customer implementations, this is generally the first item we discuss to make sure there's a plan for it (because the security and network team have to be involved in this and approve of the plan).

The solution can fall into 3 categories (note that many organizations will use multiple categories depending on where they are in the implementation process).

• Simulate mobile access from a standard workstation and browser:  You can get started by simulating mobile access using your existing equipment on a locked down environment.  You'll find, however, that you can't get very far in usability testing without using the actual devices.
• Access behind your firewall using WiFi and your devices:  When mobile devices are connected to your internal network using WiFi and the devices have access to resources behind your firewall, this will allow you to perform testing without making your PeopleSoft test environment available to the public internet.  However, many organizations have security concerns about providing this type of access to mobile devices and have policies preventing this from happening.  This could mean that you might need to have a special network just to allow WiFi access between your PeopleSoft environments and mobile devices, which means you will need to carefully coordinate how mobile devices will access the special network.
• Make your PeopleSoft environment(s) available on the public internet:  This will expose your PeopleSoft test environment to the internet very early in the process, but provides the following benefits:  (1) mobile devices only have access to resources that are explicitly allowed outside your firewall, (2) it's simpler to expand the testing group to additional users, and (3) you can start gathering performance information across all the network segments that your users will be utilizing when accessing the system in a normal case.  If you already have processes where sensitive data is masked for your test environments, you may be able to justify starting here because the risk of unauthorized access is manageable.
  

Troubleshooting and Problem Reporting

Although the robustness of the environments available on mobile devices has increased dramatically since the earlier smartphones, the process of reporting and troubleshooting issues creates a unique set of challenges.  It is imperative that you define a process that allows your end-users to identify and report issues.  Because most of the techniques we're familiar with are related to using the browser on the mobile devices, this section will cover these techniques (as opposed to techniques for native applications on those devices).

As you approach this process, you should identify the following:

• How does an individual report a reproducible test case for developers to look at?
• Where does troubleshooting data come from?
• How would future testing of an issue be tested in an automated manner?

Reproducible Test Case

Because the debugging tools available on workstation browser are superior to those on mobile devices, and because it's easier to share desktops using GoToMeeting or Webex for troubleshooting sessions, we recommend that you ask end-users to reproduce the problem on a workstation with the mobile rendering turned on.  If the problem can indeed be reproduced in this manner, it will be much easier to troubleshoot it and even if it can't be reproduced the developer will know that the problem lies specifically with the browser on the device.

When reporting the issue, the user should capture either the URL for accessing the page or the navigation followed to get to the page, the User used to access the system as well as the data put into the transaction.  They should also capture a screenshot and send that on as well.  If you have sufficient logging built into your mobile application infrastructure, you can also correlate this information with what's in the logs.

Troubleshooting Data

Troubleshooting data can come from the following sources:

• Debugging tools available in the browser.  The browser will tell you if there's a javascript error causing the issue as well as provide a representation of the DOM for determining what's causing rendering issues.  If the problem is related to traffic between the browser and the PeopleSoft server, a tool like FiddlerTool is available for showing all aspects of the traffic.  All the tools mentioned above are available on workstation browsers.
• Logs.  Depending on how many moving parts  you have in your mobile application, you will want to be able to access the logs at the different tiers:  web server, integration broker, app server, etc.  These logs will tell you what is happening at each tier of the application.
• The Mobile device.  In most circumstances, this will be a screenshot or a video recording of the actions that people are performing.  Because it's difficult to share a live session on a mobile device, you may also want to set up testing workshops where end-users can perform tests with developers available in the same room.

Automated Testing

We believe that automated testing is going to be an important component of a successful project.  There are several tools available to drive workstation browsers to run tests.  Automated tests are great for capturing javascript or other issues related to the HTML that is generated by the mobile application.  One thing to note, however, is that the engine for Internet Explorer is not as good for mobile testing as Safari or Firefox.  Because the PeopleTools Testing Framework uses IE, we've been using Selenium instead for our own internal mobile test scripts.

mobile | project management | testing