We're using it with Fiori and it's working fine. We have integration in and out of S/4 to Salesforce.com so we also automated those. The test cases were end-to-end. We start in Salesforce, which is a web application, with, for example, a quote, and then it goes into S/4 and gets reviewed and approved. It then goes back to Salesforce with the approval and a sales order is entered that ends up going back to S/4. And then there's fulfillment, back and forth, and eventually billing and collections. We were able to do that whole automation with Worksoft, plugging into Salesforce as well as integrating to S/4 and doing the S/4 automation, back and forth. It's been incredibly useful. We saved something like 80 percent of the time it would have taken to manually test, using this tool.

In terms of using the Capture feature without knowledge of testing tools, we brought on some new support people. One of them is our web support person and she had no background in Worksoft. She's been using it to do all the initial captures for our HVAC Partners. She's been able to use it very easily. Our more experienced automation engineers will follow up, after she's done the Capture piece, and troubleshoot some of the stuff that she might not understand yet. They're working with her so that she does learn it. But she's been able to use it very easily.

Worksoft’s ability to build tests and reuse them is very good. We ended up obsoleting the tests and not using them with the other tool we used, whereas now, we rerun these, at a minimum, every month. We do that for a few reasons. One reason is to keep the health of the tests up. Suppose a material is obsoleted. The test that has that material in it is going to fail because it's going to say, "Material not found." Or suppose a customer is no longer a customer and he has been blocked or archived. We run the tests to make sure that the scripts don't need any changes. We also use them in case a process has changed. We're releasing changes to SAP about every two weeks: support tickets, enhancements, maintenance, etc. If a business process changes, then the automated test needs to change to reflect that change. Running them every month, at a minimum, helps make sure that everything is healthy.

The other reason is to identify anything in our quality system that could unintentionally impact other things that the programmers didn't realize. We've caught a couple of those in queue and they said, "Okay. I didn't mean to do that. I only meant to change this one thing,” but it changed all kinds of things and we were able to catch that before it went into production. So the reusability is fabulous if you create the tests properly: no hard-coding, and you’re using data tables to hold any of your field selections, and you're using good automation standards, so you create and consume your data. If you create it and consume it, when you rerun it, it does the whole thing again. You don't have to worry about finding a sales order that works, for example. You really have to create a logical test design to make it reusable but as long as you do that, it's very reusable.

It dramatically reduces the time we spend on testing. Before we started using this tool, everyone was pretty much doing testing manually and test events were taking from two to six weeks. What they did in two to six weeks, depending on the scope of what they were doing and how many people they had involved, we can usually do in one to two days.

The most dramatic was when we finished the Middle East automation. They were bringing up another company code and they wanted us to run regression testing on all of their current company codes, about seven of them. We completed it in about four days. The IT director came to us and said that it reduced their labor by 93%. “Quite frankly,” he said, "we would never have been able to do all of that testing. We would have had to engage a minimum of 28 people, and it would've taken them a minimum of eight weeks, and we still would not have been able to do all of the tests. We wouldn't have gotten them done." We were able to do it in a fraction of the time and with a broader scope than they would've been able to do. They would've done as much as they could and then they would have gone live and hoped for the best.

And we've also been able to use it for other things like certain recurring tasks that had been done manually. We had people who were manually monitoring Tidal jobs, which are batch jobs that have been scheduled to run. If a Tidal job fails, somebody has to go in and figure out why it failed and either restart it or fix it, and then rerun it. These are jobs like billing jobs and we automated them. They probably spend 15 minutes a week on billing jobs now, whereas we had somebody doing this about 12 hours a week. And then that person would have to send out an email to whomever the relevant person was saying, "Hey, check your batch job. This isn't running." They now spend about 15 minutes running it. It saves the emails to the users, documents the results in a spreadsheet, and puts it out to a SharePoint where the auditors can pull them any time they want. It was the same thing with monitoring the claims jobs. We've done a few things like that which have added to the value.

Automation using Certify has also saved testing time, big-time. As I said, the Middle East: 93 percent. For the S/4HANA project, what we did in three or four days, they had been taking two weeks and not getting through at all. With the release, you don't get to say to SAP, "Hey, testing is running behind, we need another week," because it's in the public cloud. Like it or not, they're going live. The drill is supposed to be: You test during week one and you remediate in week two and you go live that weekend. We got our stuff done, 70 percent of the work, in about three days, and it was our first time, out-of-the-gate, so it'll go easier with the next release. The rest of the team took the entire two weeks to do their 30 percent. And within the 30 percent they were doing, a lot of them were smaller tests. We were doing end-to-end tests that go through Salesforce and S/4, etc.

In terms of defects, the value is finding the defects prior to moving something into production. There are two I'm thinking of that we found in Mexico. One of them would've brought shipping to a halt and the other one would have brought receiving to a halt. If you shut down factories, even for a short period of time, there is this domino effect. The value of those finds is huge. And this wasn't even something that the guys making this change were testing. They were testing the piece that they changed, which was working. What they didn't realize is that they changed all items instead of just that subset. It was a minor goof in the programming. It was just too broad of a statement. 

I started in IT about nine years ago and we did total manual testing. We would have defects in the high hundreds to 1,000 during the implementation testing. Now, we're probably under 100, so it's much lower. It could be that we're just getting better at implementations.

In terms of its web UI testing abilities for testing modern applications, such as SAP Fiori, we started implementing a project two years ago where we developed a logistic layer and a finance layer, which all the future SAP systems of the headquarter divisions will be using. For that project, we had introduced Worksoft for automated testing. We are quite heavily using Worksoft in that area. We have all of our core functionality in that area automated, and we had a really good experience with Fiori. 

Worksoft has these so-called configuration files that you can get for different applications to define the maps. We are also using ServiceNow or Pega for Workforce management. For both applications, you can get so-called configuration files from Worksoft, and with these configuration files, Worksoft can very easily identify the objects. So, you don't need to learn Worksoft from scratch, but you can really build on the foundation of already-existing definitions coming from Worksoft. 

It provides codeless end-to-end process automation across packaged applications. It does not have the approach of writing scripts or having a scripting language for the logic. It is pretty easy to adopt. It is helping us in general because you don't need a developer or a technical guy for building these scripts. People in the business organization can really design their own scripts without heavy IT support. Normally, we just teach testers how to work with Certify in general for a couple of hours. If they have understood the basic patterns in terms of how to find specific commands, how to really work with these conditions, and how to work with varietals, after a day or two, they are able to work with this solution. They might sometimes ask where to find specific things, but because Worksoft also provides master content with a lot of examples, they can deal with it from there. In our company, we have an approach that all people work on the same project. This means that they are also sharing their scripts internally so they can read and steal from others. We also have a concept that for every SAP system, there should be one test architect who is knowledgeable. He is a key user, and he drives the effort to bring knowledge to people. 

It definitely reduces the time you spend on test maintenance. The debug feature, the recognition feature, and the decoupling of scripts and maps are really saving time. Imagine having an error at step 850 in a test script that has 1,000 test steps, and these 850 steps have taken you an hour for execution. In such a case, you have to repeat the entire test because you don't have the possibility to go back to certain steps. Every time, you will lose an hour or two in maintenance. Having these features makes it pretty effective and efficient, but it is hard to say the exact time because you don't know how often your scripts are breaking because of updates. It also depends on the number of scripts. We also have to see the number of saved hours in relation to other tools. So, if you're comparing it with an open-source test automation tool like Selenium, it might be saving you more time, but that might not be the case if you're comparing it with Micro Focus or Tosca. 

It has definitely enabled us to scale up our testing. When you use automated test scripts for test cases, your testers are released from that testing time, and they can concentrate on further testing. The way we are introducing test automation in our organization is that we say, "Okay. This dummy type of testing can be done by a robot such as Certify," and then our testers, who are hopefully more intelligent than the machine, can concentrate more on the individual tests. You cannot really automate all the test cases, and it allows our testers to concentrate on the individual test cases.

The freshest example is some of the RPA-light activities that we have done. We have been able to save on a lot of manual work for some very highly skilled, expensive resources. This has been able to free up a significant amount of their time so they can spend more time on innovation and more creative, value-add activities. That's been one of the more rewarding things that we've done, and the most appreciated. 

We run our tests and our full suites every week. We have them scheduled in batches so certain sections of our scripts run every day, then we run them through the whole suite every week. That is how we maintain them by running and repairing them.

To run them every week and make repairs takes us maybe two hours. Because they are scheduled on batches to run, it's lights out. They are pretty hardened at this point, so there are not a lot of repairs for data, etc. If there is a break, it is usually because there has been a change to a process that we were not aware of. Our automated scripts are the company's best business process documentation, as we don't have a business process management tool. Therefore, if anybody wants to know about our business processes, they come to us for something like training or new production support resources. They will come and watch our automation if they want to understand how the systems work.

We have a weekly release. A weekly release means every week that we have testing going on. The particular year where we started is called the asset management area. We could never run our Intuit testing, and we have a whole lot of Intuit testing. This one product helped us pass the testing with the Nighthawk testing, which is working on the Nighthawk manager. That's the one that we use. We can switch it on in the night and run the testing, then come back in the morning and see what has been completed. If there is any fail, we can even analyze it. We can use the evidence document to pass it on to development team to tell them, "This is where we failed."

It has improved on our defect management time. It has improved our test execution time. I don't need to manage these things, just sit somebody down to look at how the script runs. There are a lot of ways that it has helped us.

It has cut down on the amount of low level, grunt work that business analysts have to do and can free them up to do more critical thinking. Before we had test automation, we were running tests and relied on people, which was very time consuming. A business process test might have 100 to 150 steps across different applications, and we don't have a single person who has expertise in all those applications. When executing a manual test, we have to balance the test between different people to do their steps. In a typical project, we might have 100 to 150 of these types of tests running. The coordination of the testing process where you have to have different people available at different times is very time consuming and inefficient. What automation has done is cut that cycle dramatically because automation does not have to worry about having to find the right order management or warehouse person to do their steps. The automation just runs through, then the business analyst can review the results afterwards. Therefore, it has been more efficient, cutting our testing part down by almost two-thirds to 75 percent.

Our automation tests are more robust than our manual tests. We found our test lab would grow over time because we didn't have a lot of discipline within the team for manual testing to have a master test which could be used repeatedly and revise as necessary. So, they were creating a new test for every specific little thing that they wanted to test. They were  setting up these manual tests where they had ten to 15 tests which tested the same thing, but not quite. Therefore, it became a bear to manage. Whereas, with automation, because it is more controlled, we have a core set of about 125 automation tests entered into our library. That's in our change control. Therefore, we know exactly what the state of our tests are. 

If there is a new business process or new wrinkle in a business process, we didn't have a defined process, so now we are updating automation tests. The quality of the data that we're getting out of test from automation is much higher than we received out of manual testing. If we know the automation suite is parsing, then the application is working properly. With automation, we have more confidence that if the test is parsing than the application under test is working correctly.

Our business and IT users have been able to use the Capture feature, even without knowledge of testing tools. We have different IT people from each business area, like production planning or material managements. These people, without even having any knowledge of programming or Certify, just need to know how to use Capture. They are using it because it's really easy to use. You just have to initiate a Capture and do the same work that you are doing every day. Then, Capture will record everything.

You don't need to do any coding when creating end-to-end processes; it's a codeless because it is just recording. We don't need a specific person (or multiple persons) to work with the processes to do coding for the automation, which saves time. It increases the confidence of the process owner or IT person working on it because we provide them the capability to record their own process without doing any coding and just using Capture. They are confident that whatever they have recorded is their own process. It's not someone else recording their processes. The test automator can polish that process, but we are not recording it since they initiated the Capture. Overall, this saves time.

It has reduced our test maintenance time by more than 50 percent because we don't have to do manual test processes. We have saved over 150 man-hours monthly. It has increased our delivery times. We went from 200 man-hours down (three weeks work time frame) to approximately 40 man-hours (three days work time frame).

Using Worksoft Certify, we have found and repaired more bugs, though not that many. Users cannot manipulate information during the process. We schedule our tests at the night time and leave them working. Next morning, when we come into the office, we just check our system. These tests are pass and fail. For the failed test, we have screen captures where we can go and check the screenshot to know what the issue is. No one has to sit in front of the screen when you are running regression tests or scheduling them. I can schedule them and continue with my other daily routine work.

It is codeless. Typically, you have to write code in Java, Python, or another language to automate web applications or ERP applications, but Worksoft Certify is completely different. You do not need to do any coding, and you do not need to know any coding language for automation. It is completely a techno-functional tool. You can just enable the application that you want and start automating. 

There are certain tools in the market for writing the code, but they are not supported with some of the ERP solutions available, such as SAP, Oracle, etc. Worksoft Certify is not like that. It supports each and every ERP solution available in the market.

An organization doesn't need to hire new people for automation. For example, if you already have people who are well versed in SAP, you can just train them on this particular tool, and they'll be able to do automation for you. You do not need to hire any new resources for this particular tool, and even if you are hiring, you would need a less number of people. It saves costs in terms of resources. 

Scheduling and lights-out testing are very easy. You can schedule any number of test cases on a recurring or on-demand basis. So, you can run any number of test cases. Test maintenance is very easy, and you can very easily manage all your tests, which also saves cost. So, it saves costs in terms of resources and maintenance.

If you look at the customer's experience, we have seen that if you take any testing engagement, whether it is large-scale system integration testing activities, UAT, or regression testing, and have seen that companies involve their business workforce to do lot of manual testing. Then, the business needs to take from the business critical activities and focus on testing. Worksoft significantly reduces the testing effort involved, so they can focus on their business critical activities. 

It helps us to implement automation testing as part of most projects, so the need for manual testing can be reduced. This really accelerates the testing process as a whole. Before, where it could take ten days to test a project, now it takes only one or two days to do the complete testing. So, it helps us to reduce our testing timelines.

We no longer need ten people sitting and manually testing something. We can just have one person running the entire regression automation testing suite, and this has saved us dollars.

We have never had any systematic regression testing regime in the organisation. This has helped in building an automation framework across our SAP application landscape, thereby introducing mandatory regression testing across all our key systems and improving the overall quality across our production systems.

From an audit perspective, results generated from Certify (BPP reports) provides detailed test evidence which is also being utilized for internal training purposes/training guides, etc. The BPP reports also provide details on failures along with screenshots.

We have a variety of complex systems in our landscape, one of them being the Openlink Endur which is a commodity trading and risk management system. We are currently building an automated regression test suite to support application testing for Endur.

Our weekend regression tests are performed in 'lights-out; mode. Tests are scheduled to run at a certain time over the weekend using the Execution manager functionality. Usage of Certify has also prevented some major defects going into Production and we have seen significant savings in all manual testing activities as the business users/functional teams are getting more time to perform 'value- adding' activities.

Post our recent upgrade to Solution Manager 7.2, we are currently in the process of implementing the Test suite functionality and the integration of the same with Certify. We expect Solution manager to be the single source of truth bringing out all the results from Certify which is going to be extremely beneficial from an audit perspective. We have already implemented the integration of Certify with HP ALM in our landscape.

Moreover, we have this reusable asset now which can be run frequently to support all our projects and change requests across our legacy SAP systems. Even last-minute testing requests are being accommodated by utilising the automated regression suite without any dependency on business users/functional users for their efforts. We use it across the multiple projects which need immediate assistance and for our weekly regression cycles. To give an example of a recent project which was a major platform migration from a Data Centre in Asia to Europe which needed extensive Disaster recovery testing and Functional testing/User acceptance testing. The initial testing estimate was approximately five to six weeks, however with the use of Certify we could do extensive testing in less than three hours saving many weeks of manual testing effort.

We moved from manual regression testing, once a month, to continuous testing every second day, with the same scope or even an increased scope now. We don't need to focus on the manual regression tests, so we've freed up hands for support activities and new developments. I don't think that it has changed how our organization works directly, but we have become more efficient and more flexible.

In our estimation now, we save about 160 hours of manpower every month because we use Certify. It's 80 hours of robots executing the tests, and they're doing it roughly three times faster than humans. To do the same manually, and keep up with the general pace of development, we would spend 240 hours on testing every month.

In terms of codeless, end-to-end process automation across packaged applications, technically speaking there is some programming or development, like you would learn in middle school. But you don't need to be a professional in any programming language to run it. That's how we've done it. We don't deploy any additional software packages with it. We haven't developed anything else, other than using Certify steps to run end-to-end test automation.

Nevertheless you still have to have a mindset of a developer or an engineer. You need to have understand cycles and other primitive functional blocks. Still marketing-wise, I would call it codeless due to its simplicity. 

SAP is our core and the people involved with it are not always developers. Some of them are analytics or system experts. They don't know how to write C++ or Python or Java. But they can do testing automation in Certify themselves without help from a centre of competence (CoC). The only time CoC will participate is when truly complicated logic required such as runtime variables staking.

In usual situations, the skill set to start doing test automation needed is much lower.

We used another tool for many years. It became unworkable because of the length of our scripts and how many of them there were, and how they were linked together. They became cumbersome in the other tool. It's much easier in Certify, and Certify can handle them, no problem.

In addition, our organization is implementing Agile, we're moving towards continuous development, and I don't see how we could do that, in any imaginable way, without Certify. We're able to import our changes weekly, based on the results in Certify. And we're confident that because of having tested the main business processes, fairly rapidly, within one day, we can tell whether the imports are going to break anything.

It has absolutely enabled us to automate and save time. The weekly imports of the changes allow the developers to plan on a weekly cycle, which increases the speed of their development. They don't have to wait for a release or anything else, they can test their changes quickly and get the results the next day. They know that they're able to import with no problem.

Finally, it has helped us cut test maintenance time. 

Our business users are doing regression testing as their day job. This is an add-on to their daily work. With everything so pressured in the industry, automation takes the pressure of these users. This is essential for us.

We do automation of both SAP and other applications: One of them is our new grants management system. Originally, they wanted to do everything manually. Now, they highly rely on us to do testing in very short periods. 

We do web UI testing of modern applications. In our environment, we have SuccessFactors, plus SRM through Fiori. 

We also do performance testing and end-to-end testing of packaged applications, like SAP, InfoEd, and OnCore.

Our company automates a lot of functional tests for SAP. The automated tests are included in larger integration tests of SAP transaction, workflows and end-to-end processes. Successful implementation and execution of Worksoft Certify tests has been faster than execution of the tests manually. With other tools, it was hard to get successful technical execution right quickly. Automation is not easy. Worksoft Certify makes it easier yet flexible enough to handle some of the most complex automation tasks. Every time steps are automated, test execution times are reduced and application problems are identified faster. Every time that the automated script runs (many times if developed early enough and applied with each change of the application being tested - in the current environment and leveraged in another environment), the investment of work made to develop the script is realized. The more times that the test is executed, the risk of problems going undiscovered is reduced. Testing time is shortened. Avoiding the tedious tasks of manual testing easily repeatable steps saves money.

Improvement means for us that we have to be better in quality. Due to automation, you can run every automated test case twice a week. If you do it manually, you do it once per release. This is a quality improvement.

We always have to be more efficient. E.g., if we can directly automate test cases, so if we are using older test cases, then by just switch the company code (national company), we don't have to do it manually. We are able to directly automate the test. This saves money, which is always important for our top management.

We implemented more than 200 test cases for critically defined processes. 

It helps us understand the end-to-end scenario and how it can be divided into multiple subprocesses. Those sub processes can be used whenever required. Based on that, we design automation scripts, then reuse them wherever required.

The solution has enabled us to find defects since it is a test automation tool. However, irrespective of the tool used, we are testing to find defects. Thus, it has found defects in our projects.

Worksoft Certify has helped organizations save time by using automation.

We have an internal web portal, as well as an external. We did automation for it to do regression testing and build a test space.

Because of the fact that we started just six months ago and we have a small team. But slowly but surely we are gaining more audience; more people are starting to get interested. That should lead us to be able to start implementing it the way it should be done. We have done some regression testing and, when doing so, we found real issues. So it has proven itself to be useful during regression testing at least.

We have definitely seen savings in testing time. Scripts are executed five or even 10 times faster than any one of us could do by hand. While we don't do so at the moment, we are going to start executing them in a lights-out environment. We will run tests during the night and get more numbers, execute more tests. That should also help us save time. We have to get the experience and the numbers for this, but I think it will save us a lot of time.

My company gets some savings in manpower and cost and enjoys a boost in productivity because you only need a few hours to run end-to-end testing using the tool. If you do it manually, the process takes a few weeks, so Worksoft Certify greatly benefits my company.

We configured Worksoft to setup our SAP testing environment after a refresh by regenerating all of our testing users. This sets them up with the right access, the right approvals, and everything on the back-end so we can do our scripts the next night.

Prior to Worksoft, there were three different individuals within the company who worked collectively for about three years trying to automate just one of our smoke tests for our point of sale system. A lot of them got pretty far, but they weren't able to finish. However, with Worksoft, we have been able to automate six of our smoke tests in four months.

We are a subsidiary of a larger company and we are focused on rolling it out, at the moment, to our larger company. With the tool's simplicity of use, where we are able to have a code review occurring, in that sense it will be useful in being able to roll it out to the greater company. We will be able to give it to the people who are experts in their areas, rather than trying to pass off test cases to one centralized location. It will be centralized automation and we'll just have one central COE.

Automation using the solution has saved testing time. I couldn't give you a number of hours or days because we're still in the beginning stages of trying to roll it out globally. We haven't been able to use the product and reuse automation. The whole point of automation is that the upfront cost to automate something is heavier and then, as you reuse it, it reduces the testing cycle. We're still investing in the earlier stages where perhaps we have spent equal parts right now, but we intend to see a reduction as we capture more and more.

Certify has also enabled us to find more defects. While I'm focused solely on automating and testing, so I don't have access to the defect count number, I know we have found defects, which tells me that we are finding defects that wouldn't have been found otherwise, or defects that wouldn't have been found as quickly.

We are now trying to automate all our applications: SAP, web, third-party, and legacy. Instead of multiple tools, we have been able to have Worksoft handle a lot of our applications. This has saved us a lot of time and effort. 

These are some cases where automation helped:

1. Mostly in the area of project testing, the most immediate benefit is when you historically have manual testers do a certain job, and a full regression testing was previously done 100 percent manually. We have had cases where the release testing for an entire region would take around 12 weeks. With Worksoft, we are now down to two to three weeks.
2. The second benefit would be production execution runs. This would be where we run test cases to do certain transactions, like mergers and acquisitions. Or with asset migrations, there are hundreds and hundreds of lines of assets, that we just need to set up, which can be done by Worksoft.

Previously, the business was spending a lot of time on processes. So, we started automating and executing these processes on a weekly basis. Last year, we had planned and resourced only one major upgrade, but due to this automation work, we were able to add one extra upgrade.

Worksoft is used for manual processes that needed to be automated. This has helped us make our processes be faster and more efficient because there are no manual interruptions or errors.

When we used it for web based application, so it was quite poor.

We are doing Worksoft Online Training and also take up various Worksoft automation testing projects. I have totally trained about 50 participants on this tool. Most of the trainees are happy to learn and use this product in their jobs now. We have also done two projects, one for retail sales chain and another for a banking project. Both of the projects were delivered on time and the clients are happy to generate some automated OOB reports and also create their own Receipts. The clients were happy with our timelines and also with the training we offered at the end of the implementation.

It is a great improvement, especially from my client side, where I have implemented it. One of my clients wanted to replace weekend production and support. They were using mini applications that did not need to work on the weekends. So, it was purely replaced with Certify's automation, so they did not need to come into the office on the weekends. This saves a lot of time and frees employees up on weekends.

We have already found some defects using the test automation. 

One of the bigger value-adds that we had was extracting data from our warning systems to be inputted into our new learning system.

We automated because of the value. Our business users do a lot of regression testing. They often don't have the time when we need to get the testing done, so this frees them up to do more value-added work for the company.

For this SAP upgrade or implementation, the business users are creating building blocks in their areas, then they're changing the building blocks into long end-to-end scripts to do a complete end-to-end testing to speed up the UAT. It definitely has a bigger coverage of UAT testing.

We are able to run our test phases faster. Once the scripts, the test cases, are ready and automated, not only are we able to check our systems or landscapes during the test phases, but we can proactively monitor our development and test systems. Proactive monitoring of our systems is very important for us and was not possible before because manual testing is just too time intensive.

Worksoft Certify helped us to increase time savings. We didn't start test automation in general with Worksoft Certify. We did automation before with our own tool, but it helped us to increase the coverage of test automation and to increase the time savings.

We had a success story with two teams. For the execution of the scripts, we had time savings of 82, 88, 95, and 90 percent. And for the speed, it was between nine and 21 times faster than manual execution.

It's not necessarily saving us money, but it's helping us to free up the capacities of our end users to work on other stuff. Instead of doing testing for two days, they can work on bug fixing, developing new features, etc. That person still gets the same paycheck at the end of the month, so it's not saving us money, but it increases the value of our products. It increases the quality of our products. The reason for that is we are not customer-facing. We are dealing with internal teams and internal products. We are not selling anything to the outside. We are with the internal IT department. For the development teams and the sales team or the consulting team it might be different. But we are not really going out, selling our products and getting the revenue for the company. This is done by other teams.

Well, it's definitely reduced the number of defects that we have. Before, when we were manually testing everything, it was unclear to us where changes that we were making, where the impacts were in our system. I mean, we've got very smart people that work here, but they were not 100% on where the impacts were going to occur with their changes.

By automating our scripts, we were able to do more comprehensive testing and therefore eliminate the number of defects that were be introduced into our environment.

We are able to scale up the testing and to address more business-driven projects using Worksoft, which would not be possible with any other tools. The testing organization can cut short its budget, as it is not required to hire more testers for regression testing.

We have something called automatic processing in SAP. Previously, the company was doing it manually, which used to take hours to days. Now, we have a script that processes 200 to 300 orders per day.

Everything is integrated with SAP and the web, and it works smoothly. However, we are not yet using it for web UI testing.

It facilitates 80% of our regression tests.

Of course, one of the benefits is, we are able to complete and maintain more automation.

The biggest benefit for me has been that, because the automation is basically 'event-driven-executable-documentation', it has been easy to enhance my lengthy end-to-end tests with restart capability.

It has also been easy to create automation as part of the test to find, or create data as part of the test execution. This has enabled us to instantly run a test again without the delay of manually finding and populating input RecordSet data. When you are on the clock to complete regression testing for production implementation, this is critical; that you don't have any delay to rerun.

The autotesting piece has allowed us to complete testing more quickly, which helps us with our agile sprint. We are getting our releases out at the end of every four to six weeks, then pushing them out. Thus, we're delivering value in terms of our website being faster. The whole autotesting piece has helped us get there and deliver that. This has saved us time.

With one of our top clients based in the Midwest, we have around 2500 automation scripts. These are not like unit level scripts, they are like big scripts. Previously, our development time for a medium complexity script was approximately three to five days. Now, it has come down to one and a half to two days. 

People focus on what they actually want to test and define it in a more detailed way. It shines a light on what they are testing, along with the speed and adaptability.

We were able to increase the percentage of automation from between 40% and 50% to 80% within a year.

We have Worksoft Certify on everyone's desktop. So, when we want to trigger automation, it is a advantage.

We use Worksoft Certify for smoke testing and regulation testing purposes.

Worksoft has helped us position our company better because the product lets us show our value in terms of the benefits that we bring.

SAP automation was very easy with Certify; it reduced the automation time and also, the creation of the test cases was easy.

It has greatly improved testing time and has found defects before production.

The build/maintenance times for testing are much faster. It also allows us to build tests for applications our previous tool could not do.

The faster build times allow us to respond quickly to ad hoc requests from customers that were not possible previously.

Prior to implementing Worksoft for our testing, the scenarios required eight employees over two weeks to complete (waiting for hand off of next steps, employee availability due to meetings, etc.

After implementation of Worksoft, the same test scenarios currently run in approximately 45 minutes – hands free! We have also implemented Worksoft into our SOX Control documentation processes.

We have been able to increase our overall testing maturity and test automation coverage. We have a large ERP program ongoing which requires a lot of testing. Our goal is to automate the majority of system integration test cases with Certify. This brings efficiency and quality to the program and also supports the continuous services in the future (less time needed for regression testing).

Organizations does not need to hire numerous resources to perform regression testing, therefore, cutting overhead cost at a substantial level.

It allows us to do end to end script executions.

It is good for automating SAP applications.