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.
- 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.
- 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.
Announcing TestLeft: A functional testing tool fully embedded in standard IDEs
TestLeft is a powerful yet lean functional testing tool for developers who are testing in Agile teams. It fully embeds into standard development IDEs such as Visual Studio, which helps minimize context switching and allows developers to create test cases in their favorite IDEs.
In addition, TestLeft comes with visual tools, which assists developers in solving another common testing challenge — the ability to quickly and easily identify correct object properties for application under test. Using TestLeft, developers can easily generate test code simply by dragging and dropping identifiers over objects on the screen. Furthermore, access to built-in methods and classes is available for code completion and faster scripting. Tests created by TestLeft can even be brought within SmartBear’s TestComplete for consumption by testers.
Try TestLeft for free!