Leave a comment

How to Prepare for Test Automation

by Nadine Parmelee, Senior Quality Assurance Engineer

Nadine-Parmelee1-bExecuted correctly, test automation is a major benefit to an organization with a strong return on their investment and efficient speed to market over competition. There are other benefits as well, but these are the top two. When launching a test automation initiative, there are a number of factors to consider. Perhaps foremost is how test automation will need to integrate with the current business, and technical resources of an organization.

Assessing Resources
Resources must be aligned in order to maintain and continue to build upon the test automation investment made by the organization. Projects mature, morph and change, and test automation is part of that living ecosystem.

An organization needs to look across the product delivery landscape to make sure they have the confidence their entire team is positioned well and has the expertise to move forward implementing test automation. The “team” in automation consists of everyone from Product Managers (responsible for the product delivery) to the Development Team (programmers) to Test Team (testers) all the way to Customer Support (who have to manage any issues coming in from the field). Once emphasis has been placed on having resources in line with the initiative, one of the next steps is to focus on how success will be measured.

Which Tools to Use
One of the first test automation project decisions to make is what tool(s) to use. There are many automation tools available today, and all have their own specific advantages. Take the time to determine which tool is best for your delivery goal. There is no “one-size-fits-all” when it comes to tools. And not all tools are appropriate for all projects, so it is important to make sure the tool you are using will work in your project environment (or environments). Will your project need to be supported on mobile devices? Some tools work better with some coding languages than others, and the controls the developers are using may make different tools a better option for your environment. Be sure to try the tools you are considering with your application before making the decision about which ones to purchase, and keep in mind that tools do change and mature just like your software projects.

There’s an old saying, “I’m in a hurry, so please slow down.” The point, of course, is to take your time and do the task correctly to avoid mistakes that cause you to start over. Properly executed test automation is much the same thing, and the surest way to deliver a high-quality software product is by realizing these three keys:

  • Making Test Automation a part of the overall Quality Assurance Strategy yields the most efficiency and reduces time to market
  • Test Automation is an investment that brings ROI only when an organization embraces it as part of their living ecosystem
  • Test Automation requires experienced resources that span the internal delivery team

Leave a comment

Understanding Build Server and Configuration Management – Part 1

A two-part series by Morgan McCollough, Senior Software Engineer

Morgan McCollough Bridge360The terms configuration management, continuous integration, and build server are used like buzzwords in the software world today. But how many people really understand what they mean in terms of time, efficiency and money? Most computer science programs in universities don’t talk about the practical application and benefit of these concepts, possibly because they are beyond the purview of the academic science.

In general, software configuration management is the systematic management of software changes both in terms of code and configuration for the purpose of maintaining integrity and traceability throughout the life cycle. In practical terms this can mean a wide variety of things, all the way from a simple source control branching and release management process to CMM level 5.

Continuous integration is the practice of merging all developer working copies of a source tree several times a day into a central development branch for the purpose of building, testing, and providing instant feedback. Implementing some version of one or both of these environments requires the creation of a centralized build server, the system where all code is merged, builds are produced, unit tests are executed, and eventually automated deployments are initiated.

In my line of work, I am in the position to work with a number of different clients and see diverse development environments and teams. In teams larger than two people, the difference between those that use continuous integration and solid configuration management and those that don’t is significant. I think it is very likely that many teams don’t implement continuous integration or a build server because they don’t fully appreciate what can really go wrong or the potential negative effects when they don’t have these systems in place. The time wasted doing builds, fixing deployment configurations, and correcting broken builds when configuration management is not in place is a true hidden cost in software development.

Teams that have these systems in place:

  • Have a more stable code base
  • Tend to be more flexible
  • Can deploy and test in disparate and new environments with minimal effort, and
  • Can reproduce any specific build or release from any point in the history of the application

Many software development teams are familiar enough with the concepts of build servers, configuration management and continuous integration to know they are a good idea, but often decide it’s more trouble than it is worth to implement them. In my next post, I’ll outline the basic steps you can follow to implement continuous integration and configuration management in your development environment.