Matt Archer's Blog

  • 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

Posts Tagged ‘Tips for manual testers working in an agile environment’

Tips for manual testers working in an agile environment

Posted by Matt Archer on January 3, 2013

Those of you that are familiar with my blog will know that the majority of my posts tend to be quite lengthy. I like writing this way, but I have decided to break from the norm and publish a series of shorter posts that focus on a question that I encourage manual testers working in an agile environment to frequently ask themselves. That question is;

How can I provide meaningful, quality related feedback, faster through predominantly manual, human-driven, activities whilst maintaining independence, diligence and predictability?

The question is deliberately process agnostic and designed to encourage fresh ideas and creative thinking rather than point towards a specific set of guiding principles. That said, I regularly find myself making similar recommendations to different teams and it is these recommendations (or tips) for manual testers working in an agile environment that I plan to share over the coming weeks.

Even though I intend each post to focus on a specific idea, my intention is to leave it to the reader to decide how that idea can / should be implemented in their specific project. My aim is a post per week. Let’s see how we go.

A list of the posts that have been published so far can be found below.  If no post are visible below, please click here.

Posted in Agile Testing | Tagged: | 3 Comments »

However you document your manual tests, don’t repeat yourself (D.R.Y.)

Posted by Matt Archer on January 3, 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).


For years, programmers (at least the good ones) have known that when one piece of code looks very similar to another piece of code then this typically isn’t a good sign. If something needs changing in the first piece of code, then the same change will almost certainly need to be made in the second piece of code too.

The more duplication that exists, the greater the chance that a mistake will be made during the update, the update will only be made in some places or changes will be rejected or ignored due to the daunting amount of effort that often comes with such duplication.

Unsurprisingly, when the description for one manual test looks very similar to the description for another then this typically isn’t a good sign either. It generally isn’t a good sign for any tester, but for a tester who is working in a agile team where “responding to change” is valued over “following a plan”, duplication can quickly spell trouble.

So next time you find yourself reaching for the copy & paste icons, consider the duplication that you may be about to introduce into your manual tests. And more importantly, consider the future maintenance cost to you and the team.


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.

Posted in Agile Testing | Tagged: | 7 Comments »

Tailor your agile testing practices to meet your specific needs

Posted by Matt Archer on January 9, 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).


Some agile testing techniques appear so popular it can be difficult to keep them in perspective, alter them to meet our needs or choose to ignore them entirely. But this is what successful agile teams do on a daily basis.

It can be great fun debating the theoretical pros and cons of one approach against another, however, arguments both for and against a given approach are often invalided as soon as it is used in practice.

With this in mind, never be scared to try something new. Testers can waste days discussing whether a given approach is a good idea. This can be avoided by agreeing to perform a small trial. And by small, I mean as small as possible. Forget trying something for the whole of the next sprint, try it solely for the next story you build. At the very least it will give you a real example to discuss rather than a theory. Think of it as a mini experiment to support or refute your argument.

You may think that you don’t want to compromise and instead stick to the agile ideal, but being adaptable is at the heart of agile. What follows is an extract from the extremeprogramming.org website. Many consider it to be the most important XP Rule. “Fix the process when it breaks. I don’t say if because I already know you will need to make some changes for your specific project. Follow the XP Rules to start with, but do not hesitate to change what doesn’t work.”


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.

Tailor your agile testing practices to meet your specific needs

Posted in Agile Testing | Tagged: | Leave a Comment »

Why you should resist overlaying traditional testing processes onto a sprint

Posted by Matt Archer on January 16, 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).


Agile projects rarely complete something in a single sitting, instead opting to progressively elaborate their understanding of the software and the software itself over time. It is useful to remember this aspect of agile when deciding how to perform our testing tasks.

It is not uncommon for testing to be organised around a planning-specifying-executing-reporting-maintaining pipeline, but this carries the risk of achieving failure for any project, agile included. In addition, testers who overlay this approach to testing onto a sprint carry the risk of feeling at odds with the rest of the team, to the point that even the most test-sympathetic teams can feel like a challenge.

A way to overcome this problem is to progressively elaborate our testing in the same way that the team evolves the software. This doesn’t preclude an element of upfront test planning within a sprint or early test ideas, but be mindful that some aspects of the solution are yet to be decided and those aspects already decided may change.

This turns questioning into an finely-balanced art. Early questions are to be encouraged, but demanding a complete specification is unlikely to allow your team to work in the agile way it desires.


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.

Resist overlaying traditional testing processes onto a sprint

Posted in Agile Testing | Tagged: | Leave a Comment »

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

Posted in Agile Testing | Tagged: | 2 Comments »

Don’t allow yourself to become blocked (A productivity tip for agile testers)

Posted by Matt Archer on January 30, 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).


If your project aims to release their software ten months from now, losing a day because your work is blocked can often be dismissed as inconsequential. Contrast that to an agile team that aims to release every ten days. Spending a day idle becomes much more significant.

Traditionally, testers have placed strict entry criteria before their activities, but if we took this approach to agile testing we would spend the majority of our time underutilised, supposedly blocked. One way to improve your productivity is to discard the notion of needing a “complete specification”. Instead, ask yourself what is the bare minimum I need to begin testing. The rest can come later.

Even when we begin to test early, it is easy to block or significantly delay ourselves by spending too much time pondering the gaps in our knowledge. When you encountered such as gap, resist the temptation to speculate for too long, especially in isolation.

If you believe the information is known within the team, now is a good time to remember the three ‘C’s that describe the journey of a user story; card, conversation, confirmation. If a conversation isn’t available or doesn’t leave you satisfied, leave yourself a note to revisit the gap at a later time and move on. Above all, don’t allow yourself to become blocked.


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.

An agile testing productivity tip: Don’t allow yourself to become blocked

Posted in Agile Testing | Tagged: | Leave a Comment »

Not every tester should code, but knowing how to spot risky automation can be beneficial

Posted by Matt Archer on February 7, 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).


This tip is about automation. Not because I think every tester should learn how to code, but because it is useful for manual testers to be able to recognise automated tests that may not meet expectations.

The majority of agile teams create different types of automated tests. Some focus on a few lines of code, others encompass chains of integrated systems. Some run in milliseconds, others minutes. Some interact via the user interface (UI), others probe underlying services.

When relying on automated tests, the most risky and unreliable tend to be those that cover the largest area, take the longest to run and interact with volatile aspects of our software, like the UI. We cannot always avoid these tests, but a team can aim to use them sparingly.

This is where the test automation pyramidcan help identify risky strategies by suggesting a ratio between focused, quick, beneath-the-UI tests and broad, slow, against-the-UI tests. Predictably, the ratio is in favour of the focused, quick, beneath-the-UI tests.

If your team’s automated tests go against this ratio, I recommend taking a closer look. If what you discover is of questionable value, discuss with your team how manual testing can temporally help, including any extra support and resources required to fill the gap.

Further Reading

1a. A blog by Martin Fowler about the test automation pyramid: Link

1b. Enter “test automation pyramid” into Google for countless others: Link


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.

Not every tester should code, but knowing how to spot risky automation can be beneficial

Posted in Agile Testing | Tagged: | Leave a Comment »

Why agile testers should use self-generated maps to help organise their testing

Posted by Matt Archer on February 18, 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).


To help organise our testing, we frequently divide software into parts. These individual parts can then become the focus for different activities, including test planning, designing, executing and reporting.

Traditional processes tend to dictate that testers should rely on artefacts created by other people to provide a map of the software and its different parts. A common example is to use a functional specification as a guide to partitioning the software’s capabilities.

Whilst this type of information is useful, relying solely on models and specifications created by other people to guide our testing carries the risk of limiting our work to what others have committed to file. A risk that becomes even more prevalent when you consider that agile teams value working software over comprehensive documentation.

In the absence of a provided structure, there is the temptation to wonder chaotically through the system looking for bugs. To do this is to overlook our ability to create our own abstractions of the system.

You can create your own maps using any tool or format. My only tip is not to be afraid of creating multiple maps or even temporary ones. Their goal is to help you consciously decide where to focus your testing next based upon everything you have learnt so far. Whichever maps help you with this task, are the maps for you.


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 agile testers should use self-generated maps to help organise their testing

Posted in Agile Testing | Tagged: | 2 Comments »

Use traditional testing tools in a way that makes you agile

Posted by Matt Archer on February 28, 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).


Some agile teams have the luxury of being able to chose the tools they use, but others are tied to particular tools or venders which may not necessary be their first choice due to a lack of agile credentials.

If you find yourself in this situation, it is worth remembering that just because a vender had a particular usage pattern in mind when they created their tool, doesn’t mean that you have to follow it. As an example, you could combine what the tool vender may consider different tests into a single record to reduce your test preparation and maintenance effort, whilst also placing related tests in context.

When you use a traditional tool in an agile way, it is not uncommon for people to worry about skewed metrics. In the example above, where we used to have 20 “test” records we may now only have five.

If you encounter this feedback, it can be useful to ask how the metric is being used. Are people assuming that an area with less “tests” can be tested in less time? I hope not. Or maybe that an area with more “tests” will be tested more thoroughly? An equally risky assumption. You can help your team by explaining how some of your tool’s metrics have debatable value regardless of how it is used. It will also serve as a good opportunity to discuss what information your team would like and how you can accurately provide it.


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.

Use traditional testing tools in a way that makes you agile

Posted in Agile Testing | Tagged: | Leave a Comment »

Why attending the daily stand-up helps agile testers keep in sync with the team

Posted by Matt Archer on April 2, 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).


Few things are more confusing for a project sponsor than a team that is evidently busy but failing to deliver high quality software at regular intervals. To the casual observer, the behaviour is paradoxical. If everyone is busy, how can the team’s delivery rate be so slow?

In such a situation I would recommend that the team reviews their cohesion. Is everyone driving towards the same short-term goals or are people working on activities that are at best required for a future sprint or worse, activities that are unknowingly not required at all?

From a testing perspective, this type of redundancy can come in many forms. A common example is the preparation of tests that are never executed because the target of those tests is significantly changed or placed out of scope without the tester’s knowledge.

As our understanding of other people’s work improves, the more cohesive (and less wasteful) we tend to become. It is for this reason that I advise testers to always attend their team’s daily stand-up.

Daily stand-ups also present opportunities to invite people to collaborate. Whilst strictly not part of the standard three-question agenda, I see little harm in a tester augmenting their update with an invitation to pair or an offer to review another’s work. I encourage this practice because it is these collaborative activities (not just meeting once a day) that make a team truly cohesive and strengthen their chance of delivering high quality software on a regular basis.


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 attending the daily stand-up helps agile testers keep in sync with the team

Posted in Agile Testing | Tagged: | 2 Comments »