Automated QA: A Clever Solution to Avoid Stale Element Reference Errors
You’ve just written a test using the WebDriver framework and you’re confident that it’s complete. You go to test it and….it fails with the dreaded stale element reference error.
What's Your Move?
According to MDN, the official Mozilla website for development documentation of web standards, the error occurs because you are trying to perform an action to a web element that references an element that is no longer attached to the DOM. A variety of scenarios can trigger this behavior from the web page. It's not expected to be in the page, so it’s best practice to avoid trying to perform an action with that web element. However, there are events that can trigger the replacement of an element, resulting in the web element representing it to become stale. The latter is the scenario we will be discussing.
If you’re anything like me when you face an error, you’ll turn to the internet for help. A quick search will tell you to solve this issue by retrying in a loop. Not a great fix, but QA engineers will still use it because, well, it works. However, I caution you to be aware of the potential pitfalls associated with this approach. The loop can be infinite depending on the implementation. This can be easily solved by establishing a limit, but this approach still isn’t scalable. It would require you to duplicate a lot of code that includes a loop and a try catch block. Now, we have an issue that cannot be solved as easily.
Take this Selenium.NET code as an example:
You may notice the potential pitfalls mentioned above. For one, it may loop indefinitely because there is no control in case the element is forever stale. And, we’ll still need to repeat this code for additional actions like .GetAttribute, .IsEnabled, .Text which will create our scalability issue. If you go back to the definition of stale element reference error in MDN, you will notice it mentions a UUID, which the WebDriver uses to identify each element it fetches. This UUID changes whenever an element changes. When an element goes from not stale to stale back to not stale again, change is happening, right? Understanding this is crucial in the development of a more scalable solution to avoiding the stale element reference error.
First, you will need to make sure you have access to that UUID in the framework you are using. In Selenium.NET, it is available through the ToString() method of the IWebElement interface. Then, you must find out which action triggers the replacement of the element you are trying to interact with. This step is critical because it defines a before and after and it will help you understand the application better, which is a win for you as part of the QA team. Now that you have identified the turning point, save the UUID of the element before that command.
Finally, you must find a way to limit the evaluation of this UUID. You can choose to limit by amount of iterations or time. Since the changes of the element happen over time, maybe time is the best way to go. In Selenium.NET, the WebDriverWait class will help since you can specify a timeout limit.
The code in Selenium would look like this:
This solves both our pitfalls because it has a limit and a timeout exception. After the implementation of these lines, you are safe to interact with the element. Is it perfect? Maybe not, there still may be some scalability issues, but most of those can be easily addressed regardless of your architecture.
About the Author:
Derick Arzu is a Software Engineer at number8 with extensive experience in QA Automation. He is knowledgeable in Selenium WebDriver, WebdriverIO, Protractor.js, NUnit, Mocha.js, Cucumber.js, and Chai.js. You can keep up with him by following his blog at https://derickarzu.dev/
Looking to add an experienced QA Automation Engineer to your team?
number8 can help with that. Connect with us today or continue exploring all of our custom software development and QA Automation services here.
Quality Assurance (QA) is an essential aspect of the software development process. Experienced professionals carefully comb through every feature, addition, and component of a software program or application to determine if it lives up to their standards. In this highly competitive world, companies can't afford to put out lackluster products. QA Testing is especially crucial in the software development industry because customers directly interact with and rely on software products. They'll immediately notice if something isn't working as it should. Here are some of the best practices for QA testing during software development:
Always Keep User Experience in Mind
When a company develops a product, the end goal is always to delight the user. You don't want to create something clunky, slow, inefficient, or challenging to navigate. QA testing teams often miss the bigger picture while examining minute details. If the overall user experience is poor, these small details won't matter.
Know Who Your Audiences Are
Different audiences have different expectations. Developing a software program for millennials can be very different from developing a platform for an older audience. QA teams must keep the target audience in mind while assessing products to ensure it provides a good experience.
Optimize QA Testing by Focusing on the Most Important Sections
Oftentimes it isn't feasible to comb through every aspect of a software program's code during quality testing. Teams must optimize the process by prioritizing sections that are most important or relevant. Focus on testing components that directly impact users, since their experience is vital for a program's functions.
Arrange Bug Fixes Based on Usage
Every software product has bugs that must be fixed to improve user experience, and QA teams need to focus on flaws in the most relevant sections of a program. For example, bugs in the order placement or complaint registration components of an app should be addressed immediately.
Maintain Communication with Developers
QA teams and developers must work together during the testing process. Open communication between these two departments can optimize both testing and the development processes. Testers get a clearer idea about the developer's intentions, while developers understand how to improve the quality of their products actively.
Run QA Tests in Real and Relevant Environments
Your program should work on platforms that users commonly use. Most people don't have supercomputers or the latest operating systems. A large portion of your audience will want to run programs on slightly dated systems. Make sure every aspect of the product is working well on various platforms and real-life conditions.
Have a Dedicated Security Assessment Team
Typically it’s important to have a dedicated team that focuses solely on security operations. Modern users have a healthy distrust for software applications and won't trust any program without a reliable security system in place.
Maintain a Dedicated Performance Assessment Team
A performance assessment team will navigate a program or application from a user's perspective. The process helps them identify issues in the performance of the end product and provide detailed reports on it.
Test Third-Party Systems
Applications and software programs often use third-party components like social media plug-ins, shopping carts, etc. Users will only have a smooth experience if all third-party systems work efficiently with your program. Always check them carefully for compatibility issues or related problems.
Always Take Customer Feedback into Account
No system is infallible, and QA teams are no exception to this rule. Fortunately, you have a large group of thousands of users willing to provide feedback on an application's performance. Always take their inputs into account during the QA testing process.
A well-planned and well-executed QA routine will ensure the product that reaches your audience is as reliable and efficient as possible. Companies should also review their QA routines regularly to ensure they remain useful, especially if you notice that too many issues are slipping through the cracks. At Number8, we believe in developing software that is user-friendly, reliable and completely functional. As a result, we are always recruiting talented QA professionals for quality assurance jobs on our team. To learn more about how we can help you complete and successfully launch your software project, contact us at 502-890-7665.
On top of delivering a project on time and within budget, developers must test for quality assurance upon completion to ensure stakeholders' expectations have been met. However, testing for quality after a product is built, usually results in far too little, too late. The agile model of software development encourages practicing quality assurance throughout every phase of the project. The agile way also prioritizes quality by making it the responsibility of every team member, not just the QA testers. As a result, the QA team coordinates efforts with the development team at each iteration, providing continuous testing. Implementing a feedback loop is a fundamental step in the quality assurance process. In order to guarantee that the product meets all of the requirements (feature functionality, design, reliability, usability and efficiency), it can be helpful to enlist the perspectives of those with varying backgrounds. This can include those proficient in testing, business and or development. Quality assurance testing can be both manual and automated. While both approaches are proficient at mitigating bugs, automated software testing is often more beneficial in that it is quicker and more effective at checking for code correctness. It's important to remember that the goal of Q & A testing is to find faults within the software so that an error-free application can be delivered to the client.
The following are integral software testing methods when best practicing quality assurance:
Test Driven Development (TDD)
TDD works by building a project's code around the QA tests. The programming team first designs and builds tests for functional code, and then creates code that will pass them. This development method helps everyone gain an understanding of the code's purpose before development; guaranteeing the initial functionality of the code and effectively building in quality.
Behavior Driven Development (BDD)
Similar to TDD, in that the test is written before the code, BDD tests the behavior of an application under specific conditions. This is done with the end user in mind. As development progresses, BDD often proves to be more reliable than TDD. BDD is also written in English instead of code, allowing for a more streamlined feedback loop.
Acceptance tests are simple pass or fail tests that check whether or not a feature behaves as it should. These are often automated to meet customer and business requirements.
Once one feature is functional, regression tests ensure it's stability throughout the software's other modifications. As more features are built, these automated tests check that the others aren't being negatively affected as a result.
Exploratory tests are usually manual, in that a human operates the software looking for unknown unknowns. These tests are meant to identify new situations that the development or QA teams haven't thought of. Once a product thoroughly meet's it's intended purpose and performs well under pressure, the QA testing is complete. At Number8, we believe in developing software that is user-friendly, reliable and completely functional. As a result, we are always recruiting talented QA professionals for quality assurance jobs on our team. To learn more about how we can help you complete and successfully launch your software project, contact us at 502-890-7665.
Described concisely and directly, Unit Tests is Quality Assurance (QA) for the core of your software. The main difference between Unit Tests and regular QA is that Unit Tests are not done by a user interacting with the software directly. In fact, they are done by a programmer with code.
When we develop software, it must meet an objective or main requirement.
The core of the software is the code that relates directly to that objective.
The core is essential. If it does not function correctly, the software has no purpose.
Examples of software cores:
Online Payment - the code that processes the credit card or web payment method given by the user.
Hotel Booking Engine - the code that associates the user’s information to the hotel room and saves this to a database.
Scientific Calculator - the code that performs the actual calculations and returns a result.
When a software is declared 'done,' Quality Assurance (QA) tests the software to assure it satisfies its objective.
In a controlled environment, QA tests every core function possibility, making sure nothing breaks and everything works as expected.
The core is outlined clearly with every one of its cases for QA to test continuously.
The number of tests QA needs to perform can grow rapidly...
For instance, take a basic calculator (a relatively simple, single page application) that uses 4 basic functions (ADD / SUBTRACT / MULTIPLY / DIVIDE)At first, QA needs to test the calculator's 4 basic functions... However, to ensure quality, QA needs to test every possible combination of functions at one time.
One feature at a time:
Two features at a time:
ADD / SUBTRACT
ADD / MULTIPLY
ADD / DIVIDE
SUBTRACT / MULTIPLY
SUBTRACT / DIVIDE
MULTIPLY / DIVIDE
Three features at a time:
ADD / SUBTRACT / MULTIPLY
ADD / MULTIPLY / DIVIDE
SUBTRACT / MULTIPLY / DIVIDE
SUBTRACT / DIVIDE / ADD
Four features at a time:
ADD / SUBTRACT / MULTIPLY / DIVIDE
For a basic calculator application that has four functions, QA needs to run 15 tests continuously to ensure it works properly.
Each scenario should be tested with its own input and all outputs need to be verified.
Now imagine another a new function is added to the app, for example, the trigonometric function sine. You have to test all the above functions again, but this time with the sine code added.
With the addition of 1 function, the number of tests increases from 15 to 31. The addition of 1 function doubles the number of tests to perform and forces QA to repeat tests.
A typical scientific calculator includes at least 13 functions: add, subtract, multiply, divide, percent, sine, cosine, tangent, square root, nth root, exponent, log, factorial.
That yields a grand total of 8191 different test cases to perform!
This amount of QA is not feasible for a person to perform.... enter unit tests.
Unit Tests are QA for the software core done by machine calculations, therefore free of human errors.
Unit Tests will send inputs to the software core and evaluate the result.
The fact that it is done by code helps test a big number of cases and vary the inputs accordingly.
Typical Unit Test Structure
Code to be tested.
Evaluation of results.
In the ‘Given’ section the programmer declares the inputs that will be passed to the feature tested. This can be a single number (like the calculator) or a different input, like a database object.
In the ‘It’ section, the programmer details the function or code that will be run and tested.
In the ‘Should’ section the results are evaluated and the Unit Test passes or fails.
Unit Tests include objects called ‘Mocks’ which resemble a database record. The programmer hardcodes the Mock’s attributes values, but it is important to note that the attributes are the same as a database record attributes, making it able to be tested.
Unit Tests are not fancy, unnecessary code
Unit Tests run quickly while verifying outputs correctly.
They are scalable and fit for applications with multiple requirements.
When a new variable is added, tests that verified the old cases can be reused.
Unit Tests are not a luxury, but an advanced way of doing QA by code that is needed when the software that wants to be tested has too many cases for a human to consider.
Plus, they are free from a human error, like passing a wrong input or interpreting the result incorrectly.
Unit Tests make QA more efficient while making it harder for its members to enter, as they will require a programming background.
At Number8 our programmers implement necessary code to ensure your software products can handle all functions and develop as needed. If you are interested in learning more about our development process or if you think you are qualified to join our team, then give us a call at (502) 890-7665 today!
GET STARTED TODAY
We’d Love To Schedule A Time To Talk.
Provide your information to talk with a number8 Relationship Manager about your development needs today and feel what it’s like to be listened to before being sold a solution.
number8’s onshore office is located in Louisville, Kentucky where our Account and Relationship Managers work hard to provide all of our clients with exceptional customer service. We also have consultant offices located in Escazú, Costa Rica and San Pedro Sula, Honduras that give us a strong local presence allowing for top-level recruitment, technical training and low employee turnover.