Go gaga over Machine Learning

Here are some interesting browser extensions/add-ons that might be helpful: Test IE -  Test websites in real Internet Explorer (IE6, IE7, IE8, IE9, IE10 and IE11) straight from Chrome browser, through BrowserStack. Browserling - Cross-browser testing  - Browserling is a live interactive cross-browser testing service that provides effortless cross-browser testing for web developers and web designers. aXe  - Accessibility testing in Chrome Developer ToolsAutomated tool to find Accessibility defects on your web site by using the aXe Chrome extension. Drop the aXe on your accessibility defects! JaSON  - JSON and XML test utility.A simple, easy to use utility for testing and debugging JSON and XML web services. Send requests over HTTP or HTTPS and see formatted, syntax highlighted responses. Also supports sending of form encoded request parameters. Supports the following HTTP operations: - GET - POST - PUT - DELETE - HEAD Wizdler  - Parses the WSDL files and generates SOAP

Findings and POC for using LeanFT as part of the Contentious Integration build: LeanFT uses the UFT SDK  Allows coding your tests in C# and Java in your favorite IDE (documentation is focused around Visual Studio and Eclipse) Any add-in can be automated Standard Windows, WPF, .NET, Mobile etc.. Prerequisite: You should now see:  C:\Program Files (x86)\HP\LeanFT\bin Browser Prerequisite: In the Firefox browser menu, select Add-ons and then click Extensions. Drag the Agent.xpi file from the%LeanFT%\Installations\Firefox folder to the Firefox Extension page and click ‘Install now’. If you are testing against Chrome ensure the LeanFT plugin is enabled from Chrome Settings -> Extensions. With IE, go to Settings -> Manage Addons where HP Functional Testing Agent must be enabled. Download the sdk jars/dll: https://github.com/upgundecha/lftexamples SDK reference: http://leanft-help.saas.hp.com/en/latest/JavaSDKReference/index.html

I would not agree with all the graphs here but a good depiction of what's hot in the market: Source:  http://blog.testproject.io/2015/12/03/worlds-most-desirable-automation-skills/

Technology Stack: Serenity + Cucumber + Jnit Problem: If you have been using Serenity and have seen that your reports don't show up the capabilities/epics that have been run. If you dig further you would notice that in your logs there is a statement where the epics/capability isn't able to find its parent, cardNumber Solution:  What would not work: Updating pom file Using latest jars  What works: Path to the requirements directory like this: serenity.requirements.dir = src/test/resources/features

Here is what a good friend of mine was facing with TestNG and Maven:  Bro, For your Blog: Issue while setting up TestNG and Maven from Scratch: Eclipse TestNG Plugin Version which is higher than TestNG jar in your pom dependecy, will fail to either Start or Quit the driver. For example, I downloaded TestNG Eclipse plugin 6.9.10, but my pom.xml had a dependency on version 6.9.9. I kept getting the Unreachable Browser Exception for IE, Chrome and Mozilla. I downloaded TestNG plugin 6.9.4, which is more stable, but my pom.xml had a dependency on version 6.8. The webdriver struggled to open and reported a "java.net.SocketException: Software caused connection abort: socket write error", though my test completed successfully. I received this error again across all 3 drivers, i.e Firefox, IE and Chrome. So to fix the above issues, I kept the plugin version 6.9.4, but increased the pom dependency on Test NG jar to 6.9.9. Result was a smooth execution.

Problem:  If you are using Maven and you have the enforcer plugin , you might see the error "Failed while enforcing RequireUpperBoundDeps" Solution:  Since we almost always make changes in a backward-compatible manner, it looks like the best solution for us is to ensure that the latest versions of dependencies are used . The Maven Enforcer plugin with the "Require Upper Bound Dependencies" feature accomplishes this. From  http://maven.apache.org/enforcer/enforcer-rules/requireUpperBoundDeps.html : This rule requires that the version for each dependency resolved during a build, is equal to or higher than all transitive dependency declarations. The version of each dependency resolved during the build will normally be the version specified in the POM or the version with the least transitive steps (the "nearest" definition). For more information about Maven dependency resolution, see the Maven site.