September 22nd, 2016 by Chris Riley
Ashley Hunsberger, Greg Sypolt and Chris Riley contributed to this post.
How do you build an effective team of quality assurance (QA) engineers? Where do you look to recruit the best QA professionals? How should you integrate your QA team within the rest of your organization? These and other questions related to the topic of team building came up during a recent webinar hosted by Chris Riley, Ashley Hunsberger, and Greg Sypolt. Here are links to the first and second post in this series.
Team building is an essential part of an effective QA operation, of course. Your testing strategy and execution are only as strong as the people who design and conduct them. And in today’s IT world, where DevOps is changing the way different types of engineers interact, and the supply of good QA professionals outstrips demand, having a well-planned and executed approach to team building is crucial.
Below are some of the most important team-building questions that came up during the webinar, along with answers from participants.
One thing I have noticed lately is that QA engineers are getting more respect. With automation, their skillset looks more like those of a developer. Do you agree? Read the rest of this entry »
September 20th, 2016 by Greg Sypolt
Are you experiencing slower execution times while running Selenium scripts in the Selenium cloud network? Too many network hops will add latency and slow down your test execution. Plus, every additional network hop adds cost to your execution. One way to optimize Selenium execution performance is to eliminate as many network hops as possible.
“A hop is one portion of the path between source and destination. Data packets pass through bridges, routers and gateways on the way. Each time packets are passed to the next device, a hop occurs.”
The Sauce Labs team is working on a new tool that may be interesting to you. The solution will eliminate a network hop, making running tests in parallel on multiple browsers automatic and simple.
Why Hops Matter
In my first time using a cloud-based solution for Selenium, I was both thrilled and impressed by the possibilities. A cloud-based provider such as Sauce Labs maintains and uses configuration management tools to spin up and tear down virtual machines with various OS platforms and browsers. I understand the value in this type of service. The amount of time and resources needed to build and maintain infrastructure is expensive. Been there, done that! Read the rest of this entry »
September 16th, 2016 by Dan Cuellar
When writing test automation, one of the most important factors for determining the amount of time and resources you will consume (and ultimately the success or failure of the endeavor) is the testability of your application. By testability, I’m referring to how the app interacts with UI (and other) automation frameworks, the ease by which a test script can setup the scenarios you wish to test, and how you make your tests safe for concurrency.
Making Elements Accessible
Let’s address the matter of controlling your application with automation frameworks first. Given that you are reading this blog, it is likely you are using either Selenium or Appium as your automation framework, so this blog post will only address these frameworks.
Web Content (Selenium)
Let’s start with Selenium. In order for your web app to be easily controlled by Selenium, you need to think ahead as to how you will identify important pieces of the DOM when constructing tests. Selenium provides many means by which you can do this, called “Locator Strategies”. Some are better than others. You should consider which of these you will be using in your tests as you develop the user interface. Ideally, each element would have an ID attribute applied directly to the tag for any element that the test will exercise.
Sometimes, for one reason or another, you may not be able to use an ID. If this is the case, the next recommended technique is to use a CSS selector. If your web app is developed with good principles, such as BEM (Block Element Modifier), it is likely easier to automate as it should have a relatively short globally unique CSS selector. If it does not, I would not recommend adding a CSS class just for automation, as it isn’t the purpose of the styling language to do automation. Rather, I would suggest that you use an HTML
data-* attribute. You can use the CSS selector locator to grab an element by one of these attributes, but the good news is you aren’t adding unnecessary classes to your CSS, and the purpose of the HTML attribute will be much clearer. Read the rest of this entry »
September 12th, 2016 by Simon Stewart
Selenium 3 is coming! I’m here to tell you about what’s changed, and what impact this will have on your testing.
- WebDriver users will just find bug fixes and a drop-in replacement for 2.x.
- Selenium Grid users will also find bug fixes and a simple update.
- The WebDriver APIs are now the only APIs actively supported by the Selenium project.
- The Selenium RC APIs have been moved to a “legacy” package.
- The original code powering Selenium RC has been replaced with something backed by WebDriver, which is also contained in the “legacy” package.
- By a quirk of timing, Mozilla have made changes to Firefox that mean that from Firefox 48 you must use their geckodriver to use that browser, regardless of whether you’re using Selenium 2 or 3.
In more depth:
When we released Selenium 2.0 in 2011, we introduced the new WebDriver APIs, and encouraged everyone to start moving to them. If you’re using the WebDriver APIs, then Selenium 3.0 is a simple drop-in upgrade. We’ve not changed any of the WebDriver APIs, and the code is essentially the same as the last 2.x release. If you’re using Selenium Grid, the same applies: in most cases, you can just drop in the new JAR (or update your maven dependency to 3.0.0), and you’re done.
At the same time as the Selenium project is shipping Selenium 3.0, Mozilla is changing the internals of Firefox in a way that makes it more stable and secure, but which also makes the community-provided Firefox Driver no longer work. As such, if you use Firefox for your testing, you’ll need to use the geckodriver, which is an executable similar to the chromedriver and MS’s edgedriver. You’ll need to start using geckodriver even if you’re using Selenium 2 — the change is in the browser, not Selenium. Read the rest of this entry »
September 9th, 2016 by Michael Churchman
How often should you parallel test? If that sounds like a trick question, maybe it is. In this post, we’ll let you in on the “trick” part of the question, and then we’ll talk about what really matters when it comes to when and how often you should parallel test.
Parallel Testing – What is it?
First, the trick. It lies in what parallel testing is, and more to the point, what it isn’t.
What is parallel testing? The term “parallel testing” is generic and rather broad, but it typically refers to automated systems for simultaneously testing multiple applications or components, with each application or subcomponent being tested on a different computer. It is sometimes also used to describe automated testing of a single application or component on multiple platforms. The test computers can be individual hardware units, or more typically, separate virtual machines. In all cases, however, the combination of automation and multiple test systems makes it possible to run many more tests than would be practical with serial testing, and it reduces the time required for testing to a fraction of that required for the equivalent serial tests. The key points to keep in mind about parallel testing are that: Read the rest of this entry »
September 7th, 2016 by Greg Sypolt
The goal of this getting started guide is to help teams get Jenkins continuous integration (CI) servers configured, and discover how to make a newly deployed CI infrastructure fully operational. Jenkins is a leading open source CI server. It is flexible, providing hundreds of plugins to support building, testing, and deployment, and is capable of automating any project. Jenkins CI infrastructure can be deployed to on-prem, in the cloud using configuration management tools, and third-party vendor. For the purpose of this article, let’s assume that our Jenkins CI servers are deployed in the cloud and focus on configuration of Jenkins’ web interface. I will walk through various processes and steps to set up a new Jenkins CI server for production.
Recommended best practices for CI architecture
Don’t jump head first into configuration and creating a pipeline without planning, designing and establishing standards for your CI architecture. Taking the time to think about infrastructure first will enable a stable and restorable infrastructure. Let’s review a few recommended best practices to consider in your future CI pipeline.
Backup CI Server (Fail Safe)
It may seem obvious. Recommend setting up a backup process for Jenkins configuration. Script a Jenkins job to use the thinBackup plugin or S3 plugin to send the Jenkins configuration to an Amazon S3 (cloud storage).
Here are recommendations to consider: set environment variables (i.e., hidden passwords, SSH keys, API keys, etc.); security—create generic reusable jobs, naming conventions (i.e., jobs and environment variables); keep jobs small—modulization, scalable infrastructure that allows for auto-scaling of Slave nodes. Read the rest of this entry »
September 1st, 2016 by Joe Nolan
You’ve heard about the cost of a bug—The longer it takes for a bug to be discovered, the more expensive it is to fix. But have you ever considered the cost of a reject? Do you have visibility into how much rejected stories and bugs are affecting your Scrum team’s capacity in terms of time?
Let’s take a look at just how impactful rejects can be, and how to mitigate them when they occur.
Start with an average story or bug ticket in a hypothetical Scrum team:
- A story or bug ticket is created and assigned to the sprint.
- The bug has steps to reproduce—if the writer was efficient.
- For the story, QA and the Scrum team determine the test strategy.
- The developer works on the ticket and pushes it to QA.
- QA verifies or rejects the ticket.
Different tickets take different levels of effort. For the sake of this article, let’s assume it takes an average of 30 mins for QA to verify the ticket.
At least, that’s what happens when all goes well. Read the rest of this entry »
August 30th, 2016 by Sahas Subramanian
Several years back, I wanted to understand if it’s really necessary to use thread.sleep in test automation code. Here is what stuck in my mind: Thread.Sleep(n) means blocking the current thread for the number of time slices that occur within “n” milliseconds.
There are a few things to consider before using thread.sleep in your test automation code. They include:
- The thread time slice varies from OS to OS and processor to processor. This means that once your thread goes to sleep, it’s going to wait for its turn to come back into the scheduler. So it’s highly likely that the thread.sleep time means more than what you really intended. For example, with thread.sleep(1000), you intended 1,000 milliseconds, but it could potentially sleep for more than 1,000 milliseconds too as it waits for its turn in the scheduler.
- Each thread has its own use of CPU and virtual memory. That means our thread acquired its resources (say 1MB virtual memory, some CPU cycles and some context switching cycles), and is simply not using them.
- If it’s a foreground thread, it’s preventing the application from exiting as well.
- What about Thread.Sleep(0)? This tells the processor that I’m ready to lose the remainder of my time slice, and you may pick up the next thread from the queue. On one hand, it feels good and efficient. But on the other hand, you are also telling the processor that you are better at scheduling than the processor. (I don’t know the side effects this can cause, but I’m not smarter than the processor.)
We are talking about milliseconds when dealing with thread.sleep, but it’s important to understand that the more we use thread.sleep, the more we defer solving the real problem, which is how to handle async in modern web apps. Read the rest of this entry »
August 25th, 2016 by Joe Alfaro
If you’re attempting to implement an Agile/Scrum development process where none has existed before, you will surely an encounter a moment of frustration on the part of your developers. “Why do we have to do these standups?” “I don’t understand why we need to assign story points, can’t we just get to the projects?” “Where is my technical specification?” Like Ralph Macchio in The Karate Kid, your developers may wonder why you have them doing the engineering equivalent of “wax on, wax off,” when what they really want to do is get into the fight. What Ralph Macchio eventually understands is that the performance of rote, rigid external exercises is a first step on the road to internal mastery, a process well known in the world of martial arts as Shu Ha Ri.
In its broader definitions, Shu Ha Ri describes a process of learning: in the Shu stage, the learner follows directions literally and adheres rigidly to whatever rules the teacher has set. In the Ha stage, the learner begins to see how the rules and directions can be adapted for specific situations, and exercises some judgement in how they should be applied. In the Ri stage, the learner has developed her own techniques, and now innovates freely as the situation demands. Read the rest of this entry »
August 23rd, 2016 by Chris Riley
Ashley Hunsberger, Greg Sypolt and Chris Riley contributed to this post.
Bringing test automation into your organization is not as easy as writing and running a Selenium script. It involves first getting buy-in, building a team, establishing a strategy, and picking the right tools. During the Q&A portion of a recent webinar hosted by Chris Riley, Ashley Hunsberger, and Greg Sypolt, the presenters realized that these aspects of introducing test automation are well known, but not well understood. In our first post of the series we discussed getting buy-in. Below, in the second post, we discuss how to build a test automation strategy.
Getting started with test automation is easy. If you have a technically minded QA team, you can usually create your test script, sign up for a test cloud, and run the script in just a few hours. But keeping a test automation environment going for the long term is not as easy as any of us would like to believe. QA teams are generally better at building strategy than any other. And when it comes time to build a test automation environment, strategy is a key first element to both getting started and keeping it going. Read the rest of this entry »