Please wait while we process your request.
Please wait while we process your request
Please wait while we retrieve the user's information
Your bio is currently empty. Now is a great time to fill in your profile.
This profile is private.
This profile is only shared with friends.
This profile is under review.
We were unable to request friendship with this user.
We were unable to request friendship with this user. Are you logged in?
Your friendship request has been sent to this user.
We were unable to terminate friendship with this user.
We were unable to terminate friendship with this user. Are you logged in?
You are no longer friends with this user.
We were unable to ignore this user.
We were unable to ignore this user. Are you logged in?
This user is now ignored.
We were unable to stop ignoring this user.
We were unable to stop ignoring this user. Are you logged in?
This user is no longer ignored.
We encountered a problem recommending this user.
You have recommended this user.
This blog post is hidden because you have chosen to ignore Marni Tolle. Show Details
This blog post is hidden because you have submitted an abuse report against it. Show Details
For many it’s a no brainer to bring automation into the testing process but something that can ruin your approach is not building maintainability into your scripts. I started working in QA automation 7 years ago using the Selenium IDE, which is a record and playback tool, and it was groundbreaking at the time. All of a sudden a job that was done mostly in the manual fashion could be automated easily? But soon the community began to learn the caveats of this approach. Its been awesome to evolve with the automation movement and see how we have shared our experiences regarding pitfalls to avoid. Every day I think about how we can improve our automation test framework and my team's absolute nemesis is brittle scripts.
A brittle test can just be a test that fails intermittently and it’s unclear why. It could be a test that is difficult to update, or due to a page that is commonly updated so suddenly the path to an element changes. If you haven’t thought through these kind of scenarios when approaching your automation project, you will end up wasting much of your time managing out these problem scripts instead of concentrating on growth.
One basic problem that can be avoided is thinking of locators in your scripts as variables. Let's say you have a button on a page that you utilize across multiple scripts. If the locator for that button changes, suddenly all of those tests fail and you must update it in every test script. There are two things to be aware of to avoid this problem: brittle locators and duplication in scripts.
For brittle locators the first piece of advice I have is to avoid absolute paths. If you utilized the Selenium IDE that is what you would get. Instead start with the element ID and work backwards. It is easy to find suggestions on how to approach locating elements in the UI so I won't rewrite a full rant on the best methodology here but do your research and get your team on board.
You can be smart about your locators and still run into problems with brittleness due to duplication. Say you have 10 different tests that reference the same object on a page (create new field button for instance) and you have been smart about the locator utilized. Still the locator changes and suddenly we are updating 10 different tests. This maintenance headache is a waste of time that can be avoided by modularization. We utilize the 'Page Object' pattern to avoid this problem, so when clicking on that ‘save’ button on the page used in multiple test scripts, we reference that action once. Again I won't go into specifics on the page object pattern for QA automation since there is plenty of documentation out there already. I highly recommend evaluating this approach for your own automation projects.
Duplication is not limited to locators, it also can be the workflow for an action that is common in tests. This is where the Page Object pattern helps us to follow the ‘DRY’ (Don’t Repeat Yourself) Principle. With the Page Object approach, we consolidate the code interacting with a UI element. Instead you now have methods for what a user can do with exposed elements on a page. Now N test scripts can call a method to access the edit settings page for a user. This leads to less duplication as well as more readable test scripts as the details of how we access this page are executed via a method the script calls.
Automation can make a world of difference in the ability to verify the quality of your product but it can also be a huge pain if you don’t think of the long term approach and effect of taking short cuts. Not everything should be automated. Take a step back and look at your framework. Are you encouraging your team to just pump out tests to show a boost in your automation or create a highly efficient and low maintenance approach that your organization can use long term for stability in your product? We all want things done as quickly as possible but it will cost more in the long run if reducing brittleness is not something your QA team takes into account.
We're sorry, we were unable to record your recommendation at this time.
We're sorry. We are unable to delete this blog post at this time.
We're sorry. We are unable to block this blog post at this time.
We're sorry. We are unable to unblock this blog post at this time.
Please wait while we file your abuse report.
We're sorry. We were unable to report abuse at this time.
We limit the number of reactions an individual user can submit over a given period for quality reasons. You have currently reached that limit. Please try resubmitting your abuse report again later.
Comment is too long. Enter 500 characters or less.Send Cancel
Please wait while we send the email.
You may send this to 5 e-mail addresses. Please separate each address with a space.
vote upvotes up
vote downvotes down