Appium Reviews

It's for automating mobile testing. It's related to the engineering side. It's a tool used by engineers for automating apps in the mobile world, for testing, like doing manual testing and automation testing. So, it's an okay customer thing.

It's an open-source tool. You can handle the application stuff with different programming languages. With those, we can use it anywhere for automating mobile apps.

There is room for improvement in stability. It breaks down.

I have been using it for three to four years. 

It breaks down. It's open-source, and it will have bugs. I rate it, like, three out of five.

So it has some issues.

It is a very scalable product. It can be used with different programming languages.

And we can use it for multiple devices, like thousands of devices.

It's like open-source, like, a kind of community support.

There is no, like, it's an open-source application. There's no, like, designated support team. Anyone from the community will help.

We need to have some experience to set it up. 

It's open source, so it's completely free.

It's for automation testing of mobile apps. If you want an open-source tool, you can go for it.

Our primary use case addresses customer requirements from the healthcare domain, a few from the construction domain, and logistics.

The automation part is extremely helpful in streamlining our processes.

There is always a concern about the amount of code that is required to enhance the automation process. The idea of having less code or no code is what we would like to see in future updates. Increase performance, battery, load testing, and no-code less, more advanced topics which we can bring to the tool features. If we can make it lightweight and clear to understand and in an easy way, that will make this tool even more worthwhile.

I have been using Appium for the past six years.

Appium is definitely stable.

Appium is scalable and we plan to increase it in the future.

The initial setup is straightforward and not that complex, There is a little procedure that we need to follow in the setup, and then just go ahead and run it. You may need to write a little bit of scripting here and there to connect with the respective code. But it is all possible and quick.

We did the implementation in-house. It is just a specific process to get setup and then deploy.

The price is good for people to be able to make a favorable decision for the value.

I would rate Appium a nine out of ten.

I'm using Appium for the automation of applications on Android and iOS.

Appium has improved my company because it makes it easier to connect devices to automation scripts because the library is easy to use. You can also detect mobile elements faster in both Android and iOS.

The best feature of Appium is that it allows you to inspect the element. With the Appium Inspector, you don't have to install another application to do the inspection. I also like that Appium has Android device connectivity. Currently, most people use Appium as automation software, and I haven't found any other tool that's more powerful than Appium.

I rarely use Appium nowadays because I'm now at the managerial level, but the last time I used it, whenever I selected and clicked on an element, Appium was very slow. I tried to debug it, but I still couldn't find the problem, so this is an area for improvement in the solution.

Another area for improvement lies with the connector and server. For example, the effort to get into the local machine sometimes causes the emulator to become slow, which then leads to failure in testing, and this is the usual issue I've encountered from Appium.

An additional feature I'd like added to Appium in its next release is being able to do automation in iOS without using XPath and the name of the element. In Xcode, you can use previous UI tests for detecting elements, but in Appium, you have to use Xpath and the element name instead of being able to directly put the X-UiPath, which is what you can do in Xcode. In iOS as well, sometimes the element doesn't have a name or a path. Sometimes, there's also no element.

I've been using Appium for more than four years.

Appium is a solution that's quite stable.

Appium is a scalable solution. A lot of devices are connected to Appium, and the solution runs every day for integration testing, with new test cases added daily. Appium keeps growing, and it's scalable.

A separate team works with the Appium technical support team whenever there's an issue, so I have no experience contacting support.

I've only used Appium, and I haven't found a solution that's as good as Appium.

Setting up Appium is quite easy because a lot of documentation can be found on the internet. From setup to deployment, it only takes less than one hour if there's no problem, but usually, the problem is on the environment side, not in Appium itself. Sometimes the emulator doesn't connect to Appium, and sometimes there's a broken dependency, for example, Node.js isn't supported, or a certain percentage of Node.js must be used.

As far as I know, Appium is a free solution. It's not for commercial use.

I'm using the latest version of Appium.

My current company has a lot of programmers, so I don't have the exact figure on how many people use Appium, but in my previous company, two people deployed the solution on the cloud server.

The only time maintenance is required in Appium is when there's a new update, and my team would first ask about how stable the new version is, then that's the time the team upgrades the version of Appium.

In the AP department, seventy to eighty people use the solution. The users only create the automation path and then test it on the local machines with Appium, then deploy it on the cloud server. The AP users aren't in charge of maintaining Appium.

I'd recommend the solution to other users. Most of the companies here in Indonesia use Appium, and on a scale of one to ten, my rating for Appium is nine out of ten.

My company is a customer of Appium.

We use Appium mainly for mobile test automation, while Selenium doesn't support mobile testing. In my personal use of the tool, I primarily convert manual test cases into automated test cases. We also link our test cases between Selenium and Appium with cases from Jira

The solution helps with test automation. We focus mostly on Java.   

One area where I think Appium could improve is in addressing security concerns for our data. Currently, we're unable to use cloud solutions like CloudForm due to security restrictions on our servers. We also face challenges in updating packages for the same reason. It would be beneficial if the solution could provide better support for auto-reporting and easier connections to mobile device farms.

I have been working with the product for six months. 

I rate the product's stability as six out of ten. 

I rate the solution's scalability a four out of ten. 

The solution's deployment is not simple.  

The solution is open-source. 

I rate Appium a seven out of ten. 

We primarily use the solution for UI validation of mobile applications. It's a mobile development platform. We have an application where we have to test the front end and how it is cloning.

It's easy to connect the product. Within a single command, we can easily connect to the device. The connectivity is just that easy.

We get a list that shows all devices that are connected to the system.

It is a very easy initial setup.

Support-wise, it could be better. Whenever we get some issues, it may take some time. I'd like them to be more responsive. 

There's not too much public documentation or information. If we Google information or something else regarding the Appium, there won't be much compared to Selenium. Selenium is also open-source. Appium details are limited.

It is difficult to understand. Recently, there were major changes in Appium. Understanding those changes, was a bit difficult. There just wasn't enough transparency.

I've been using the solution for one and a half years. 

The solution is pretty stable. That said, either from the application side or the Appium side, sometimes, I get some error that is not correct. Even if the application is open, sometimes it throws some error, however, maybe it is from the emulator side. I'm not sure. 

If I run the same test case, and in the same execution, I don't see that error again. It's random, yet may be from our side. I don't think it's from Appium. However, I'm not sure. 

The solution is scalable. The capacity is very good. 

We have three QAs using the product.

Technical support is not as responsive as we would like them to be. They often are late to reply. Sometimes to topic diverts towards something else. It's open-source, which means support is always a bit of an issue. 

Neutral

We also have used Selenium, which has more information available. Selenium is also open-source. Both are pretty similar. 

The solution is very easy to set up. It's not an issue at all. It took one or two days to connect the emulators. It was pretty simple and straightforward. 

I'd rate the initial setup at a five out of five in terms of ease of deployment. 

This is an open-source tool.

We are end-users. We tend to use the solution on a weekly basis.

I'd rate the solution at an eight out of ten. 

It's normally used to test mobile applications, and to interact with some power applications. It's mainly for mobile testing applications?

I like the app inspector. It's quite a good and useful tool for us. I like that we can use it almost out of the box. 

It works well on Android. 

The solution is stable.

It's very scalable. 

The solution is free to use. 

I'm facing a lot of issues with my new juniors when they set up Appium for iOS. For Android, it's easy, however, for iOS to interact with it on iPhones or something. It requires some additional libraries and some additional installation. Sometimes it's not working. While Android works well, iOS continues to be an issue. 

There are a lot of issues on GitHub discussions and Stack Overflow, et cetera, and it's still not resolved. When we use Appium Inspector and just Appium, we are not able to inspect nest elements. Half of the elements are nested. Especially for React Native, it's not visible in Inspector, and we cannot interact with this element. We need some bug fixes for nested elements. 

We'd like a one-button click where you hit it, and everything is automatically installed. 

I've used the solution for three or four years, maybe less. 

Generally, I'm not facing any issues with stability, so I am quite satisfied. There are no bugs or glitches. It doesn't crash or freeze. 

I'm not facing any issues with scalability. It's not a problem to expand. 

We have a team of ten using the solution right now. We use it on a daily basis. We have daily test runs, using Appium, and have test cases to update, to add on a daily basis.

We have zero direct interactions with Appium. If we need help with something, we just use some resources from the internet or some documentation. Aside from eh issues we've had with nested elements, this has always been enough for troubleshooting. 

I have no experience using other automation tools for our devices. We only use Appium.

It's not difficult to set up and deploy. However, it does take time. We use Macbooks. We don't use Windows. It's more complicated to set up on iOS than on Windows. It can take two to four hours to configure everything once you have it deployed. For example, if you have ten devices, the time is two to four hours each, so it can take a while. 

I'd rate the solution two or three out of five in terms of ease of deployment. 

This is a free tool. 

Based on the issues we've had, I'd rate the solution six out of ten. 

I use the solution for Android and iOS mobile automation testing.

The solution's most valuable is its interface, which provides smooth drag-and-drop functionality. It is easier to capture screenshots as well.

The solution's integration with the cloud-based setup needs improvement. Also, they should work on making the link text easily clickable.

They should add an in-built framework. In addition, they should work on automatically updating the new versions for Android. Presently, we have to implement the pop-up updates manually. Due to the pipeline setup, the same updates fail to adapt to different mobile versions. They should also add a feature to automatically recognize the change of the locators and update the solution. It will save us a lot of time.

I have been using the solution for three years.

It is a stable solution. I rate its stability as an eight.

The solution's scalability is good; I rate it as a nine.

The solution's technical support is available on the Internet. You can reach out to many online forums in case of any issues.

Positive

I used the Silk Test earlier. But I will suggest Appium over it as of now.

The configuration for iOS automation requires profile provisioning and following a set of separate rules. In the case of Android, I prefer Vysor for mirror image as it is already available.

It is challenging to start the configuration from scratch. I spent around two months on the process. Instead, I suggest using BDD framework, which is readily available in the market. I rate the setup process as a seven.

The solution is easy to use. If you have resources available for Java and are looking for free tools, then you should go for Appium. But you should evaluate some other tools as well. Also, if you have experience with selenium, you must prefer Appium, as 95% of selenium libraries are similar.

I rate the solution as a nine.

We use this solution for mobile UI automation, and particularly for regression test automation.

We develop complete, end to end test cases, then we automate them and run those test cases in a DevOps process. It's a complete CICD (continuous integration, continuous development) using DevOps methodology.

Our automation job triggers immediately after a successful development build. Upon completion of automated test cases, results are emailed to all stakeholders. This is a completely automated process without any manual intervention.

This solution has improved our organization in terms of efficiency. We use this tool for one of our mobile applications that supports iOS and Android devices. The application should support all Android devices with OS version 6 and above, whereas the iOS application should be compatible with iOS 9.3 and up. Therefore, it supports multiple OS versions with all of the devices and handsets that are coming to the market.

It becomes very difficult for our regulation team to test the solution, or run their test cases, on all of these platforms and mobile devices. But, with the help of automation, we can create a single script that does so. Not only that, but we can run our tests in a 24/7 model that includes weekends. Our team members cannot work overnight or on the weekend.

This solution continuously generates reports, and the report is the only thing that needs to be analyzed by the testing team. It runs completely flawlessly and seamlessly every day. This makes it very cost effective and productive. That is one of the major benefits for us.

Appium is a very good tool because with its help we can automate all of the platforms, Android, iOS, or Windows, and there is a single solution. We can create a single framework for all platforms that can satisfy all of the needs. Being an open source solution it is free of cost.

Otherwise, there are other open source tools for particular platforms, but with the Appium library, we can automate all major platforms.

This product is still maturing, so at times there are issues with its stability if your scripts run continuously for more than fifteen to twenty hours. At times, we have witnessed the Appium server stop responding for forty to forty-five minutes. As a result, scripts do not move in this time period. Sometimes the connection resets due to USB or Network issues, which is not an Appium issue.

There is no user interface because it is a complete development solution, and you have to code in Java. I do not see any room to include an interface in the near future, as is the case with other commercial automation tools.

For iOS automation, it is very tedious to install or configure this particular library in your system, and it becomes very difficult to troubleshoot if you are not Mac and Xcode savvy. You require an understanding of the configuration of Xcode projects and you have to troubleshoot a lot of things at times. 

Configuration/Installation-wise, there is a lot of room for improvement in this solution, especially for the iOS platform.

Stability-wise, this tool is still maturing. I have seen improvement over the past two years, with every release. I expect that in another year it will be even more stable.

In our experience, if you are running smaller scripts that execute for two or three hours, then this tool is good enough. If, however, your scripts run continuously for twenty or twenty-four hours then the tool give you issues at times. The connection gets reset or the server hangs in between. These things are normally seen after ten or eleven hours.

In terms of scalability, this tool is doing well. We have automated more than five hundred test cases, which run for twenty to twenty-two hours in one go. In that way, it is doing well, although, sometimes there are cases where the Appium server hangs, and the script does not proceed forward. This has to be ironed out.

We do plan to increase the usage of this solution. Right now, our company has a lot of experience and a lot of people are learning this tool, as well as other open source solutions. We do not use any commercial products. In fact, we have a policy of using open source solutions, as they are in demand. There is nothing challenging the capability of this tool right now.

Being an open source project, there is no company that specifically supports this tool.

That said, the open source community is quite strong. If you are having any kind of issues, with your solution or your implementation, there are multiple points that are available and you can ask questions. Most of the time you get your resolution in a very quick time, maybe in a day or sometimes a couple of days. In fact, most of the time, with my experience I can say 95% to 98% of the time, I found a solution which helped us. 

The open source community includes a large user base who are actively using it and sharing their experience, as well as their implementation solutions, over the net. 

Before this solution, I only had experience with HPE UFT (Unified functional testing). I, later on, moved to Selenium because we are able to achieve the same results with this open source solution as with any other commercial product, without any one-time or recurring cost for the tool. 

Selenium has matured with time and become a stable solution for Web Application automation. More and more clients are preferring Selenium because of the no-cost factor, and as a result, there are good job opportunities available for people who can work on Selenium. 

These were the major driving forces for me to move towards the Selenium automation solution.

Installation of this particular tool is tedious, and it gives you a good number of challenges at times. You have to resolve them, troubleshoot them every now and then, and you need the right people. You need a good expert with experience who can help you. It is not possible for a novice user, or any user who is new to the team, to do all of these things. There is a steep learning curve.

In order to use this tool for iOS applications, you have to use Xcode and have to install and create profiling for your development solution. For a user who is new to the system, and perhaps not aware of Xcode or profile creation on a Mac machine, it becomes difficult. The majority of developers use Windows-based development systems. In order to automate iOS applications, we have to use Mac-based machines to provide the operating system.

This means that you need to have some kind of experience with Xcode, or at least some experience with iOS application configuration. These are the skills required in order to set Appium up on your Mac machine and use iOS automation.

A Windows-based system can be used for Android applications, but a Mac machine can be used for both iOS and Android. I rely on Windows for Android, but you are certainly free to work on a Mac machine.

There are six people in our team using this solution on all platforms. I have the role of Automation Architect, and the others are Automation Engineers. We have set up a local cloud environment in our office, and we do everything ourselves.

We deployed this solution ourselves and created our own script for Appium installation on an iOS machine. Instead of individual commands, we have created a BASH script which installs & configures the automation development environment. With this, it is easy to install and configure a system for a new developer who is coming to our team. If you do not have such a script then it is a full-day task to complete the setup and configuration on your iOS machine.

This is an open source solution so it does not cost anything for licensing or otherwise.

I had evaluated SeeTest before Appium for mobile solution development, but the customer was not willing to invest in a commercial tool. SeeTest is more stable, mature, and easy to install as compared to Appium, but it comes with a significant cost of almost $80,000 per year (number of licenses that we required). This is the reason we decided to move on with Appium.

This solution is one that you need a little bit of time and patience to learn, but once you learn it, it opens the gate to work on many other similar types of tools or wrappers that are created, keeping Selenium at the core. 

Overall, the product is good. On a scale of one to ten, I am only deducting two points because you cannot automate & run the iOS application on the Windows OS. You require Mac machines for iOS automation. Also, installation and configuration are also tedious for new users.

I would rate this solution eight out of ten.