A paradev is defined as “anyone on a software team that doesn’t just do programming.” In his book “Pride and Paradev”, Alister Scott discusses a lot of the trade-off and issues met by software testers in an Agile software development project. As the world is not black or white, he decided to write a collection of contradictory claims about software testing; knowing that the practical implications lie somewhere in between.
After starting with a short presentation of Agile, the book covers many aspects of the Agile testing practices. It discusses questions like “Do agile teams even need a software tester?” or “Do agile software testers need technical skills?”, presenting always both sides of the coin in a fairly neutral approach but with the experience that the author has gained in the trenches. This short (70 pages) book is very easy and enjoyable to read. The author has inserted in his book interesting quotes that you might be tempted to reuse later.
This book shows you some of the many shades of gray related to Agile Testing with a practical and experienced point of view. I will recommend it to every Agile tester, but every software tester or Agile developer will also benefit from reading it.
Reference: “Pride and Paradev – A collection of agile software testing contradictions”, Alister Scott, http://leanpub.com/pride-and-paradev
Quotes
Best practices are often sold, particularly by consultants, as silver bullets. I have particular disdain for best practices, they’re not contextual and too black and white for me. I tend to see the world in shades of gray, a best practice in one context makes no sense in another.
Most agile teams and product companies sooner or later realize they need a software tester. Software testers provide a unique questioning perspective which is critical to finding problems before go-live. Even with solid automated testing in place: nothing can replicate the human eye and human judgment. I’ve noticed that a lot of organizations that typically didn’t have any software testers have started to hire or dedicate staff as testers as they begun to see the benefits of testers, or have starting feeling the pain of their absence.
You’ll often be tempted to do a quick bug fix when you know why something is broken, but you should avoid it. If you quickly fix it, the programmer who created the bug doesn’t get the feedback that they made a mistake, and will repeat the same mistake over again. Over time, if the programmers know that you’ll fix bugs, they’ll naturally start providing you with buggier code as they know that you’ll just fix it as needed. Programmers crave feedback, both positive and negative, that’s why it’s good having a tester on an agile team. But fixing bugs yourself means there’s less feedback being given, and less communication happening.
You should always test your user stories in an integrated test environment: that is, an environment that is centrally managed and integrated with other systems. One reason is that when you’re testing; you’re not only testing your application, but that your application can be deployed and work in a dedicated environment. This means you’ll find issues that don’t appear locally – like forgetting to include a file to be deployed, which will not show when testing locally.