Welcome!

@DevOpsSummit Authors: Zakia Bouachraoui, Stackify Blog, Jnan Dash, Liz McMillan, Janakiram MSV

Related Topics: @DevOpsSummit, Agile Computing, @CloudExpo

@DevOpsSummit: Blog Feed Post

Why Organizations Need to Bridge the Gap Between Dev and QA By @SmartBear | @DevOpsSummit #DevOps

Over the years we've seen a push in the software industry for tighter release schedules and a more agile development process

Why Organizations Need to Bridge the Gap Between Dev and QA
by Dan Karlin

Over the years we've seen a push in the software industry for tighter release schedules and a more agile development process.

As a result, departments that used to function independently in a waterfall development environment are now working more closely together in an accelerated release environment.

What does this mean for the relationship between development and QA?

Folks in Dev and QA are part of a symbiotic relationship that's critical to put out a high-quality product quickly. Teams that are able to bridge the gap between these departments will have a real advantage.

One of the biggest benefits for developers with working more closely with QA is the speed in which they can receive detailed feedback.

Normally the job of QA is to find issues and report them back to the developers before anything is released. The timing of when those bugs are reported and how detailed those reports are is extremely important.

Developers want feedback on their code immediately, when they're still intimately familiar with the requirement or the user story and how they got it done. Once a developer moves on to coding a new requirement, they have to spend time and energy switching from one project to another.

Finding bugs after that switch has been made forces the developer to move back and forth between different projects. That can significant cut down on their productivity.

The fastest feedback is going to come through automation.

Developers have the ability to create their own unit tests, but most automated testing suites are primarily maintained by the QA team.

Depending on the application and your development process, there are two main ways that automation is run - on a schedule or as part of a build process. In either case the idea is to find issues as quickly as possible so that developers can make any necessary updates while all their new code is fresh in their mind.

Another benefit for developers is that testers can help set up and maintain regression tests.

Automated tests are going to be key to covering common user workflows quickly. The QA team's expertise in the product is critical to putting a suite of relevant regression tests together.

It's also typically QA's job to keep that regression suite up-to-date as an application grows in complexity. The more thorough those tests are the more bugs can be caught early in the development process.

That being said, there are always going to be at least a few tests that are run manually.

As new functionality is developed QA has to design tests to cover any new requirements or user stories. Eventually it would make sense to automate those new tests if possible, but more than likely they'll start out in a manual form.

Let's say someone in QA finds a bug through a manual test. Their immediate responsibility is to get that issue documented as fast as possible with all the supporting information the developer needs. This usually involves a step-by-step guide to reproduce the issue with screenshots to describe the problem.

One way to do this is to create an automated test as part of the bug report you send to your developers. That automated test then serves a few goals.

First, it will outline for your developers all the actions leading up to the issue and depending on the automation tool you're using you can capture screenshots automatically.

But that test will also continue to be useful later when the issue is fixed. The developer will be able to use your script to see if the problem's resolved and if needed, that automated test can be incorporated into your ongoing regression suite.

To recap:

  • QA teams can help developers by providing fast feedback on bugs and detailed documentation.
  • QA teams have the necessarily knowledge to set up a suite of relevant regression tests.
  • QA teams can provide the necessary documentation to reuse tests, which can be easily automated to improve productivity.

Now that we've looked at how QA can work with dev, let's turn things around and see how testers can benefit from working more closely with developers.

I've talked to some SmartBear customers where their QA team is all manual testers without any development or scripting experience. I've also interacted with teams on the other end of the spectrum, where the QA team has testing engineers that are used to creating unit tests and scripts completely on their own.

On the development side, your task is to create whatever functions and UI elements are needed to meet a requirement or user story that's been handed to you. And for most developers I've talked to, adding hooks for automation purposes is not a high priority.

This is an area where developers can benefit QA. If you're able to add a static identifier or property to a control, that can be a huge help in automation later.

Different development frameworks like .NET, Java, or web specific technologies like AngularJS all have slightly different ways of generating the buttons, textboxes, and other controls that make up an application. Many of the modern frameworks for web and mobile applications will generate controls dynamically as the user interacts with the application in different ways, and that means their default identification properties may change every time a test runs. This can be a huge headache for testers, and most of those modern technologies have built-in options to add a static identifier somewhere that a test can use.

With static identification properties in place, it's much easier for the QA team to create scripts and tests that are able to find objects reliably, and that's going to cut down on how often they need to ask the developers for help. It will also make it easier to eliminate as many slow, manual tests as possible.

The last suggestion I would give to developers is around customized controls.

Every development framework comes with its own set of standard buttons, textboxes, grids, and other controls. But there may be times when you need something in your UI that just can't be accomplished with something standard. When that happens a new control is made, either completely from scratch or by modifying an existing standard control.

Once that new control is made, it's useful for QA to know a bit about the custom properties and methods available to interact with it.

With QA teams that have engineering experience, they can use those properties and methods themselves in any script or unit test they create.

Testers who are used to manual testing and can't script out these actions on their own, can use sample script to use with their test automation tool. If they are using a record-and-replay tool to create automated tests and run into trouble recording actions on a custom control, they can swap in a script you've made to cover that piece.

To recap:

  • Developers can benefit QA by designing with automation in mind.
  • Developers can make QA more efficient by sharing insight into custom controls.

Bridging the gap between Dev and QA will improve your teams efficiency and reduce friction in the development process.

Read the original blog entry...

More Stories By SmartBear Blog

As the leader in software quality tools for the connected world, SmartBear supports more than two million software professionals and over 25,000 organizations in 90 countries that use its products to build and deliver the world’s greatest applications. With today’s applications deploying on mobile, Web, desktop, Internet of Things (IoT) or even embedded computing platforms, the connected nature of these applications through public and private APIs presents a unique set of challenges for developers, testers and operations teams. SmartBear's software quality tools assist with code review, functional and load testing, API readiness as well as performance monitoring of these modern applications.

@DevOpsSummit Stories
Cloud-Native thinking and Serverless Computing are now the norm in financial services, manufacturing, telco, healthcare, transportation, energy, media, entertainment, retail and other consumer industries, as well as the public sector. The widespread success of cloud computing is driving the DevOps revolution in enterprise IT. Now as never before, development teams must communicate and collaborate in a dynamic, 24/7/365 environment. There is no time to wait for long development cycles that produce software that is obsolete at launch. DevOps may be disruptive, but it is essential. DevOpsSUMMIT at CloudEXPO expands the DevOps community, enable a wide sharing of knowledge, and educate delegates and technology providers alike.
Docker is sweeping across startups and enterprises alike, changing the way we build and ship applications. It's the most prominent and widely known software container platform, and it's particularly useful for eliminating common challenges when collaborating on code (like the "it works on my machine" phenomenon that most devs know all too well). With Docker, you can run and manage apps side-by-side - in isolated containers - resulting in better compute density. It's something that many developers don't think about, but you can even use Docker with ASP.NET.
If you are part of the cloud development community, you certainly know about “serverless computing,” almost a misnomer. Because it implies there are no servers which is untrue. However the servers are hidden from the developers. This model eliminates operational complexity and increases developer productivity. We came from monolithic computing to client-server to services to microservices to the serverless model. In other words, our systems have slowly “dissolved” from monolithic to function-by-function. Software is developed and deployed as individual functions – a first-class object and cloud runs it for you. These functions are triggered by events that follow certain rules. Functions are written in a fixed set of languages, with a fixed set of programming models and cloud-specific syntax and semantics. Cloud-specific services can be invoked to perform complex tasks. So for cloud-na...
Kubernetes is an open source system for automating deployment, scaling, and management of containerized applications. Kubernetes was originally built by Google, leveraging years of experience with managing container workloads, and is now a Cloud Native Compute Foundation (CNCF) project. Kubernetes has been widely adopted by the community, supported on all major public and private cloud providers, and is gaining rapid adoption in enterprises. However, Kubernetes may seem intimidating and complex to learn. This is because Kubernetes is more of a toolset than a ready solution. Hence it’s essential to know when and how to apply the appropriate Kubernetes constructs.
In a recent survey, Sumo Logic surveyed 1,500 customers who employ cloud services such as Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP). According to the survey, a quarter of the respondents have already deployed Docker containers and nearly as many (23 percent) are employing the AWS Lambda serverless computing framework. It's clear: serverless is here to stay. The adoption does come with some needed changes, within both application development and operations. That means serverless is also changing the way we leverage public clouds. Truth-be-told, many enterprise IT shops were so happy to get out of the management of physical servers within a data center that many limitations of the existing public IaaS clouds were forgiven. However, now that we've lived a few years with public IaaS clouds, developers and CloudOps pros are giving a huge thumbs down to the...