These days I am participating, as a Peer Advisor, at the Online Rapid Software Testing Explored class with James Bach.
I had an interesting experience that made me think and articulate more carefully about a certain subject. I say this because although we might know we have the answer to some questions we usually see just a part of a situation and sometimes we might forget (not consider) more clearly the context(s) for which the answer might apply. But there is more. Is about the context(s) of the one who poses the question, the context(s) of the ones who might participate in the conversation and the context(s) that influenced my answer.
The example described below helped me realize this and adapt my message.
At a certain moment, the topic of testers and unit checks[tests] and whether testers should be involved or do them, popped up. I gave a response. Afterwards somebody in the class thought that I was saying that testers should never touch the product on a unit level. Then another student in the class asked if a tester could do pair programming with a programmer, when the programmer was doing the unit checks[tests].
I am glad that those two students stepped in and made me aware of their contexts.
At that moment I realized that my message was not accompanied with all the premises I had in my head and the realities that affected my response.
I say premises because of a blog post, written by Michael Bolton, where he says that: “Most arguments seem to be about conclusions, when they’re really about premises” (1)
So here are premises that I had in my mind:
- unit checking[testing] with mutation checking[testing] AND TDD are techniques that the programmer uses to take care of the semantic stability of the code. (2)
- it is helpful for testers to have interactional expertise, as Harry Collins intends it, when it is about code. Allways a session of pair programming or a code review done with a tester is something that is special. Special in the sense that the programmer feels very well that is something else. Is like the tester without wanting it, it triggers some tacit aspects in programmers mind regarding code, that usually with another programmer does not necessarily happen.
- me witnessing and discussing with testers, often, that they are being forced to do unit tests[checks] and selenium via UI. Testers which have no programming background and for which the message is that if they don’t do these, they are out.
- for me testing is this one that James Bach is teaching, the RST (more broadly I am thinking about Context Driven Testing where we have the RST, BBST, JIT, Buccaneer Testing)
- I have been a programmer for 19 years already. It was hard, but at this point I can say that I no longer make any confusion between testing and checking (3). And also, I am very aware of how management might misuse, abuse, play these disciplines, not in a naturalistic way of how things should fit, if may I say so.
- I deeply appreciate and encourage when both programmers and testers try to find out about each other’s nature of work. And I say this because of several reasons: empathy, helping in sensing and navigating the complexity of the product needed to be done, helping with test ideas the tester.
- context is everything, I have no doubt. And when I say this, I am fully aware about the cognitive patterns activations which are triggered by the situational context. (4)
- knowing the origin of a theory, principle, … is good because when making deviations from it, we will know why it might work or not work. For example, we have been doing at industry level OOP wrong, I believe, for the past 40 years now (5). We have just taken some principles/techniques out and popularized them without understanding the whole thing as it should be, and we wonder why it does not work.
- the importance of identity/role and how in the IT industry we try to smash these and use in reckless ways just some techniques.
- testing is an intellectual discipline because in RST we say that testing is applied epistemology.
- a tester is or should be closer to the people using, in the end, the application.
So, should a tester do TDD or unit checks[tests]? And I realized that it depends also on what it means by ‘do’. Does ‘do’ mean:
- being forced by a polluted context where the real testing has no chance of being done and the tester otherwise might get fired.
- because the tester wants to learn what it means for a programmer to do it.
- because the tester wants to learn programming in this way.
- because the tester thinks it’s his/her responsibility.
- because the tester is also a programmer and switching context might be needed (Side note: Very often I find myself in this situation. But I am fully aware about the programming and testing disciplines and their particularities, intentions, goals…).
- because the tester wants to help, she/he loves so much the context that will do whatever it takes to help.
I have answered initially in the class by considering just one interpretation of ‘do’. Mea maxima culpa. But I did it because I am deeply affected by the realities I am witnessing. Realities which try to reduce testing from a discipline to just some techniques which can be fully automated, if I may say so. And as a programmer I know that I need a complement that will not confirm and follow my biases but will really complement my actions/work/ideas.
(1) Testing, Checking, and Changing the Language. James Bach, Michael Bolton. http://www.developsense.com/blog/2009/09/testing-checking-and-changing-language/
(2) Robert C. Martin. https://cleancoders.com/
(3) Testing and Checking Refined. James Bach, Michael Bolton. https://www.satisfice.com/blog/archives/856
(4) The Context–Object–Manipulation Triad: Cross Talk during Action Perception Revealed by fMRI. Journal of Cognitive Neuroscience. Wurm, M., Cramon, D., & Schubotz, R. (2012), 24, 1548-1559. https://doi.org/10.1162/jocn_a_00232
Implicitly activated memories are associated to general context cues. Memory & Cognition. Nelson, D., Goodmon, L., & Akirmak, U. (2007), 35, 1878-1891. https://doi.org/10.3758/BF03192922
(5) When I think about OOP, I have in my mind the work of Trygve Reenskaug and James Coplien regarding OOP: https://fulloo.info/