When I began my IT career, I was a QA tester. But sooner rather than later, I was asked to program to learn more about the applications I'd be testing. Since I had programming experience from college, I didn't mind taking on work in both areas—but programming in a corporate environment? Intimidating.
In the end, it gave me a ton of insight into what it's like on both sides of the engineer/QA relationship. And when I became a QA department manager, I was able to use my experience in both programming and QA to streamline the software development life cycle. Here are some tips I learned along the way to help with common issues that come up between developers and QA.
Problem: Programming has completed a project according to guidelines, but QA is moving the goalposts
It happens to the best developers: they've worked hard on a project and completed everything to the given specifications. The programmer is feeling good about the project. They might even take the afternoon off.
But then, QA begins their testing and points out the project works well according to what was asked but negatively impacts another part of the system.
Solution: Involve QA from the start
In my career as a QA manager, sometimes I'd be told programming "didn't want to waste QA's time" early on in the development life cycle, before project details had been finalized. But this isn't ideal! QA should be involved from the beginning of a project's development—even before programming has begun.
A good QA tester knows the entire system they're testing and can provide valuable input from the start. A change to one function may impact another function, and QA can ask up front if this functionality is being considered.
If a question is asked and resolved at the beginning, programming is saved from having to redevelop and test something down the pipeline after it's sent to QA. That means QA will spend less time retesting the project prior to release, and everyone is happy.
Problem: Programming can't recreate issues found by QA
When I programmed, there were times someone would send me an issue with my code, I would follow the steps they gave me to recreate it, and the error wouldn't happen. Good? Not quite.
Eventually, we'd figure out I had different permissions in the system, or we were using different browser versions. But until then, I'd be frustrated, repeating the same steps over and over again to no avail.
Solution: QA must ensure programming can successfully recreate the issue
When a tester enters a bug report for programming, it should be as specific as possible, with other relevant information included, like:
What user permissions do you have set up in the system when the bug occurs?
If you change those permissions, does the bug still occur?
Which browser (and version) are you using?
Work with programming to create a template of necessary, but maybe overlooked, information for debugging. And if the programmer still can't recreate the issue, the tester should work directly with the programmer to find differences in the tester's and programmer's environments.
If the issue still can't be recreated together, enlist the help of other testers to get additional ideas.
Problem: Programming gives projects to QA late, and all teams rush to find and fix issues—if they can
My personal biggest frustration as a tester (and then QA manager) was the number of projects getting to QA too close to a release.
When QA receives a large project right before release, it can't be tested thoroughly, but teams are still pressured to make the assigned release date. When multiple projects hit QA at the same time, and with a short turnaround, the results are mayhem.
Solution: Together, QA and programming need to set project-specific cutoff dates for release
When I was a QA manager, I'd often be asked when projects should be to QA prior to a release. When programming asks this, they usually want a specific cutoff for the entire release. But one blanket date rarely works for all projects.
For example, a very large project may need significantly more QA time than smaller ones, including the time for programming to make any fixes. It's also problematic for QA if programming gets all of the projects to QA at once—and it happens to be that aforementioned cutoff date.
To avoid this, set cutoff dates for each individual project. Staggered projects benefit both QA and programming by preventing a mad scramble and late deliverables. And if something comes up and a date is missed—after all, programming has other tasks to attend to besides a release—programming should check in with QA and ask:
Is one project ahead of schedule, making it ok another project is a day or two behind?
Can another lower-priority project be removed from the release?
Is it possible, in extreme cases, to bump the release?
Problem: Repeatedly, projects arrive at QA with obvious bugs
QA finds bugs during testing. It's what they do and why they exist. Software is complex and needs a second (or third or fourth) look before release.
Sometimes, though, a programmer will lean on QA too much. In my career, I've sometimes been sent projects with basic functionality missing or broken—as if no preliminary testing was done at all. And other programmers would send over the same types of bugs every project, never learning how to properly address them. I could break their programs the same exact way every time.
Solution: Programming needs to thoroughly test projects before QA gets involved
QA is meant to be the final check for issues in a project, not the first line of defense. Programmers should thoroughly test their code before sending it to QA. If a programmer is unsure of how to test their project, they should ask the assigned QA tester for tips. A good tester will be happy to share their knowledge to prevent back and forth, but the programmer should take good notes to prepare for similar testing in the future.
Programmers should also keep track of the type of bugs sent back to them from QA. If QA always finds the same mistakes, make a checklist to address these errors and complete it for every project—before sending it to QA.
When programmers and QA work together throughout the entire software development process, problems are anticipated, errors are addressed, and the process becomes smoother for everyone involved. Teamwork makes the dream work, right?
