Using Implicit and Explicit Wait in Selenium

Using Explicit and Implicit 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

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

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 Headache Solved

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.

Test Automation ROI Calculator

Test Automation ROI calculation

Test Automation ROI calculation is difficult. There are so many unquantifiable benefits to test automation. It is almost impossible to map these benefits to direct dollar savings. However, in order to make a business decision, it is important to know the test automation ROI. ROI is calculated by taking the benefits from the business decision and then dividing them by the cost of implementing that decision. Test Automation ROI can similarly be considered as a ratio between the benefits of testing and the cost of testing. The cost of testing is inversely correlated with the extent of automation. But this cost-saving happens over the years. In the interim, automation actually adds to the cost. The Test Automation ROI calculation formula is: (Saving on manual testing + Benefits from Test Automation) / (Cost of implementing Automation) Saving on manual testing can be calculated by using: The volume of Test Cases– The number of manual test cases that can be moved to automation has a direct impact on the time saved by automation. This also has a direct impact on test coverage. Number of Releases per year – Each time a product version is released, there is a substantial manual effort in testing the product. This can be cut down by using automation. Regression cycle per year– Regression tests are the ideal candidates for automation and are vital in calculating ROI. Number of browsers, devices (mobile, tablets), and configurations. Cost of manual tester. The cost of Implementing Automation can be calculated from Tool cost– Not all tools are free. Some like Selenium, Protractor, etc are open source, but a tool like Test Complete, and UFT adds substantially to the cost of implementing automation. The initial setup cost includes time spent on developing the automation frameworks, reusable components, and batch scripts. Cost of Automation Tester The benefits from Test Automation are the most unquantifiable. In order to calculate them the following should be kept in mind: To really understand the benefits of test automation, we need to see how and where all the automated tests can be utilized. It could be part of the verification process used by developers to ensure they have not introduced regression issues; integrated with the build tool as a post-build job to trigger the automation test runs on every build; besides obviously being used by the QA team as part of their testing for every release. Understanding the focus of automation with respect to maximizing test coverage, reduction in testing cycle time, reaching the market faster, etc The strategic direction of the organization To calculate your Test Automation ROI. Click on the link below: Give us your contact details here and we will collect the required data from you and calculate the ROI of Test Automation!

4 Leading Test Automation Tools

4 Leading Automation Testing Tools

Test Automation has come a long way.  The new automation testing tools of software automation now allow things unimaginable in the past. It is now possible to think of a situation in which you open your IPad and start running your tests over your company’s VPN while sitting in Central Park. The 4 leading test automation tools which have changed the automation landscape are: UFT [QTP] – Popular tool from HP which can be used to automate web and desktop applications Selenium – Most popular open-source tool available for web automation TestComplete – a Popular tool for web, desktop, and mobile automation testing TestCafé – a popular tool that uses all browsers which support HTML 5 to record and run functional tests across operating systems (Windows, Mac, and Linux, and on remote computers) and mobile devices (iPhone, iPad, Android, and Windows Phone). Let’s discuss each of these leading automation testing tools in greater detail: UFT (QTP) UFT stands for Unified Functional Testing and was formerly known as QuickTest Professional (QTP). This tool is from Hewlett-Packard. UFT combines manual, automation, and framework-based testing together into an Integrated Development Environment. Some of the key functionalities of UFT are: Cross Browser and multi-platform Image-based object recognition Visual representation of test flow Selenium Selenium was developed by Jason Huggins, while he worked for ThoughtWorks. Since the inception of Selenium 2.0 (commonly referred to as Selenium Webdriver) in 2009, testers around the world swear by its name. Selenium is the most popular testing framework for web applications. Some of the key features of selenium that make it one of the leading automation testing tools are: Open-source robust, browser-based regression automation suites and tests Ability to scale and distribute scripts across many environments It can be run in many browsers and operating systems Selenium can be controlled by many programming languages and testing frameworks. TestComplete This is a product from SmartBear Software. Using TestComplete a tester can automate the testing of software developed in various technologies. The technology platforms supported by TestComplete are desktop-based, web-based, and mobile-based (IOS & Android). It is used for automating functional testing and database testing. The features of the test complete which make it one of the leading automation testing tools are: Keyword Testing: TestComplete uses keywords to represent automation testing actions, which are easily identifiable. Test Record and Playback: Using TestComplete the user can easily record and playback the scenarios. Bug Tracking Integration: it allows for a bug tracking system integration. Data-driven testing: With TestComplete it is no longer required to hardcode the data. In fact, you can feed that data from an external data source and monitor the test based on different types of data. TestCafé TestCafe is the functional web testing tool from DevExpress. The key features which differentiate TestCafe and make it one of the leading automation testing tools are: Ability to work without plugins on any browser Compatible with any browser which supports HTML 5. (Nowadays almost all browsers support HTML 5) It also supports all the major operating systems. Have questions about Test Automation? Contact the software testing experts at InApp to learn more.

10 Common Selenium Automation Testing Commands for Newbies

10 Common Selenium Automation Testing Commands for Newbies

Before we come to the Selenium Automation testing commands, let me relate to you an interesting anecdote on the christening of Selenium. Jason Huggins (the creator of Selenium) worked at ThoughtWorks. One day he got really irked with their Competitor “Mercury” (owned by HP). In his frustration, Jason wrote a mail to his colleagues at ThoughtWorks. The mail said that selenium supplements could cure mercury poisoning. Ever since that day the name Selenium got associated with this product. Since the inception of Selenium 2.0 (commonly referred to as Selenium Webdriver) in 2009, test engineers around the world swear by it. Selenium is the most popular testing framework for web applications. If you are a budding tester or a developer looking for some common Selenium Automation testing commands to make your life easier while doing automation, you have come to the right place. 10 most common Selenium Automation testing commands: 1. Open a browser Web applications are the flavor of the season. Why?  Coz, they are running on browsers! Duh! A web application is essentially an application running on a browser. The browser’s UI is actually working on the client side. So, the most basic thing for a budding automation tester working on a web application is to simulate opening a browser. Here is the command for it: Driver = new <browser name>Driver(); 2. Navigate to the web application As mentioned earlier, if you compare the web application architecture to the client-server architecture, the web application’s client is actually the browser’s UI. In order to access the application, one needs to query the server, which is done by typing in the URL of the server. In order to automate this scenario via Selenium, you have a couple of options: Option 1 – driver.navigate().to(“url”) Or Option 2 – driver.get(“url”) 3. Maximize the browser window Testing is really about exploring real-life user interaction with any application. One of the most common user behaviors is to maximize the browser before using any application. The command to execute this action is: driver.manage().window().maximize(); 4. Close the browser The most basic actions are opening and closing the browser. We already saw how to open a browser, now let’s see how we can close the browser using a selenium code, automatically; There 2 options for closing the browser: driver.close() (will close the current window in focus) or driver.quit() (will close all windows, including child windows, and safely end.) 5. Switching frames How does the application handle a pop-up window (child window)? This is a critical part of testing the application. Below is the command for this: webDriver.switchTo().window(handle) 6. Finding an Element Another frequently used Selenium command is to find an element on the UI. The element can be easily found on the basis of a unique identifier. The uniquely identified could be “element id” or “name.” Selenium provides many options for finding elements (ClassName, cssSelector, id, LinkTest, Name, partialLinkTest, tagName, xpath) Out of the above, CSS selector and XPath are the most frequently used, and here is the syntax for using them: driver.findElement(By.Xpath(“”)) driver.findElement(By.cssSelector(selector)) 7. Writing into a Text Box Webpages frequently contain forms with text boxes. So a basic test would include commands to write onto a text box. In order to do so the existing text needs to be cleared and new text inserted using the following commands: driver.find_element_by_xpath(xpath).clear() driver.find_element_by_xpath(xpath).send_keys(“data”) 8. Count of element One use of Selenium-based automation could be running a set of scenarios on a group of elements on a UI. In this case, it would be helpful to have a count of elements that are to be subjected to the automation scenarios. Below is a command to count the number of elements: iCount = driver.findElements(By.xpath(“xxx”)).size()); Waits – In most modern web applications, elements load at different times. This brings complexity to selenium-based automation testing. This is solved by using “wait” commands: 9. Implicit wait Implicit wait means waiting for a specific period of time. driver.implicitly_wait(55) It 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 tells selenium to wait for an exact period of time before it throws a “No Such Element” Exception. 10. Explicit Waits Explicit Waits means waiting for a condition. WebDriverWait(driver, 55).until(“condition”) The explicit wait will tell the Selenium web driver to wait for a condition. Best Practice while running automation tests – Using Tear Down techniques: It is generally a good practice to clean up the database after each automation run. This is important because after each run the size of data in the database increases. This could slow down the application if it has to deal with a huge amount of data, over a period of time. Have questions about Automation Testing? Contact the software testing experts at InApp to learn more.

Benefits of Test Automation

Benefits of Test Automation

Benefits of Test Automation Saving time spent on test execution Increase in Test Coverage Sustained reliability despite repeated runs Reduced dependency on the QA team To understand these benefits of test automation let us see how Test Automation helps its 3 main stakeholders – The developer, the Product Manager, and the CEO/CIO Benefits of Test Automation for a Developer If you are a developer practicing Test Driven Development, you write code till the test for the code passes. Once your code passes, does it means you were successful?  Yes, but only at the functional level. Now, as happens in all Products, changes are introduced. The impact of this can touch the UI, the database, and already written functions. This brings in the need for regression testing. For a quality-conscious developer who abhors that his code introduced bugs, an automated test suite will be a face-saver. Without the need of depending on QA to validate if his changes have not introduced bugs, he can run the regression test suite and fix issues, if any, right away. Saves a great deal of time in the long run. Benefits of Test Automation for a Product Manager As a product manager, your responsibility is to deliver the product along with all its features within the committed timeline. Now suppose a situation in which you are close to the final release. You have worked with your team for over 12 months and you are close to completion. Suddenly you realize that an important feature may have been missed. You rally your team around and make sure you deliver within the timeline. In the process, you may have to compromise on regression. Keep in mind that whatever changes you make has cascading and often interrelated effects on other modules of your product. In addition, you don’t know if your developers didn’t do the basic checks in a hurry for the approaching deadline. If you had planned on using test automation you could have easily accommodated QA without affecting the delivery date. You could have run regression automatically. Your developers could have used test scripts ensuring lesser regression and code quality issues. You could have also planned cross-platform automated testing. Benefits of Test Automation for a CIO/CEO As CIO/CEO you can actually reap the rewards of Automation in your organization. With Test Automation you can ensure that large parts of the organization (developers and product managers) are working efficiently. This could mean that they have enough time to come out with the best quality product. This could also mean your QA team had enough resources at their disposal to ensure that your product was of the highest quality. You would have successfully reduced your dependency on your testing team and acquired artifacts (testing scripts) that will be of value for future releases of your software product. Have questions about Automation Testing? Contact the software testing experts at InApp to learn more.

Step-by-Step Neoload Tutorial in Performance Testing

Nowadays, most, software applications are written as web-based applications to be run in an Internet browser. Independent software testing provides key contributions in making sure the user experience and expectations are met to the highest level. The software industry is currently going through a highly competitive phase as Darwin says-“Survival of the fittest”; this is what will be noticed in this industry too. In order to survive the competition, the capabilities and incapabilities of a software application need to be tested. This includes testing for functionality, usability, and compatibility of the application across the environments it is used on. Along with this, a very important aspect is Performance Testing. Performance testing is a type of non-functional testing that is mostly recommended for business-to-business, business-to-customer applications. Performance testing can be categorized into load testing, stress, volume testing, etc. Common questions asked are, Will our application handle the load or, will it fall apart under load? How many users can our application handle, simultaneously? At what point does the server crash? Performance testing may answer the above questions. The cause of performance-related issues varies with the architecture and configuration of the application. Poor software, network configuration, poorly optimized software code, hardware configuration, etc. are some of the common reasons for performance degradation. One of the best and most emerging tools available to identify ‘performance issues’ in the market is NeoLoad. NeoLoad Tutorial NeoLoad was introduced by “Neotys” as a performance-testing solution for web and mobile applications. NeoLoad becomes popular with its simplicity in usage and easiness of analyzing reports. It allows, tracking statistics of the application infrastructures such as OS, database, and networks, along with the usual response time. Recording scenarios and analyzing its result in NeoLoad is just a 3-step process:- Installation 1) Download and install NeoLoad (for Windows) from the Neotys website 1.1) Install the downloaded exe file to your system. Designing Test Scenario 1) Open NeoLoad and create a project. 1.1) Select the “New Project option”. N3 1.2) Enter the project name and click Finish, NeoLoad design UI will appear. The design page contains three sections: Virtual Users– NeoLoad records the scenarios under the virtual user section, for the free version user can create up to 50 virtual users. To know more about virtual users click here. Populations– Populations are a group of virtual users, mainly used for monitoring the application behavior in different ways. Eg: an e-com application can be tested by simulating 60% of users browsing the site, and 40% making transactions under different browsers. To know more about populations click here. Monitors– NeoLoad supports monitoring of OS, Networks, Databases, Web/EJB Tier, etc. Adding and configuring monitoring machines are allowed through the monitor tab. For more details click here. 1.3) Recording with NeoLoad – virtual users can be created automatically by clicking the start recording button. After clicking the ‘OK’ button NeoLoad Container will open along with the selected browser window. Open the application and enter the Container name in the provided text box. In the above example, ‘google.com’ is the test site and the container name given is “Searching NeoLoad”. Based on the actions, the user can change the container name by just renaming the existing name- the rest of the actions will be recorded under the new container name. The reference video of the NeoLoad recording is here. The recorded scenario will be listed under virtual user profile containers as shown below. Users can apply conditions and loops just by dragging them from the actions menu. The selected request can be edited from the right-hand side. Running and Analyzing Results 1) For running the recorded scenario a population should be created from the population tab. Go to populations Click on the ‘+’ button, enter the name, and click OK to save. In our example, we created only one virtual user, so that user scenarios are running by giving 100% population. After creating the population, assign that population to the runtime scenario. The settings required to run the load test are defined under this scenario page. After configuring the scenario page, the load test scenarios can be run by clicking the play button. After running the scenario a report will be generated. The generated report can be exported to PDF, HTML, XML, and Word formats. Select “Tools” from the ‘Test Summary’ page Then select “Generate Reports” from the “Tools” menu Then select the report type Then customize the report’s contents From the output options page, select the output format and click Finish to generate the report. The generated report can be compared with a predefined set of values using SLAs. SLA (Service Layer Agreements): It allows the user to set a baseline for performance statistics. By applying SLA user can compare the values in generated report with a predefined set of values. Neotys provides a wide range of support to their product NeoLoad through their blogs, websites, and communities. Have questions? Contact the performance testing experts at InApp to learn more.

Useful tips in Selenium WebDriver

The integration of WebDriver API has been a major change in Selenium in terms of browser automation. WebDriver has a well-designed object-oriented API that provides a simpler and more concise programming interface. Along with Selenium, WebDrivers can make direct calls to the browsers by directly using the browser’s built-in support for automation. The following figure shows the Selenium Web server as an intermediary that interacts with the script (in Python / PHP) and the browser (Chrome / IE / Safari / Firefox). Here are some useful tips on using Selenium WebDriver 1. Open different browsers in the web driver a. Firefox Driver WebDriver webDriver= new FirefoxDriver(); b. Chrome Driver WebDriver webDriver= new ChromeDriver(); c. Internet Explorer Driver WebDriver webDriver= new InternetExplorerDriver(); d. Safari Driver WebDriver webDriver= new SafariDriver(); 2. Open new Tab webDriver.findElement(By.cssSelector(“body”)).sendKeys(Keys.CONTROL +”t”); 3. Close the newly opened tab webDriver.findElement(By.cssSelector(“body”)).sendKeys(Keys.CONTROL +”w”); 4. Wait for an element to be available on the page a. Method one WebDriverWait wait = new WebDriverWait(driver, 30); WebElement element = wait.until(ExpectedConditions.elementToBeClickable(By.xpath(‘xpath-of-element’))); b. Method two List<WebElement> sElements = webDriver.findElements(By.xpath(xPath)); int sCount = 0; while (sCount < sTime) { if (sElements.size() > 0) { break; } else { Thread.sleep(1000); sCount = sCount + 1; sElements = webDriver.findElements(By.xpath(xPath)); } 5. Drag and Drop items Actions builder = new Actions(driver); Action dragAndDrop = builder.clickAndHold(someElement) .moveToElement(otherElement) .release(otherElement) .build(); dragAndDrop.perform(); 6. Execute Java Script statement JavascriptExecutor jsx = (JavascriptExecutor) driver; jsx.executeScript(“sample code”); 7. Enable elements that will be visible or enabled only on mouse over ${iid}= webDriver.findElement(By.id(“id123″)).getAttribute(attributevalue); Execute Javascriptvar innerDiv = document.querySelector(‘DOM- element#${iid}’);innerDiv.style.display=”block”; DOM-element can be div or input or li 8. Upload a file – We can do it in 2 methods a. Method1 – If the upload button is defined as DOM element – ‘input’ use following method WebElement w = getWebDriver().findElement(By.xpath(element-xpath)); w.sendKeys(path-of-file); b. Method2 – If the upload button is not defined as – ‘input’ String filePath = “path-of-file-for-upload”; JavascriptExecutor jsx = (JavascriptExecutor) driver; jsx.executeScript(“document.getElementById(‘fileName’).value=’” + filePath + “‘;”); 9. Switch between frames WebElement iframe = getWebDriver().findElement(By.xpath(“//iframe xpath”)); getWebDriver().switchTo().frame(iframe); 10. Switch back to default content from the frame After performing actions in the iframe that was switched we might switch back to default content to perform further activities getWebDriver().switchTo().defaultContent(); 11. Switch to new window for (String winHandle : webDriver.getWindowHandles()) { webDriver.switchTo().window(winHandle); } 12. Switch tab String oldTab = webDriver.getWindowHandle(); ArrayList<String> newTab = new ArrayList<String>( webDriver.getWindowHandles()); webDriver.switchTo().window(newTab.get(0)); 13. Wait for page load webDriver.manage().timeouts().pageLoadTimeout(100, TimeUnit.SECONDS); 14. Scroll window to bottom, to view elements webDriver = getCurrentWebDriver(); JavascriptExecutor jsx = (JavascriptExecutor) webDriver; jsx.executeScript(“window.scrollTo(0, document.body.scrollHeight);”); 15. Scroll window to specific height -scrollHeight is the value passed to function webDriver = getCurrentWebDriver(); JavascriptExecutor jsx = (JavascriptExecutor) webDriver; jsx.executeScript(“window.scrollTo(0, ” + scrollHeight + “);”); Have questions? Contact the software testing experts at InApp to learn more.

InApp India Office

121 Nila, Technopark Campus
Trivandrum, Kerala 695581
+91 (471) 277 -1800
mktg@inapp.com

InApp USA Office

999 Commercial St. Ste 210 Palo Alto, CA 94303
+1 (650) 283-7833
mktg@inapp.com

InApp Japan Office

6-12 Misuzugaoka, Aoba-ku
Yokohama,225-0016
+81-45-978-0788
mktg@inapp.com
Terms Of Use
© 2000-2026 InApp, All Rights Reserved