At the Agile Testing Days 2015 Marnix van den Ent gave a talk in which he explained how agile testers can signal and question the (testing) process. He views testers as a harlequin: "a servant to the team and its process, like the Italian Harlequin he is there to help to understand what is happening".
InfoQ interviewed Van den Ent about how testing can be seen as asking questions, what testers can do to develop an art of questioning, how an agile tester can signal and question processes and practices, XP practices that testers can adopt and use, and how testers can contribute in retrospectives.
InfoQ: You mentioned that testers question the product by testing; they are gifted in asking questions. Can you give some examples where testing can be seen as asking questions?
Van den Ent: In the testing quadrant Brian Marick distinguishes tests that support the team and tests that critique the product. One can see parallels with asking closed and open questions.
Well, exploratory testing is an excellent example where we test by posing open questions to the system under test. In some tests we don’t know the systems response - but we can determine whether the actual response is all right. What is the systems behavior? A test makes this question concrete, for a specific situation: How does the system react when the user logs on with a valid username and an invalid password after three or four times but closing his session in between and with long intervals between them?
InfoQ: What can testers do to develop an art of questioning that can help agile teams in delivering better products?
Van den Ent: This help may occur on two levels. First, when looking at ’how do we test the product’, there are several ways to go. What helps is to clarify what testing is about, is to learn about (the old school) of structured testing where testing activities and testing responsibilities are addressed in separate functions, separate phases and separate tasks and so on. This unraveling helps to clarify which things have to be addressed in testing. And it states somehow on _how_ you can or should do the tests. In the context driven testing school people investigate about the how to test, more than in any other school in the testing discipline. Here is where this ’art of questioning the product’ is educated.
Then, when we look at the other level of helping the team to deliver software: how can we help or improve their way of working? This is the area of the Scrum master or the agile coach if you like. Having said that, the assumption is around the corner that this responsibility is addressed by the people who are one of these roles and not by others. When performing the tests mentioned earlier you are confronted with the consequences of the choices made by the team in the development process. So, as a tester you see the disadvantages of these choices. When one learns to look at those and ask questions to himself and the team he can help to improve the process. This kind of questioning should address a rather broad area, and thus is difficult to pin down into a certain format. You can’t even say closed questions are bad because in certain situations you might need to provoke.
InfoQ: Can you elaborate how an agile tester can signal and question processes and practices that are used in teams and in the organization surrounding the teams?
Van den Ent: As mentioned before when performing the tests one can observe the situation. E.g. if the last tests of the most important user story (the on that should be developed as the first) can be performed only in the second half of the sprint then you have a hunch that the process isn’t that optimal. Given that the user story isn’t that big one can ask what choices were made; e.g. did the team agreed on working on several stories simultaneously; and for which reasons?
A different situation is where the (externally operating) product owner is convinced his telephone conversations with team members are good enough, so he visits the team only once a sprint. In that situation it turned out that the agreement between management and this product owner prevented the change of this situation - and that, maybe, strong personal convincing skills would have helped to change this after all.
InfoQ: Do you have some examples of XP practices that testers can adopt and use when working in agile team?
Van den Ent: I personally find extreme programming a great resource from which a tester may learn "new" practices useful for his team. In extreme programming, one of the practices is shared code ownership. The same holds for test stuff. There are many teams were the tester does his trick and he is completely trusted doing that. That is not good. Also testers in the team should be aware that sharing thoughts, the way of "designing" test cases and the tests themselves help to improve the quality and efficiency of those. Pairing and extensive reviewing are ways one can do that.
XP has also this value "simplicity". There are many situations where tests are simple to draw. But there are also many situations where the behavior tested depends on many parameters and their values, and combinations of those! Keeping tests simple is however key in communicating your tests with team members and key users.
InfoQ: Can you explain what in your opinion makes retrospectives so important in agile? How can testers contribute in retrospectives?
Van den Ent: First of all, I would like to thank you for asking this question! Learning is one of the key aspects of the agile way of working. No learning, no agility. Retrospectives are the standard means to reflect and improve your work as a team. You can often hear that retrospectives are experienced as just a boring obligatory ceremony. But then, you don’t learn. Keeping an open mind and keep asking questions in order to improve the process of the team, that will help the team to learn. Testers are gifted with the quality of asking questions. Testers should learn not to ask questions to the product only, but also to the team and "to" its process.