A High Level Overview of Quality Assurance
Here’s the short version: “Resolved” is for when someone solves something, and “Closed” is for when someone verifies that it’s been resolved. And that applies for bugs or questions or feature ideas or tasks or anything else. But when it comes to software in particular, we’ve found that it really helps to have a second set of eyes to make sure that whatever is being solved is really solved.
Why We Chose “Resolved” and “Closed”
We chose the names “Resolved” and “Closed” because they’re flexible enough that you can apply them to things like bugs, issues, questions, features, and other stuff. We wanted words that could apply to all of those—and we found that “Resolved” and “Closed” fit the best.
Sometimes They’re Not Perfect
The downside to words like “Resolved” and “Closed” is that they’re sometimes a compromise for certain types of issues or things you’d put into Sifter. For instance, a lot of people think of bugs as being “Fixed” rather than “Resolved.” But the reason we didn’t use “Fixed” is because that doesn’t work so well with things like new features. A new feature isn’t something that gets “Fixed” because that would imply that it was broken in the first place. Similarly, if you’re trying to hash out a question among your team, you may come to an answer, but a question isn’t something that gets “Fixed” either.
There isn’t a magical word that can work for every type of thing that people might stuff into Sifter, but we’ve found that “Resolved” is the best overall fit across most types of things you might want to track in Sifter.
What Does “Closed” Really Mean?
Most of the time, “Closed” means that a problem has been solved or fixed. But that’s not a hard and fast rule: sometimes “Closed” can mean that an issue won’t be worked on any more—that it’s reached the end of the line. Now and again, some customers mention that they’d like a way to put an issue on hold, and they ask for a specific “On Hold” status. That may sound tempting, but from what we’ve found, putting something “On Hold” is a bit like sweeping it under the rug or cramming it into your junk drawer. If something isn’t going to be worked on, you can instead close it and add a note in the comments saying that it might be worth working on in the future.
Or as another option, you could create a category for “On Hold” and put those types of items in there when you close them. We really think that an issue-tracking workflow works best when you think of issues as “something being worked on” or “something that’s not being worked on.” It’s okay to close things that aren’t “complete.” File them away, and if you want to reopen them later, they’ll be there.
“Open” vs. “Reopened”
You may notice that after an issue has been resolved or closed, it can be “Reopened.” That’s pretty much the same thing as being “Open” again, but we use slightly different visual cues for “Reopened” issues. And we added those visual differences because teams sometimes prefer to treat “Reopened” issues differently from regular “Open” issues. For instance, if an issue were to be reopened because a fix didn’t work out, the developer who attempted that fix may want to give it another try right away.
Who Gets to Close Issues?
There’re a bunch of ways to set up your team and your issue tracker. Whichever arrangement you go for, you’ll probably have several roles that interact with your issue tracker. Among them, there’s the “issue opener” or “reporter”—that’s the person who initially filed the issue. Then you have the “assignee,” which is the person who’s working on an issue. And then there’s typically a “reviewer” who double-checks things to make sure everything looks good—to see whether an issue has all its I’s dotted and T’s crossed.
Those three roles could be played by one person—or by three people. There’s no right or wrong way to do it, but we’ve found that things usually work best when the person working on an issue (the assignee) is different from the person checking that it’s done (the reviewer).
Let’s take a closer look at some of the options.
Quality Assurance Team
One common setup is to have a dedicated team of folks that do nothing but double-check issues. A great tester is an awesome thing to have, and if you can pull together a QA team—even if it’s just one or two people—I’d highly recommend it.
The Person Who Opened the Issue
If you don’t happen to have a QA team, another great option is to have the person who originally opened the issue review the work on it. Since they’re the one that filed it, they probably have a pretty good handle on what’s involved and what would be expected of the work that’s done.
Team Leads
If your team is large enough, you probably have a team lead who’s really proficient in the type of work that you’re doing. And that makes them pretty well suited to reviewing issues and retesting bugs. As an added bonus, this type of arrangement also opens the door for teaching opportunities for more junior developers—when a team lead reopens an issue, that may give them a chance to chat with the developer about what went wrong in their issue and how they can improve.
Your Clients
If you’re a small team working in close contact with clients on simple projects, you might consider letting your clients test and review fixes. That’s not to say that your clients should be your only layer of testing, but it can be a great way to keep your clients engaged and up to date on how things are coming along. This very scenario is one of the reasons we created Sifter in the first place—we had clients that were willing to join in with the testing process, but all the issue trackers we tried were just too overwhelming. So we set out to build an issue tracker that could be approachable for non-technical and technical clients and team members alike.
Other Team Members
If your team is a small group of close-knit developers, you could even have other team members review and retest fixes. But that’s not really an ideal arrangement because developers on a team are often too close to the code to offer an unbiased testing perspective. That’s not to say that this arrangement can’t ever work, but I wouldn’t go for this as your first choice.
The Assignee (the Original Developer)
You probably don’t want to have the person who worked on an issue be person who’s double-checking that it works. That kind of arrangement should only be used a last resort, but if you have no other option, I’d recommend at least having the developer test their work in a staging or QA environment—that way, you’ll have a chance to test against an environment that’s closer to real life rather than just a local environment on a developer’s machine.
The Quality Assurance Process
There’s no shortage of ways to develop software. And nor is there any shortage of options for managing bugs and tracking issues. A lot of these don’t have a right or wrong way about them, but I wanted to talk through a few of them to help you make informed choices.
Fancy a Staging or QA Environment?
Some teams try to have their testers work off the team’s development environment. That can seem tempting—especially since your development environment is already up and running—but there can be some perils to that approach. The biggest shortcoming is that testing against a development environment can feel like the ground is shifting under your feet as new features and fixes are constantly being committed to the codebase.
But an easy way to remove that impediment is to set up a staging environment (sometimes also called a QA environment). And once that’s up and running, you can feel confident that everyone’s on the same page and that the testing process is working against a consistent set of code that isn’t changing from one minute to the next.
It’s crucial that your staging (or QA) environment have conditions and data that are as close to your production environment as you can get. That allows you to release code into that environment and comb through all the “Resolved” bugs to double-check that everything’s in good shape—while helping to bring to light any previously unknown side effects that might not have been evident on your development environment.
Should Issues Be Reassigned?
If an issue’s opener—the person who first filed an issue—is also the person doing the testing, we don’t think there’s a need to reassign issues as they’re completed. Rather, the person who’s looking for issues to test can just create a filter to see resolved issues that were opened by them. And then they can pick one and go from there.
On the other hand, if the people doing the testing aren’t always the same as those who filed the issues, you may want to consider reassigning issues when they’re resolved. For instance, if you have a dedicated QA or testing team who’s testing issues that may or may not have filed by them, you might choose to have the developers on your team reassign issues to a designated tester once they’re completed.
Or as another option, you could have the developers “unassign” the issues as they’re completed—assigning them to no one. And if you were to go that route, your testing team could then keep an eye out for unassigned issues and test those. (Sifter’s unassigned-issue notifications can come in rather handy in kind of scenario.)
Is It Ever Okay to Skip “Resolved”?
You might be wondering, “Well, could we just skip ‘Resolved’ and go straight to ‘Closed’?” Sure—when you’re dealing with things like questions, that can make a lot of sense. For instance, let’s say that someone files an issue to the boss to ask if it’s okay to work outside on Friday. Once they answer that question, the issue can go straight to its “Closed” state—there’s nothing for your QA team to do there.
Can “Closed” Mean Something Else?
Here at Sifter, we use “Closed” to mean that “there’s no doubt in our mind that this can safely be released into production.” But maybe your team would prefer that “Closed” have a slightly different meaning—such as to say that an issue has made it through testing but it hasn’t yet been released. Or perhaps your team might prefer to reserve “Closed” for issues that have made it all the way into production. There’s no right or wrong here—it’s up to you. As long as everyone on your team is on the same page, that’s the important part.
Summary
We created Sifter as a simple tool to track issues. It’s flexible enough to handle a wide variety of development and testing arrangements, and we think that Sifter’s workflow options can be a great fit for most teams and their everyday needs.