The test of a first rate intelligence is the ability to hold two opposed ideas in the mind at the same time, and still retain the ability to function.
— F. Scott Fitzgerald
It was the best of times, it was the worst of times
– Charles Dickens: A Tale of Two Cities
As I recently said, I will be writing a series of articles here about agile software testing, focused around the theme of how to survive as a solo tester in an agile team. The idea is these articles which will eventually become a book titled Pride and Paradev (read this article if you don’t know what a paradev is).
I had been struggling to decide upon on a creative approach for this series/book when I recently had a epiphany in the shower (they can happen at the best of times).
Most software testing books are a verbose collection of best practices: what you should do as tester to be successful, sometimes in the form of lessons learned. I particularly dislike best practices, they’re black and white, and I prefer to see the world in shades of grey, a best practice in one context make no sense in another.
“The color of truth is gray.”
~ André Gide
Acknowledging this is easy, but writing articles in this doctrine isn’t. It’s much easier to write a best practice book as you can squarely sit on one side of the fence and write from there.
One approach to write a book about grey areas is to write things sufficiently nebulous/generalist that they could appear to work in different contexts. But not only is this hard, the outcome for the reader is weak and ineffective.
What I am proposing instead is “Pride and Pardev: a collection of software testing contradictions”, which, as the title states, will be a collection of contradictory statements, and supporting evidence, in regards to agile software testing. The added benefit of writing contradictions is no one can really argue with you, as you’re already arguing with yourself.
I haven’t done a lot of planning as yet, but here’s some examples of contractions that may feature as articles and in the final book:
- Generate test data for all your testing
- Use production data for all your testing
- Keep a record of bugs as they are found
- Don’t keep a record of bugs at all
- Test everything in IE
- Don’t test anything in IE
- Automate your acceptance tests
- Don’t automate your acceptance tests
- Your automated acceptance tests should be in the same language as your codebase
- Your automated acceptance tests can be in whatever language the testers want
- Testers should automate acceptance tests
- Developers should automate acceptance tests
- Test extensively before going to production
- Test most things after go-live in production
- Testers should write the acceptance criteria
- Testers shouldn’t write the acceptance criteria
- Involve real users in your testing
- Don’t involve real users in your testing
One of the key objectives is to keep things lightweight, that’s why I think the blog article format will nicely translate into a chapter in the final book. As Dr Seuss famously said: “So the writer who breeds, more words than he needs, is making a chore, for the reader who reads.”
I’m looking forward to writing the first article soon. I am also looking forward to the great feedback that I will receive before collating these into an eBook on Leanpub.
Please feel free to leave a comment below about what you’d like to see covered in a collection of agile software testing contradictions.