Mongo::Error::OperationFailure: Cursor not found

Lately, I’ve been running into this error while running my nightly automation scripts. From my experience in resolving nagging errors, this one too was another of those annoying/inconsistent errors which did not have any concrete solutions on the internet.  This post is for the benefit of those fortunate people(unlike me) who will encounter this error in the future.

Small Background on the task:I had to query all data which was in my MongoDB server one-by-one and compare it on real-time with my api responses. I am using the ‘mongo’ ruby driver gem to interact with the db.The total data in the db was ~3.5 lac records but while running the script – at around the ~350 iteration mark I was getting this error :-

  Cursor not found, cursor id: 79727049273 (43)
/home/qaserver/.rvm/gems/ruby-2.3.0/gems/mongo-2.4.0/lib/mongo/operation/result.rb:256:in `validate!'
/home/qaserver/.rvm/gems/ruby-2.3.0/gems/mongo-2.4.0/lib/mongo/operation/executable.rb:37:in `block in execute'
/home/qaserver/.rvm/gems/ruby-2.3.0/gems/mongo-2.4.0/lib/mongo/server/connection_pool.rb:107:in `with_connection'
/home/qaserver/.rvm/gems/ruby-2.3.0/gems/mongo-2.4.0/lib/mongo/server.rb:242:in `with_connection'
/home/qaserver/.rvm/gems/ruby-2.3.0/gems/mongo-2.4.0/lib/mongo/operation/executable.rb:35:in `execute'
/home/qaserver/.rvm/gems/ruby-2.3.0/gems/mongo-2.4.0/lib/mongo/cursor.rb:188:in `block in get_more'
/home/qaserver/.rvm/gems/ruby-2.3.0/gems/mongo-2.4.0/lib/mongo/retryable.rb:51:in `read_with_retry'
/home/qaserver/.rvm/gems/ruby-2.3.0/gems/mongo-2.4.0/lib/mongo/cursor.rb:187:in `get_more'
/home/qaserver/.rvm/gems/ruby-2.3.0/gems/mongo-2.4.0/lib/mongo/cursor.rb:113:in `each'
/home/qaserver/.rvm/gems/ruby-2.3.0/gems/mongo-2.4.0/lib/mongo/collection/view/iterable.rb:44:in `each'
./spec/all_usecases_spec/rovi_ott_validation_spec/rovi_ott_links_validation_for_all_programs_spec.rb:66:in `block (2 levels) in '


254      # @since 2.0.0
255      def validate!
256        !successful? ? raise( : self
257      end
259# Install the coderay gem to get syntax highlightingpre>

The crazy part was this error was not at all consistent but would happen at times. I would overlook this by re-running  my scripts.One day suddenly out of nowhere this error became almost 100% consistent! On priority, I had to find a solution for it.

After doing some amount of reading, I realised that this error is to do with the cursor which gets created while querying the db. So what happens is MongoDB returns a cursor when the query happens. In my case as my query is one which ‘finds all’ I do not fully know if multiple cursors are returned for each sub-query or a single cursor is returned which loops through the whole db. I need some more clarification on that.

But what I understand is that MongoDB closes all cursors that have been inactive for 10 minutes.It has something called a cursor timeout to do the same. So maybe one such cursor created was getting inactive after a particular time.

On more exploring I understood that there is a way to disable this cursor timeout. The hard part was to find the key word for this cursor timeout for the ruby driver which I was using, in my case the ruby driver ‘mongo’. Going through multiple stackoverflows which gave some incorrect solutions like use ‘:timeout => false’ I had to struggle my way to find this answer.

After going through the Mongo Ruby Driver documentation(which has a very confusing sequence) thouroghly, I found my answer!

There is an option while querying called ‘no_cursor_timeout’ which must be used to disable this cursor timeout. Here’s how you implement it :-

coll.find({:date => { ‘$eq’ => }}).no_cursor_timeout.each do |doc|

          ########## Code goes in here ###########


Giving a timeout in ruby


The ‘num_secs’ value can be an integer or float. Also, if you’re writing this within a Rails app, or are using ActiveSupport library elsewhere in your project, you can construct longer intervals using the following convenience syntax:

# or, even longer...
sleep(2.hours); sleep(3.days) # etc., etc.
#Or shorter
sleep(0.5) #Half a second

Key Parameters while choosing an Automation Testing Tool

Hey all,

Hi Techies! How are you doing? Everything alright? How is the software industry treating you?

I hope it is keeping you all at the tip of your toes, as always. At least here in India it is! The industry is evolving at a blazing pace. There are start-ups propping up in every nook and corner. There are huge rounds of funding for those which show promise & all my buddies working in such start-ups are earning big bucks. Older more established companies are either withering away or are reinventing themselves to stay relevant & competitive.

Software Development  has moved on from the ‘Steam Engine phase’ to the ‘Bullet Train phase’. Cloud Technologies like AWS, Azure are enabling companies to set shop quicker,cheaper,lighter & to scale their systems more easily. Release times are getting shorter and shorter.To aid these faster release cycles there is a new set of Software Ninjas called Devops Engineers who are bringing a paradigm shift to the way the industry was working uptil now. There is a cultural and ideological change happening and conventional boundaries of Dev, QA and Support are slowing fading away for the better.

Coming straight to the subject of this post…

There is a huge necessity of software automation for various tasks & processes in today’s industry.Each company needs to have a robust automation framework in place. This is to match up to the speed of software development and test out the iterative builds. A quick reliable feedback loop on the code quality thus ensures moving to a ‘Continuous Delivery’ model where builds are deployment ready. It is close to impossible to test the quality of every single release with manual testing alone.I’m sure you’ll agree with me on this. Hence automation is the pressing need of the hour.

Automation requirements are massive in the industry – from UI automation for Desktop Applications,Browsers and Mobiles, to API level automation for backend architecture, to machine level automation for various tasks. There are a vast many automation tools out there in the market which can be used for different automation requirements. In my 5 years of experience in the Software Industry, I’ve come across many instances wherein I’ve had to select a tool for a type of automation & I’ve always been spoilt for choices. I had very little time to decide on the tool & design my automation framework. To add to this, an engineer is always expected to deliver fast tangible results. Simply put, you have the opportunity to make it or break it.

It becomes very important that you make a quick but well balanced decision while selecting your tool. Else sooner or later you will be in a situation that you have to scrap the tool you selected for more reasons than one. The tools all look similar in the beginning, but on careful reading and research, you will be able to identify the variations in each tool & the limitations of each one.

In this article I would like to share few key parameters to keep in mind while selecting an Automation Tool for your software quality assurance needs :-

1.Ease of setup- setup must be pretty straightforward and all dependencies must be handled internally during installation of the tool.

2.Ease of implementation-the APIs provided by the tool must be simple to understand. There must be good documentation for beginners.

3.Execution time of the scripts- each command in the script must be executed fast and overall time needed to execute a test-suite must be in acceptable limits.

4.Reliability- the tool must be reliable and must not give different results for the same test. Execution times & results must be consistent when run on a day to day basis. The tool must also work as per the documentation. Any deviation from that is a sign of unreliability.

5.Big developer/user community-Very important parameter. The bigger the community of users, the faster you will be able to resolve any roadblocks.

6.Support for issues/upgrades-There must be frequent updates to the tool with bug fixes. This shows that there is an active development team working to make the tool more and more robust. See the release notes too if possible and get an idea of the issues that have been fixed and how quickly they were fixed.

7.Integration with Continuous Integration- The tool must have hooks to be integrated with CI tools like Jenkins,Bamboo,Travis etc. Without that a user must then create his own hooks to plug the automation scripts with these CI tools which again requires time and effort.

8.Ease of maintenance-The tool must have a good overall framework which can handle maintenance related work. Eg: An update version of the tool must not break existing workflows. Google for such issues and if the occurrences of such issues are frequent, then that is a warning signal.

9.Open Source- I would prefer to select a tool that is open-source. Period.

10.Choice of Language- Lastly, select a tool which supports a programming language you are familiar with so that script development can be faster for you.

So there it is! These are the key parameters which came to my mind while selecting automation tools for my workflows. Hope it helps!

As you venture out to select your automation tool, it is best to create a table with all these parameters and evaluate all of your prospective tools against these parameters carefully. Believe me this definitely helps your decision making process and you will come out with a well balanced, level headed decision.

Until next time… From the Silicon Valley of India… Love to all 🙂




NameError: undefined local variable or method `null’

I bumped into this error while trying to implement API validation tastcases using Airborne tool :-

undefined local variable or method `null’ for #<RSpec::ExampleGroups::ApiProgramProgramid:0x000000030d2f20>
# ./spec/my_test_name.rb:9:in `block (2 levels) in <top (required)>’

Background of the issue:-

In the ‘expect_json’ part I had given the exact response of my API request as test data for future executions.

So for eg: if this was part of my API response:-


I had given this as part of my Airborne validation script :-


While trying to execute this script, I was continuously encountering this error saying “NameError: undefined local variable or method `null'”. It sure was getting on my nerves as I was’nt able to proceed with my implementation. And we all know how deadlines work! hehe… Anyways…

After a fair bit of trials & failures I found out the issue :-

Ruby as a language stores null values as nil. I was unaware of this as this is the first time I’m working with Ruby & had already started my implementation of Airborne Tool(ruby based), without getting sufficient time to ramp up on the language. We techies are required to deliver fast results you see.. hehe..

So finally, I gave this as my expected json value :-


And voila! The script worked!! 🙂

Hope this helps someone to resolve this specific issue.







Steps to get Safari Webdriver running on Mac OSX

Since this topic has not been well documented on the net and I struggled myself to get Selenium tests running on Safari browser, here are the complete set of steps to get Selenium tests up and running on Safari browsers. :-

Creating “Safari Extension” Developer Certificate

  1. Create an Apple developer account.
  • Go to
  • Click on “Member Center” on top panel.
  • Select “Create Apple ID”.
  • Go through the sign up forms and provide valid fields for a succesful sign up

2.  Login to created Apple account.

3.  Sign up for “Safari Extensions” developer

  • Click on “Certificates, Identifiers & Profiles”
  • In the “Safari Extensions’ section, click on “Join Now”
  • Go through the following steps and provide valid fields to successfully sign up for the “Safari Extensions” program

4.  Create “Developer Certificate”

  • Now inside “Certificates, Identifiers & Profiles” > “Click on Create/Add Safari Certificate”
  • You will see the following page – “About Creating a Certificate Signing Request (CSR)” Screen Shot 2015-04-15 at 1.40.24 pm
  • Click on “Continue”

You will see the following page :-Screen Shot 2015-04-15 at 1.40.42 pm

  • Upload the CSR file and Click on ‘Generate’ to generate the certificate
  • Now download the certificate once it is generated.

5. Download the certificate and install in the machine

  • Download the certificate in the download tab.
  • The certificate is downloaded as “safari_extension.cer”.
  • Double-click on the file to install the certificate in the Mac client/OSX.

6.  We have installed the safari extensions certificate for developers. Now we need to install the Safari Webdriver extension for the Safari Browser.

 Installing the Safari Webdriver extension in the Safari Browser

  1. Download latest Selenium Safari extension.

2.  Install the Safari Extension

  • Double-click on the “SafariDriver.safariextz” file.
  • You will get a prompt asking “Are you sure you want to install the extension “WebDriver”?“.
  • Click on “Install”

3.  Provide the default setting for the Selenium Webdriver Extension.

  • Click on “Safari” > “Preferences” > “Extensions” > You will find Selenium extension
  • Select “Enable Webdriver”

Now all the settings are done and now we should be able to launch our Selenium scripts using Safari Webdriver.

Launching Safari Webdriver

Webdriver driver = new SafariDriver();                

driver.get(” );

builder = new Actions(driver);

This should launch your safari browser with the Safari Webdriver Extension 🙂

Hope this article comes of use to you all.

UPDATE (18th June,2015): With the latest update of Yosemite 10.10.3 & Safari 8.0.6, the execution on Safari Browsers has become unstable & unreliable.

Selenium Scripts work best on 10.10.2 , Safari 8.0.3 & Selenium 2.45.0 combination.

So if OSX prompts you for updates, please DO NOT install them if you want to run automation on Safari Browser



Decreasing False Positives in Automated Testing

Hey all,

I attended a webinar last night on “Decreasing False Positives in Automated Testing”. This event was conducted by Sauce Labs and webinar presented by Anand Ramakrishnan, QA Director, QASource

There was very good learning in it and I would like to share in brief various things which were discussed.

All attendees of the meeting were initially asked to fill a small survey question…

Q. In your organization, what is the primary objective of using automation?

Options: A. Save money

                B. Save time/ release faster –>This option got the maximum no. of votes 

                C.More QA coverage

My vote too was for the same option. Looks like the industry on the whole is facing a similar challenge of meeting faster release times.

Moving on to the topic…

 Q.What are False Positives?

Ans. Tests that are marked as failure, when in reality they should have passed. In other words, they are false alarms.

 We had another survey question just then :-

  1. What is the percentage of false positives within your respective automation tests?

Options: A. <5%

                B. 5-15

                C.15-25%        –> This option got the maximum no. of vote

                D. >25%

My vote was for option B. Though we are on the better side of things, we still need to further reduce these false positives.

Reasons why tests encounter false positives : –

  1. Flawed automation approach
  2. Choosing the wrong framework
  3. Inadequate time to accommodate a test plan/design.
  4. Hard-coded waits/delays
  5. Less modularity of code
  6. Relying on co-ordinates & xpath of objects
  7. Change in UI element id, classname etc
  8. Shared environment for QA as well as automation.
  9. Slow performance of application, or particular environment
  10. Manual intervention prior to execution of automation scripts
  11. Browser incompatibilities.

Impact of False Positives :-

  • Frustration within engineering team
  • Sooner or later, test failures are ignored by stakeholders
  • Risk of overlooking potential bug
  • Babysitting of automation tests
  • Maintenance cost of automation increases

Now the most important part of the discussion.

Ways to Reduce False Positives :-

  • Deploy application on optimal configurations, for automation
  • Keep tests short and simple. Avoid trying to do too many things in a single test case.
  • Keep tests independent. No sequencing of tests
  • Provide unique identifiers while developing application itself.
  • Using right locators i.e in decreasing priority of id>classname>css locator
  • Tear-down approach. Bringing test machine to base state before/after every testcase
  • Dynamic object synchronisations. No hard-coded waits
  • Re-execution capability of test framework. In case test fails, re-execute test and if it passes to ignore the previous failure.


Benefits of Eliminating False Positives:-

  • Will not miss potential bugs
  • Certainty of application health
  • Increase in productivity
  • Save time not babysitting
  • Decrease cost of automation

Summary: It was an awesome webinar and also brings perspective on how critical automation is to meet current day SDLC challenges and how to make it more effective.

Your feedback both good & bad are always welcome.



Jenkins + Selenium Error: org.openqa.selenium.firefox.NotConnectedException

Hi all,

A small background : I run my automation suite using Jenkins on a nightly basis. The suite is maintained as a Maven Project. I run ‘mvn site’ to execute the test suite.

I encountered the following error when Latest Firefox version 36 was released and I had to upgrade my selenium jars to the latest version i.e from 2.44.0 to 2.45.0. :-


The error seen is

org.openqa.selenium.firefox.NotConnectedException: Unable to connect to host

I had promptly downloaded the latest selenium standalone jar 2.45.0 and configured the build path with the latest jar. The scripts were executing successfully while being run individually but while running as a test suite using the ‘mvn site’ command, my execution was failing.

 Solution: Initially I thought that the execution was failing due to some configuration on Jenkins. But later after some debugging I realised that I had not updated pom.xml with the latest selenium version.






Next time Selenium releases a new version, I know what to do now! 😀



Selenium Error: StaleElementReferenceException

Most automation tools depend on the concept of the page has finished loading. With AJAX and Web 2.0 this has become a grey area. META tags can refresh the page and Javascript can update the DOM at regular intervals.

For Selenium this means that StaleElementException can occur. StaleElementException occurs if I find an element, the DOM gets updated then I try to interact with the element.

Actions like:


are not atomic. Just because it was all entered on one line, the code generated is no different than:

By fooID ="foo");
WebElement foo = driver.findElement(fooID);;

If Javascript updates the page between the findElement call and the click call then I’ll get a StaleElementException. It is not uncommon for this to occur on modern web pages. It will not happen consistently however. The timing has to be just right for this bug to occur.

Generally speaking, if you know the page has Javascript which automatically updates the DOM, you should assume a StaleElementException will occur. It might not occur when you are writing the test or running it on your local machine but it will happen. Often it will happen after you have 5000 test cases and haven’t touched this code for over a year. Like most developers, if it worked yesterday and stopped working today you’ll look at what you changed recently and never find this bug.

So how do I handle it? I use the following click method:

public boolean retryingFindClick(By by) {
        boolean result = false;
        int attempts = 0;
        while(attempts < 2) {
            try {
                result = true;
            } catch(StaleElementReferenceException e) {
        return result;

This will attempt to find and click the element. If the DOM changes between the find and click, it will try again. The idea is that if it failed and I try again immediately the second attempt will succeed. If the DOM changes are very rapid then this will not work. At that point you need to get development to slow down the DOM change so this works or you need to make a custom solution for that particular project.

The method takes as input a locator for the element you want to click. If it is successful it will return true. Otherwise it returns false. If it makes it past theclick call, it will return true. All other failures will return false.

Personally, I would argue this should always work. If the developers are refreshing the page too quickly then it will be overloading the browser on the client machine.


Migration from Selenium RC to Webdriver – Executing Javascript APIs

Executing Javascript Doesn’t Return Anything

WebDriver’s JavascriptExecutor will wrap all JS and evaluate it as an anonymous expression. This means that you need to use the “return” keyword:

String title = selenium.getEval("browserbot.getCurrentWindow().document.title");


((JavascriptExecutor) driver).executeScript("return document.title;");

7 Best Practices for Agile Test Driven Development

Test Driven Development (TDD) is a minimalistic software development process that is driven by an automated test case which defines the desired enhancement to the system. The test is first executed to fail. The developer then comes up with a minimal code that will pass the test case. Once the new code is tested, it is refactored to adapt to standards and retested. The cycle is then repeated to add further enhancements.

Designed as an offshoot of extreme programming, TDD follows the agile method of building software in iterations and involves clean, simple designs and code.

We present some of the best practices to be followed in TDD projects:

1.    Avoid functional complexity

Keep functionality to be achieved simple. Deliberate on it with the whole team to ensure the test case covers the desired functionality in every way possible. As the test case is the driver here, it should be reviewed for correctness and completeness.

2.    Focus on what you need to achieve

Be sure you understand where the code needs to be called and frame the test suite accordingly.  Ensure test cases follow standard naming conventions and clearly depict what needs to be achieved by the end of development process. This is crucial as functionality keeps getting added with iterations. Future developers should be able to look at the test and easily deduce the intended functionality.

3.    Maintain code austerity

Ensure your code has just enough meat to satisfy your test case. This is a basic tenet of TDD. This minimizes the chances of defects and also simplifies review and testing processes. However, do ensure the code is understandable and allows future enhancements.

4.    Test repeatedly

Test before coding and after coding. Then test once again after code refactoring. This is to reinforce that no code is broken in any of the steps. During refactoring, ensure the new code is maintainable and adheres to standards. The rule of thumb here is repeat testing whenever there is a code change or code move or code merger.

5.    Maintain code sanctity

Use version control tools to check out and check in code. This is important, specifically when more than one developer is working on the code. Using continuous integration tools like Jenkins can avoid code merger issues.

6.    Application knowledge

In TDD, coding needs to be limited but effective in that it achieves its purpose without breaking anything else. Also, the new code should ideally pass the test case in the very first run. Maintaining adequate system documentation, including a repository of test cases, and engaging team members with good application knowledge can ensure a smooth and successful project execution.

7.    Know when to use TDD

Last but not the least, TDD, like any other development concept, works best in certain scenarios. Use TDD for developments that can be quickly tested. Any testing that is prolonged or complex defeats the purpose of TDD.

With TDD, development is more controlled and, as a result, defects are considerably reduced. Repetitive testing ensures each component in the system is working correctly at every step.

Gallop is a front runner in providing agile testing services. Our expertise in various agile methodologies like Test Driven Development (TDD) and Behavior Driven Development (BDD) combined with the benefit of co-located test services can help you get the maximum benefit out of your agile projects. Contact us today to see how we can help you.