The { } and Lessons I Observed

 

I did not know { } are called braces.  I called them curly bracket or flower bracket in my verbal communication until I started my career.

In the early days of my engineering college, I wondered why the braces are used and not the square bracket or parenthesis to open and close the class, function and a block of code.  

I was practicing C, C++ and COBOL then.  Though COBOL did not use braces, it used indent to start from specific column in a row.   But, the philosophy of a programming language construct looked relevant in COBOL as in C and C++. 

When I practiced Core Java, I could relate the programming constructs and find the similarities in C, C++, COBOL and Java.  So with C#, JS, and Shell Scripting.

All this said, the question that remained in me is -- Why these programming languages use braces to open and close the class, function, loop & conditional blocks?  Why this similarity?

When I studied Discrete Mathematical Structures in a semester, I could correlate the programming to it.  This helped me to reason and interpret why the braces in a programming language.   

Pic: Programming languages having braces to open a function.

{ } and Set

In the Discrete Mathematical Structures, I studied Sets. Further, I learned how the Sets is used to classify and organize the elements in problem solving.

While I was solving a discrete math exercise,  this struck to me -- Why the braces to represent a SET?  This triggered my associative memory and sparked a question -- Why do I see the braces in C, C++, and C#?

Here is how I interpreted and reasoned my thoughts and questions.

• The SET is to represent the elements of common nature and characteristic which has a purpose. Most of the times it is deterministic.
• But, why the different programming languages use this braces to group a set of instructions? Why not something else to represent programming instructions with a common and deterministic purpose?  
• The COBOL do not use braces, but, the philosophy and thought process of braces exist in it as starting from specific column.
• I observed Java and Shell scripting using the braces.

The point and thought to note here is, the two words -- SETS and Groups. I'm studying this since my primary school days.  But, I had not realized how they are so much into the computer science!

Today, I observe most programming languages use the braces to group the set of instructions which are for a specific purpose.  Be it a class, function, loop or a conditional block, they are within { }.  

Between the { }

The instructions written between the braces has an objective.  Be it class, function, condition or loop block.  That is, I group this instruction as a set.

Why I call it as a set?

• The instructions between the braces have the one purpose.
• Is this SRP -- Single Responsibility Principle?  I am yet to put this in a better word!

Is the set a collection of elements that has a common characteristic and purpose?  Then, between the braces, the code has a common [one deterministic] purpose.  

Does this thought of programming language creators made to use the braces?  If so, this is a beautiful learning which is missed to observe and interpret.

{ } and Programming Languages

A programming language is created [written] to overcome the limitations of other language in a context.

Yet, each person who created the respective languages did agree to a common representation and understanding of semantics and constructs like the braces.  I see this is missing in Software Testing fraternity.  

Though, the creators of programming languages have a differing thoughts on other programming languages and what it takes, they have something in common to represent their thoughts.  

Looks like the most creators seem to go with this common representation.  The braces is one such example.  

Their vocabulary is something amazes me; most don't seem to have a problem with it.  The idea and thought are the same behind the vocabulary in most cases.

Another example is how to write a comment.  The programming and scripting languages that I have used so far uses // to comment a line.

To end this post here, personally I feel, I as a Software Test Engineer have a lot to learn from the programming fraternity.  

The next blog post is continuation of the thought shared here and sharing my experience of how the software testing fraternity looks to me in comparison to programming fraternity.

Testing and Programming Are Not Separate Disciplines

 

Do you and your team see Programming and Software Testing as two separate disciplines?  You believe that programming and testing are as different as oil and water?   If so, this blog post will converse with you to realign your thoughts.

When I started to draw the correlation between Software Testing and Programming,

• That is when I realized Programming is beyond writing the code.
• Testing is an integral part of programming.
• Writing code is one part of programming.  
• Likewise, testing the written code and the associated system, is part of programming.  
• I see, the idea of TDD is an example to it.
• Testing is not the other side of a coin.
• Programming and Testing are on the same side of a coin!  Testing helped me to learn this.

Then, what is on the other side of the coin? 

• It is we on the other side of the coin, 
• Who are seeing and advocating testing and programming are the two different disciplines.

Had I understood this early in my career, it would have made a significant difference.

For the last 10 years, I have been assisting myself and mentees to experience this perspective of programming and testing.

The sad part is, the colleges and universities do not tell this to their students.  Instead, we are said the programming and testing are two different stuffs in software system and engineering.  Thereby, treating the one is superior to other.  Eventually, we in the industry continue to share the same thought and dialogues in all spaces.  Thereby, creating the gap in skills and thoughts of both programmer and tester.

Programming 

What is Programming?

A program is planned and an ordered event of actions with a purpose.  When it is ordered in a specific way, it involves logical decision of a programmer to design and implement a program in a intended way.  

In Computer Science, I accomplish this with the help of programming languages and commands which an operating system leverages and executes.

Programming is a thought process and thinking activity which evolves over the time with discipline and consistent practice.

• It involves thinking, understanding, questioning, and analyzing the intent of learning and solving a problem in hand.
• It demands questioning and learning the context.
• It involves studying of -- systems, people, environment, communication, programming languages, design, modeling, simulation, engineering, technologies, anthropology, geography, economy, business, politics, laws, regulations, computer software, software tech stacks, hardware, domains, different professions, jobs, emotions, crime, psychology, science, arts, and you can add more to this list as you unlearn and learn.
• It demands analytical thinking, critical thinking, and ability to develop clarity for making decisions to design the implementation and code.

Programming is like a manifest file in Android app, where it manifests and expects how and what the app should be like.   The app code implements the manifestation.

Coding

Visualizing and writing the programming instructions from the manifestation thought of programming is coding.  The programming instructions [logical] are written using programming languages.  I understand it, this way.

To code, one uses programming languages.  Further one has to understand the Data Structures and Computer Hardware and associated software to code efficiently and effectively.  This is where I understood the need and value of the Data Structures.  This forms the basic and fundamental necessity for one who wants to build and test the software system.

Each programming language has its own,

• Syntax
• Rules
• Limitations
• Way of execution
• Space
• Time
• Storing and retrieval of data

The below said will be well evaluated for the context,

• Which programming language to code? Why?
• What Data Structures to use for processing the data?

That said, the idea of debugging remains relatable and same in most cases irrespective of the programming language.  

That is, the debugging is at meta layer of programming.  Based on the context, how the debugging is done, can change with the programming language.  But, the idea of debugging remains the same.

Programmers learn and practices different programming languages.

Programmers solve the problem using programming language.  To solve, programmers start visualizing with programming, and then code.

I see, the programmer learn -- Is the actual problem being solved?  So that the time and efforts are well spent.

To stop here, there is,

• Clean Code, and not Clean Programming
• Code Smell, and not Programming Smell
• Code Refactoring, and not Program Refactoring

Programming and Coding are two different skills and it runs in parallel helping each other.

It is like, the programming is a blue print, and, coding is the construction work.  Both are needed!

Testing

Having one's own definition as a practitioner is good.  But, then I see, my definition also aligns with that of Dr. Cem Kaner, James Bach and Ashok Thiruvengadam.  So, I quote their thoughts here.

Testing is,

• Questioning a product to evaluate it.
• Probing the system to learn and evaluate it.
• Empirical technical Investigation
• To learn quality related information of a software system
• So that the stakeholders can make informed decision

I see, testing is an another stand to the programming.  It is not different.  

Programming and Testing are analyzing and thinking skills for first.  The thinking applied and implemented and evaluated is coding skill.

What all needed for better programming, all those are needed for value adding testing.  Refer to the above section on Programming.

Further, testing uses coding to execute the intent of a test to some extent.  And, this is a need.  Being skilled in programming and coding gives a different perspective and strength to the testing.  The value out of this will be distinct and prominent in most context.

If one can test, one can program too.  

Now, do you see that the programming and testing are not the two disciplines?  They are one!  They are on the same side of the coin.  On the other side of a coin, it is we who are not willing to see this and advocating these two are different.  

I learn, a skilled tester can add keep adding ways to sample, interpret and test when she or he can use the coding skills.

To summarize,

1. Programming and Testing are the same discipline.
• Seeing it as two different discipline is counterproductive!
• This counterproductive can be seen in the software industry, today.
2. It is useful thought process, mindset and attitude to see both programming and testing as a overlapping areas and one discipline.
• Both are on the same side of the coin in Computer Science, Software & Engineering
3. Coding skill does not mean one has programming skill.
4. Coding skill does not mean one has testing skill.
5. Programming skill shows the testing skill and vice versa.
6. Programming is a way of testing.
7. Programming is a way of debugging.
8. Testing is a way of debugging and refactoring the programming.
9. Programmer develops the tests and code.
10. If you can program, you can test.  If you can test, you can program.  If you can program, you can code.
• But, coding skill alone is not enough to program and test.
• These all are three distinct skills, where programming and testing overlaps very much on each other.

RAAMA: My Test Discovery Model

 

RAAMA -- I Look at You Everyday!

I have tried to put up one of my Test Discovery models in a conceptual way here with name RAAMA - Refer to, Arrange, Action, Monitor, and Assert.

Maybe this model helps you and your test engineering team as it is helping me.  Use this to your context with addition or subtraction for what you are seeking.

I refer to this RAAMA of me everyday and when I'm testing.  I'm finding the new learning and realization everyday that I was unaware earlier.  My understanding of RAAMA is not same what I had on the previous day.

My understanding of this RAAMA is incomplete and I have made PeACE with it by accepting it.  My understanding is growing and getting better everyday.  I will share a better version of it as I experience it.

Each time I look up to RAAMA and refer to it, I see a new dimension to RAAMA.  The awareness, exposure, and the questions are getting better giving the better realization of what I was ignorant and unaware.  The RAAMA is exposing me to be a better test engineer today than what I was earlier.

RAAMA - I Look at You Everyday!

RAAMA - One of my evolving models for Test Discovery

Note: I have not explained in detail what I mean for each node and its sub-nodes.  I can talk and discuss it with you if you look for it; I'm just one email away to get started.

The "Bottleneck" in a Test Engineer's Eyes

 

Preference to Bottle Over Jar! Why?

Have you heard Jar Neck anytime when describing a problem or solution?

• I have heard Bottleneck often and consistently; but, not Jar Neck .  Why? 
• Be it in Software Engineering or day-to-day life problem solving description,
• The Bottleneck is referenced and not a Jar Neck.

Looks like people want Bottle but not the Bottleneck speed and benefits.  Bottle without its neck is a jar?!

Bottleneck exist for better controllability.

• In a bottle, the bottleneck is a solution!  It is not a problem!
• It is to mitigate any risk and problem that arises from the flow of content in the bottle.

Yet we describe, learn and communicate the neck of a bottle as a relativity and analogy to a problem.  

Are you aware of Gateway in the software system?

• The Gateway can be seen as a neck of a bottle which controls the incoming requests and outgoing response.
• Gateway is a necessity.
• We need Gateway to be adaptable in size of its neck based on traffic volume it is handling.  Here, the gateway's neck size should adapt and scale contextually.
• When describing a problem, we are talking about how this bottleneck size which is not adaptable for the context.
• That adaptability has to be built in engineering to scale in any dimensions and magnitude.
• When this is not done, we equate the software system's problem to a bottleneck as a analogy, which is incorrect!  The bottle has got its size and its neck size fixed for a purpose and as a solution.
• The context of a bottle and today's any systems are different.
• It is good to draw similarities from General Systems Thinking and observations.
• But the solution cannot be generic to all systems; it has to be contextual.  The software system has to have its contextual solution.

So, next time when someone in your team or network talk about bottleneck, do share them bottleneck is for better controllability.  Having a contextually resizable and adaptable bottleneck is the need for Software Engineering; not the elimination of bottleneck.

In fact, a software system should have and will have a bottleneck in a point.  And, this bottleneck will be adaptable to the context for having what it should let through and process.

Is the runway of an airport a bottleneck when it is compared to a sky?  Is that a solution or a problem?  Likewise, the ship will have a defined route path and it does not sail without a route path.  Is this a bottleneck to ship and its business?  A elevator can accommodate the defined number of people or kilograms allowed, and not beyond that to move.  Is that a bottleneck?  The esophagus in human body has a size which medical science observes as normal and acceptable; any deviation from that size measurement, the medical science test investigates it as a risk and problem. Why?  Is the circumference size and length of esophagus a bottleneck to human anatomy and physiology system?

The engineering solution will and should have a bottleneck at a point.  Having a adaptable bottleneck to the context is one what tries to accomplish in a software system's scalability and operability.

Please, do not equate solving a "bottleneck" situation with Agile practice.  Does it look like a joke?  I will not be surprised if someone says bottleneck problem is solved if practiced Agile.

Dealing with the Fallacies of a Fallacy

 

One of my mentees asked me to help in identifying and understanding the fallacies in Software Testing.  I did not know the context in which the help was sought.  All I got is, on reading the book from Gerald M. Weinberg, the mentee wanted to understand and know the testing fallacies better and in simple terms.  For "fallacy", I understand it as -- a misconception resulting from incorrect reasoning and a false belief.  

Further, I learn that reasoning and belief are also heuristics. Can the heuristic be a fallacy? I see, the heuristic can be a fallacy.

The Reality of the Fallacy is a Fallacy

I will keep this blog post layered and oriented with technical lines so that it becomes easy for anyone in tech to understand my thoughts.  As I write this, I get hit by this question -- "Fallacy is a Fallacy?".  With that, I'm left with a successive question -- Fallacy is a Fallacy? Is that not a logical question? 

When I mean logical, I understand logic is one of the aspects of rational, scientific, and systematic analysis.  The analysis has limitations, knowns, and unknowns.  Further, this is super covered by a meta context which includes the uncertainty -- we are aware of and not aware of in our analysis.

When I write this, I see the word "meta context" in my mind.  I don't know if someone has used it earlier.  I presume, someone should have definitely used it when talking about engineering and systematic rational analysis. 

When we work on an engineering problem, we work with a context.  In that context, we learn 

• the problem, 
• need (requirement), 
• assumptions we make, 
• what we know, 
• what we do not know, 
• potential solutions, 
• approaches, 
• execution, and more

The engineer in me says, there is a meta context for every context.  Doing engineering to the meta context is an over-engineering is what I understand.  

Engineering to a context, by solving the risks and problems which are identified in that context, is what we all are doing, today.  This is my observation!  An example of this is the software system that we are building and continuing to consistently develop to be updated for the need.  The software system we are building, testing, and deploying is bound to a context and not to the meta context.

In Software Engineering, we work on a context, and, that itself is huge engineering.  Eventually we start seeing the context in which we work as a meta context, while it is actually not.  This is one of the fallacies which we encounter and most times do not identify it.  You see?  Then how to think about the meta context which comprises the infinite contexts from which we have picked a context to engineer and solve?

Once we try and continue to be aware of meta context and what it has, we start to learn everything is a fallacy, including the fallacy.  That's enough philosophical from me.  But, that's the reality and fallacy, as well. 

That said, thinking is a fallacy.  We know that exhaustive testing is not possible.  Likewise, exhaustive thinking is not possible.  When one's thinking is not exhaustive and bounded, don't a fallacy exist there? 

One's scientific and logical thinking is modeled and sampled over a few models, space and dimensions.  The decision from this thinking, practice, and testing will have limitations and fallacies that are noticed and unnoticed.

If an organism can think, then that organism will undergo the influence of a fallacy.  And, the organism can learn to identify fallacy, if at all it understands -- I can be fooled no matter what.  That is one of the byproducts of testing -- knowing the few possible ways how one can get fooled.  And, we have no leisure and luxury to find "all the ways"; this bound brings in fallacies in one's belief, thinking, work and decision.  So I say we work in a context which is pulled out of a meta context.

I see this is the stem of fallacy; the fallacies get wired to our thought process and to the engineering we do. Our systematic and scientific interpretation accepts the fallacy as -- logical, and systematic, and claims the problem we're solving is solvable.  Note that, when I say solvable here, I mean, we can deal with it for the costs and value we get out of it.  By doing so, we handle and manage the fallacy to yield the value.

What Did I Read Just Now?

Well, what you read above are engineering philosophical thoughts of me.  Now, let me pull that to the Software Engineering and Software Test Engineering.

The software system or a hardware system or any system that we have built is an assumption.  We assume it works because we work to make it work.  And, we sense that it works because we adhere to the protocols which define these assumptions.

So that tells me, that anything and everything is built, and being built is an assumption and has protocols. And if anything is working, it is on assumptions.  If anything has failed to work, it is on our assumptions.  That infers me, that rational and systematic analysis is an investigated and experimented assumption.

These protocols and assumptions can blind us to fallacies and limits us to not identify the fallacy.  On witnessing an incident, the fallacy or the outcomes of a fallacy may get uncovered a bit.  That is what we do in the RCA -- Root Cause Analysis.  We do the RCA so that we learn the fallacy in which we got trapped.

On RCA for an incident, we will experience a similar or same problem again.  Why?  We think, that once we do the RCA and practice, we do not repeat the mistake -- this is a fallacy too.  We do a new mistake, which leads to another RCA.  Does that means, the RCA of an incident says not to fall for the same fallacy again but okay for another fallacy?

Managing Self with Fallacy

I too fail in identifying the fallacies.  I continue to prompt my thinking and analysis to see the obvious traps while I test and deliver the testing.  I do not identify all the fallacies in a context.  I will work to find the list of fallacies that brings the most cost in testing delivery and system development technically.

Here are a few questions that I ask myself each time in my test session and analysis:

1. What are the five contexts where this is a problem or risk?
2. What are the five contexts where this is not a problem or risk?
3. What are the five ways where this looks to work as expected?
4. What are the five ways where this does not work as expected?
5. What are the five contexts that matters most about this system and I have missed to know them?
6. In what contexts this bug is not a bug anymore? Why?
7. In what contexts this will be a bug/problem/risk/cost? Why?
8. What are the influencing factors and practices considered in making this decision? In what contexts do these factors and practice displace the value with the cost?
9. What are the assumptions and beliefs that are driving my testing?  Whose assumptions and beliefs are they?
10. Do I know that I can be fooled?
11. Do I see any problem here?
12. Do I see any value here?
13. Do I see any cost here?
14. What More Can I See Here?

Understanding and learning -- how my team and stakeholders attach the importance to the same information, helps me. This potentially hints me if they are under influence of any fallacies.  I learn, the context in which team members and stakeholders are also influencing the importance attached to the same information.  Sometimes, the team and stakeholders use the same word; but, I notice they have other meanings.

This has lead me to learn, it is not about being precise or not for first; it is about, having the ability to communicate and help each other to have the clarity in what is expected.  And, how to achieve this clarity considering the thought processes and beliefs that each stakeholders hold, is a must to understand.

To sum up, we cannot avoid ourself from the fallacy.  What is not a fallacy at present, it can and will be a fallacy in coming time.  The goal is to how we manage to identify and deal with the fallacy which is influencing us and our work.

There is no escape from the fallacies!

Note: The count of words "fallacies" and "fallacy" in this blog post is 47.

Testing and Exploratory Testing

 

A Discussion in The Test Chat

In one of the discussions in The Test Chat on Telegram, the topic was "How to test without an SRS document?"  One pointer put to help in this direction was -- "Even though there is no document, you can find the requirement if you look hard enough." 

This pointer was put as a question asking how it can be done.  Further, the discussions spoke about Testing and Exploratory Testing.  

This discussion brought up the below thoughts from one of a fellow tester:

Only exploratory Testing part can be done when no document is provided , assuming the meaning by looking hard enough may lead to  various assumption 

They are suggesting to look at software under test  hard enough it seems.

And in further points they are saying know your end users and personas which is again product owners job before creating document.

In short :they are saying look hard and create SRS/BRS.

What am I seeing in the above discussions?

There is nothing wrong here with this discussion point.

I see one's learning journey in this discussion.  The good thing is -- the space as The Test Chat is available where one can share her/his thought and discuss.  All of us will have the learning journey and so do I.  It evolves as one shares her/his thoughts like this and opens up to discussion.

If we do not open up to discussion and share our thoughts like this, that's when we are not doing it right.  We have to encourage the discussion, questioning and foster an environment where it is accepted and practiced.  Only then, we will speak our learning and work, and understand it better.

Testing and the Exploratory Testing

I'm sure most of us would have crossed and crossing:

1. The job description, talks, discussion, and tasks assignment having two words -- Testing and Exploratory Testing.
2. The instruction a,s "Do the Testing and then do the Exploratory Testing".  It could also be one of your team members and manager asking "do Exploratory Testing after the regular Testing".

Few of my fellow testers use the word Exploratory Testing and Testing.  I have no problem with it.  When I discuss and write, I use the word i.e., Testing, in my practice.

Here are my thoughts for today from the learning I'm having from my practices:

• I cannot differentiate between the words Testing and Exploratory Testing.  To me, both look similar but an additional word i.e., Exploratory.
• I learn, Dr. Cem Kaner coined the word Exploratory Testing around 1982.
• Each time I test, I explore!  I could not break and create two sessions for Testing and Exploratory Testing.
• Could be there was a need then to differentiate and communicate that testing is and as Exploratory explicitly.  So did he coin the word Exploratory Testing?  I'm not sure!  
• But this has become one of the most misused words today where it is said to do Testing and then do the Exploratory Testing.  That's a different subject altogether to discuss is what I see.
• Testing is exploratory in its nature.

James Bach shared a document having the history of Exploratory Testing definition.  I'm sharing the same here with his permission.  The credits of this document are to James Bach.

Testing with no SRS or BFS

I looked and asked for SRS and BFS documents at beginning of my career.  After a year, I had no SRS documents for the product I was supposed to test.  All I had in my hands were the architecture diagram.  The team did not have the luxury of writing SRS in the timeline it was running.  This helped me to develop a skill -- to test using what I have at my hands; I did not depend on SRS documents.  I see the requirements coming in two forms -- explicit and implicit.  

• Most times, when there are no recorded documents, the documents I make on the product and system as a whole, are used for immediate reference.  Should it be called SRS/BFS?  I do not think so; I would not call it as well.  But it is part of my testing outcome i.e., by-product -- Test Notes.
• Today the FCO i.e., Feature Coverage Outline is spoken very much.  Likewise, KYC -- Know Your Customer (user of a product and stakeholder as well) is also one of the key tasks.  The testing team does this task in modeling the users and their personas so that they derive the test data and figure out the tests and scenarios.
• I have been testing with no SRS/BFS in place.  I will have to figure out what is the expectation somehow.  Else, how will I evaluate?  I use multiple approaches for the same.
• I do not crib anymore if there is no SRS/BFS.  It is one of the contexts in Software Development.  I will have to deal with it while I test and automate.  I also make sure that I'm aligned with the stakeholders for what they want and also with the market fit of the product and the problem it solves.

At this point in Time

I'm also testing for a Machine Learning product today when I write this blog post.   This project has detailed content written on the engineering and architecture of the product.  But there is no SRS/BFS written for the product.  I had challenges for a week in knowing what is what and why it exists.  The architecture content helped me.

I continued to explore the product and system; read the engineering documents and spoke to programmers when I had questions.  This helped me to test this product.  I'm testing it for 4 months now and it does not have SRS yet, though it is an ML product being built and used by customers (technology companies) for 10+ years now.  

The new features, design changes (not the UI), and fixes are being rolled out.  At this point in time, while I'm writing this line, I get a Slack ping saying -- "Upgrading and improvising the algorithm; it will take an hour.".  And another programmer pings saying, "A change in classifying algorithm for correction bug is committed and the pod is up with changes."   I'm not sure what are these changes nor it is documented anywhere. 

I will explore, figure out and test!