Usually, in sprint planning comes a moment when developers and testers have to give an estimation. After the tasks seem to be clear, the testers and developers give their corresponding story points. What seems strange to me was the fact that these estimations are calculated and a single number is created.
For me, this approach seems like comparing apples with pears and then generating a number.
I imagine a lot of agilists will say that this is working. I would say: maybe. What gave them the impression it works? Well, I saw that human nature is capable to cope with formal non-sense, so that, then, informally, make it work, one way or another. Why? Well, because, sometimes, a lot of energy is lost in convincing some people of some strange truths. Truths that are not in trend but for the moment might seem easier to cope with. Why? Well, because of laziness, fear, workload, or just because it’s safer….
For me, developers and testers worlds are very different. Yes, these worlds can intersect somehow, but they are still very different like two oceans uniting/meeting each other.
For a developer, when he/she knows what to solve and how to solve it, the task is easy, and the code is written. That code should behave in a deterministic manner. The developer might write unit tests and/or integration tests – from a tester perspective these are automated checks not tests(1). And when I say developer I am thinking of an XP developer, of a developer who should aim at what Uncle Bob says(2).
For a tester things are different. Although things might appear to be clear for the same story, we might deal with non-determinism. When I say tester I am thinking of a tester who is part( consciously or unconsciously) of Context Driven Testing(3) school, for example a Rapid Software tester(4). Testing actually poses a need for a very different skillset because the problems the tester encounters have a different nature, compared to the ones a developer faces. So even if a developer has modified just one line of code, a tester can spend days and days if she/he decides to make a deeper testing, and not just a shallow one. Why? Because the code is, usually, surrounded by a larger code context that might affect the stability of the product. But if is just one line of code, why would it take a lot of time? A small cause can have big effects. For example, does the developer know with great precision all the details, internal technical details of the code? A simple data type problem can cause one of the strangest and ugliest effects and it all starts from just one line of code.
Therefore, I think we should be careful what we do, and we shouldn’t be reluctant to raising questions, even if we might be wrong. I consider this approach of combining numbers that mean different things, a fallacy. For me, this is an oracle(5) to spot the problem and, why not, I have a name for it: Two oceans integration.
(1) James Bach, “Testing and Checking Refined“: http://www.satisfice.com/blog/archives/856
(2) Robert C. Martin, “The Programmer’s Oath”: http://blog.cleancoder.com/uncle-bob/2015/11/18/TheProgrammersOath.html
(3) Context Driven Testing: http://context-driven-testing.com
(4) Michael Bolton, “What Is A Tester?”: http://www.developsense.com/blog/2015/06/what-is-a-tester/
(5) Michael Bolton, “Oracles from the Inside Out, Part 1: Introduction”: http://www.developsense.com/blog/2015/09/oracles-from-the-inside-out/