Welcome!

@DevOpsSummit Authors: Zakia Bouachraoui, Elizabeth White, Yeshim Deniz, Liz McMillan, Pat Romanski

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
CloudEXPO | DevOpsSUMMIT | DXWorldEXPO Silicon Valley 2019 will cover all of these tools, with the most comprehensive program and with 222 rockstar speakers throughout our industry presenting 22 Keynotes and General Sessions, 250 Breakout Sessions along 10 Tracks, as well as our signature Power Panels. Our Expo Floor will bring together the leading global 200 companies throughout the world of Cloud Computing, DevOps, IoT, Smart Cities, FinTech, Digital Transformation, and all they entail. As your enterprise creates a vision and strategy that enables you to create your own unique, long-term success, learning about all the technologies involved is essential. Companies today not only form multi-cloud and hybrid cloud architectures, but create them with built-in cognitive capabilities.
For far too long technology teams have lived in siloes. Not only physical siloes, but cultural siloes pushed by competing objectives. This includes informational siloes where business users require one set of data and tech teams require different data. DevOps intends to bridge these gaps to make tech driven operations more aligned and efficient.
Daniel Jones is CTO of EngineerBetter, helping enterprises deliver value faster. Previously he was an IT consultant, indie video games developer, head of web development in the finance sector, and an award-winning martial artist. Continuous Delivery makes it possible to exploit findings of cognitive psychology and neuroscience to increase the productivity and happiness of our teams.
Atmosera delivers modern cloud services that maximize the advantages of cloud-based infrastructures. Offering private, hybrid, and public cloud solutions, Atmosera works closely with customers to engineer, deploy, and operate cloud architectures with advanced services that deliver strategic business outcomes. Atmosera's expertise simplifies the process of cloud transformation and our 20+ years of experience managing complex IT environments provides our customers with the confidence and trust that they are being taken care of.
Serveless Architectures brings the ability to independently scale, deploy and heal based on workloads and move away from monolithic designs. From the front-end, middle-ware and back-end layers, serverless workloads potentially have a larger security risk surface due to the many moving pieces. This talk will focus on key areas to consider for securing end to end, from dev to prod. We will discuss patterns for end to end TLS, session management, scaling to absorb attacks and mitigation techniques.