Book Review: Pride and Paradev

As I have been looking through and wanting to dig out of my deep hole of collected and unread book titles, I also wanted to look at and give attention to books that I have that are a little less common or advertised.

I completely support the model of self-publishing and services like LeanPub and Lulu, and the opportunities it gives to those in the field to publish their ideas without having to wait for a formal publisher to put it out. Additionally, I wanted to start having a give and take between books that are recent (like my review for “More Agile Testing”) and titles I’ve had for a year and more and haven’t yet reviewed. To that end, I am excited to give some time and attention today to Alister Scott’s "Pride and Paradev”.

“Pride and Paradev” is a short e-book, clocking in at just under 100 pages, yet it is probably the most concise and specific “what” book yet written about Agile testing and the contradictions that exist. In fact, the book’s subtitle is “A collection of agile software testing contradictions". Every question that is posed is answered with a yes and a no, a should and a shouldn’t, with clear explanations as to why both make sense in given contexts.

Alister is the author of the WatirMelon blog, and all of these contradictions are explored there. Wait, if that’s the case, then why should we go and get this book? Lots of reasons, really. For starters, they are all gathered together in one place, which makes it convenient. It can also be loaded onto your favorite reading device, or downloaded to your computer, and used offline as you see fit. Also, 10% of the proceeds from the sales of the e-book go towards helping homeless in Australia, which I think is a perfectly awesome goal :).


Back to the book, and specifically the title, Alister states that a “paradev” is anyone on a software team that doesn't just do programming. That definitely includes software testers. As he pointed out in the introduction of the book:

“…some quick etymology […] para is also used to indicate “beyond, past, by” (think paradox: which translates to "beyond belief" ). This same reasoning translates paradev into "beyond dev" or "past dev". […] paradevs are the people on the team that don’t box themselves into a narrow definition, happy to be flexible, and actually are happy to work on different things.”

The contradictions that Alister focuses on in the book are as follows:

• Do agile teams even need a software tester?
• Do agile software testers need technical skills?
• Are software testers the gatekeepers or guardians of quality?
• Should agile testers fix the bugs they find?
• Should testers write the acceptance criteria?
• Is software testing a good career choice?
• Is it beneficial to attend software testing conferences? 
• Should testers get a testing certification?
• Should acceptance criteria be implicit or explicit?
• Should your acceptance criteria be specified as Given/When/Then or checklists? 
• Are physical or virtual story walls better?
• Which is better: manual or automated testing?
• Can we just test it in production?
• What type of test environment should we test in?
• Should you use test controllers for testing?
• Should you use production data or generate test data for testing?
• Should you test in old versions of Internet Explorer?
• Should you use a tool to track bugs?
• Should you raise trivial bugs?
• Should you involve real users in testing?
• Do you need an automated acceptance testing framework?
• Who should write your automated acceptance tests?
• What language should you use for your automated acceptance tests?
• Should you use the Given/When/Then format to specify automated acceptance tests?
• Should your element selectors be text or value based? 

Each of these questions are bolstered with quotes from programmers, testers, writers, celebrities, politicians, philosophers, and others to help make the case for each of the points where appropriate (and yes, it adds a dose of fun to the sections).

The book ends with three non-contradictions, which sum up the rest of the book pretty handily:

• You can only grow by changing your mind.
• Everything is contextual.
• You can always choose your reaction.

Bottom Line: Testing is often more than just testing. It involves many disciplines, and in that way, testers go beyond just the programming of software. If you chafe at the title of “tester” and feel in the mood to provoke some interesting conversations, start referring to yourself as a “paradev” and see where the conversations go. If you do that, I would highly recommend getting this book and reading through its contradictions, and decide when and where the contradictions are those you should heed or ignore, do or do not. It’s ultimately up to you. As for me and my testers, including my daughter, I’m going to encourage discussions around being a “paradev”, and I’m going to use this book to do exactly that.