The Matrix – ‘The illusion of Manual vs Automation’

If you haven’t watched this interesting movie ‘The Matrix’ at least once, let me copy/paste one of the plot summaries.

Hooked into the Matrix without even knowing it, an elaborate, omnipresent computer system designed to manipulate free will, reclusive hacker Thomas Anderson, aka Neo, is about to have an eye-opening revelation. And haunted by burning, unspoken questions, Neo crosses paths with leather-clad cyber-rebel Trinity and inspirational leader Morpheus, who claim to hold the answers to the reality of his imprisoned existence. Little by little, as Neo tumbles down the rabbit hole, the shocking truth about an artificial dreamland unfolds, catching the attention of the Agents: sentient programs guarding all the doors. But with people so hopelessly dependent on the system, what will it take to unplug and escape the Matrix?

Courtesy: Rick Nigaras @ https://m.imdb.com/title/tt0133093/plotsummary/

If you have watched ‘The Matrix’ and paid attention to those periodic and profound conversations between Morpheus, Neo, Oracle, Trinity and Agent Smith, well and good.

I dared to imagine such a ‘The Matrix’ in the software testing world. There are a handful of Morpheus, Neo, Trunk, Trinity and unfortunately there exist Cyphers and agents like Smith too.

Few important things to note is the context of this post.

Morpheus is not looking for Neo!

It is a curious, confused, concerned and somewhat manipulated Neo, who is looking for Morpheus.

But Neo probably may be ‘The One’.

Alas! very often Neo finds himself meeting Cypher and Agents. 😉. Many Morpheus know many such Neo for sure and trying to make them aware about ‘The Matrix’ in various ways.

As far as the original movie is concerned it took roughly an hour for Morpheus to convey Neo one important life lesson. The lesson was something like this.

‘I can show you the path, walking the path is your job’. 

Even when Neo went to meet Oracle and Morpheus stayed outside and repeated similar words. The ultimate message of this post is also the same.

For the moment let’s two of us (you the reader and me) play miniature versions of Neo and Morpheus of the software testing world. Who of us plays who doesn’t matter much.

Let me first try to define ‘The Matrix’ and ‘A hopefully realistic world’.

The Matrix – ‘An illusive yet so realistic world of misinformed QAs (software testers) who started believing into Manual vs Automation.’

AND

A hopeful realistic world of ‘Software testing that embraces good thinkers who choose to code and use automation to help them test smartly and wisely’.

So, the question that a curious and somewhat confused Neo asked to someone else (on LinkedIn).

So far, I am a Manual QA, how can I switch from manual QA to Automation QA?

I read the above question multiple times.

Assumptions: I made five key assumptions as far the question is concerned…

1. QA implies or means Testing.
2. Our Neo, the QA persona, seems to be working in an organization where QA is performed, and the QA may or may not be integrated within an org level QA (Quality Assurance) framework.
3. Neo seems to be in a dilemma of ‘Manual’ vs ‘Automation’. Source of the dilemma could be anything.
4. Switching could mean a permanent move or may be acquiring an ability to switch between Manual and Automation back and forth.
5. Neo knows better about her dilemma, feeling uncomfortable and unsettled and hence seeks answers.

I made many interpretations too and formed a handful of reactions and responses. Finally, coming out of analysis-synthesis paralysis zone and selecting from five different possible ways, I chose to respond in the following way.

Let me gently pull and push the questioner in a necessary process of analyzing her question first and then start constructing a set of answers for herself.

If I were Morpheus, I would have offered Neo a red pill or a blue one. The red pill can take Neo out of the matrix, and if Neo choose the blue pill, he stays in the world of manual v/s automation.

…if Neo feels like “Alice in Wonderland, falling down the rabbit hole.” He explains to Neo that they exist in the Matrix, a false reality that has been constructed for humans to hide the truth. The truth is that everyone in the world is a slave, born into bondage. Morpheus holds out two pills. In his left palm is a blue pill. If Neo takes it he will wake up in his bed and “believe whatever you want to believe.” But if he takes the red pill in Morpheus’s right hand, then “you stay in Wonderland and I show you how deep the rabbit hole goes.” Neo takes the red pill… [Courtesy: https://m.imdb.com/title/tt0133093/plotsummary/]

Suppose you are Neo and chose to take a red pill. The act of making a choice, picking up and swallowing down a red pill indicates that Neo is willing to come out of the Matrix. Now here are a few steps to follow and before you do so, I say this to you.

‘You have to let it all go, Neo. Fear, Doubt and Disbelief. Free your mind.’

So do following activity with a free mind…

Step 1: Since you seem to declare ‘I am a Manual QA’, please first help yourself finding what is ‘Manual’ in you or your QA process.

How to do this?

Step 1.1: Narrow down your entire QA process to Test Design and Test Execution. Remember that I am talking about you and your process of performing QA (see my assumptions). Don’t confuse it with QA (Quality Assurance). 

Step 1.2: Identify, for yourself first, and label what looks like a ‘Manual’ effort or a task or a behavior to you? Do it for Test Design and Test Execution. You should further narrow down by splitting Test Design further into [Test Case Design, Test Data design, Test Scenario Design and whatever suitable to fill your current Test Design activities array].

Step 1.3: In all your honesty and with a free mind, write down for each of the activities, what you think, feel, and factually know that is Manual. e.g. Typing test cases?

Step 1.4: Also write down what you find is / can’t be ‘Manual’. e.g. Thinking of an edge case?

Go to Step 2 only IF (You have completed above step(s) AND You have written it AND You are at least 50% sure that you are right about it) ELSE (Go Back and complete Step 1) 

Step 2: Write down what is NOT the problem and what is THE problem with this ‘Manual’ in QA?

Step 2.1: Be positive and write top 5 things that make you feel happy about your Manual QA style, process and achievements so far.

Step 2.2: What are the top 3 things, in each of the categories mentioned below, that you think or firmly believe or have data to prove that something is wrong with your manual QA. When you think of Wrong, think Wrong,

1. For you in the present 
2. For your current QA process
3. For software under test
4. For your team
5. For your organization
6. For you in the near future 

Step 2.3: Write down what you think Automation is. Don’t think too much. Just what you currently know about Automation and how it can be helpful for your day-to-day testing work? Also write what ‘Manual’ work you think you should give to tools and what tools those can be?

A gentle yet firm reminder:

When you are on 2.3, you may be offered a yellow pill from the same or other Morpheus. They have a Yellow Pill of some roadmaps. 

The yellow pills can be something like ‘Here is a roadmap for switching / jumping from Manual to Automation’ Many such roadmaps lead you to the world of Web GUI Automation. This seems beautiful from outside but as long as you carry the baggage of ‘Manual vs Automation’, you will find yourself in another Matrix sooner or later. You may also find yourself asking similar vague questions of ‘switch’ from X to Y to Z to … next time too.

Remember:

Those roadmaps can be contextually useful but only after taking the red pill and walking the path and coming out of The Matrix of Manual v/s Automation.

An alert:

You may also find some Agent Smith around you either in the organization or on social media who almost always try to give you either an expired yellow pill or a shiny blue pill because they manufactured those and want to sell those pills to you without telling its long-term bad side effects. These blue pills, in many shapes and sizes, if not harmful to your body in the short run but will be very unhealthy to your overall thinking and performance in software testing.

So far so good?

The real Morpheus and oracle, know the source of the red pill and they give you the pill for free, but you need willingness and guts to swallow that down and that’s just a prerequisite.

I stop here because there was another important lesson from Morpheus. 

Knowing the path is one thing. Walking is another and that makes all the difference.

I suggested one path.

The path of questioning your own understanding of Manual QA and pen down your answers.

Take this path and see how it helps you or not!

P.S: I can give you names of a few real Morpheus, Oracle, Trinity, Trunk and others to follow on LinkedIn, Insta, YouTube but only if you ask! Looking forward to seeing a Morpheus or Neo or Trinity or even a Cypher come here and comment on my imagination and addressing a burning issue in this manner.

Image credit: Photo by ANIRUDH on Unsplash

Oscillations…

They asked me to Shift Left,
I shifted and trusted them to be correct
The journey was joyful, 
But the feeling of fixation was awful

They felt they got me corrected
But I felt disconnected.
Then they asked me to Shift Right
I shifted assuming that the future would be bright.

I incepted in an utter absurdity 
For a moment
If Software Testing can be thought as a Number Line
Shifting extreme right may give rise to false positives
And to extreme right may give rise to false negatives 
I did a Values At, Within, Towards Boundaries Analysis
I sensed an 'Analysis' paralysis

I argued
I may be right or wrong some day
But, that prediction doesn’t stop me to say
That, Blinded by marketing gimmick
Probably, we forgot the Dynamics, Balancing and Equilibrium magic

In shifting to the boundaries, hours are burning
Gradually we may lose momentum and agility in learning
Nevertheless
I still have positive thoughts
Shift left or shift right,
Just don’t forget to step back
backtrack and connect the dots

Let’s not forget we are sitting on the heap of assumptions and ambiguities
Beyond shifting left or right
There is a context and there are non virtual realities

Experiment, Innovate, elevate
Just don’t fixate
Give yourself a chance
Revert and continue work with common sense

The arguments went up
They asked me to shut up
I kept myself calm
And here came a noise coming from the alarm!

टैस्टिंग करना सीखो, ओ वेरीफाई करने वालो !

इस रचना से मेरा कोई उद्देश्य नहीं की मैं किसी के टैस्टिंग स्टाइल, एजुकेशन, कैरियर, सर्टिफिकेशन या किसी वैल्यू सिस्टम से जुड़े होने पर कोई व्यंग्य करूँ या ज्ञान बांटने का ढोंग करूँ| 

वो प्रयास नहीं है. 

प्रयास बस इतना सा है की अगर कोई इसे पढ़े और उसे लगे की कुछ तो सच है, तो कुछ पलों के लिए खुद के लिए सोचे, समझे और जो सही लगे वो निर्णय ले. 

इन शब्दों को लिखने के लिये मैंने सफदर हाशमी साहब के एक बहुत मशहूर गीत (https://bit.ly/SafdarKiEkNazm) को एक जरिया बनाने की हिमाक़त की है. 

मेरी जो थोड़ी बहुत समझ है उसके लिहाज़ से मैं कह सकता हूँ कि, उनका तो बहुत ही बड़ा उद्देश्य था, कोशिश थी और एक बड़े तबके को एक बहुत मानवीय और वजनदार मैसेज देने का बेहतरीन प्रयास था. 

मेरा काफी छोटा उद्देश्य है, लेकिन है. उनका ये ओरिजिनल गीत मैं बचपन में दूरदर्शन पर सुना करता था. आवाज शायद उनकी ही थी या नहीं, ये तो नहीं पता लेकिन उन्होंने जो लिखा, पढ़ा और कहा वो उम्दा है.

उनको और उनकी रचना को पूरा सम्मान देते हुए, 
ये जानते हुए की ओरिजिनल रचना की आत्मा और भाव से जानबूझ कर कोई छेड़ छाड़ नहीं करूंगा 
और ये लिखते हुए की कुछ भी गलती होगी वो मेरी होगी।
शुरू करता हूँ 

टैस्टिंग करना सीखो,
ओ वेरीफाई करने वालो !
टैस्टिंग करना सीखो, क्यू-ए / क्यू-सी करने वालो !

प्रॉब्लम और कॉन्टेक्स्ट को जानो,
यूज़र्स को पढ़ना सीखो;
एक्सप्लोरेशन को साथी बनाकर
प्रॉडक्ट लर्निंग करना सीखो!

टैस्टिंग करना सीखो, ए-आई से डरने वालो,
टैस्टिंग करना सीखो, जी-यू-आई ऑटोमेशन में रमने वालों! 

टैस्ट केस चलाने वालों, पास और फेल करने वालों 
टेम्पलेट्स भरने वालों, साइन -ऑफ को झेलने वालों 

टैस्ट डिजाईन का फैसला अगर तुम्हे करना है
फीडबैक और स्ट्रेटेजी को अगर सॉलिड करना है,
रिस्क और थिंकिंग को हथियार बनाकर लड़ना सीखो!

टैस्टिंग करना सीखो, बस चैकिंग करने वालों 
टैस्टिंग करना सीखो, इट वर्क्स से खुश होने वालों 

पूछो डॉक्युमेंट्स की खातिर 
टैस्टर्स भटकते क्यों हैं?
पूछो खुद से 
अपनी जॉब्स ये टूल्स लपकते क्यों हैं ?

स्मार्ट, प्राउड और कॉंफिडेंट टैस्टर बनना हो विज़न हमारा 
जुडो कम्युनिटीज से, होगा लक्ष्य पूरा हमारा 
सीखो टैस्टिंग जो ‘मैनुअल’ से पाना है छुटकारा 
सीखो टैस्टिंग की हर कोई दोस्त बनेगा तुम्हारा 

टैस्टिंग करना सीखो 
ओ वेरीफाई करने वालो 
टैस्टिंग करना सीखो,
ओ वेरीफाई करने वालो !
टैस्टिंग करना सीखो, क्यू-ए / क्यू-सी करने वालो !


Hinglish Version

Testing karna Seekho, 
O Verify karne walo, 
Testing karna Seekho, QA / QC karne walo. 

Problem aur Context ko jano, 
Users ko padhna seekho, 
Exploration ko saathi banakar 
Product learning karna seekho. 

Testing karna Seekho, AI se darne walo, 
Testing karna Seekho, GUI Automation me ramne walo. 

Test case chalane walo, Pass or Fail karne walo, 
Templates bharne walo, Sign off ko jhelne walo, 

Test Design ka faisla agar tumhe karna hai, 
Feedback aur Strategy ko solid agar karna hai,
Risk aur Thinking ko hathiyar banakar ladna seekho

Testing karna Seekho, bas Checking karne walo
Testing karna Seekho, ‘It works’ se khush hone walo

Poocho, Documents ki khaatir testers bhatakte kyo hai 
Poocho khud se, 
Apni jobs ye Tools lapakte kyo hai? 

Smart, Proud, aur Confident Tester banna ho vision hamara 
Judo Communities se, hoga Lakshya poora hamara 
Seekho Testing jo 'Manual ' se pana hai chutkara 
Seekho Testing ki har koi dost banega tumhara.

Testing karna Seekho, 
O Verify karne walo, 
Testing karna Seekho, QA / QC karne walo. 


==================================
पढ़नें के लिये धन्यवाद / Thank you for Reading
समझने के लिये शुक्रिया / Thank you for Understanding
एक्शन लेने के लिए बधाई / Thanks for taking Action
कुछ पूछना हो, बताना हो तो फील फ्री फॉर कमैंट्स / Feel free to comments

थैंक यू  / Thanks
संदीप गर्ग / Sandeep Garg
स्टूडेंट ऑफ़ सॉफ्टवेयर टैस्टिंग / Student of Software Testing
==================================

Meaning of ‘Life’?

जीवन का अर्थ?

सुना है शब्दों  के अर्थ होतें हैं ?
या शायद नहीं?

मैं मानता हूँ कि 
शब्दों के लिये सिर्फ नये शब्द होतें हैं 

अर्थ का 
क्या अर्थ है?

जीव की यात्रा होती है 

अनुभवों की यात्रा 

मैं और तुम, सब जीव हैं
अभी सजीव 
और बस अभी 
निर्जीव 

सजीव से निर्जीव की यात्रा 
और 
निर्जीव  से सजीव की यात्रा 
कोई धर्म , कोई अवतार , कोई महापुरुष 
क्या तुम्हे बता सकता है?

हो सकता है 

लेकिन 
अनुभव की यात्रा मेरी है 
यात्रा में आनंद है 
अर्थ में बस नये शब्द!

संदीप गर्ग 
स्टूडेंट ऑफ़ सॉफ्टवेयर टेस्टिंग 
स्टूडेंट ऑफ़ लाइफ 

‘I’ is present and continuous

‘I,’ ‘My,’ and ‘Myself’ are three powerful words in my view and understanding.

Since I first heard the sentence ‘Aham Brahmasmi,’ it almost always got me thinking, what does / could this sentence mean?

As I grew, I shared my interpretations of this sentence but only with myself. 🙂

The most childish one was imagining someone sitting in front of me and saying to me, ‘I am Brahma, ‘The creator of the universe (as per Hindu mythology).

The other exciting interpretations were

1. Utter self-appraisal
2. Ultimate Self-Awareness
3. Self-Knowledge
4. Conveying my existence explicitly
5. Realising self-integration with the world and recognizing individualism
6. Ahankar or more concisely Ahamkara (both, usually perceived in a negative way)
7. Ghamand (usually maps to the English equivalent ‘Arrogance’)

Nevertheless, as I became an adult (at least age-wise), I found myself a proponent of individualism and got into thinking that why this ‘I’sm is ofen taken so negatively? Is it propaganda against the individual’s awareness about oneself? Is it something else?

I still don’t know, but what I think, as of today, is this. 

• Each one of us must work on oneself to build excellent ‘I’s
• Identify and associate with different such ‘I’s and co-create amazing ‘We.’

Based on this current thinking process, here I go to write A-Z of how I see myself building a ‘I’ who becomes enabled to…

1. Appreciate life and people and their helpful contribution to other’s life
2. Apologize the moment I realize to do so
3. Bring Clarity to me, my peers, and our common goals and objectives.
4. Communicate assertively to everyone
5. Declutter my mind, in different ways, the moment I feel a need to do so
6. Embrace ambiguity to an extent
7. Feel good when my peers, friends, and community members make progress in life
8. Get the right things done in the right ways
9. Honestly, accept my mistakes
10. Inquire as much I should minimize my ignorance
11. Jeopardize things and situations as minimum as possible
12. Know better about myself and the world around me
13. Laugh loudly at my stupidity and the jokes people tell me to see me laughing
14. Learn from different people, situations, and events
15. Minimize biases, misconceptions, and miscommunication 
16. Notice what’s going on
17. Offer Help without being judgemental.
18. Practice testing, good thinking, understanding, writing, and conversing
19. Question
20. Recognize the nurturing needs of my body and mind
21. Say ‘Thank You’ to someone who helps, criticizes, brings joy to work, conversation, interaction, and helps reduce my foolishness
22. Say ‘No’ when I know it is the time to say so
23. Seek Help by surrendering my ego
24. Trust people around me
25. Understand (the best I can manage to) people around me, working with me and their situations
26. Validate my assumptions by explicating those
27. Write (type) and publish, if I should

Yes, there are no X, Y, and Z, and there are no periods.

It is not a template.

It is an experience and journey.

It is present continuous

CDT, Agile Context, Selling and some Laws…

This post is an excellent example of procrastination by choice. There is no story as such. Just an attempt to solve a puzzle in my head. This post is for all my testers friends who are choosing / moving / pushed to play different roles in Agile contexts, and the new role might be very different from that of a software testing professional.

If you are not one of those friends/connections/acquaintances, you may stop here and read something else more helpful for you. But, probably, this article, even remotely, may be beneficial.

I propose to read it, and you decide for yourself.

Let me begin…

Some of you (my friends) might haven’t read Context-Driven Testing (CDT) principles. Yet, some of you were performing testing aligned with CDT principles. So if you don’t understand what CDT is, help yourself by clicking https://bit.ly/CDTPrinciples and staying for a few minutes at the landing page.

Now, suppose that, in the past,

• You have practiced testing in alignment with Context Driven Testing principles. 
• You demonstrated decent self and people-management skills.
• You solved some problems of some size, importance, and urgency daily.
• You understood what it takes to exist in a cross-functional team. One meaning, to me, is to continue developing different skills.

Then, I guess, it might become easy for you to start gracefully and firmly in ever-growing agile contexts within the software development space.

If you have ever talked to me about this before, I would have said the following to you.

Please don’t forget Context Driven Testing principles.

I usually prefer to remember them in the order of 3-6-1-2-7-5-4

CDT

But, of course, you may have a different order or may not be. As long as your testing is aligned to those principles in your context, that’s perfectly okay.

Please read the Agile manifesto carefully, and think of a value (left over right) that you haven’t learned (directly or indirectly) from CDT principles. Please note that I am not saying to look for a direct 1o1 mapping here :).

Agile

For example, pay attention to ‘Individuals and interactions over processes and tools.’

Note: Whenever something inside you tempts you to call something a law/standard/custom in Agile, remind yourself of this statement published on the top of the manifesto stating,

‘We are uncovering better ways of developing software by doing it and helping others do it.’

If you become ScrumMaster, please remember that you are first and foremost a facilitator in this role. From Jerry Weinberg’s books, I got to know about three types of management. Micro mgmt., Motherly mgmt., and Masterly mgmt. So, if you ever choose to be a ScrumMaster, you would want to play a Master Facilitator role. You would want to empower and enable self-organized teams to flourish within the culture.

**I am not, by any means, an authority on ScrumMaster role’s do’s and don’t, so let me stop here, for now.

I am still looking for credible references for the Product Owner role to understand this role better. For now, I am content with https://bit.ly/PO-TA-DEEPTEST.

https://bit.ly/PO-TA-DEEPTEST

If you have become a PO/PM by now, can you help me by posting some credible references in the comments section? Please make sure that those references are at par with what I posted so far 🙂

For the Business Analyst role (if that exists in Agile contexts), I may wish to connect you with people who identified customers’ real problems, proposed reliable solutions, and helped teams deliver those solutions. I worked with some of the very humble, down to earth yet highly knowledgeable business knowing leaders. They are still focused on their new missions, as far as I know.

In parallel, you might want to read and make sense of the following laws [https://bit.ly/LawsofSD]

1. Conway’s Law – My all time favourite and I am trying to understand
2. Ziv’s Law – I recently came to know about and sounds very familiar to me. How about you?
3. Humphrey’s Law – Reading now!

The important thing: Please start / resume conversing with the people who bring money to the table. We call them salespeople. They know that the successful culmination of any job is to the outcome of collaborative work on many fronts. They know that people buy from people. They usually know more about the business while testers often focus on functional aspects of the products. You may want to spend good time with ‘Sell‘ by Subroto Bagchi.

Did I not tell you that I am just attempting to solve a puzzle in my head. I am not successful yet but you my friend should have got some ideas by now.

Signing Off for the day.