Tips for manual testers working in an agile environment
$7.99
Minimum price
$14.99
Suggested price

Tips for manual testers working in an agile environment

About the Book

Whenever I join an agile team I ask myself the following question. How can I provide meaningful, quality-related feedback in a way that is compatible with the values and pace of agile software delivery, whilst maintaining independence, diligence and predictability?

You would be forgiven for thinking that after many years of asking myself this question I would have converged on a common answer. Nothing could be further from the truth. The reality is that every agile team is different and must continually be the subject of various experiments and trials to help the team evolve a blend of testing practices that will aid them in achieving their particular testing goals.

It is for this reason that I have decided to write a book of tips for manual testers working in an agile environment, rather than step by step tutorials for specific testing practices. It is through these snippets of information that I hope to seed new ideas in your mind that will inspire you alter the way you work by trying something new.

Maybe that new thing will work for you; maybe it won’t. Either way, you will have expanded your experience of testing in an agile team through your own success or woes. This, in my opinion, is a great way to study the craft of testing and continue to improve as a tester. I wish you the best of luck in all your agile testing endeavours and I hope you enjoy the tips. You can read them in any order you like.

The following tips are available in the current version of the book.

Tip 2: Tailor your agile testing practices to meet your specific needs

Tip 3: Understand the risks associated with manual test scripts

Tip 4: When testing or preparing, don’t allow yourself to be blocked

Tip 6: Enrich your knowledge and expectations using multiple oracles

Tip 7: Favour dedicated learning resources to educate new testers

Tip 8: Before you document information, question who it is for

Tip 9: Help your team by undertaking work that isn’t testing

Tip 11: Follow an exploratory approach to your testing

Tip 12: Keep supporting information in a single place (not in your tests)

Tip 13: Set testing objectives that realistically align with regular releases

Tip 14: Be cautious of any sprint that is organised like a waterfall

Tip 16: Share common information with other members of the team

Tip 17: Use traditional testing tools in a way that makes you agile

Tip 18: Ask yourself what you can do to improve overall team performance

Tip 20: Value demonstrations from developers as a source of information

Tip 21: Use self-generated maps to help organise your testing

Tip 22: Look for opportunities to generalise less relevant interactions

Tip 23: Offer to demonstrate the team’s software to your customer

Tip 24: Resist overlaying traditional testing processes onto a sprint

Tip 26: Describe tests using design techniques and a coverage target

Tip 27: Learn how to spot risky automation: an upside-down pyramid

Tip 28: Learn how to spot risky automation: infrequent execution

Tip 29: Learn how to spot risky automation: most runs “fail”

Tip 30: Consider visual ways of representing your tests

Tip 32: However you document your manual tests, don’t repeat yourself

Tip 33: Attend the daily stand-up to keep in sync with your team

Tip 34: Be prepared to occasionally trade testing early for technical debt

Tip 36: Invent a multi-dimensional scale to discuss documentation detail

Tip 38: Question the efficiency of representing each test separately

Tip 41: Test multiple stories together to uncover different perspectives

Tip 42: When you describe your tests, don’t just copy existing documents

Tip 43: Agree a simple means of visually tracking your testing

Tip 46: Use existing documents as a canvas for test ideas and bug reports

The tips below are currently being written and will be included in a future version of the book.

Tip 1: Appreciate that an agile tester never blindly follows a tip or practice

Tip 5: Don’t try to test so quickly that you slow yourself down

Tip 10: Ask questions, but if nobody knows the answer, research yourself

Tip 15: Look to automated tests for inspiration for manual test ideas

Tip 19: Learn how your software works under the covers

Tip 25: Consider using the gherkin notation to record manual tests

Tip 31: Use abstractions to help you plan, but don’t lose focus on reality

Tip 35: Build a support network of people that can aid your testing

Tip 37: Familiarise yourself with how agile teams organise “requirements”

Tip 39: Appreciate examples, even those that aren’t automated

Tip 40: Regularly remind people that testing is everyone’s responsibility

Tip 44: Encourage your team to automate their build and deployment

Tip 45: Agree a place for everything and keep everything in its place

Tip 47: Consider bringing many tests together into a single checklist

Tip 48: Try to avoid requesting unwanted features via the backdoor

Tip 49: TBC

Tip 50: “Live as if you were to die tomorrow, learn as if you were to live forever”

About the Author

Matt Archer
Matt Archer

Matt has dedicated his career to software testing, working as a consultant, trainer, writer, conference speaker and practitioner. He first worked as an agile tester in 2003 when he joined an Extreme Programming (XP) team that built software for the energy and petrochemical industry. Since then Matt has held testing positions at over 25 companies that span the retail, government, telecommunication, finance and media sectors. A passionate advocate for agile software development, Matt has helped manual testers adopt agile practices in teams as small as two, scaling to departments of hundreds.

Table of Contents

  • Introduction
    • Welcome to the review edition
    • Acknowledgements
    • Why a book of tips?
    • Why have you focused on manual testing? What about automation?
    • Why all the pictures and graphics?
  • Tips
    • Tip 1: Appreciate that an agile tester never blindly follows a tip or practice
    • Tip 2: Tailor your agile testing practices to meet your specific needs
    • Tip 3: Understand the risks associated with manual test scripts
    • Tip 4: When testing or preparing, don’t allow yourself to be blocked
    • Tip 5: Don’t try to test so quickly that you slow yourself down
    • Tip 6: Enrich your knowledge and expectations using multiple oracles
    • Tip 7: Favour dedicated learning resources to educate new testers
    • Tip 8: Before you document information, question who it is for
    • Tip 9: Help your team by undertaking work that isn’t testing
    • Tip 10: Ask questions, but if nobody knows the answer, research yourself
    • Tip 11: Follow an exploratory approach to your testing
    • Tip 12: Keep supporting information in a single place (not in your tests)
    • Tip 13: Set testing objectives that realistically align with regular releases
    • Tip 14: Be cautious of any sprint that is organised like a waterfall
    • Tip 15: Look to automated tests for inspiration for manual test ideas
    • Tip 16: Share common information with other members of the team
    • Tip 17: Use traditional testing tools in a way that makes you agile
    • Tip 18: Ask yourself what you can do to improve overall team performance
    • Tip 19: Learn how your software works under the covers
    • Tip 20: Value demonstrations from developers as a source of information
    • Tip 21: Use self-generated maps to help organise your testing
    • Tip 22: Look for opportunities to generalise less relevant interactions
    • Tip 23: Offer to demonstrate the team’s software to your customer
    • Tip 24: Resist overlaying traditional testing processes onto a sprint
    • Tip 25: Consider using the gherkin notation to record manual tests
    • Tip 26: Describe tests using design techniques and a coverage target
    • Tip 27: Learn how to spot risky automation: an upside-down pyramid
    • Tip 28: Learn how to spot risky automation: infrequent execution
    • Tip 29: Learn how to spot risky automation: most runs “fail”
    • Tip 30: Consider visual ways of representing your tests
    • Tip 31: Use abstractions to help you plan, but don’t lose focus on reality
    • Tip 32: However you document your manual tests, don’t repeat yourself
    • Tip 33: Attend the daily stand-up to keep in sync with your team
    • Tip 34: Be prepared to occasionally trade testing early for technical debt
    • Tip 35: Build a support network of people that can aid your testing
    • Tip 36: Invent a multi-dimensional scale to discuss documentation detail
    • Tip 37: Familiarise yourself with how agile teams organise “requirements”
    • Tip 38: Question the efficiency of representing each test separately
    • Tip 39: Appreciate examples, even those that aren’t automated
    • Tip 40: Regularly remind people that testing is everyone’s responsibility
    • Tip 41: Test multiple stories together to uncover different perspectives
    • Tip 42: When you describe your tests, don’t just copy existing documents
    • Tip 43: Agree a simple means of visually tracking your testing
    • Tip 44: Encourage your team to automate their build and deployment
    • Tip 45: Agree a place for everything and keep everything in its place
    • Tip 46: Use existing documents as a canvas for test ideas and bug reports
    • Tip 47: Consider bringing many tests together into a single checklist
    • Tip 48: Try to avoid requesting unwanted features via the backdoor
    • Tip 49: TBC… Get out of the building to meet real users ???
    • Tip 50: “Live as if you were to die tomorrow, learn as if you were to live forever”

The Leanpub 60 Day 100% Happiness Guarantee

Within 60 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.

Now, this is technically risky for us, since you'll have the book or course files either way. But we're so confident in our products and services, and in our authors and readers, that we're happy to offer a full money back guarantee for everything we sell.

You can only find out how good something is by trying it, and because of our 100% money back guarantee there's literally no risk to do so!

So, there's no reason not to click the Add to Cart button, is there?

See full terms...

80% Royalties. Earn $16 on a $20 book.

We pay 80% royalties. That's not a typo: you earn $16 on a $20 sale. If we sell 5000 non-refunded copies of your book or course for $20, you'll earn $80,000.

(Yes, some authors have already earned much more than that on Leanpub.)

In fact, authors have earnedover $13 millionwriting, publishing and selling on Leanpub.

Learn more about writing on Leanpub

Free Updates. DRM Free.

If you buy a Leanpub book, you get free updates for as long as the author updates the book! Many authors use Leanpub to publish their books in-progress, while they are writing them. All readers get free updates, regardless of when they bought the book or how much they paid (including free).

Most Leanpub books are available in PDF (for computers) and EPUB (for phones, tablets and Kindle). The formats that a book includes are shown at the top right corner of this page.

Finally, Leanpub books don't have any DRM copy-protection nonsense, so you can easily read them on any supported device.

Learn more about Leanpub's ebook formats and where to read them

Write and Publish on Leanpub

You can use Leanpub to easily write, publish and sell in-progress and completed ebooks and online courses!

Leanpub is a powerful platform for serious authors, combining a simple, elegant writing and publishing workflow with a store focused on selling in-progress ebooks.

Leanpub is a magical typewriter for authors: just write in plain text, and to publish your ebook, just click a button. (Or, if you are producing your ebook your own way, you can even upload your own PDF and/or EPUB files and then publish with one click!) It really is that easy.

Learn more about writing on Leanpub