How to Prioritize QA Tasks

At the start of my almost fifteen-year software testing career, I often struggled with prioritizing tasks, particularly when my work backlog began to overwhelm me. Questions would arise, such as should I write these test cases for this new feature? Should I start regression testing of the build we want to release this week? Also, what about those bugs waiting for QA verification?

In any given day, there are prioritization decisions to be made.

At one of my first QA gigs when I was the only dedicated QA engineer on the team, I was given a great piece of advice while meeting with my manager about my testing priorities. As we looked at the multiple projects and their tasks, he advised me not to worry too much about whether what I was working on at the time was the absolute top priority. Instead, he suggested I focus on working on tasks that needed completing and keep the focus there.

For some reason, his advice resonated with me, and I still remember that conversation today when I look at the 87 tasks vying for my attention. I remind myself that I can only give my full attention to one task at a time, and there is nothing more motivating, stress reducing and empowering than finishing that first task of the day, whatever it is.

I’m certainly not an advocate for ignoring task prioritization. Software development teams need to be cognizant of the road map for feature and product releases and choose tasks accordingly. To reiterate, the best remedy for stressing over which task to tackle is to grab one and complete it.

With that bit of advice out of the way, let’s talk about particular software quality assurance items that have higher priority than others. Completing a task is great and all, but if it doesn’t move the project forward in an efficient way, you may end up spinning your wheels. Here are two software testing tasks that should have a lower priority, with two that you should not procrastinate.

Lower Priority Items

1. Overly Detailed Test Cases

I’ve written in the past about Keeping Test Cases Lean, and I want to begin with this concept. In general, writing test cases is the highest priority a tester can have.

A philosophy I have heard for test case authoring is to write tests in a way that anyone you meet on the street could just stroll in and test your product by following the test cases. I have always thought this was a bit odd because, when are you going to find someone in the street and ask them to test your product without any training? That’s quite unlikely I’d say, so writing test cases for this hypothetical audience doesn’t make sense.

In reality, you probably have a pretty good idea about who is going to be consuming the test cases, so write the test cases for your actual audience and save your energy by forgetting the hypothetical tester who doesn’t know how to navigate the product because they’ve never used it before.

I’ve worked on several teams where I was the sole test case author and “runner.” I knew my audience well because it was me. The main point here is to write the test cases for the recipients, whomever they may be.

2. Documenting Bugs for Obsolete Features

I’ve seen bug reports from sources I won’t name, where testers are paid by the number of bugs reported. This can get ugly to say the least. The overhead caused by sifting through worthless bug reports causes more harm than good.

Full-time testers should aim to avoid working in this way. Documenting bugs that won’t be fixed is something that can be avoided by looking at the product roadmap. If a feature is being overhauled before release, testing that feature’s legacy code should be a lower priority.  Sure, if you come across a high impact issue during regression, it should be reported, and if there is ever any doubt as to whether the issue should be reported, always report. It’s undoubtedly better to close out an invalid bug than to not report something you later find out should have been reported.

Always check with decision-makers when it comes to entering bugs that you believe may not be fixed because the code will be replaced or refactored; deeming it not worth fixing at that time. Balance this by working with the development or product manager and knowing the timeline of releases and feature improvements.

Higher Priority Items

Writing Test Cases

Back to writing test cases. As I alluded to above, this is the highest priority item on my list when starting a project, and there are a few reasons why test case authoring is QA’s job above all else.

Here’s why.

In order to write test cases, you must first understand the requirements. The process of reading requirements, asking questions, pointing out gaps in logic, any contradictions that need addressed, and considering scenarios not detailed in the requirements, if done right, makes the test author an ultimate subject matter expert. After completing this process, if you don’t know the ins and outs of the feature better than anyone else, you may not be focusing enough attention on test cases. Not only does the exercise of writing test cases give the tester an abundance of knowledge about the product, but it also points out scenarios that developers and product managers may have overlooked. This kind of information is much better served as close to project inception as possible. For example, finding these scenarios after code has been written might have saved that dev work if they had been identified prior to development. The process is beneficial to the team and project more than most realize.

A tester’s job starts with test case authoring and if done right, with good communication amongst the rest of the development team, it will prevent bugs before development begins.

Test Case Organization and Reporting

Organization of test cases and reporting might seem like two different items, but in fact they are highly related. Without the use of a proper tool for test case organization, it’s difficult to report on your test case results, and Writing a Good Bug Report is a useful skill in itself.

For example, let’s say you just use a spreadsheet for your test cases. You can write the test cases and check them off the list in the spreadsheet. After testing you can report to the product manager that you found X number of bugs and share a spreadsheet to provide coverage information.

Does anyone really want to read through a list of tests in a spreadsheet, to see the work that QA has done? And how can you prove you’ve covered all the requirements?

There is one thing about a tester’s job that is very different to a developer’s job. That is the lack of a concrete product at the end of the day. A software product is on display for all to see and the underlying code was of course written by the developers. Without a solid tool for test case documentation, management, and reporting, there is less transparency into the QA scope of work.

Although reporting may sound like just a tester’s way of saying, “Look at me. I did work,” in reality, easy to read documentation and reporting provides numerous benefits to the product and development team. It provides a way to assess how the team as a whole, is performing. Without adequate reporting, product and development managers are blind to the trends that show important statistics, such as how many bugs were found (or missed) during QA testing, how many gaps in requirements caused code re-work and most importantly for QA, how well the test cases covered the product requirements.

Conclusion

Two items I hope you remember from this post:

1. There are major hidden benefits to test case authoring. The next time you consider skipping the test case authoring and want to jump straight into testing without test cases, remember the benefits and efficiency it brings to the entire team and project. Prioritize test case authoring higher.
2. Don’t fret the prioritization of tasks of fairly equal importance. Jump into a task you know needs completing and knock it out. Take that momentum and ride it into the next task, and the next.