Rahul Verma: My Petty Bits

A (Rather Long) Digression

It’s human nature to simplify and categorise. Whatever one is not able to simplify, one ignores it or is reluctant towards learning it. It’s almost a fashion to talk about simplicity – rarely one hears about complexity as complexity. Whatever one is not able to categorise and label, confuses him/her – how does one refer to something without a name? Both of these have value in human understanding. Both of these are also thought cages.

I’ve tried tackling simplicity. Simplicity is complex. As a recent example, I had two talks in a single conference of the same duration on the subject of test automation. In one of them I presented on 7 concepts related to design of data in automation. A general feeling was that it was too much for a talk. I presented the second talk on a single concept – waits. A general feeling was that it was too deep for a talk. It made me wonder what is complex or deep. In the past, I have tried talks with sarcasm, they were a big hit. But at their core what did they deliver? Made me famous, yes. What did the audience really gain? Is breaking dogma or relating personal stories the only successful “formula” to a talk or discussion? I see the same pattern in responses to my short posts which are often simple or sarcastic vs Embracing Infinity series (which in my opinion is my best work in 20 years).

In the same conference, I had a keynote, for which I was primarily invited. The above two talks were me filling for a speaker who didn’t make it. At the time I was in an already puzzled state – is it important for a speaker to be an entertainer even if it means delivering almost no core value in a talk? It had such an impact on me that I decided to let go of my originally submitted idea – The Last Keynote on Software Testing and presented an on-the-spot talk without slides as The Last Keynote. It covered random themes and I ended up talking mostly about happiness, childhood and life. There were those who cried (literally) because the talk moved them. There were those who started avoiding me. There were still others who thought it was all planned, how can someone present a 45 minute talk on the fly. And then others who missed the slide-deck and thought I was insensitive towards people with disabilities.

All of them were right I guess in their own way. That does not make me wrong.

In my own opinion it was the most honest talk I have ever delivered. I’ve stopped presenting talks after that, for the time being, till I make sense of talks being a medium of communication for me. I only take multi-day workshops as they provide me decent time to convey what I want to convey.

That’s a long background story 🙂 to tell you why I have decided to almost ditch simplicity in this series. I will of course not make it deliberately complex. I will try to make it as simple as it makes sense without losing the core meaning of what I want to write. But that’s the line. I’ve made peace with what I have to say as more important than how I have to say it. I don’t want to spend 10 hours in shaping up what I can write in less than an hour like this article. Simplicity has a cost. For this series, I am not ready to pay this cost, I’d rather write 10 articles to cover more concepts. I’ve had enough of changing my ways because of feedback. I’ve never felt so peaceful. In short, please bear with me as my thoughts unfold :-).

That was about simplicity. Categorisation and labels form most part of the content that follows here.

Uncaging

I’ve been talking about it for many years. In the initial phase, I used to call it anti-boxing as seen in the following title slide from some time in or before 2011:

At the time, I used to talk about mostly humans uncaging themselves from different boxes. Later, it became more generic and that’s what this article is about. This thought is at the core of my style of thinking and has hugely benefitted me.

Let’s start with a basic example. I was tempted to start with an analogy or an example from non-testing world to show you the meaning of uncaging. But then I rejected the idea. Let me give you a concrete example from our field of work itself:

• A Cause-Effect graph is a graphical representation that tells as about the causes and their logical relationships with respect to the effects. On its own or preferably as converted to a Decision Table (a reduction of full truth table of conditions), it is used to come up test cases.
• Decision Coverage/Condition Coverage/Modified Condition Decision Coverage/Elementary Comparison Testing are used in white box testing to cover decisions, included conditions and decision-to-decision paths.
• Root Cause Analysis is often used by managers to identify the possible root cause(s) of the problems e.g. failures in production, beyond the tech problems in the test object itself.
• Debugging is done by developers to find the cause of a problem. Experienced developers do much more than using the IDE.
• Threat Tree is a concept from security to visually depict the logical relationships between different types of vulnerabilities which can make a specific threat a reality (e.g. Credit card data theft).
• More?

Give yourself a moment and think. You will quickly find a lot of information overlap.

Why is cause effect graph/decision table taught to you as a black box testing technique? That’s a cage.

What is the difference between Cause Effect Graph, RCA and Threat trees? Theme? Direction?

What is the difference between the thought behind debugging and Root cause analysis? IDE? Technology?

What makes Elementary Comparison Testing a white box testing technique? Code?

Think.

The Perpetual Translation Engine

If you are working in automotive domain and are a tester, you would have realised how little testing world talks about things relevant to you. So, will you wait for that automative testing conference to happen? That magazine which will hardly exist? Or feed on extremely infrequent and often hardly useful content spread here and there? Or you decide to uncage yourself? And the techniques and the methods? You decide to translate.

Are you a black box tester thinking that you don’t know about white box testing? Is it because you have been told that the formal test design techniques that you have learnt are black box testing techniques? Or you decide to reinterpret them? Uncage them? Translate them?

If you are a security tester, do you realise how much value you can get from other fields of testing? Do you realise that the maturest defect taxonomies are created by the security world and in the other places, it is more or less a theoretical concept with sporadic limited examples? Do you realise how much you can help your peers with the translation? If you are a non-security tester, will you wait for someone to do this uncaging for you? Or do you decide to translate?

This translation engine needs to be perpetual. You will find a lot of testers talking about how to learn testing from doctors, music, weight loss journeys and so on. There is value in that of course. That’s also uncaging and translation. However, I often wonder how little we do when it comes to uncaging and translating the things which are in our closest reach.

The Deltas – 𝛿

Consider A and B. You are translating a concept from A for its usage in B.

1. Some stuff in the concept belongs only to A.
2. Some stuff is directly translated to B.
3. Some stuff is directly translated to B but involves effort.
4. Some stuff is translated to B with a lot of abstraction.
5. Some stuff is missing but is needed by B.

The translation will give you two types of deltas. In the above list point 1 and 2 are those deltas.

When you want to experiment with a new field, use a technique from A to B, the first 4 steps are your confidence zone. You will feel good because you are building on what you already know. Or you will feel good because you have a source of information which you thought didn’t exist.

Step 5 is the real delta to explore. And often in terms of usage you can do this as you go or is a small percentage of the overall effort.

Some Examples from my Work

• Test Encapsulation – a concept that I developed on test-centric design in test automation engines was based on Sufism and Encapsulation.
• My test automation design learning was based on Peach (a fuzzing tool), JMeter (a performance testing tool), Head First Design Patterns book (development) and X-Unit Test Design Patterns (development).
• My work in data transformation automation was based on looking at a worker sieving stones from sand at a construction site.
• My style of using ECP is based on Sampling as a general concept.
• The Sieve Sponge concept in this series was derived years ago from a book on reviewing newspaper articles.
• My version of regression testing thinking is based on a simple lake theory.
• and so on.

Where to start?

Pick a technique/concept that you know. Ask yourself – Can I do something with it elsewhere?

Pick a technique/concept from elsewhere. Ask yourself – Can I do something with it here?

Make it a habit. Thinking in this manner is not a burden. Start with it deliberately, then it liberates you when it becomes a part of you.

That’s all for now.