Eggplant Test Reviews

We use Eggplant for robotic process automation across several use cases. We primarily use it to test television set-top boxes, and we also use it for some automated content matching and for over-the-top streaming device testing as well.

The automation and the testing that we perform with eggplant is really for automation that allows us to generate data via our products, to validate that the data being generated is what we expect. Our primary use cases are for post-development, operational validation and support.

We were performing tests on television set-top boxes manually. It would take a person anywhere from 90 minutes to over three hours to perform a given test. It would require them to sit in front of a computer screen and manually perform the test operations. Not only was it resource-intensive, but it resulted in inaccuracies because the tests require certain channel changes or activities to be performed on a set-top box with particular timings. Since there were humans performing the tests, the timing was not always accurate. And there would be issues with missed button pushes. Eggplant allowed us to replace that human work with an automated solution that reduced the time that it took a person to perform the test from upwards of three hours down to a few minutes. It also increased the accuracy to the levels where we are entirely accurate with our timing and tests. We now have an extremely precise and extremely accurate level of testing.

It enables true end-to-end testing of processes that span a wide range of devices and architectures. We have used it for several different scenarios and devices. We use it for automating processes on our products, our company's products are primarily SaaS-type products, and we're able to develop automation that works on our entire suite of products across all of our implementations.

It has also helped to uncover critical bugs that our normal testing would have completely missed. By performing the automated tests that we do, we've been able to perform many more tests than we would have done manually. By being able to cover that much more ground, the tests have resulted in discovering issues that we likely wouldn't have discovered before. We've been able to perform both a broader and deeper level of tests.

The testing that we're doing with Eggplant is in operations, a post-implementation type of validation. The information that we uncover from our tests is used as a feedback loop to our internal technical teams and to our external data partners, allowing them to investigate and resolve the issues that they may have in their production systems. The results of our tests are used to identify potential issues with our data partners' data. They are also used to evaluate the data that we generate in our systems, and those results are fed back to our teams. They take the results of our automated tests and use them to apply fixes and upgrades to our existing systems. We're able to inform our internal and external partners and, in turn, have them improve and stabilize their platforms.

The feature that we use most is the optical character recognition. The features that we like the most are the developer interface and the ability to quickly develop and deploy tests.

Although the solution enables you to test any software on any device, from mainframe to browser to mobile, our primary use for Eggplant is robotic process automation. We're not using Eggplant for its original software testing purposes. But we have found that, for all of the devices that we need to use Eggplant for, such as Rokus and Fire TVs, we've been able to use it and have not run into any issues.

If one area could be improved, it would be some of their documentation. In particular, some of their online help and user support documentation is a little bit out of date and could be revised and updated on a more frequent basis. Other than that, I haven't really found any issues or problems.

We have been using Eggplant Digital Automation Intelligence for seven years.

I'm very impressed with the stability of the solution. I haven't found any issues there.

I also haven't found any issues as far as scalability goes. We've expanded the usage from our original use case and have quadrupled the utilization, at least, across some other use cases within our organization. We're always looking for areas where we could expand and continue to grow our use of Eggplant.

I currently have five people using the solutions and they're all data analysts.

Their customer support is really impressive. I would rate them a nine out of 10.

We did not have a previous solution.

The initial setup was very straightforward. To get our first use case working in production, it took a matter of days, perhaps a week.

We had a specific use case that we were trying to address. We had an already defined scope of manual testing that we were performing. So our strategy was to identify the first test candidate, by starting with testing of devices that were housed internally, within our building and within our testing lab. We implemented that and validated that the Eggplant software was working as expected on those and then we rolled out the testing to external devices and additional use cases after that.

Deployment and maintenance of Eggplant are done by one person in total, and that is divided between a manager of the analysts and myself.

We did it all ourselves.

We've reduced the costs involved in performing the tests that we perform, taking a person from hours down to minutes to perform a test. That has translated directly into return on investment, both in overall cost savings to perform the tests and in our ability to do much more with less.

Depending on your use cases, it's prudent to look around at some other solutions if you feel there are others that offer similar features. If you choose Eggplant, you should evaluate how you're going to use it and make a smart decision about the number of developer- and execution-only licenses you purchase to maximize your budget. We found that going heavier on execution-only licenses has been a way to reduce our costs and maximize our ability to benefit from the software.

Beyond the standard licensing fees there is just the cost of the resources it takes to do the work of utilizing Eggplant. And that is much better than the alternative of manual testing. There are almost negligible hardware costs. We have Eggplant running on commodity workstations that aren't anything special or expensive. I wouldn't consider it a significant expense to host it.

We did not evaluate other solutions. We chose Eggplant because they had some documentation and online information that I found during my research that was very specifically geared towards my use case. I found out very quickly how easily and how well it worked to solve the problem that I had. I didn't feel that it warranted any further research.

My advice would be try it before you buy it. They offer a trial copy and you have plenty of time to build some prototypes. The speed at which you can actually be up and running is great, so that during the trial period you can very quickly find out how well the solution is going to meet your needs. See if you can build a prototype that meets your needs quickly and if you can do that, then you're going to be in good shape.

We use the basic, core functionality of Eggplant Digital Automation Intelligence, where we develop tests in the user interface and usually execute them via the command line. We're developing those tests manually to serve our needs. We've had some exploratory sessions on the solution's AI features and that's something that I'm sure we'll be diving into further in the near future. But we have been able to meet most of our needs with the more core functions of the software.

If someone who is not using Eggplant said to me, “We are comfortable with automating 70 percent of our linear paths," I would say that we had a similar quote from our QA manager, seven years ago when I decided to look for a solution. The QA manager was satisfied with what was being done and didn't want to really put forth the effort to look for an additional or different solution from what he had. With a little bit of work, I was able to discover Eggplant as a solution and build a prototype and automate the work that was being done. It was very eye-opening to our company and was received very well. You're doing yourself a disservice if you're not constantly looking for better solutions and improvements in your current processes.

The biggest lesson that I've learned from using Eggplant Digital Automation Intelligence is that it pays to do your research and look for solutions. When you've got a use case or an issue that is presenting itself, do your research and find out what other people are doing and what else is out there that may help with solving the problem at hand. In most cases, you're not the only one who has that problem. Doing some research to see who's doing what and the experiences that others have had with the different solutions out there is a great way to find a good solution like Eggplant.

We've been using this product for quite a while and we've found that it's able to address the use cases that we throw at it. We haven't run into any situations that I'm aware of where we earmarked Eggplant for a solution but were unable to apply it.

We provide software for doctors and hospitals. In one of our business units, business analysts and quality assurance people are working together and there is no requirement in the job description for programming. These users are doing the tasks the doctors would do. In the testing environment, they don't need technical, medical knowledge. They are just testing the software in a process that mirrors how a doctor would behave, what a doctor would do for the patient.

Everything is happening on the layout or display that is used by the user. Eggplant prompts processes, like "click here," or "look for this image." Eggplant makes it possible for QA people and BAs, working in the actual display, to check if the software is providing the right images, the right text, and the right results. They don't have to go inside the code or to the TCP/IP layer. Everything is happening at the highest level. You don't need much coding knowledge to program what can sometimes be complex processes.

Eggplant works very well when it comes to uncovering bugs. In many cases, it has revealed bugs in our tools and modules. That is great.

It has also helped to quickly stabilize updates. It has improved the whole process in acknowledging the images and texts that are shown. Everything is running even better than before.

In addition, it reduces and even eliminates test processes that might have otherwise been necessary for us to do as part of quality assurance. I didn't have to do those processes, Eggplant was doing them. For example, there was a formula used by doctors every day. For a human to check it would take eight hours, but Eggplant does it in two hours and 20 minutes. It's quicker.

We also get better quality because a human eye, after such long and concentrated work, can't see what could be very important images or very rare results. It just doesn't see them anymore, but Eggplant recognizes them. We had an example where a certain text was not Arial 12 but, instead, Arial 9. Human quality assurance people were not able to recognize that, but Eggplant recognized it and told us that something was wrong. We just activated Eggplant and it did the work for us. Eggplant has influenced our release schedules greatly. It showed us errors that we must not have when the doctors are working with our software in real life. It has definitely improved the quality of our software. Eggplant found all the errors before release and gave us the information we needed to look closer at some of our modules, and we improved the quality of our product as a result.

The digital twin tool is perfect for combining the non-technical and technical sides. Someone who is not actually in the code can understand the processes that are presented by digital twin. I was introduced to it with a short introduction of about one and a half hours, and I was very surprised to see something like that because I had only been working with Eggplant programming and coding. With digital twin I can program something and visualize it within a module, within a process. For us, an example of such a use case is creating a new patient.

These small use cases are visualized in actions. Everybody who looks at it can understand what is meant by the representation and what an action is doing. In the past, everything was programmed and nobody could understand what I was doing. I put things in modules and described them very clearly, but if somebody was going into the modules, there was code and nobody could understand what it was doing. Now, everybody knows, when clicking on the action, what is going on in the software.

I tell my colleagues, "Look people, when I'm gone, with digital twin, everybody who is working with me will know the actions and can use them and can create a whole process that is visualized, installed, and implemented in Eggplant." We need to understand each other from the first moment, when I'm coding something. That is what is possible with digital twin.

What I like the most in Eggplant Manager is the functionality where you are informed, via email, if something is wrong.

For the future, I would like to see standardized actions already built into Eggplant. For example, "wait eight seconds". That way, I wouldn't need to create it as an action. Right now, I have to program that wait and describe it as an action so that everybody knows it is an action that waits eight seconds. Another example would be a "while" process: while this variable is less than 100, for example, do X. That way, somebody who is not familiar with programming processes like "if-else", or "for", or "while", would be able, from the first moment, and without programming, to put some easy-to-use, standardized, actions in place. Eggplant is such a great tool, but everything is based on programming.

It would be nice to have something like Microsoft's automation tool has. That tool has pre-programmed use cases. Everybody who uses it the first time understands what is meant by the "wait" process. Everybody can get in and program. That is not possible right now in Eggplant. If somebody asks me, "Is it possible, from the first moment, that somebody who has never used Eggplant can create actions?" I must answer, "No, it is not possible." Currently, it requires teamwork where somebody programs the actions so somebody else can use them. Eggplant doesn't have standardized actions right now.

Also, the longer the code for a process is, the greater the possibility that Eggplant will not find, for example, the images we need it to find. My advice would be not to program 5,000 lines of code. Try to reduce it to 1,000. Eggplant works very well when it comes to finding the images that are required, but when there are more than 1,000 lines of code, there's a kind of delay in every network. I don't know if this is an Eggplant issue or not, because Eggplant works very intelligently, but eggplant waits for the next action. If a required image can't be found within one millisecond, Eggplant is already responding, "I haven't found anything." Although Eggplant has intelligence built-in, it needs more. The stability would grow if Eggplant did not give up in the first moment and, instead, continued to look for an image a little bit longer. There is a delay in every network environment. It would be great to implement some kind of process in Eggplant that allowed the system to wait longer and to communicate more with the system.

We have been using Eggplant Digital Automation for between three and four years.

Overall, the stability is good.

For us, scalability is related to the licensing cost problem. If you have only two licenses and can't afford a third one or a fourth one, the scalability is limited. In terms of the system itself, it's perfect. You can change and share a script, or processes, or actions. But you can't grow within a company when you're limited by the number of executable licenses because of the price.

There were occasions where I asked questions about coding and, within 15 minutes, I got answers. That was perfect. I wrote to support about every little process that stopped me and got the answer about coding within 15 minutes. Other questions that were a bit more complex needed more time and it took them 24 hours to resolve. Support reacted very quickly. This is a point in favor of Eggplant, one that I want to stress when trying to convince my new business unit to adopt Eggplant. Support reacts so quickly. The kind of communication they provide and their politeness make it perfect.

End-to-end testing isn't possible for us because of the licensing problems. It's very expensive, so we only have two development/execution licenses.

When I started programming in Eggplant, everybody who looked at my screen just saw a lot of code. But when I activated it by pressing play, and that code was working in the background and started doing all the tests that a human would do, everybody said, "Hey, Eggplant is doing it. Cool." Everybody liked it. But the processes behind that, which needed to be programmed, was the part nobody liked.

Right now, I'm totally convinced about Eggplant, and I try to convince others in my company about it. There are some other tools I have to evaluate, and to give my opinion about, but no doubt Eggplant will still be my favorite.

The OCR (Optical Character Cognition) is a very useful feature. It mirrors your phone or your device system.

The scripting is nice and easy to use. The use of the tool is great. You can recreate scripts as well. It can generate scripts based on your actions from the screen.

The setup process is quite lengthy. There's a lot of dependencies. Parts of it need to be centralized.

The reporting function is a bit shallow. The solution does not offer very comprehensive reporting in terms of your test results. The reporting time and the logs are very high level as well. These areas need improvement.

The tool is quite stable. The only issue is connectivity. The RDC connection might be problematic, but I think the call tool itself is quite stable. I haven't really experienced a lot of crashing, or time-outs, or things like that. The stability could be affected by the number of resources available.

The solution is based on a Windows model, where adding users is just a few clicks. It is easy to manage users and add them.

I would rate technical support at three out of five. I don't think they have enough coverage for support. The issues take too long to be resolved. There are also relational issues, location issues, or geolocation issues. For example, in my case, when the support person is in America the response will be the day after the ticket was originally issued. It's too slow of a response because the response team is in America.

The installation is easy, but configuration, based on our project at least, is quite extensive.

We implemented the solution ourselves.

Implementation depends on a lot of factors, but you do need a team that has technical knowledge of the tool. There's a lot of configuration involved when you set up the solution.

I would rate the solution seven out of ten.

I am not a fan because of the reporting functionality and the difficulty in configuring the solution.

GUI testing is the strength of the tool. We have been satisfied with the tool, and not only the tool, but the service behind it. The tool works as expected, and the response from eggPlant, as a company, has been quick and substantial.

We are able to now automate tests, which so far have been manual. Now, it is possible to automate them.

• The availability of the support. 
• The internet presentation: If there are any questions, most of the questions can be answered with the web presentation and documentation. 
• The strength of the tool is we almost have no unwanted influence on the system of the test, because Eggplant is based on the reality approach. 
• It can be used for different operating platforms.
• It is easy to use.

A step forward would be to have event support; supporting different events. At the moment, it is more or less linear. We write the code, but from the tool, we do not have support of events in the system. E.g., programming timers where we have different actions in case certain timers expire. If one part of the program is running, we can get a key event. At the moment, we can implement everything in a linear manner, as predicted. 

The world is not linear and can have unpredictable events where you have to react, which should be allowed in a system on a test. The system on a test should be able handle different events at the same time with different elements or servers. At the moment, this is not supported in eggPlant, and it would be a big step forward.

Stability is okay, and has improved from version to version. However, it has not been 100 percent reached, and it will not be reached as long as the software is being developed, used, and new elements are being introduced. Errors and failures can happen, but if you detect them, the support is quick. 

I had a case that they improved over the weekend. Friday evening, I detected a bug, and by Monday morning, it was corrected. From this standpoint, the stability with the support behind it, I am very satisfied.

It is scalable, but it is a matter of money in the pocket. You can scale it, but then you have to have additional licenses. The licensing approach of eggPlant is not the best. 

The support is good. I would rate the technical support between an eight to nine out of 10.

Previously, we used C# based implementation. The reason that we changed was the instability and inflexibility of the tool. If the system on the test has improved and developed, then we needed a test tool which we could adapt in the same or even faster manner. Our previous tool did not help us in this direction. With eggPlant, we have this possibility and can keep all our tests up-to-date all the time.

The initial setup was easy.

I did the initial setup myself.

We did evaluate another US vendor, but I have forgotten their name. They reused something which were the property rights on eggPlant's site, which is why we did not select them.

You should be very clear about what your goals are. If you have this, then check the fit and the match. Afterwards, have a trial period and again check how the tool fits. 

When discussing eggPlant, it is important to use it, implement the scenarios, and run the tool in a regression mode, permanently. Then, you can see the benefit of what you have done and what it is improving. Working with it, this is the important part.

The most important criteria when selecting a vendor is the product. The product has to fulfill our requirements. Then, the vendor should be one that we can trust in.

Object recognition on applications with minimal data input, and the fact that it is designed to run on a machine when you can install automation software on the actual device.

Prior to using the product, all regression testing was done manually for our POS system. Now regression test packs are 70% automated. We have also integrated eggPlant into HP ALM.

eggPlants data input is text based and does not easily conform to data driven test, and this makes data management painful. Integration into other vendor tools are important in today’s market, Even though Vendors would like us to use only their toolset, it is not always possible, Integration into JIRA, Mantis, and HP ALM etc. is important as most of us use a combination of them.

I've used it for two years.

Deployment went smoothly, installed on server and on the client with no problems, and upgrading to new versions were also seamless.

We did however have problems when we tried running the scripts on multiple machines concurrently.

We had licence errors even when we had the correct licences and we got connection issues as well when trying to scale.

Service has been impressive time wise, with basic queries I always got a working answer with more complicated questions (integration or data driven) I would get the “Sales answers” but after speaking to a more senior support person I was given a decent answer.

The set-up was straightforward.

We implemented with an in-house team.

I think the licencing model needs to be looked at as it is very expensive, other companies are using/looking at multiple models to assist with various sized companies.

I did evaluate other automation tools, the problem with the other tools is that you had to install it on the machine with the software being tested. At the time eggPlant was the only tool that could be installed on another machine other than the POS machine and create tests and the object recognition and methods were superior at the time.

If the company only writes systems like POS, and GPS – graphical systems, then eggPlant is a great choice. If the company writes a mix of systems POS, SAP, and insurance software, then I would advise you to use a different tool. The other tools are better suited for high data input systems and have built in mechanisms for tables and similar objects.

We evaluated this solution and began writing code, but we are not comfortable coding in Eggplant so we are not buying it.

We are definitely moving to an open-source solution.

The most valuable feature is the ability to create code from a flow chart, and then run the code through it. 

We found that we had issues regarding the VPN setup, which is one of the reasons that we did not purchase this solution.

We found that the interface is not user-friendly.

We were not able to write code as fast as with the competing open-source software, so that needs to be improved.

We were not able to view all of the resources that were present.

We did not use the product for long enough to rate its stability.

We were in contact with technical support and we found them to be very helpful. They have good knowledge. It is just the product that we are not happy with, and do not feel that it is suitable for our industry.

We did not use another solution prior to this one.

We did not evaluate other options before trying Eggplant.

I would rate this solution a five out of ten.

We use it for desktop applications. We are using its latest version, and it can be deployed on-premises as well as on the cloud.

Its scalability is good. It is useful for desktop applications, and it also uses OCR and does image recognition.

Its performance and stability could be better.

I have been using this solution for about a year.

Its stability could be better.

It is easily scalable. We have about seven users who are using this solution. We don't have any plans to increase its usage.

Their support is okay.

It is difficult. You need some kind of training. Its implementation took some time. It took about one to two weeks.

We didn't implement it ourselves. We needed some consultancy.

It probably has a yearly license.

I would recommend it based on the project. I would rate it a six out of 10.