Matt Archer's Blog

  • LinkedIn

  • Twitter

  • Twitter Updates

    Error: Twitter did not respond. Please wait a few minutes and refresh this page.

  • Advertisements
  • New Book

    I'm working on a new book. View the home page for the 'Tips for manual testers working in an agile environment' book
  • Enter your email address to receive notifications of new posts by email.

  • Subscribe

Why sharing information with other people can make you a more agile tester

Posted by Matt Archer on January 23, 2013

This post is part of the tips for manual testers working in an agile environment series. A series of posts inspired by the topics covered in the Techniques for Agile Manual Testers course that is currently available to take in London (via the Ministry of Testing) and in Copenhagen (via PrettyGoodTesting).

When testers work in isolation it is easy to forget that some of the information that we gather and store for future use is the same, or very similar, to the information that other team members document.

In agile development teams, testers typically work much closer with other team members which helps highlight this kind of repetition. That said, even when the overlap becomes obvious, the practice of “my documentation” is one of the hardest habits to break.

I attribute much of this resistance to the practice of using documents to represent key milestones and the rate of document production as an indicator of progress. Based on this mentality, reusing another team member’s documentation can feel like you are not providing measurable value. In reality, this type of reuse will give you more time to focus on the things that make you valuable, like finding bugs.

This emphasis on documents is something that agile teams replace with a focus on working, business impacting, software. Testers can help support this ethos by looking for opportunities to reuse existing documents that have already been produced and either updating or amending them directly, or referencing them from their tests or new (typically much shorter) test-centric documentation that only contains information that cannot be found elsewhere.

If you have a comment or question about this particular tip, please do not hesitate to Leave a Reply.  A complete list of tips is listed below.

Why sharing information with other team members can make you a more agile tester

2 Responses to “Why sharing information with other people can make you a more agile tester”

  1. Hi Matt,

    Nice article! This is especially poignant since I just became the only Tester in my organization but with two new people that will be doing a combination of help desk and testing. I’ve always believed in sharing and reusing of documentation, but with this new staffing, it will be even more important for me.



    — MA: Thanks Teri. Good luck with your new role. I hope it works out well for you. Whilst I can always see a place for specialist testing knowledge, I think role sharing (similar to your help desk colleagues) will become more common. Hopefully this will lead to documentation sharing becoming more prolific too. Thanks again, Matt.

  2. Scott said

    Hello Matt. I see the advantage of re-using documentation, but I would like to challenge you on this statement:
    “In reality, this type of reuse will give you more time to focus on the things that make you valuable, like finding bugs.”

    One of the common themes we hear in the software assurance field is the notion of “fresh eyes”. I know one of the issues which befall us is inattentional blindness. This also leads to some testers being complacent in their motivation and curiosity.

    Can you expand on the statement you made regarding reuse and address how using another documentation will free a tester enough to find new defects? I would be interested.


    Thanks for your comment Scott, I’ll try to answer your question is two parts (as you have hinted at two slightly different topics).

    A distinction I like to keep clear in my mind when I am testing is the time I spend interacting with the software vs. the time I spend doing other activities, like creating documentation. I do this because whilst other activities like creating documentation are important and have their place, my understanding of the quality of the software only improves when I am working with it directly (or a snapshot of its state). Re-using existing documentation allows me to spend more time interacting with the software to improve my understanding of its quality, which I can then share with a wider audience. One way I share my understanding is through the creation of bug reports. It doesn’t always hold true (for various reasons) but typically the more time I spend interacting with some software, the more bugs I will find. It is for this reason that I try to maximise the time I spend with the software I am testing. I do this through various means, one of which is reusing existing documentation. I encourage other people to do the same.

    The said, just because we maximise the time we spend with the software we are testing, it doesn’t mean that by default we will spend our time with the software wisely. There are plenty of traps we can fall into, including the example you gave of inattentional blindness. As far as I know, there is no “cure” or quick-fix for inattentional blindness, so the best we can do is work to minimise its affect. One of the ways that I do this personally is look at the same piece of software from many different perspectives. It is a relatively easy thing to do, as long as you don’t expect multiple perspectives to be handed to you on a plate (an element of personal investigation is nearly always required). With a little digging, I find it relatively easily to generate multiple views or models of the thing I am testing (sometimes just in my head, sometimes on paper). By no means do I limit it to the following list, but to give you an idea, I deliberately go out of my way to understand the thing I am testing from a user perspective and a technical perspective, from a data structure perspective and a workflow perspective, from a first-use perspective and a subsequent-use perspective… you get the idea. I find using these different perspectives to guide my testing helps produce a fair number of “how did I miss that bug before” moments. How does this relate to re-using existing documentation? Quite simply, the less time I spend documenting, the more time I have to test from different perspectives, which in turn typically helps find the bugs I’ve previously missed through inattentional blindness.

    I hope that all makes sense. Thanks again for your comment.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s