What’s The Worst Advice we’ve ever heard about Test Automation Tool Comparison?
The worst advice you can hear on Automated Testing Tools comparison is “There isn’t any need for using the tools trial version.” In this article, we will explain why a trial is essential when doing an Automated Testing Tools comparison and how we can do this trial systematically. There are many things you need to do while you compare Automated Testing Tools. You do an analysis on the basis of your selection criteria. To know the Automated Testing Tools comparison criteria please read our blog: Automated Testing Tools Selection Headache Solved How to Choose Automated Testing Tools? But finally, just before you take the plunge with the tool you have shortlisted, it is very important to do a trial. Till the time you haven’t gotten your hands dirty with the tool itself, you can’t really tell how useful or how useless it would be for you. Of course, you can’t spend weeks doing a trial. In order to do the trial systematically let me present to you 4 point plan of action: Automate selected scenarios using the shortlisted tools. When doing a trial you can’t run the full set of test cases. You wouldn’t want to waste your time doing so when you aren’t fully convinced this is your tool of choice. Instead, you should choose the test case scenarios and run them on the trial version. Select a complex test case. So which are the test case scenarios, which would be run on the trial version? This is a critical decision. If you choose a scenario that is simplistic, you wouldn’t know if your complex scenarios will run. Therefore choose a scenario that is fairly complex and covers all the critical components of your software. This would ensure that the automation test coverage through this tool is high. It is also important to keep the customer in mind when you shortlist the scenarios. It is important to choose a scenario that is critical to your customer. This is after all the main aim of test automation. Find a Known Issue. Don’t forget the purpose of testing. The purpose of testing is to explore any bugs in your application. The real test of the effectiveness of a tool is in its ability to find a bug. But how do you know if the tool has this ability? Well, if the application has a known bug, automate it and showcase that the issue is identifiable using the script execution Generate and Analyze the Report. Lastly, it is very important to have a close look at the report produced by the tool. Is the report in the format that you need? Is it easily understandable? All these questions are important before you finally end your Test Automation tool comparison. Need help? Contact us now!
Using Implicit and Explicit Wait in Selenium
Explicit Implicit wait selenium is an important command. They are used while running automation scripts created using Selenium Web Driver. Implicit and Explicit Wait in Selenium is primarily used to handle the different load times of elements on the web browser. Using Implicit and Explicit Wait in Selenium Example Consider a situation in which you are testing the Facebook web application and you want to test a scenario in which you post a comment. When you automate this test scenario, there is a possibility it may fail, especially during low bandwidth and high usage. The reason for the automation failure, in such cases, is that the post button was yet to load. Elements on a web application load at different times. In order to handle this, Selenium has introduced the usage of “Explicit” and “Implicit” wait. Selenium documentation on Explicit and Implicit wait warns users not to use both together. Using Implicit Wait in Selenium The implicit wait is a quick and easy way to handle the problem of elements loading at different times on a web application. It is applicable at a global level and affects all the elements. It basically tells selenium to wait for a specified time before it throws a “No Such Element” Exception. Let’s dive into an Example: driver.manage().timeouts().implicitlyWait(10, TimeUnit.SECONDS) In the above example, we have instructed selenium to wait for the time frame of 10 seconds if the element is not present. It means that if the element is not located on the web page within that time frame, it will throw an exception. The script will keep polling the DOM to find if the element has shown up. The polling interval cannot be changed. If the element is found selenium continues with the execution. There are some apparent drawbacks to this: Applied globally and hence affects all elements It can be only used to find elements and not conditions The polling interval cannot be changed It will slow down the execution time Using Explicit Wait in Selenium The explicit wait is a remedy to some of the problems which occur in implicit wait. However, the flip side to explicit wait is the complexity and the number of lines of code. When we use Explicit wait, we tell the Selenium web driver to wait for a condition to occur. This is different from waiting for a specified period of time. Here is an example: WebDriverWait wait = new WebDriverWait(<expected condition>,10) Here selenium will wait for an expected condition or 10 seconds whichever is earlier. The list of expected conditions for Java can be found here. Some of these conditions are listed below: alertIsPresent() elementSelectionStateToBe() elementToBeClickable() elementToBeSelected() frameToBeAvaliableAndSwitchToIt() invisibilityOfTheElementLocated() invisibilityOfElementWithText() presenceOfAllElementsLocatedBy() presenceOfElementLocated() textToBePresentInElement() textToBePresentInElementLocated() textToBePresentInElementValue() titleIs() titleContains() visibilityOf() visibilityOfAllElements() visibilityOfAllElementsLocatedBy() visibilityOfElementLocated() A user on Trello explained the differences in using Explicit and Implicit very well. I am summarizing the differences between Implicit and Explicit Wait selenium here: Explicit: Is in part of selenium which is local Can handle most of the conditions Returns either success or timeout error A success condition can even be the absence of an element Polling time can be customized But the as long and complicated syntax Implicit: Simple usage Is in the part of Selenium that is Global (the part controlling the browser) Can only work with finding elements Returns element found or error Polling time cannot be customized Need help? Contact us now!
Make Your Testing Run Faster with Protractor
Protractor is an E2E test framework for AngularJS app testing. It is a Node.js program that works on top of WebDriverJS. Protractor was developed by the Angular team for testing Angular. It recognizes Angular’s processes and waits for them to complete. As a result, the browser “sleep” time is optimized and the tests run faster in Protractor testing. Protractor Vs Selenium If you visualize Selenium and Protractor diagrammatically, the protractor encapsulates all of the Selenium. Since Protractor is built on a Selenium base, all the functionalities of Selenium are also available for Protractor testing. As you can see in the diagram, large parts of the functionalities of Selenium and Protractor are similar. But Protractor is also different in many ways from Selenium. One of the bigger differences is that Selenium interacts with a web page in a different manner when compared with Protractor. In Selenium, because of the way it interacts with the webpage, you have to wait or sleep many times in running automation. Selenium is not able to optimize the wait time for elements to appear on the web pages. Selenium requires the setting up of waits (Implicit and Explicit) so that automation can be synchronized. In case of wait is not programmed into an automation code, selenium will throw exceptions. In the case you are using an Implicit wait with Selenium, you can wait for the element. In case you are using an Explicit wait with Selenium, you can customize the waits to correspond with some expected conditions (elements to be clickable, elements to be visible, etc). You end up with lots of waiting based on what “wait” you program into the automation. The protractor is very tightly coupled with AngularJS and therefore is able to optimize wait and reduce wait time. It also has commands like `browser.waitForAngular()` to wait until the cycle is done before continuing on. Because of these functionalities in Protractor, you can avoid waiting (Explicit or Implicit) for business logic to process. In fact, Protractor automatically applies this command `browser.waitForAngular()` before every WebDriver action. For details on this please visit this page. With Protractor testing, the test script runs using Node.js. The protractor runs one extra command before performing an action on the browser to make sure that the browser application which is being tested has stabilized. For example: element(by.CSS(‘button.happy’)).click(); This will result in three commands being sent to the Browser Driver. /session/:sessionId/execute_async – First, Protractor tells the browser to run a snippet of JavaScript. This is a command which asks Angular to send a response when the application is done with all timeouts & asynchronous requests, and ready for the test to start again. /session/:sessionId/element – Then, the command to search the element is sent. /session/:sessionId/element/:id/click – Finally the command to “click” is sent. Instruct the web driver to wait until Angular has finished rendering and has no outstanding $http or $timeout calls before continuing. Note that Protractor automatically applies this command before every WebDriver action. Please visit this page for further details. Need help? Contact us now!
3 Myths of Test Automation
Let’s be clear, “3 Myths of Test Automation” is not about bashing test automation. If you are a tester frustrated at having to do test automation (or generally unhappy!), reading “3 Myths of Test Automation” will not bring you any solace. However, if you are a CEO/ CTO/ Product manager or someone genuinely interested in finding a value proposition through test automation, you may find this a good read. Automation testing is a concept that is heavily marketed today. You may ask, WHY? Well, the simple answer is – “Clients dig Automation.” Let me list down your common problem and how you believe test automation is your panacea: While these beliefs aren’t entirely false, they hide some common misconceptions. It is, in fact, these incorrect assumptions that result in the failure of test automation projects. Let us enumerate the tasks in test automation and map these tasks to a human or to a machine (automation script): If you agree with the task distribution in the table above then you cannot deny the following misconceptions: “Test automation is a means to reduce cost,” is one of the 3 myths of test automation. To be honest, test automation cannot be looked at from the prism of profit/loss. The benefits of test automation: – reliability, scalability, reduced dependency, robustness, etc, are unquantifiable. You cannot put a number on them. Even the most notable critics of test automation like James Bach or Michael Bolton, would agree that test automation has unquantifiable and innumerable benefits. Just that you can’t measure all these benefits and you can’t map them to cost savings. “With Test automation, I can replace manual testing” Nothing can be farther from the truth. As the table above shows, test automation supplements a manual tester. It does not replace the manual tester. Let me quote Jonathan Kohl (famous software scientist) from his interview with DZone: Kohl: “Think of all the things people can do well that machines can’t do well. Machines can’t feel, they can’t have a hunch, they can’t be suspicious, they can’t investigate, and they can’t change their minds due to better information. I don’t see automated testing throwing manual testing aside. And I have seen a lot of efforts fail when people have tried to do that.” “Test automation will improve my product quality.” This may not be a complete misstatement, but it is a myth. A machine can find a problem if it is programmed to find it, and it can do it without any intervention, efficiently, and with reliability. A human will be inefficient and unreliable. But a human being can do what a machine can’t; it can ideate and anticipate. A human being can find a problem, which was not thought of in the product specification (which is actually the true purpose of testing). If you really care about product quality, give the tester all the automation tools and let him ideate and anticipate. This is the value proposition offered by Test Automation! Need help? Contact us now!
How to Select the Right Test Automation Tool
Test Automation tool selection is a headache. But fear not, we have the cure for your ailment. At the outset let me congratulate you. By choosing to go for Test Automation you have made a very judicious decision. But if you are still considering Test Automation, you may want to read about: The benefits of Test Automation And I recommend the below, for the confused lot: If they made the correct decision? Now that you have made up your mind on Test Automation, the next step is to decide on the tool. Test Automation tool selection criteria 1. Cost Cost for obvious reasons is the first concern. There are many tools in the market. But not all tools are within your budget. Small organizations are generally not able to afford costly tools like UFT (from HP). Hence it is important for you to make a budget and shortlist the tools that fit your budget. It also makes sense to do this exercise first. This will save you unnecessary effort in analyzing tools that are beyond your budget. 2. Community Support Support by a community of developers is an important Test Automation tool selection criterion. Essential for organizations that are just starting out with Automation. They would need support in setting up the tool, remedy for any glitches, patches for bugs, and training on usage. Also, an organization can get a lot of help with usage if the tool has a large user base. A large user base ensures forums and vibrant discussion on the tool. The other way to ensure support is to buy from a recognized & established vendor (for example HP). 3. Script Creation time The major overhead of automation is the time spent on writing the script. So it is important to choose a tool that doesn’t make your Automation ROI negative. How can that happen? Well, let me give you an example. Suppose it takes the manual testing team around 100 hours to complete the testing of your software. Now you introduce Automation testing with an expectation to cut down your manual testing time by 50%. So you have saved 50 hours. Congratulations! But hang on. Did you realize that you may actually have spent 60 hours writing the script for the automation? So let me recalculate your effort and make it clear to you: Time spent on testing before automation = 100 hours Time spent on testing post-implementing automation = 50 hours (manual) + 60 hours (scripting) = 110 hours. My friend, you have a negative ROI for Test Automation. So you go back and buy the tool (price $ 3000) which makes scripting a breeze for you. But did you take into account the cost of the tool itself? Let me recalculate it for you: Cost of testing before automation = $ 4000 (100 hours @ $ 40 per hour) Cost of testing after automation = $ 2000 (50 hours of manual @ $ 40 per hour) + $ 3000 (tool). Net cost $ 5000. Once again your ROI is negative. It is therefore essential to consider both the script creation time and tool cost in conjunction before you purchase your test automation tool. 4. Scripting Language Well, I hate to break it to you. You can’t buy a tool and expect to script in the programming language of your choice. So if you aren’t proficient in all the programming languages, (.NET, Java, Python, Ruby, etc) which is highly likely (to this date I haven’t met a programmer proficient in all languages), I suggest you pick the tool which allows scripting in the language of your choice. 5. Handling UI Changes If you are testing the UI of your application, the ability of the automation tool to handle UI change is an important criterion for selection. Not all tools are equally capable of handling UI changes. It would make sense to analyze the complexity of your software’s UI. For example: if you are developing an analytics dashboard. You are likely to have many widgets. It would, therefore, make sense for you to choose an automation tool that can handle complex UI changes. Have questions about Test Automation? Contact the software testing experts at InApp to learn more.