At some of Sam Connelly’s previous jobs, she was used to being the person pushing developers to adopt better testing infrastructure. But at her current job as a test engineer for e-commerce platform Equal Experts, she was happy to find the role already taken by a developer. Having a developer who advocates for testing on her team has been great.
“I haven’t had to get on my high horse as much,” she said.
Thorough testing is a big part of all software development projects. Developers and test engineers work closely together to improve code quality, but as in every relationship, the working partnership between test engineers and software developers can become strained. Back-end code can be especially tricky because it lacks a visual element to check against and touches on concepts such as performance and security.
But there’s a lot that developers can do to improve the partnership with testers and much of it comes down to communication.
8 WAYS TO IMPROVE THE DEVELOPER-TESTER RELATIONSHIP
- Understand testing responsibilities. Developers should get to know their own responsibilities around testing as well as the limits of test engineers’ responsibilities.
- Consider performance and security concerns. Planning for these factors should start early. Don’t let a focus on speed squeeze them out of the planning process.
- Include plenty of logging. Adequate logs make catching production bugs much easier.
- Grant permissions to testers. It’s best to give testers all necessary permissions ahead of testing to save time.
- Go over what you’ve already tested. Developers should share with testers what’s already been covered to prevent redundant testing.
- Test at the right times. Practice risk-based testing so test results get the attention they deserve.
- Keep testers up to date on deadlines. Test engineers are often the last to know when deadlines shift but that shouldn’t be the case.
- Communicate in real time when possible. It’s a time saver and allows each side to ask and answer questions.
“Over-communicating, signifying intent, being really clear about what you’re doing and what your concerns are — all of those things are so important in software and certainly as well in the relationships between different roles,” said Jeff Scott, senior quality advocate engineer at Olo.
Scott coaches developers, helping them improve code quality and establish continuous integration and continuous delivery systems. But some of the biggest improvements to quality come from culture changes — like documenting the testing responsibilities of each role, thinking about performance and security throughout the agile process, and finding bugs soon after merging code. Back-end test engineers talked to Built In about a few habits that can make the tester-developer relationship more efficient and enjoyable.
Determine and Document Testing Responsibilities
One way developers can contribute to a positive working environment is by getting to know each role’s responsibilities around testing. Testing responsibilities often aren’t communicated explicitly, which can lead to lack of code coverage and redundant tests, said Melissa Tondi, a quality engineering consultant with over 20 years of experience.
“I ask a lot of quality engineers the question, ‘What are your developer counterparts’ unit or integration guidelines and standards?’ And most of the time the answer is, ‘I don’t know,’ or ‘There are none.’” Tondi said.
That kind of response is a red flag, she said, and can indicate that work is being unfairly shifted onto test engineers when developers don’t feel obligated to test. It’s not very efficient either: Test engineers’ time is better spent creating tests that developers aren’t trained to write and creating additional layers of quality control. Meanwhile, developers should also be adding tests to the codebase, especially when it comes to writing unit and integration tests.
It’s best for companies to have standard guidelines for the types of testing developers and testers are expected to perform. For example, companies can specify that all unit testing is the responsibility of developers or that all manual testing should be performed by test engineers. All guidelines should be documented and accessible to everyone at the company, including new hires.
Don’t Let Speed Overtake Performance and Security Concerns
The agile software development process is helpful for many development teams but it has its drawbacks. Agile’s emphasis on delivery speed doesn’t fit well with the need to consider important back-end concerns such as performance, security and reliability at each step of the software development process.
“[Developers] may say, ‘We’re going to emphasize being fast on this,’” Tondi said. “And instead of testing their own stuff, they’re going to ‘throw it over the fence’ — which is not necessarily a positive experience.”
That type of mindset can lead to testing teams catching the vast majority of bugs. Then the bug has to get reported to developers, the developers have to roll out a fix and the test team has to check the code one more time — creating significant lag time for each bug fix.
But security experts advise that it’s better to instead try and catch issues early, or to “shift left.” When issues in the code are caught around the same time the code is being written, there is much less lag time to roll out the fix. That applies to performance concerns as well.
Connelly said companies often block off time for performance and security testing after most of the coding work for an application is completed. But structuring the workflow so testing is totally separate from development has the potential to cause problems.
“It’s like, lo and behold, there are issues,” Connelly said. “If only we were able to get this feedback earlier on, we wouldn’t have to almost rebuild our entire solution.”
Use Logging to Simplify Testing in Production
Test engineers primarily work in the test environment but testing is sometimes needed in other places as well, including the production environment. When errors occur in production, teams are under a time crunch to find and fix the bug immediately.
That’s why it’s important to structure projects ahead of time so testing in production is easy to do. Adding good error logging is helpful, Connelly said, but it often gets overlooked during the development process. That can make it difficult when there is a production issue, especially for errors in the back end, which lack visual cues.
“Back-end code can be more abstract, so it can be quite challenging to try and figure out what’s going on,” she said. “When you can’t access the code in production, you don’t have the same development environment debug options and you can’t do remote debugging as much.”
Logging should ideally be in all the different layers of the application, Connelly said. If a service is talking to an API, audit logs should track what the service is interacting with and what data gets transferred.
Ensure Testers Have All the Permissions They Need to Test
Test engineers are usually not given access to everything developers have by default, so developers can make the testing process easier by granting all the necessary permissions testers need ahead of time.
Scott considers this a time-saving strategy not just for test engineers but for developers as well. It can be costly for developers to go back and forth between tasks all the time.
“One of my colleagues asked, ‘How many times do you want me to force you to change context in order for me to get the tools I need to test?’” Scott said. “And having it framed that way, the developer was like, ‘Well, I want to provide you everything up front, so I can just do my thing and you don’t need to interrupt me.”
Fill Testers in on What You’ve Already Tested
Developers should have conversations with test engineers about the tests they have already written themselves, and also the parts of the application testers should cover, ahead of each testing session.
These discussions not only save time but can also help test engineers orient themselves within an unfamiliar project. Because they are not the ones who wrote the code, talking with developers can help testers cut down ramp-up time and figure out where to start.
“It really does have several really good outcomes,” Tondi said. “It’s all part of the shift-left mentality. If you shift it all the way left, it really does optimize the developer’s time, and certainly the quality engineer’s time.”
Having those conversations are also important because assumptions about what needs testing and who is going to do it can lead to tension, Scott said.
“Unnecessary testing can cause friction,” Scott said. “If the tester doesn’t really understand the code or the developer hasn’t really outlined what is covered under unit tests, then there can be lots of test iterations that might be covered already.”
Redundant tests can frustrate testers who already have a lot they need to juggle and it can hold up the project timeline if it happens often. But developers who are proactive about communicating can help test engineers work effectively as part of the team and cover more ground with testing.
Practice Risk-Based Testing
Developers and testers should try to get the timing right when it comes to running tests. If teams don’t run tests at the right time, it can lead to a culture of ignoring test results.
“There’s a time and a place to do different levels of testing,” Connelly said. “The idea of testing is to help get feedback. ... If your end-to-end tests get triggered too early on in the process and you’re not paying attention to that information, then you need to move that feedback loop to a point that makes sense.”
Instead, teams should use risk assessments to determine what tests are most important to run at each step of the development process. And tests all come with a cost of maintenance, Connelly said, so the more you write, the more time you have to spend maintaining them.
When CI/CD processes are overloaded with tests, people may not have time to follow-up with each failing test. It can also be counterproductive if important issues are getting lost in all the noise. Even if automatic alerts are used, developers may quickly start ignoring warnings when they appear.
“It’s really easy to ignore emails, especially if they’re automatically generated,” Connelly said. She’s noticed that having builds integrated with Slack channels works better because problems will pop up on Slack and notify everyone if a build is not working correctly. Back at the office, the team had a dedicated TV monitor that contained build information visible to everyone.
Alert Test Engineers to Shifting Deadlines Right Away
Test teams should be quickly alerted when things don’t go according to plan. When a project begins, there’s always a time estimate on when development for specific features is going to wrap up — only then can test engineers begin testing those features. But sometimes estimates are flawed, projects get delayed, and timelines have to be pushed back. That’s a normal part of development but, when it happens, test engineers shouldn’t be left out of the loop. Developers should update testers with the new date they can expect to begin testing.
“The moment that you know the original estimates are not actually going to happen, that warrants a conversation so the quality engineer can pivot and put in risk-based testing techniques,” Tondi said. “I’m not going to now have time to complete my entire test strategy, so now I have to take the most important tests and prioritize them higher because my time has now shrunk.”
Tondi said situations like that can cause “a ton of scrambling” for test engineers, who may need to reorganize their testing schedules for other projects to accommodate the change. It’s best to give testing teams as much advance notice as possible to do that.
“It puts us in a bind,” Tondi said.
Advocate for a Closer Relationship Between Testers and Developers
Test engineers who are well-integrated into development teams can have bigger positive impacts on projects. Connelly has found it challenging to work on teams where testers are located many time zones away from developers, especially when there’s not much overlap in the work day.
In one of her previous jobs, Connelly was based in Sydney while the developers were in London. Developers would start their work day just as she was signing off, so she had to resort to communicating through more formal channels such as bug tickets, instead of real-time conversations.
“If I had an issue, I’d basically have to raise a request for it overnight and get back to it the next day,” she said.
Companies should try to organize teams so test engineers have as much time overlap as possible with the development teams they work with. Tondi agreed that communicating in real time is often better than communicating through bug reports and documentation. That’s because documenting bugs takes time and there are nuances that can come through when testers and developers talk together.
“For organizations that really embrace the agile workflow, we emphasize conversations over tools and process,” Tondi said.
That includes keeping the goal of the developer-tester relationship in mind — not one where either party is in a lesser position of power, but one that is mutually beneficial.
“Engineers should ultimately be working collaboratively together to come up with the best and highest-quality solution,” Tondi said. “If you find that the relationship is less than symbiotic, then it’s not a code issue or a quality engineer versus developer issue. It’s probably a communication issue.”
