Agile Testing Days 2013: Agile Testing is nonsense, because Agile is testing…
The Agile Testing Days has definitely been an experience for me. I wasn't sure what type of people I would have met at such supposedly very "vertical" and specific conference, focusing on testing in the Agile world. It's definitely one of a kind, and I was positively surprised about the amount of people who are actually getting closer to Agile through the testing experience.
The quality of the speakers has been very high, I have attended almost all of the keynotes, and were all very well followed, and engaging too. I have learned that there are still a lot of people calling themselves tester, who are clearly willing to part themselves from the "developers", which I find particularly strange in an Agile environment. Shouldn't it be all about the team? Shouldn't the team be a peer to peer team, with no hierarchy and no roles? Developing a product in Agile means making it shippable at every iteration, and that requires all the skills needed to make it happen! Which ones? It depends on the context… every product is different, and requires different skills and people to be developed.
I have met a lot of people and I have also rejoiced with some old acquaintances that I helped starting the journey toward Agile in 2009… and now they had quite some stories to tell, great! Overall it seemed a very well organized event, with fun in the evening, the right mixture of talks, workshops and also Open Space. One thing I would definitely change if I were one of the organizers, would be to cut the talk length to 45m maximum, so there would be more talks, and probably some would be more focused, I include myself in the category.
My opening keynote writeup in some way…
How it all started
It all started about a year ago, when I was asked to prepare a keynote for the Agile Testing Days, after having presented at the Agile Dev Practices in the same year. I was pleased to be asked to have the opening keynote, and on the other side also a bit puzzled, as I am no testing expert, as many of you may have noticed. I have been developing software for a very long time, and I still do it for fun, but now my main focus is on an overall organizational perspective, and definitely a mixture of Agile, System and Professional coaching (who doesn't after all).
Still I am pretty much involved in supporting teams, and I can still teach ATDD, BDD and TDD to pretty much any programming language (well it is not about the language after all). So I had to think about what should I talk about, for 1h, one year ahead of time? How agile is that? Then I thought, maybe I should ask what sort of keynote were they expecting from me, considering that a keynote should maybe open a lot of doors to more specific and vertical talks, I was still unsure about the focus.
At the end it went a bit on the provocative side, well you can't really argue that testing isn't needed, or is a waste (as someone likes to say, and with whom I disagree). Testing is one of the activities required to create a product (software or not, doesn't really make a difference), and it is not just about the compliance of what has been done with the expectations, but is about creating confidence in the team developing the product, that they are pursuing the right objectives, that what they are building is going in the right direction. Still some people tried to convince me that their job as tester is to find defects, which are a sort of trophy, a demonstration that they have been able to break the product (or even more explicitly the work those "others" developers did).
Why? As far as discovering things which do not behave as expected, or even discovering new things that nobody had thought about, testing is a discipline which helps a team refining its targets, and learning. Once it becomes a self-fulfilling prophecy, it looses pretty much its purpose and also introduces various dysfunctions. One of these, is the one I have exposed in my keynote as the "Show me the money!" dysfunction. If you are Agile, you know what I am talking about probably, such behavior is resulting from a fundamental distrust in the team and in what the team is doing. If there is no trust, then there is no Agile, but trust needs to be gained, it is not something we can "expect" as a precondition (sounds like testing a bit). And here is where I wanted to emphasize that being Agile requires to develop a certain mindset, which in particular is reinforcing the attitude to trust results based on the fact that we can validate them.
Testing as an attitude
This might seems natural to many, but if you have been in enough messed projects in your career, you probably will remember at least one time, in which people didn't know exactly why they were doing what they were doing. And this is where the Agile mindset, strongly focused on results and goals, and allowing individuals to commit to achieve a goal, by allowing them to pull the work from a list of defined objectives (normally called backlog).
People start thinking about how would they know when they will be done, before starting to do anything. This attitude is required especially when working in complex contexts, where often isn't clear what is the end results you are trying to achieve, or even it is a set of options and you need to understand if you are moving within the expected range. To strengthen the attitude, you need to practice, but before you can practice effectively, you need to try some approaches and understand what works and what doesn't.
Testing as an approach
So let's think at testing as an approach to experiment different ways in which a problem could be solved. If you think this is reflected in any sounding Agile thing you might be doing already since quite some time, you want to know what are the "Acceptance Criteria" of a User Story before committing to do any work on it. And once you have it in your hands, the first thing you start doing, in order to focus, is to identify what are the possible acceptance tests that you can derive from those agreed "Acceptance Criteria".
Good teams at this point are already looking into automating, to be sure they are not wasting time in doing the wrong things, and to make sure there is a safety net, which will remind them to refocus on the goal of that story. As you may know it is all about shorting feedback loops, and the most valuable ones are the one you can shorten through the conversations with the Product Owner and the stakeholders, while defining what to test and how to test. Agile people do all possible things to visualize anything, because by visualizing, conversation can be more structured, and focused. This is a great approach too. Now the practices come into place, testing is full of practices.
Dan North (@tastapod) pointed out in his keynote, that there are at least 120 different testing practices that he was able to count in his experience, and decided to categorize in four quadrants (how comes are always four…) based on two dimensions: deterministic towards "random", and manual towards automated (you can read more about this in his keynote Accelerating Agile Testing). Practices are useless if they aren't supportive of the approach you are willing to adopt. Many people just adopt practices, such as TDD, because someone told them they are good, and they do not really think about the value nor the economical impact of doing TDD. Maybe they will eventually end up stopping doing it, because they won't see any benefit (just another cool practice isn't it?). Well, if more people would understand that TDD is about design of the software, and not testing.
Testing as a practice
This is exactly the approach that I was trying to highlight in my keynote, by explaining that Agile people might decide to approach the solution of a complex problem, by defining a set of tests which a possible solution should be able to successfully pass. This approach - writing tests first - is a well known principle of eXtreme Programming, and it is embedded with very fast feedback loops into the TDD practice.
So TDD is not about writing automated tests (that's the output) but is about discovering the solution to a complex problem, by means of limiting the solution space through the definition of tests, which the solution has to fulfill. This leads to a more clean and focused design of the software, aiming at solving the "problem" and happens much faster (this is the outcome), than if you would sit and think at the solution from the inside out.
Finally I have made some back references to System Thinking and the Theory of Constraints, to highlight the importance of the behavior that a particular system is producing. I have presented as an example the behavior a push system is producing: focused on individual, competition, and compliance, while a pull system is normally producing a behavior focused on team, collaboration and value (as outcome). So if you really have complex problems to solve, you need people who can work in the most creative, safe-to-fail environment possible. This will require discipline, will require courage, and commitment, all of which is based on transparency, respect and trust.
With this in mind, invest in building great teams, and lead by example, coaching them developing the right attitude toward Agile. After a while, and some failed approaches, they will eventually find out practices which are supportive of their intentions, and will become more productive over time. Also don't think you can sit on a bench and enjoy the ride, because the Agile mindset is rooted on continuous improvement, and that means, your bench will change shape, and move… probably every couple of weeks :-)