We all know the benefits of using the PeopleSoft Test Framework (PTF). Streamlining the testing process, reducing costs, and keeping your PeopleSoft system up-to-date are just a few of the advantages. However, clients still want to know if it is the best tool for their organization.
In order to gain insight into the value of PTF and how to optimally leverage it, I spoke with Russ Barberio (RB) and Dan Croce (DC). Both are Senior Consultants with Sierra-Cedar and have experience using the PeopleSoft Test Framework (PTF) to automate testing.
Q: Why did you start using PTF?
DC: Many years ago, when the product was released, I was invited to a week of PTF training by my employer. The thought was that a few technical and functional resources should be trained and ready for the wave of work that was coming involving automated testing. It turns out that we were ready years before clients were ready. Implementations and upgrades were so complicated that clients had little desire to devote any time or money to automated testing.
RB: I saw that PTF was an essential part of an organization keeping current on its PeopleSoft investment. Testing has always been the main issue of applying an update, and the cost of testing has been the reason organizations were hesitant in applying updates. PTF mitigates that cost of time and expenses by automating a large part of the testing process. Automated testing encourages clients to apply the updates on a timely basis and thereby maximizes their PeopleSoft investment.
Q: How did PTF differ from your expectations?
DC: In general, PTF is similar to other testing utilities where scripts must be recorded by navigating through the application. However, PTF is also integrated into the Application Designer environment by including Tests and Test Cases as managed objects. On the reporting side, PTF is integrated into the Pure Internet Architecture (PIA) environment.
RB: When I first started learning PTF, I thought it was a completely functional process. With experience, I recognized that it is more technical than functional. While the basic script just copies the keystrokes of a single user in PIA, the optimization tools require a more technical expertise than I originally thought. The PTF scripts are just the beginning. The real power is in the analytical tools.
Q: What are the skillsets, and who is involved in creating the test scripts in PTF?
DC: The ideal is to have both functional and technical skills, but there are several scenarios that could work. With the new upgrade model, it would make sense to have business analysts initiate requests for the technical side to build or modify a script.
RB: The ideal skill set would be a techno-functional analyst who has a lot of depth of experience in PeopleSoft. In many ways, developing PTF scripts is somewhat of an art.
Without skilled techno-functional resources, I highly recommend the business create detail scripts in the traditional way and deliver them to technical analysts to create the PTF scripts. The technical analysts need to be skilled enough to create scripts that can be run repeatedly.
Q: For an experienced PeopleSoft user, how long would it take them to get up to speed?
DC: I would say a few months to start feeling very proficient.
RB: This depends on the type of resource that will be doing PTF scripts. In my case, I used every resource I could find and then dug in and created hundreds of scripts. I would say the experienced PeopleSoft user who also has technical skills could be competent in a couple of months.
Q: What advice would you give when you’re just starting to deploy PTF-the must-do’s—and what should one try to avoid?
DC: Don’t start until you know how you are going to use your implementation of PeopleSoft. Knowing your business processes and having them documented is key.
RB: The first step is to discuss the implementation requirements with the appropriate security personnel. Then, install the product and set up the Integration Broker as required. Develop a thorough understanding of the entire process and requirements to map out a project plan and become completely comfortable with the tool by taking the basic Oracle course (either in person or online) and reading everything you can find. Gather the scripts that will be the scope of the PTF project, and finally, start creating scripts.
I would avoid implementing PTF during an implementation or upgrade project when it is more difficult to get the attention of the appropriate resources.
Q: What are the best situations in which to use PTF, and do you avoid any type of tests?
DC: The best scenarios to test are those you would write manual test scripts for during one of the implementation testing phases (i.e. User Acceptance Testing) or from user training.
RB: Any test that can be performed by a single user in PIA is the best situation. I have only run into one situation where I could not duplicate every step in a manual test. When tests are extremely complex, PTF may not be the right tool. For example, in Grants Management there was a very complex series of events that all depended on a complex predecessor which could only be used once. Each of the processes had many options. While this can be done in PTF, careful thought needs to be given to these types of tests.
Q: What are some of the limitations of PTF?
DC: PTF will obey the rules of your system. In other words, it can’t magically override your security rules or enter data that is not valid. It requires that tests are thoughtful and well planned as to how and what data will be entered.
RB: PTF works well to mimic one user in PIA. It would not work well for stress and volume testing. It also does not work well with sequential batch processes that are dependent on successful completion of previous batch processes.
Both Russ and Dan have more to say on PTF—view their recent webinar for additional information or register for their upcoming webinar below. Look for Part 2 of our conversation coming soon!