preload

Dialectical Materialism in Testing

Posted by Albert Gareev on Oct 05, 2015 | Categories: HeuristicsNotes

Dialectical materialism is a philosophy of science and nature, based on the writings of Karl Marx and Friedrich Engels.

Wikipedia

Dialectic (also dialectics and the dialectical method), from Ancient Greek διαλεκτική, is a method of argument for resolving disagreement that has been central to European and Indian philosophy since antiquity. The word dialectic originated in ancient Greece, and was made popular by Plato in the Socratic dialogues. The dialectical method is discourse between two or more people holding different points of view about a subject, who wish to establish the truth of the matter guided by reasoned arguments.

Wikipedia

Crazy?

What?? Theories that inspired communism? Ancient philosophy? Are you crazy? – I almost hear this. But bear with me. This might be worthwhile to learn about.

The Three Laws of Dialectical Materialism come as

  • The Law of Unity and Struggle of Opposites
  • The Law of Transformation of Quantitative Changes Into Qualitative Change
  • The Law of Negation of the Negation (“Thesis – Antithesis – Synthesis”)

Unity and Struggle of Opposites

This concept is not new. It goes back to Yin and Yang. I once blogged on Testing vs. Checking subject with a reference to this (note that my views have evolved since then but the Yin/Yang analogy is still valid).

Human exploration always precedes creation of a step-by-step script for checking. Once created, the checking script may replace this particular exploration. To some extent, if executed by humans, to full extent, if executed as a program. However, with proper automation approach, execution of those scripts frees up human time for more exploration, in the new and risky areas, where scripted checking is ineffective.

Skills and experience allow for strategic and tactical utilization of both checking and exploration for the best effectiveness and efficiency of testing in the given context.

Transformation of Quantitative Changes Into Qualitative Change

This concept describes ongoing evolution.

Change of quality usually doesn’t happen instantly but appears so. While quantitative changes go through intermediate stages they gradually produce a qualitative change. Water, being chilled, at first only becomes colder with all other characteristics remaining. But when the temperature reaches zero, crystallization suddenly starts, and the liquid turns into solid matter.

The nature of change and conditions of transformation depend on the acting force (actually, superposition of all forces in effect) and time. Even small force may produce qualitative change if applied long enough.

We can see this Law through many examples in software testing process. My favorite example is paralysis of testing progress caused by quality degradation loop.

It occurs in the following conditions. A number of defects gets discovered during development of new features. In the following days programmers divide their time between fixing of the defects and developing new features. Testers, accordingly, spend less time testing the new features because they need to retest the fixes and perform regression testing. While doing so, they discover not only bugs in the new code, but some problems with the existing features. Programmers have to spend even less time developing new features and being in a rush they make even more mistakes. Testers have to spend even more time retesting the fixes and doing regression testing. They also notice that previously fixed bugs sometimes reappear so they have to check all fixes which takes even more time. Eventually, development of new features stops – or continues only because more and more bug fixes are rejected – an arbitrary lowering of quality bar.

I observed such scenario happening to some extent, from inconvenient to disastrous, quite a few times.

What we, as testers, can do being aware of this Law?

First of all, have a line of sight. Don’t treat any task or bit of information in isolation. Put pieces together. Have a journal and regularly take notes on the project, process, and daily events. Review the journal from time to time, and discover new information. And report everything that threatens project and product.

Negation of the Negation

Negation of the Negation, also referred as “Thesis – Antithesis – Synthesis”, describes evolution spiral. People say: “history repeats itself”. But it’s never exact repetition. As people learn or context changes (or both!) things are repeated in the new level.

In Testing, we begin with acquisition of some idea, a basic information, a claim, a thesis. We accept it as a starting point. Then we begin questioning. We analyze, we dissect, we discover new angles, we find inconsistencies. Our questioning forms antithesis. We keep acquiring the information from various sources, through our inference, and practical experiment. We fill the gaps.

Finally, we develop our own mental model. And this is the synthesis.

It is crucial to be conscious about thesis-antithesis relationship. Good testing is impossible without skilled pro-active questioning. We may be passive with the initial information intake, but then we must confront the gaps and inconsistencies, gain information through experiment and observation, identify and bring up any concerns.

Next time planning your testing, ask yourself, is it only based on the thesis?


  • 2 responses to "Dialectical Materialism in Testing"

  • Conrad Braam
    6th October 2015 at 8:53

    Excellent. it’s uncommon to hear anyone talk openly about the pain experienced when testers are discovering so many bugs that they go into paralysis. I hope I’m reflecting your intention here Albert:
    This paralysis or stalling happens not only for developers, who start finding new issues in the related code, but testers scripting these tests suddenly find new cases. STOP…
    If we all stop and use this “event” as a marker that we uncovered a new area that maybe needed more testing, but remember the antithesis. The product was good enough to ship last week (you are using agile process, right?), just because we uncovered a new rat-hole, lets not go down it, but keep the end-goal in sight and come back to this later, but only when the agile process tells us to cover this feature again. Simply make a note in your test-script, that’s part of the exploring process to make notes as you go.
    Now if only I could remember to do as I say. :-)

    [ Albert’s reply.
    Hi, Conrad! Thanks for your witty comment.
    I actually saw this stalling effect both in Waterfall and Agile projects.
    You’re right! Feature expansion wave in Agile often coincides with bug infestation. I saw some successes in mixing in at least one hardening sprint (bug fixing / no new stories) when bug counts reach certain level. And having 2-3 hardenings before going live.
    But it’s not always in our hands so we can only keep trying by providing the information about threats to the product and the project..
    Thanks! ]

  • Conrad Braam
    7th October 2015 at 8:22

    I like to write blog comments to ensure I am learning new things, and that I understood the writer, (you Albert).

    Makes real sense to have a “bugfixes only” sprint whenever it looks like a wave is hitting the team. In waterfall we did this by having a special release to fix only bugs, which even in agile model is often out of our hands. But the tester is not a monkey and needs to keep conveying not just raw test results, but also interpret the risks clearly.
    This change in mindset from test-monkey to risk assessment is still new to me Albert, but has been a good thing to remember.

    [ Albert’s reply: Conrad – thanks for the follow up and sharing! ]

Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported
This work by Albert Gareev is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported.