Is there one special thing where experience might actually help?

Context: I think it is about some meta-thought I have.

There are times when I feel hopeless. and this happens to me whether it is about programming, testing, management, agility….

Maybe I’m wrong, but there are times when fragments of situations/thoughts/experiences show me quite clearly what is coming. And I can’t do anything to correct it even though what I want to do is very coherent with my thoughts, experience, and theories.

Thought

I suppose each of us can have his/her own take on this. 

My take, that never disappointed me till now, is that it helps to prepare myself mentally and emotionally for the bad things – that’s it, but not to solve them however. 

No one told me this when I started. I thought that by knowing things will be enough to apply the solutions, but it is not like this at all. 

You might say that with the experience applied solutions might come. But it is not quite like this. Because, it seems to me, Weinberg was right by saying that the definition of “quality” is always political, emotional and relative.(*) And I feel it so strongly.

It is very hard to combat a dominant position, usually a win will happen when a crisis comes, when the bubble will burst. 

At a very, very distant moment maybe is applying what is known to be ok in that situation, but in the background, so that the situation/project will not tear apart. Of course, it will never be known because two things usually happen in parallel: showing agreement with what and how it is wanted/fabulated and on the other hand making the things actually work. Of course, the dominant view will succeed, as always, and it will not be known that those informal things/work/connections happened in order to make it work in that situation.

(*) ‘Agile and the Definition of Quality’, Gerald Weinberg, https://secretsofconsulting.blogspot.com/2012/09/agile-and-definition-of-quality.html 

Testing Pyramid Problematics

I consider the Testing Pyramid a not so good way to use it for sizing up testing situations.

I say this because:

  • for each project the response of what can be a test strategy is the same: unit tests, component tests, integration tests and manual tests. But the problems, bugs, issues are contextual. It is like a medical doctor giving the same medicine to each patient, no matter the context.
  • automation can be used only for automatic verification of whether something is true or false. But automation in testing is much, much more.
  • it invites to a confusion of roles, which means a confusion of intentions. I speak here about the roles of the programmer and tester. The programmer wants to confirm and the tester tries to refute.
  • it constrains in an entrenched way regarding the dimensions to consider when testing the product. Important dimensions are ignored, like: product factors, quality criterias, multitude of coverages, product environments – and each of these dimensions have their own internal dimensions.
  • it does not invite explicitly to think about the risks that will guide the testing.
  • by having unit, integration and UI as the main components of that triangle/pyramid it is like considering that everything is known and that treating the known is enough.
  • it invites a false dichotomy of what a human can do and what automation can do, when actually it is a continuum of activities done by the human with the tools.

I kindly ask James Bach what else he might add to the list above. Here is what he added:

  • It treats GUI level testing as almost unnecessary, yet real users only experience the product through the GUI. It is wildly optimistic to presume that there are no important bugs to be found in fully integrated products.
  • It provides no actual guidance. What does it MEAN to have “a lot of unit level testing” compared to higher level testing? Counting tests is nonsensical. So how is this supposed to be measured? What are we actually supposed to do? Any specific guidance is certainly not based on any kind of science.
  • Sometimes it’s called the testing pyramid and sometimes the test automation pyramid. Which is it?

*Regarding the testing pyramid image I just used one of the simplest forms found out there. The testing pyramid concept was created by Mike Cohn

**James Bach proposed and alternative to the Test Pyramid way of thinking called Round Earth Test Strategy . I also wrote a post about it some time ago called Round Earth Test Strategy and earthquakes