As the whole talk is about 45 minutes long, I post series of the review in my blog.
Part 1 – Rationale for Refactoring
Points – Value – Problems
- It’s an open question: what are the roles and responsibilities of testers in agile development environments.
- Testers do something important, special, and different. You don’t get these skills automatically when learning to program.
- “Checking is the part of testing that can be completely automated. The rest of it cannot be automated and we call that testing”.
- The distinction is important to highlight the skilled intellectual part that cannot be outsourced to automation or unskilled labour.
- “Testing is just pushing keys in the same way as programming is just pushing keys.”
- “Agile Testing Quadrants” misrepresent testing
- Marick’s version misses concept of critical distance.
- Crispin/Gregory version implies that critique is not supporting the work of programming.
- This helps perpetuate the ignorant attitude that testers don’t belong in Agile unless they write code.
- Both versions confuse output checking (completely automatable) with testing (which is a live thought process, not automatable).
- Crispin/Gregory version makes confusing and unnecessary distinctions about testing “done manually” and testing “done by tools”.
- The core heuristic of Agile
- Continually re-focus on value (in order to produce value) and ply our craft in ways that reduce the cost of change (rather than deny change).
- More problems with the original quadrants
- “Facings” are beside the point. It’s all about business and for business.
- “Technology-facing” simply means doing things that help us build with change in mind.
- Reification Fallacies
- “Test cases are testing”
- “Examples are tests”
- “Testing can be encoded”
- “Business people can “read the tests”
- Particular problem of Crispin/Gregory version
- “Critiquing the Product” was put opposite to “Supporting the Team”.
Comment – Argue – Acknowledge
- I can very much relate to the “open question” – not only roles and responsibilities of testers not understood in agile development environment, the whole agile thing is often much misunderstood and misimplemented. But, there are agile product management and agile development coaches in abundance, a very few true agile testing coaches. Notably, Agile Manifesto has principles like “continuous attention to technical excellence..” and “build projects around motivated individuals. Give them the environment and support they need” – so skilled testing MUST be welcomed and MUST be supported by the very own Agile guidelines.
- Back in the university, I had a lot of technical courses and programming disciplines. There were no specific testing disciplines though, we were all software engineers taught to investigate problems in the context, invent solutions, but also to criticize and find risks. I also had a breadth of disciplines like physics, biology, chemistry, sociology, philosophy, and, of course, crazy lot of math and math analysis. I suspect it’s that breadth of angles and crazy “mind-stretching” is what made me an avid self-learner and, eventually, helped to become an exceptional tester. Programming was important, too. Knowing programming and technical architectures is a sort of domain knowledge for software testing engineers. But it’s the abilities to see systems, to analyze information critically, to model, and to experiment scientifically is what constitutes core testing skills.
- When I first saw “Agile Testing Quadrants” model I haven’t got any insights. The picture looked simple and useless. I suppose, it can be used to confuse some business people to let them do your stuff the way you want.
But I have to admit – when Michael Bolton showed me the prototype, as it looks at the end of this talk, – I was confused, too. The model was very logical and rich, but I was concerned that it’s even more confusing to use it to “sell” testing to business and managers.
Unexpectedly, Michael told me: “We didn’t create it for managers. We created it for testers and testing leaders passionate about the craft. We created it for people like you”. And so we dived into discussion of the model.
But now, with James Bach’s talk and step by step walkthrough, it makes so much sense to use this model in discussions with business and management! The model turned around simple to explain while being rich in meaning.
- One of the study projects I’ve been long pondering about is studying of the fallacies. Not just reading or memorizing the definitions. Learning what they really mean, how to recognize one, how to discuss the problematics of it with people, and, of course, how to practically apply it in testing.
Now, seeing how elegantly James Bach used that knowledge urges me to put this project in my queue.
- “Critiquing the Product” being put opposite to “Supporting the Team” doesn’t surprise me. Unfortunately, I’ve been a witness to accusations that testers are bad team players for opening all these bugs that make developers looking bad. Furthermore, accusations that the project has been delayed because of testers finding too many bugs, and bonuses being cut for the same.