Recap: Easy Continuous Deployment You Can Trust (Webinar)

April 14th, 2016 by Bill McGee

Thanks to everyone who joined us for our recent webinar, “Easy Continuous Deployment You Can Trust”, featuring Solano Labs Founding Engineer, Brian Kendzior, and Sauce Labs Solutions Architect, Neil Manvar.

In their presentation, Brian and Neil demonstrated a continuous deployment release process that used Solano CI, Sauce Labs, and AWS CodePipeline. The release process included smoke, unit, integration and browser tests to guarantee issue-free deployments.

Brian and Neil also demonstrated how to:

  • Build your software release pipeline by connecting different steps into an automated workflow using AWS CodePipeline
  • Run your automated web tests on any browser and operating system combination using Sauce Labs
  • Auto-parallelize your test runs with a Continuous Integration server using Solano CI

Want to learn more about automated testing and Continuous Integration? Download our free report, “How to Get the Most out of Your CI/CD Workflow Using Automated Testing”. 

Access the recording HERE and view the slides below: 

3 Simple Strategies to Get Started With Automation

March 24th, 2016 by Joe Nolan

If your test automation team’s directive is to automate X amount of tests, and you have no strategy as to which tests they should focus on, you are wasting your time. Before you begin writing your first line of automation code, make sure you have a strategy in place. Otherwise, you will have a ton of ineffective tests to maintain.

Don’t Choose a Random Goal

How many times have you been told that the goal of the team is to have X amount of test coverage? This is an arbitrary value picked out of the sky. What is it based on? If a UI automation team were to cover 80% of the stories in a sprint, they would never get done in time.

We all know how fragile UI automation is! How many times will a designer make a change that directly affects the UI and breaks the test? This is almost manageable during a sprint while you are working closely together, but how about when the product is sent to be translated to another language? The translator inevitably comes back with suggestions to allow for phrases more common and translatable. Bugs might be entered and UI changes made by a maintenance team with no heads up to the automation team, and Bam! — You have broken tests that need to be investigated. (more…)

A Two-Minute BDD Overview

March 16th, 2016 by Ashley Hunsberger

Behavior Driven Development, or BDD, can help get your teams building the RIGHT product. Although I’ve heard the term used interchangeably with Test Driven Development (TDD), I personally see it as an extension of TDD to help your team focus on the business’ goals. While TDD provides tests that drive development, those tests may or may not be helping you meet those goals.

The WHY Behind the Code: BDD vs. TDD

Behavior Driven Development
Test Driven Development
  • Start with business value, then drill down to feature sets
  • Lots of tests that may or may not meet the business value
  • Team gets feedback from the Product Owner
  • Coder gets feedback from the code

BDD is a more outside-in approach that is really focused on business drivers. It takes TDD a step further (as you still want that feedback from the code), but it now gives you feedback on the feature.


BDD Workflow

Getting Started

So what is the general process to use BDD? It aligns itself nicely in the Agile framework and is simply a WAY to implement Agile. Continue with your usual scrum activities: milestone planning, defining user stories and acceptance criteria and developing, and iteratively repeat that process until you are ready to release. (more…)

Changing Development Culture to Become Quality Focused

January 25th, 2016 by Joe Nolan

How many project teams have you worked on where the accepted culture was to rely on the QA members to bear the load for quality? As the leader of a QA meetup, I still constantly hear stories from my members about developers’ assumptions that it is QA’s responsibility to find bugs. Not only is this attitude demoralizing for QA, it is also not in the best interest of the team. How can a team change development culture to one that is quality focused for the entire team?

From the Top Down

The answer seems obvious — Management needs to declare that all team members will have a hand in quality. This truly is critical to a successful culture change! Besides empowering dev managers and Scrum Masters to direct team activities (such as enforcing unit tests), it will give QA members the confidence to push the team as well. (more…)

Planning Quality Architecture for 2020

January 11th, 2016 by Greg Sypolt

I was inspired by Denali Lumma (@denalilumma) when she delivered a glimpse of the future in her talk about 2020 testing at the Selenium 2015 conference. The session was an excellent introduction that compared many scenarios of the minority testing elite versus the more common development team. The elite companies consider infrastructure FIRST, and the majority thinks about infrastructure LAST. It got my wheels turning regarding the future of software development. I don’t have all the answers right now, but I want to be part of the movement to plan and build architecture with quality. A few words come to mind when thinking about quality architecture — automation, scalability, recoverability, and analytics.

Build a culture

When building a culture, avoid too much control. You want a culture that embraces freedom, responsibility, and accountability. Why is building a culture like this important? It allows passionate employees to innovate and find big-time solutions. You can’t plan for innovation. It naturally happens. When you give passionate employees an inch, they’ll take a mile. The future team culture needs to push the envelope and step outside their comfort zone. (more…)

Re-Energize Your QA Career With Automation and DevOps

January 7th, 2016 by Joe Nolan

It’s time for you to stop being content with the status quo and re-energize your QA career with Automation and DevOps — otherwise, you might find yourself fading away like Marty McFly! I’m talking to YOU, manual tester! And YOU, QA manager! Oh, and YOU TOO, automation engineer! Every one of you who has a vested interest in your career growth needs to familiarize yourself with automation and DevOps tools.

Of Course You Need to Understand Automation

Let’s face it: In this day and age of software development, speed is the key to survival. In order to achieve clean builds, Continuous Integration, Continuous Delivery, and Agile development, manual testing just ain’t gonna cut it.

Everyone with the QA title needs to continuously build on their skill set, just like a developer. Even if you aren’t actively writing automation code, you still need to understand the capabilities and benefits of each type of automated test, especially the ones written by your development team. The team is relying on your expertise to guide them with acceptance criteria for stories, while bringing QA concepts to the table. (more…)

Drinking from the Firehose (Priming the Scrum Pipeline)

December 21st, 2015 by Eric Jeanes

Development teams always have plenty of work to do. Requests come from every direction, with all facets of the business requesting assistance with their projects. How does a team go about parsing, filtering, distilling, and prioritizing all of those requests into something actionable?

A Scrum team typically consists of a Product owner, a Scrum Master, and anywhere from 3-9 team members. Each member of the team has a defined role to play, whether it is the Scrum Master that needs to clear roadblocks, or the Product Owner that needs to prioritize and coordinate with others outside the team. In an ideal scenario, the Product Owner will have just enough in the backlog to keep pace with the team. This is rarely the case, though, especially if the team is serving internal customers (in which case the members of the team play their different roles, but emphasis is placed on an additional facilitator).

The Analyst

One of the absolute key members of a Scrum team is a business analyst. Unless you are very lucky, your business stakeholders will rarely come to you with a list of “Ability to…” stories. The Business Analyst role is key to helping the stakeholder develop a set of requests that can be prioritized in the queue. Many times, this also requires the Analyst help the business team to understand and document their own process, as it is currently being used. This is especially true in smaller organizations. Without a defined operational process, business processes may go on a meandering path, grow stale, or exist in a single person’s head. This is an opportunity to examine what the current process is, refine it, and then make a constructive request for assistance to the Scrum team to improve it. The Analyst can be of great assistance to the next role. (more…)

Why Does (Story) Size Matter?

December 8th, 2015 by Joe Nolan

When writing a user story, you need to think more like Dr. Seuss than Stephen King. You want user stories to be easily consumable, like Green Eggs and Ham. You don’t want a user story on the level of Under the Dome. If you discover your story’s duration will span more than one sprint, your story is too big.

But I Love Long Stories!

If you are a reader like me, you love to become immersed in a novel that can take weeks to read, and when you love a story, there is nothing worse than realizing you are about to come to the final chapter.

I look at novels like Under the Dome, and I’m reminded of old school waterfall development. Lately, series writers seem to be following a more agile approach with trilogies. Think Hunger Games, not Lord of the Rings in scale.

Who else likes long stories? Developers, who like deep investigation and experimentation for a new feature. This tends to occur at the beginning of a project when the feature infrastructure is developed, but can be pervasive throughout a project.

Let’s face it — Isn’t it more fun to show a fully completed feature, with all the bells and whistles? Showing off your work at the end of a sprint can be humbling if you don’t have something visible and flashy to show for your efforts, which can happen quite often with two-week sprints.

It’s Not All About You


Developing Consistency

November 16th, 2015 by Tom Overton

“Well, it works fine on my machine.”

That’s a phrase I loathe hearing when engineers are doing code review and an issue is discovered. Left to their own devices, engineers will approach setup of their development environments in whatever manner each one deems most efficient. Very frequently this creates two critical issues, a lack of consistency between the environments of the developers, and by consequence, disparities between development and production. These issues are fundamental. Quality is compromised when the application or the environments behave differently for each engineer. This is further complicated when there is a QA team. How were their environments built? How can they be confident they have written the appropriate test cases before release to production?

You want none of this…

Image source:,,

Image source:,,

The obvious benefit of ensuring consistent environments is improved code quality, but another great benefit is reduced finger-pointing and improved team morale. When setting up a team’s development environment, the first consideration to make is where to locate it. Should it be local or remote?


Try Making It Smaller – It’s The Agile Way

November 4th, 2015 by Greg Sypolt

Agile is a must for development shops. Agile is a mature, iterative, collaborative methodology that breaks the development process down into shorter sprints. At its core, Agile development is about small iterations, test automation and a continuous integration pipeline.

Waterfall Was Created For a Perfect World, But We Don’t Live In One

Agile is a reaction to the slower, sequential approach known as Waterfall. Where Waterfall requires upfront planning to ensure that all details are accounted for, with no room for surprises or changes, Agile accounts for the inevitability of change, adapting to the project as it unfolds.

“Imagine a waterfall on the cliff of a steep mountain. Once the water has flowed over the edge of the cliff and has begun its journey down the side of the mountain, it cannot turn back. It is the same with waterfall development.”  (Search Software Quality)

To understand the advantages of Agile, it’s important to first understand the more traditional Waterfall methodology:

  • It is a sequential design process: discover, plan, build, test, review
  • Each project is based on the extensive collection of clear documentation gathered at the beginning
  • The whole product is only tested at the end of the cycle
  • It doesn’t take into account a client’s evolving needs or leave any room for revision (more…)