Inside Story: What is in my talk for you at API Summit 2021?

I'm excited to say I'm presenting my talk at API Testing Summit 2021, this 8th May 2021.  Registration is free and you can register here.  

Get your testing team and fellow engineers to the summit. I see the unique value it brings with an opportunity to network with Test Engineers. Before reading further, register here and mark your calendar.

Does Black Box Exist?

The term "Black Box" is very much known to Software Test Engineers. Almost everything is a Black Box in relativity? How can we look into the black box or box of any color? What is the inside story of a black box?

Is API a Black Box?

To the consumer of an API, in a way, it is a black box. The consumer usually does not bother what happens within an API. All the focus is on processing the given information and responding appropriately.

As a Tester, do I have the below questions in me?

1. Should the API consumer know what happens behind and beyond the exposed endpoint?
2. Should the API consumer know what happens behind the exposed endpoint? 
3. Should the Test Engineer see an API as a black box?
4. Should the Test Engineer see what this black box constitutes and why?

Inside Story: Scratching the Black Box – API

I'm trying an experiment of analogy and demo. It is a 30 minutes talk and how can I make it? I'm working on it. I'm keeping it as short as possible as I have to demo and draw an analogy with the current pandemic day. 

In the 30 minutes' brief talk and a short demo

• I try to visualize how we can scratch the black box - API
• Dive layers down in learning and testing the API in a context. 

Who are the Audiences of this Talk?

This talk focuses on the fundamentals. Going advanced means getting deep into the fundamentals. To advance high and further, consistent learning of fundamentals is a must.

I classify my audiences of this talk in two categories as below. Do not forget to get your fellow Testers to this conference.

1. In Testing:

• One who is wanting to start the practice of API Testing
• One who is practice API Testing and wants to debug better

2. In Current Day:

• One who is looking at the happening pandemic
• The learning of API that we know but not monitoring enough

About the Conference

API Testing Summit 2021 is brought to you by

• Agile Testing Alliance
• DevOps++ Alliance
• CP-WST
• QualityKiosk

Conference web page

• https://apisummit21.agiletestingalliance.org/

HashTag:

• #APISummit2021

Me in Speaker Interview Series

• https://youtu.be/TfcYNQVU7C0

For other speakers interview, look at the right side of this below page:

• https://apisummit21.agiletestingalliance.org/ravisuriya-eshwara/

Why the Wait?

I'm waiting to listen to the other speakers and learn. Why you wait? Register and get your fellow testers and team.

See you at the conference and my talk -- Inside Story: Scratching the Black Box - API.

After the talk, you decide what box and layer of an API to uncover in your testing.

Black Box in Every Other Box of Software Testing

 

Modeling Software Testing With Boxes

The fact is something that is not put to scrutiny or questioned much and often.

As a fact, the Software Testing is explained to us using boxes.  That is,

• Black Box
• White Box
• Grey Box

Is this wrong? No, it is not wrong.

There was a need to explain for one how to visualize -- how a person would interact and interpret the software system when testing.  The analogy of these boxes helped and helps.  These boxes are mindsets.  In a way, these boxes are like models to interpret the different ways and approaches we take in Software Testing.

I see, we are seeing Black Box in every other box.  Maybe, this is limiting one not to think to learn software testing in other than a black box mindset.

If you ask, are we not automating? Is not that a Grey Box?  Very much, we are a black box mindset when writing automation as well.  I include myself here.  I'm exploring how to break out of this and see the Software Testing.

Do programmers think of their code as different boxes?

• A programmer reads, writes, deletes, and views the data. events and state
• The programmer as well cannot see what's happening between the binaries on the electric circuits
• The programmer evaluates her/his code's testing via logs, debugger, and assertion for the data, state, and events
• Is this a white layer or box?
• Is it called white because one can see through the logs, debugger, and assertion?
• But that is still not a sight of binaries on the electric circuit, right?
• If one could see through the binaries, we should not be having race conditions, out-of-memory, and unhandled exceptions
• Isn't so?

This makes me feel, there is a Black Box in every box and we are largely confined to this Black Box.  

Exploring to step outside this box helps to understand the testing, software testing, system [and software] under test, and what is needed to test better.

What Test Engineers Forgot By Saying "Out Of The Box"?

When I started my testing career, I read the lines which said, think Out of the Box.  My then manager said the team to think and work, out of the box.  

I see testers practicing, working, testing and automating by saying, out of the box.

Wait! When said boxes, what comes to one's mind is Black Box, White Box and Grey Box.  But, I tell you, there exists no such boxes.  These boxes are imaginary; it was termed probably to give an analogy, to see and know the ways to test the product's code and infrastructure.

I do not tie myself to these imaginary boxes, but, it is a useful analogy.  After all, when said Out of the Box, which box are we referring to?

And, what is that I'm missing by saying and doing out of the box?

What Have we Forgotten?

While me talking and saying *out of the box*, I'm not letting myself to think Inside The Box, for first.

If I cannot know what is *inside the box*, how will I know what is outside the box?

If I cannot see, think and explore for what is *inside the box*, how will I know what is outside the box?

I see, we have forgotten "Inside The Box" by saying and hearing "Out of The Box" for decades.

What's inside the box which you are testing?  Does it have just functionality, though the functionality is the heart beat of a system?  Okay, have I explored the functionality in all possible dimensions?

Almost everything in the box is associated with functionality.

When I'm not said to test for what is inside the box, I will be lost with Out of The Box.  Do you?

If I explore Inside The Box, fore sure, it will help me to go beyond functionality.  What all I can do inside the box?  What all I can evaluate inside the box and how?  That is, I think of performance, security, usability, observability, traceability, monitoring, and you label next.  All these are associated directly with the functionality.

All the boxes in software testing are imaginary.
We have forgot to see and explore Inside the Box.

Inside the Box, helps you to identify and observe,

• Why these exists?
• Why these are interconnected?
• How these are interconnected?
• How are they communicating?
• What are they communicating?
• To whom they are communicating?
• When are they communicating?
• When they fail to communicate?
• How fast and reliably they can communicate?
• The programming, code, protocols, tech stacks, libraries, money, ports, cables, people, etc.
• What they are holding and where, how and why, when?
• And, more ...

As you go Inside the Box, this space grows in multi dimension.  You will realize what is out of the box and what is inside the box.  You will consistently tune yourself to fit in any imaginary boxes with your tests.  From there on, you will explore, test, automate and talk to all the imaginary boxes and system[s] you are interacting with.

If I cannot see what is within, how can I see what is outside?

The Reality, Pain, and Cost

This is my observation.

• When I ignore Inside the Box, I will continue to talk with more focus on vocabulary, terminologies, schools, process, advocating on one aspect of the discipline and think this is craft and craftsmanship.  
• I will be stuck here and pass on the same to upcoming generation of software test engineers and practice.  
• This is the reality and painful part. 

Is talking and working on vocabulary, terminologies, schools, craft, craftsmanship and advocating that one aspect is testing, wrong?  

• No, it is not wrong.  
• But getting lost here indefinitely is beyond wrong.  
• The cost of this is huge to the craft as a practice and to the software test engineering discipline.
• As a result, the upcoming test engineers and generation will pick whose voice, approach and content is more opted.
• If observed, this is not the case with programming and programmers.
• I see, the programmers challenge most times and everyone who pushes or sells the thoughts. 
• Why? I see, they are trying to learn and understand from inside the box for first.

Unfortunately the smart people who are with role and title of influencers, thought leaders, keynote speakers, seniors, directors, VPs, ambassadors, and advocators of a thought and schools are lost here.  My question to them and me is, why not we explore Inside the Box?  Why just confined for propagating the philosophies and one's ideas alone ignoring what is Inside the Box?  The philosophy is a need; I do not say we should not ignore it.  Philosophy alone do not pay one's bills and fill the stomachs.  I wish, I had learned this lesson in the start of my career.  The business is a philosophy by itself and it will make use of or ignore any other philosophies as and when needed.  I hope and wish, the test engineers will interpret this.

I see this is one of the key reasons why the software testing as a discipline and practice we did not gain the recognition and importance as programming the product and solution.  Though we work closely with the product code and the test code, we miss our craft and names being called out.  This is reality and painful.

To end here, if I'm not seeing and thinking for what is Inside the Box, how will I excel in Out of the Box?

I Have a Programming Book in My Software Testing Books List

A Question From Mentee

One of my mentees asked for the books to understand Software and Software Testing better.  She shared the list of books to which she is referring.  She asked,

What other books and resources do you recommend to me for learning and understanding Software Testing?

I want to share my thoughts by talking a bit about boxes of software testing, books, and personas.

Software Testing, Books, and Personas

Read this blog post (Black Box in Every Other Box of Software Testing). It talks about the different boxes in Software Testing.  On reading, do you see a Black Box in every other box?

I classify the books and resources on Software Testing per the below classifications.

Pic: Classification of Books & Resources for Software Testing

I keep the Programming book in Assistive classification.  I have it in my first three books.  How can I test a software system if I do not understand how it is programmed?  Maybe, I can do testing to some extent. But,

• What will I miss if I do not understand how it is programmed?
• What will I miss if I cannot make sense of the code?
• What will I miss if I do not know how to use automation to help my testing?

I consider the different personas to aid my testing.  But, I do not see the programmer persona of writing the code for the system I'm testing.  How to use the Programmer persona to test the system?

What stops me from considering programming as one of the characteristics of a persona?  What can influence and help me to think and include this persona?

I'm not knowing [or ignoring] the first circle of persona (programmer).  But trying to think of different personas to include in my testing strategy.  Is this rational, logical, sensible, and appropriate?

If I practice programming to the extent of reading and understanding the code, I can think of risks to a larger extent.  This is helpful.

If I practice programming skills to the extent where I write automation, I can think of how to automate, how much to automate, and where to automate in that context.  It is helpful.  Isn't it?

If I practice programming skills to the extent where I can discuss confidently with the programmer about the possible risks, it is helpful.  It will also help me to debug and test investigate better.  Isn't it?

This will change how I look at the system and how I test the system with my testing and automation.

Book, Programming, and Language

• In your list of Software Testing books and resources, have a programming book
• Testing software without knowing or understanding programming will always limit us sooner in our Test Coverage, Test Strategy, and Automation Strategy
• It will always limit our understanding of the system we are testing
• It will always limit us in knowing the potential risks and problems inside and outside of the system
• It will limit our perspectives
• For example, 
• When and how the functionality of a feature can be vulnerable?
• When and how to decide how much sampling is enough in a context?
• When you are building a mindset and thought process in programming, pick a programming language to practice the programming
• Start small
• Start simple
• But, start, and then continue

It is always good to derive relative learning and analogy from different practices and study areas.  It helps to register one's learning.  But it should not happen at the cost of avoiding and ignoring the practice of programming by a Software Test Engineer.

Programming is very closer to the software system which we build and test.

Do not get into the thought of whether it is compulsory to be aware of programming for testing software.  This is procrastination probably due to fear.  Face it!  Fight it!

I suggest "Head First Programming" for programming for one who is starting to practice programming.  This book is self-descriptive and communicative.

Start practicing the programming at your own capability; but, do not give up; continue the practice.

Upskilling yourself here will put you on the competence line.

I have a Programming book in my list of Software Testing books and resources.  Do you have it?

Testing The Magician's Fingers

A student from primary school where I studied came up and asked "Will you see the magic?" I like the tricks and uncovering those tricks of magic, hence requested her to illustrate the magic. She had brought box of color pencils with her.

I was asked to pick few color pencils while she turned such that I could see her back. She asked me to place those picked color pencils slowly in her left hand.

Later I was said to note down the color pencils which I have picked. And, I made note of those color pencils which appeared to me as red, green, black, blue, yellow and orange colors. After few seconds, I was asked to remove one color pencil from her left hand and place it in her right hand. It appeared as she was making sure that a color pencil was in her right hand. Later she moved it back to her left hand, where other color pencils were.

She instructed me to remember the color pencil which I have picked and placed in her right hand. And she asked me to move all the pencils in her left hand to box and close it. I had picked a color pencil which appeared to me as yellow-in-color and placed it in her right hand. Turning around she took the closed box in her hand and shuffled it with smile and confident. These actions of her made me more curious to observe her movements much more consciously.

She began to pick the color pencil by opening the box. She picked the pencil which appeared as pink-in-color and said not this. Later she picked the pencil that looked like brown-in-color and said not this. I kept looking at her eyes and body movements. Later she picked the pencil which looked as yellow-in-color and said this is your pencil.

I was surprised and sensed the trick here. And I believed my observations can be different if I closely investigate it. I asked her to repeat what she done. She was in full of joy and readily did illustrate her magic again.

I started my testing by stating test mission, "To uncover the illusion of little girl's magic trick."

Below are the questions that I gave for myself:

• Do I know what should be tested, by modeling the magic trick that I witnessed just now?
• What are the oracles and heuristics that can help me to know this magic trick?
• What approaches and techniques should I be using in current and unexpected contexts to test, for revealing this magic trick?
• How to configure, operate and observe the tests that I will be making?
• How can I infer and perceive the test results?
• How can I summarize my testing activities on revealing the illusion of magic trick?

While the little girl was illustrating the magic trick I was observing the possible suspicious (which acted as heuristics) moves which I thought of. Moving further in my tests, kept talking to the girl and varied my tests.

The information that I made note were as below while I varied my tests:

• Was she able to see which color pencil I picked? She was not able to see it while I picked one color pencil from box.
• What was the length and width of color pencil she was using to illustrate the magic? It was the pencil of length and width which was fitting in her palm.
• What kind of traces does the color pencils leave behind when colored using it or touching the tip of its lead? The trace of color was bright enough to identify by me in this context.
• How quick the traces of color can be erasable either on palms or on paper in this context?
• Is this color trace visible to other person, if the little girl is away from the observer?
• Am I biased here with anything here? Is it helping me? I was biased with information that color pencil will not leave any traces on palms on holding it.
• Does the lead and body of the color pencil appear to be of same color?
• What were the sequences of the pencil positions in the left hand of the girl?
• What if I place pencil in alternate pattern such that head of one color pencil will see the lead of the other color pencil in left hand?
• What if I change the position of color pencil head in the right hand of girl? Will she be still able to identify the color pencil I picked?
• For what number of times the little girl can consistently identify the color pencil that I pick? And the girl should not clean her palms or hands on each time this trick is illustrated.
• What if I place the same brand or manufacturers color pencil with broken lead, so that it cannot color unless it is sharpened to see the lead?
• What if I place other brand or manufacturers color pencils in her hand? Will she be able to identify the one I pick?
• What if I place pen with closed cap or colored objects in her hand that fits her palms? Will she be able to identify the one I pick?
• Was there any embosses or any kinds of surface marks on color pencil, which could tell the color of pencil on touching it?
• Did each color pencil have particular odor? If yes, how strong was that odor to identify uniquely? And this odor help her to identify the color pencil I picked?
• What if I place the black lead pencil of same size to the color pencil in her hand? Will she be able to do the same gimmick as with color pencil she had bought?
• What if I had smeared or rubbed the color pencil lead with other color pencil such that it gives two colors or a new color combination of the two? Will she have any difficulty now in identifying the color pencil I picked?
• Does the color pencil's body will leave any color strains on the palm or fingers while it is held in hand? If yes, for what time period should a color pencil to be held in hand? For how long the color stains or traces from this will remain there?
• Can I break the lead of a color pencil and can place the lead of other color pencil to it? How she can illustrate the same magic now?
• What if I place color pencil, which appeared as its lead color and body color are not the same? Will she be able to pick the right color pencil now?
• Were the color pencils are used earlier to color or yet to be used for coloring? Or it is used only for such trick purpose?
• Did the box of color pencils had anything in it to make this trick happen?
• What if I smear the oil or wax or water over her palms and fingers, before placing the color pencils in her hands? Will she be able to show her trick?
• Will she be able to do the same trick using single hand and one finger, instead of both hands and its fingers?
• How long and good the nails of her hands are? Did she make use of her nails too in this trick? Was nail polished with nail polish? If yes what was the color of it?
• Had she smeared anything on her nails, palms and hands?
• What all she is using to do this trick?
• How quick the pencil will leave its strain if it is kept in hands?
• What was the size of the lead of color pencil in the box?
• What if I place the pencils all of same color in the box instead of those appears to be of different colors?
• What if I closed her eyes by cloth so that she cannot see her hands or palms or fingers? And now I request her to pick the pencil. Will she able to do the trick now?
• Was there any person who I did not see, helping her to say which color pencil I picked?
• Was there any object around her that helped to see her which color pencil I picked? Did the direction she turned and stood have any influence or not?
• Is she able to do this trick in any place and any time, apart from the place where she stood now?
• What if I do not place the color pencil in her hand, instead keep an object that appears and feels like a color pencil but not a pencil? Will she be able to identify it or will she proceed further to say to put all the pencils back to box and be shocked to see no pencils in box?
• How long did she keep the color pencil in her right hand? What time did she take each time to repeat when I asked her to illustrate, when I chose different color pencils?

These were few questions that I got during that context. Asked her to perform the trick for few times and showed that it can be different if tested. And her little thumb finger nail of right hand had color of pencil I picked, through which she identified. She left saying "cheating, you saw the magic on my nail."

Magic is also an art as testing is. Magic and testing can make the illusions and remove the illusions too. Both require skills, practices, explorations and failures to find alternative approaches that fit into the contexts.

Testing will show how our biases, anticipated, inferences, perceptions, investigations and the information we have will not be the same for any time.