Setting Priorities in Software Testing

This is a guest post by Cameron Laird.

Software organizations frequently talk and think in terms of priorities, with fine distinctions about urgency, importance, precedence, severity, feasibility, and so on. Testing has its priorities too, and while these priorities should be related to those of other departments, they are distinct.

By understanding clearly how priorities operate in testing, everyone can make the most of the effort there.

Advocate for testing

Testing’s very first priority isn’t technical, isn’t focused on the user experience, and has little to do with automation and computing expertise.

Testing’s first priority is to set clear expectations with other departments — and live up to them.

An important part of that latter notion of accountability is communicating when other departments are and aren’t meeting their own commitments. Sometimes that means reporting the discovery of a gap in existing test plans; sometimes it means telling the team that a calendar isn’t realistic and needs to be adjusted; sometimes it even means letting everyone know a testing sequence is ahead of schedule and deserves releveling. In any case, testing does best by establishing itself as a full and trusted team member, communicating effectively and professionally about business values as well as technical ones.

A second priority for the testing department is advocacy — that is, the presentation of the business value of testing. Organizations often think they can skimp on testing. When a delivery is missing its deadlines, one of the most common reactions is to compress the schedule for testing that delivery. When things are going well and customers are happy with a product or service, it’s almost equally tempting to conclude that testing is more cost than benefit, and erode the attention and resources, and time allowed for testing.

Testing always needs a strong internal voice to express the value a professional testing program brings to products and services. Only the testing department itself has the background and experience to communicate that truth, so a necessary priority is to remind the whole team of testing’s benefits.

Similarly, the testing department itself is best situated to judge the sustainability of its activities and how to enhance them. Are testers expected to work on weekends, to help compensate for slipped schedules? Does the organization grade testing careers as junior or inferior? Does it train programmers, sales staff, or marketers to stay current with their technologies, but skimp on training testers? Does the organization appear to believe that it accelerates completion by adding staff late in a campaign?

All those choices communicate that testing staff is more like consumable commodities to be used up and discarded than expert investments to be cultivated. Learn negotiation techniques and help the organization better care for its valuable testing staff.

For example, if testing is told that they need to work extra or shifted hours in order to meet a deadline, respond professionally by agreeing with the condition that at least one of the following requests be met:

  • Testing will receive appropriate compensatory time off afterward
  • Testing will get subsidies for commuting, home technology purchases or training opportunities
  • The next budget will increase the size of the testing department
  • Another reasonable, specific, meaningful recognition that the test team be managed sustainably, rather than worked until they burn out

Sharpen your axes

The priorities above focus on how the testing team operates systemically within an organization. A good testing department needs that kind of vision and execution. It simultaneously needs to balance strategic engagement with the trustworthy execution of testing activities.

The third priority is to sharpen axes — that is, ensure that all your testing tools are in shape before testing starts.

Does your staff have all the licenses, modern equipment, network connectivity, test data sets, and so on that are needed, so they can concentrate on testing rather than struggle with limitations of insufficient tools? Do your testers spend time on boilerplate or administrative chores or bureaucratic workarounds that can be streamlined or automated?

Identifying and resolving these areas for improvement is one of the best ways to increase velocity and finish assignments quicker.

Documentation is automation

Another evergreen priority is to document your testing work.

Documentation becomes an asset for future assignments because it minimizes rediscovery of all that slows you when you first undertake a task. This kind of documentation also helps communicate to decision-makers and other departments the specific details that promote understanding of the value of testing.

Read Tom Limoncelli’s classic article “Documentation Is Automation” for further inspiration. Notice particularly his emphasis that documentation is progressive, an iterative undertaking to which we return through time as we gain understanding and as our circumstances shift.

Modern Test Case Management Software for QA and Development Teams

Focus on your own work

Finally, as in any list of priorities, recognize that reverse engineering is an anti-priority. More specifically, testing should never have to analyze how an application works to determine why it works as it does.

Insist on specific requirements for each object tested. In the absence of explicit specifications, it’s more honest to report simply that the software meets its non-existent requirements than to speculate about what product management or other decision-makers intend for the software. Testers might still occasionally lean on reverse engineering to suggest useful test values, but leave requirements synthesis to those who deserve this responsibility.


Any testing you do ought to start with this outline of priorities:

  • Set clear expectations between testing and other departments
  • Advocate for the business value of testing
  • Communicate with the team
  • Ensure tools are ready for action
  • Document findings and techniques

Get these right, and your tests will be well on the road to success.

Cameron Laird is an award-winning software developer and author. Cameron participates in several industry support and standards organizations, including voting membership in the Python Software Foundation. A long-time resident of the Texas Gulf Coast, Cameron’s favorite applications are for farm automation.

In This Article:

Sign up for our newsletter

Share this article

Other Blogs

General, Agile, Software Quality

How to Identify, Fix, and Prevent Flaky Tests

In the dynamic world of software testing, flaky tests are like unwelcome ghosts in the machine—appearing and disappearing unpredictably and undermining the reliability of your testing suite.  Flaky tests are inconsistent—passing at times and failin...

General, Continuous Delivery

What is Continuous Testing in DevOps? (Strategy + Tools)

Continuous delivery is necessary for agile development, and that cannot happen without having continuity in testing practices, too.Continuous delivery is necessary for agile development, and that cannot happen without having continuity in testing practices,...

General, Business, Software Quality

DevOps Testing Culture: Top 5 Mistakes to Avoid When Building Quality Throughout the SDLC

Building QA into your SDLC is key to delivering quality. Here are the mistakes to avoid when building quality throughout the SDLC.