Fiori is SAP’s brand new UI/User Experience to help move all of SAPs offerings into the Mobile & Responsive Era. Per their site:
“Enjoy a user experience that is personalized, responsive and simple. SAP Fiori is the new user experience of SAP software – such as SAP S/4HANA, SAP Simple Finance and the SAP Business Suite. Using modern design principles, SAP Fiori provides a role-based experience across all lines of business, tasks and devices.”
SAP is a logical extension of our efforts to help enterprises adopt Mobile & Responsive test automation. With its gargantuan global footprint and breadth & complexity of offerings, SAP is a perfect candidate to build automation around. We have focused on Responsive & Functional Test Automation and built out a variety of tests that showcase both our capabilities to rapidly automate tests (using a variety of Open Source Test Automation tools) and the sheer breadth of coverage you can achieve on large complex applications like SAP. This post will give you an overview of the preliminary work we’ve done.
First we’ll examine the setup and framework behind the functional and responsive tests. After, once we are ready to execute, we will run the test cases through Awetest. Then, we will take a look at our reports and analytics to see the results of our automated tests.
Our functional test case is built to validate the content and search functionality of the Employee Lookup module in SAP Fiori. We will click on the module, enter our employee name in the search field, and validate elements on the employee page. Looking at our uploaded feature file in Awetest, we see each line of the script has a specified object name that is receiving the written command.
The object name references our object repository, which is created here in an excel document. The repository contains identifiers for our various html elements which we can assign an object name to, creating a data driven framework powering our feature files.
As SAP Fiori is a responsively designed website, we can use the same script used to validate web, to validate mobile web. The responsive design means that the HTML elements will remain the same when viewed on mobile, and only the visual layout of the website will change, depending on the screen breakpoint.
Now let’s delve into our responsive set up. We use Galen, an Open Source framework, designed specifically for automating responsive testing. The Galen framework allows you to define various design & layout rules across different breakpoints for a given view, and run scripts that can validate these rules simultaneously across multiple windows. Here we have our config file where we have our breakpoints defined that will be tested on, and our spec file where we define our rules to be validated. In this case we validate the My Accounts module, and check for alignment of the home button and column count at various breakpoints. As you can see, the column amount varies depending on your breakpoint, with larger having more and smaller having less. Now that we are setup to run, we can launch our first functional web test case.
We’ll navigate to the jobs page where we can create a job and specify which test case we’ll be selecting. Here we choose employee lookup and select Chrome. Then we’ll hit run. The test will execute, and we can see validations happening in real time. Next, we can do the same thing for mobile web. We’ll go to the jobs page, add a new job, select our devices, and execute. Now we can see 3 devices running the same test case on the employee lookup module, as we had just done with web.
Next we can run our automated script for responsive testing. As previously discussed, we will launch a few windows to test the SAP site at various breakpoints. And now that we’re in the Fiori Responsive project, we’ll select Web, go to jobs, and create a new job specifying the script we want to test on, which is the My Accounts page. Now we can go ahead and run. Our windows are launched, and we’ll see them run and validate our rules, simultaneously, for each breakpoint. Once the validations are complete, we can go ahead and look at our reports from our previous runs.
We switch back to the functional project, navigate to our jobs module. From here we’ll click on what we just ran. And now we see the script with 12 validations, and 0 errors. if we click show all, we see the details for each step. If we had a failed step, we would’ve been able to hover over and see the reason why it failed, and subsequently click through, and alter the test case for the purpose of debugging. Now let’s see the results of our mobile web run. We click through jobs as we just did with Web. Select the job, and just like Web, we see 12 validations, 0 errors, with every step passing.
Now let’s see the result of our responsive test. We go back to our responsive project, go to web, jobs and select our job. We’ll download the Galen report through Awetest and open it to see our results.. We can click through and view the report for each individual browser window; again, each window represented a different breakpoint. We’ll expand all to view our rules, and we can see details by clicking on one.
As you can see this opens a screenshot showing a highlighted element which was validated. Here we see all of our columns displaying correctly. For big desktop we’ll have the most columns; here we had 8 that were correctly validated. Now we’ll go back and check desktop device. Here we see 6 columns, validated correctly as we can see in the screenshot. For our mobile device, we should have 0. And finally, our tablet device will have 4 columns. All of our validated elements were correct for each breakpoint, meaning we had no errors.
So now you’ve seen how simple it is to set up, run, and check out the report of SAP Fiori automated functional and responsive test cases through Awetest. Fiori’s collection of modules means there is always more to be automated; We’re continuing to expand our test coverage to validate their functionality across an increasing variety of devices.