The Changing QA Process in a DevOps World

There’s no denying that the advent of the Agile and DevOps methodologies have changed the way software gets written. DevOps, with its emphasis on collaboration and communication, especially fits in today’s fast-paced business world. Many enterprises now aspire to a continuous deployment model so new features or bug fixes don’t have to wait a few weeks before making it into production.

So how does a faster software development process affect Quality Assurance? Are QA engineers now stuck in meetings most of the day with minimal time to actually test software? What follows is a look at the changing process of QA in this era of DevOps.

Software Development: One Process and One Team

At many enterprises, the executive team perceives the task of software development as being performed by one group, even if legacy methodologies like the Waterfall are still in use. The distinction between separate software engineering, QA, and network administration teams doesn’t matter to them. With DevOps, this perception finally becomes a bit closer to reality with everyone working closely together towards the common goal of rapid software delivery.

For the QA role to succeed in the world of DevOps, automation and a robust set of tools to support the testing process are vital. This allows the QA engineer to accomplish more within an 8-hour day that now includes additional interaction with developers, network engineers, and business analysts.

Their ultimate goal is to find defects as quickly and as early in SDLC as possible. Continuous and automated software deployment in today’s business world makes the concept of a software release schedule almost seem quaint by comparison.

Automation is a Key for QA in the DevOps Era

Being able to automate the software testing process helps QA operate at the faster speed necessary in the DevOps era. Leveraging automation also speeds up the software build process — at the developer, QA, and production release levels.

Additionally, if the development staff follows TDD (test-driven development) principles, their unit tests will catch many programming defects, allowing QA personnel to direct a portion of their efforts towards other aspects of software or system quality. This is one example of how DevOps forces team members to share responsibility for the overall product, instead focusing on what used to be their own specific area.

In DevOps, QA can now serve a role as a final arbiter for overall system and process quality, a point emphasized by Carl Schmidt, CTO for Unibounce. “I’m of the mindset that any change at all (software or systems configuration) can flow through one unified pipeline that ends with QA verification. In a more traditional organization, QA is often seen as being gatekeepers between environments. However, in a DevOps-infused culture, QA can now verify the environments themselves, because now infrastructure is code,” said Schmidt.

So migrating to a DevOps methodology doesn’t make QA go away. In fact, with additional responsibilities on their plate, QA engineers depend on state of the art tools to accomplish more tasks at a faster rate. Ensuring quality throughout the process — including software delivery — is the ultimate goal.

In the upcoming weeks, we’ll look more closely at some of the tools used by QA personnel to help them do their jobs — whether on an Agile or DevOps project as well as any other software development methodology.

The Advantages of Software Testing in a Different Time Zone

The growing popularity of modern software development methodologies, like Agile and DevOps, combined with the social media-driven 24-7 business landscape has led to the need to enhance applications at a faster pace. Relatively new methodologies like Continuous Delivery and Continuous Integration are the ultimate goal for many software development shops. In short, software engineering needs to operate at the speed of business.

What if your QA team is located in a different time zone than your development staff? Maybe even on the other side of the world? Your programmers arrive each morning with a list of bugs to fix, while the QA personnel are able to test those changes “overnight.”

Is this an alternate way to make Agile or Continuous Delivery work? Let’s look more closely at the details.

Your Entire Software Team works around the Clock

Having your entire software development team engaged on a 24-hour basis offers many advantages to companies aspiring towards the Continuous Integration model. Separate locations for your QA team and software engineers help make this a reality.

Even a four to five hour difference in time zones provides time for additional collaboration when both teams are “on the clock.” Longer distances place an onus on providing clear communication between teams on what needs tested and/or what bugs were found in the last test cycle.

If your entire staff is located in the same building, however, either testers or programmers need to wait around for the other team to finish their tasks. This leads to inefficiency, even considering the enhanced communication desired on an Agile or DevOps project. A scenario where one team works while the other one sleeps offers the best use of time.

Helping the Software Development Process achieve Continuous Delivery

Ian Lotinsky, the CTO for LearnZillion, leads a software development process leveraging the Continuous Delivery methodology. In a blog post offering advice for shops looking to implement Continuous Delivery, he mentions the advantages derived from engaging a QA team located offshore. “When an engineer’s code has passed peer review and the automated QA test suite, it is sent along to QA for manual inspection. Test results are back by the next business morning because some of our QA team members are located in India. They test our work while we sleep,” said Lotinsky.

Another key point from Lotinsky’s quote worth noting references the fact only a few of their testers are located offshore. This arrangement allows some QA personnel to work more closely with the programming team during the day, while the testing never stops after the remote QA staff picks up the effort overnight. The key for your software team is finding the right mix of a 24-hour development cycle compared to the enhanced communication and collaboration when both testers and programmers are located in the same building (or closer time zones).

Betica’s own certified Software Testing Laboratory is located in the Philippines, offering your organization the benefit of a 24-hour development cycle depending on the location of your software engineers. Contact us for additional information.

Tips for Finding the Best QA Software

Outfitting your QA team with the best software to help them perform their job plays an essential part in the overall efficiency of your SDLC. Trying to manage a complex QA process using merely the Microsoft Office suite or similar applications offers some benefit, but they aren’t really tailored to the task at hand. A dedicated QA application needs to provide the right feature set to compliment how your organization tests software.

In the past, we’ve talked about the importance of a robust toolbox for any QA team. Let’s take a closer look at some tips for finding the right QA application for your company.

Perform your Due Diligence First

Doing a complete needs assessment is a must before even beginning to research the various off-the-shelf QA applications. The size of your organization is important, as larger companies may benefit from more esoteric features like testing automation. Smaller firms where testers wear many different hats might want the ability to easily manage test environments without having to get help from network administration personnel.

Whether or not your software development projects follow the Agile or DevOps methodologies is another consideration. In this scenario, features supporting collaboration are necessary. Easy interfacing with other applications geared towards Agile project management helps make things run smoothly.

Does your shop primarily develop desktop software for Windows or Mac OSX? What about web applications? Are mobile apps or embedded software also part of the equation? These vital questions all factor into your final decision.

All QA applications need to provide requirements and bug tracking, as these are core functions benefitting both testers and project managers. Make sure a robust reporting engine — including rich testing history — is provided. The ability to export reports in a variety of formats, like PDF or Wiki, is a plus.

Get together with your software development management team and discuss these and other important points. Make a list of required features as well as functionality that is nice to have but not essential. Now you are ready to begin researching applications.

Find the Vendor with the QA Application for your Team

Make it a point to collect product information from a variety of QA software vendors. Work with your team to narrow down the choices to anywhere from three to five applications. Have your team rate each QA application on the criteria you feel most appropriate.

Follow up your team member’s individual ratings by researching online reviews from trusted sources within the QA community. Reach out to some of your connections on LinkedIn to see if they have any hands-on experience with the applications in question. In many cases, these sources provide more meaningful insight than those derived from marketing information or even press reviews.

Take advantage of any free trial periods if provided, so your team can actually get hands-on experience with the various candidate applications before a final decision is made. Once you’ve decided, make sure to choose a licensing option offering the most flexibility for both your team and your company’s bottom line.

Hopefully, these tips offered a measure of insight before you go shopping for a great QA application for your staff.