I remember a day that the Scrum Master told me a complain: “why, QA guys are all the time thinking in the demo meeting?”
The question came to me after the “stand up” meeting on Thersday, one day before of the end of the iteration. I also remember the face with a extrange grimace of no aproval.
At the very begining I was surprised, I had not understood the question or why he did that question. Finally, he explained that he was expecting me I offer my help to those who were stuck with the pending testing.
That it makes a lot of sense. I replicated. But remember that in my case, for the product I tested no other responsible will show our results and it’s not so easy to gather all the items to go straight to the relevant things during the demo. Nobody wants that a mistake happen because lack of concepts or wrong dataset in the acceptance testing.
You know, a bad presentation is a kind of failure in the worst moment.
So, what I learned from this very very important coment from my Scrum Master is:
- it’s true, QA guy are allways focused in demonstrations and at least for me, this is the main reason, other team involved should discusse face-to-face with the QA guy about the Expected results.
- a real QA guy it’s more than just a tester who accomplish with test cases execution. He/she is a professional on strategical thinking and his/her goal is more than checking expected results but helping the rest of the team to reach the general goal (big Y) via the particular actions (the xs)
- is possible that an iteration fails for lack of testing, but we can not allow our iteration fail due to poor exposure of our work. Everything is in doubt if our show is poorly done, our capacity for coding and testing, but even worse, our ability to understand and manage the problems.
- In any case, if we don’t finish the iteration as expected because the not enough time to test, at this moment we have the evidence that the way we estimate should be adjusted in order to get time to test all the user story committed.
- all people of the development team should look into the activities of others involved, not just the names of the activities but that they are. Thereby avoid wrong assumptions and expectations