The Actual Performance Bottleneck is a Test Engineer's Awareness & Practice

 

The bottlenecks are necessity.  We cross bottlenecks everyday; just, we do not observe it.  If you have not read my today's thought on the bottleneck, read it here.  

The seventh question from season two of 100 Days of Skilled Testing is:

What are the common performance bottlenecks, and how do you go about pinpointing and resolving them?

I have a different opinion and thoughts to share on this question.  It may look weird, but, I see this is the reality.

Let me share what happens to a practicing Test Engineer when going through a bottleneck in practicing a subject to upskill.

• The time taken to accomplish tasks and its milestones looks unusually high - the other extreme end.
• Some attempts will not even kick off on entering the bottleneck for several reasons. 
• One of the reason is the fear and what my peers think if I fail to accomplish it.
• I lose the focus.
• It leads to lose of interest, unhealthy confidence and the inconsistency.
• The procrastination kicks in.
• Without no self-motivation, determination and consistency, we give up; clog and remain in the bottleneck.  One will fail to make use of the bottleneck to scale self.
• One do not go back or come out of it.
• We start to blame the bottlenecks.
• But, we fail to understand that the bottlenecks are part of the system.

What makes one to have a hard time with available bottleneck is,

• Ignoring the bottleneck.
• Not being aware of the benefits and impact from the bottleneck's existence.
• Its effects are adverse in a longer run
• Likewise, its benefits are immense in a longer run

If seen, the existence of bottleneck has two extreme ends -- good and not so good.  The bottlenecks cannot be eliminated or eradicated; it can only be managed with awareness and knowing how to adapt and scale through it.

Me, The Actual Performance Bottleneck

This may appear as a critical self evaluation.  But, it is not.    In my experience and practice, I'm learning consistently,

• If there is any difficulty in communicating about the tests and identifying the information from my tests,
• It is do with me for first.
• I will have to communicate it and why it is so.
• If I'm not exposing myself to a subject's area and its practice by putting the subject to test,
• I'm the bottleneck.
• Further, the other bottlenecks that I encounter from all other systems, it easily compounds the problem and its impact.

Did you see the bottleneck is a necessity? It drives me to scale and be operable.  If no bottleneck, may be, I will not expose myself to the awareness to identify and learn the information.

Call out any testing with a name, for first I will be the bottleneck to myself and to my testing, if I'm not aware of it and not practicing in it.

For example, I'm asked and taught to do functional testing at a GUI layer.  Why I'm not asked and taught to do the performance and security tests at a GUI layer?  Or, why I do not think of it?  Should someone say me to think of it, practice it, and, do testing for the same?  If the floor and industry do not push me to do so, I will have to open myself to create that opportunity and awareness.  Did you see that, this is my performance bottleneck?

To test, evaluate and identify [pinpoint] the performance bottleneck in the software system, I will have to practice Performance Engineering & Testing.  Only then, I will be able to identify its existence precisely before pinpointing.  If I do not practice by building and refining the awareness, I cannot explain what I'm pinpointing.

I pinpoint myself [the bottleneck] first, if I identify wisely what is the performance bottleneck.  If I fix my bottlenecks, I will be able to identify bottlenecks in the system that I test.

Let me practice the performance engineering and help my team, and community to practice it.  If not, I will not be in position to name a bottleneck, forget pinpoint it. I will just follow, what others say and think it is right.

Note: I share the above from my personal experience in testing practice and also from reading [& answering] the performance testing questions that are posted in the communities social spaces.  I see fixing this and practicing better here is important for first, than identifying and solving the bottlenecks in software system.

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.