There are no stories to test – what do I work on?

I tweeted about this a few days ago and it has seemed to cause a lot of buzz:

This seemed like a great topic to blog about.

First off, I find the notion that there is nothing to test, a nonsensical statement to begin with. You are never ‘done testing’.  A feature in development or one that is recently completed, can always benefit by more testing.

When I was a tester, I often found I was busier and seemed to be multi-tasking more when there were actually no issues ‘to test’. I always had a laundry list of things that I wanted to do but never seemed to have time for.

The following are items testers could be working on:

Study Testing

As @michaelbolton replied below, a tester can spend some time learning their craft. Often, ‘not having anything to work on’ is a symptom of not knowing the depth and breadth of testing, the value they can be adding to their teams and all the various activities they could be doing.

Exploratory Testing

The ability to test outside the scope of a story is refreshing. This is where a tester can add tremendous value. Identifying quality criteria, alternate scenarios/workflows, edge cases, etc is vital to the success of your teams.  Take advantage of this time whenever you can to do some real testing!

Adhoc Testing (bug hunting)

The ability to bang away at a system and try different things to see if problems arise, is a useful activity. There are problems you can identify by testing unencumbered in this fashion. Testing by following a spec, a story, a test charter or any sort of document can biase you as a tester, and limit the imagination and approach you take.  Embrace this activity whenever you can!

Sometimes you may find a bug with this approach but not remember how you produced it. Make sure to take notes as it can help.

Testing Technical Debt

I seriously doubt that testers always have enough time to accomplish all of the tasks they wanted to do. Inevitably, we always carry forward some sort of technical debt.  Identify these items and take advantage of this time to carry them out!

Tools to Support Testing

Research these tools, download them, play with them, learn how they can help you in your day to day.  Many are free. Find the ones that are invaluable and share these with others.

Data to Support Testing

Test data is the bane of every tester.

Securing the right data to use to test, is a major challenge in testing. Write some batch scripts, develop some additional E2E scripts, explore performance/security data, develop quick and dirty methods of getting test data into the system to make testing easier. Often, these methods do not have to have a lot of rigor around them.

Create them to save effort the next time!

Refactor Test Code

We always think we do our best work at all times.

Unfortunately, the need to refactor code is sometimes a necessity for developers and also for testers from time to time. Take this time to better align the code with your business processes, use cases and domain. Make it more readable, quicker to execute, remove unwanted and unneeded procedures, optimize it. As test suites get larger and take more time to execute, this is a much valued task.

Refactor Test Documentation

Concise, well thought out test documentation is greatly valued. Take the time to refactor this documentation whenever you can.

Review Upcoming Work

Take some time to review items in the pipeline or items in the backlog. The more upfront learning and testing you can do ahead of time before items are in work, the earlier you can find problems. Use your testing experience, domain knowledge, product knowledge, how products integrate with each other, etc to raise potential concerns.

Research Domain

Take some time to learn more about the domain you are working in. Your users will only benefit by you improving your knowledge of the industry they work in and how they do their day to day jobs.


Pair with developers, business folks, support personnel, tech writers, other testers, etc. There is a lot to learn for yourself and a lot to educate others on. Pairing can help everyone with both.

Mentor Developers on Testing

Once you are familiar with the depth and breadth of testing (see Study Testing from above), educate your teams on testing.  The more knowledge you can share with them, the more these concepts will be forefront in their minds before they hit the ‘Commit’ button.

Implement Quality Improvements

Take this time to work on quality improvements. Always strive to make your teams better and bring quality to the forefront.  You are your teams quality ambassador. Find ways of embedding these improvements in your teams day to day activities.

Bug Introspection

Do some introspection on why bugs slip through the cracks. Testers should treat these as learning opportunities to try and prevent this same thing from happening again.

Installations and Configurations

Since you install, uninstall, and configure your applications hundreds or thousands of times, you are the teams expert in this field. Learn it, understand it, dig deep, and experiment. Try and find ways to make this process easier if possible.

Targeted Release and Regression Testing (not checking)

You have tons of automation – good stuff. These are very important and key to your teams success. We cannot manually test everything all the time. But remember, this is not testing, this is just checking that everything still works as expected based on the knowledge you had at the time. Targeted release and regression testing should still be done. Products change, code changes, and impacts to functionality changes over time. Be proactive, and smart with your testing to target things that your automation may not cover or more importantly – does not know about!

Talk Testing With Other Testers

Share with others and learn from others. Find time to sit down, grab a coffee and talk testing.  You would be surprised what others know and don’t know, what you don’t know, and what you can offer others.

While I could go on and on, the point of this blog is to highlight that there is always work to be done.

So, the next time during a standup, when asked if you have anything to work on… simply say…

‘Oh hell ya!’