Empathy - Missing in Engineers. Then, Why Think Like a User?

I did not know about the word 'empathy' in English.  I heard it for first time 15 years back.  This does not mean, I did not have or express or share the empathy.  

We engineers talk about empathy to the users when building the software.  That is, think like a user.  If you are a test engineer, testing, then you should have heard this.  And, you should have asked yourself -- "How will the user feel with this?".  Did you?

When you write a bug report or any test report, you think and ask yourself, "Can this be easily understood by the reader?".  Won't you?

You are having the thought and an emotion of empathy in that thought and question!

How's the Empathy of Engineers for Engineers?

Anytime, you asked these questions to you?  What do your voice say?

1. Do I truly listen to my colleague and peers?
2. Do I document?
• How well and lean I document so that fellow engineers can use it?
• Can they use it in my absence?  Does it serve?
• For example, 
• How well I name the variables, so that, someone who is reading my code can make sense out of it?  This is empathy to your colleagues.
• How well I write the test engineering related testware, so that, it serves my fellow test engineers and others?  This is empathy to your fellow testers.
• Before thinking like a user, think -- How my fellow testers feel for using your work and communication?
3. Do I consider how my words and behavior affect the people I work and collaborate with?
4. Do I listen and respect my colleagues and peers view while I discuss and share my perspective when it differs?
• Am I ready to accept the same treatment and communication that I share with others?
• Do I share and communicate my perspective and intent for first?
5. How do I interpret other person's understanding and thought about a subject, work and practice?

If you are a programmer, 

Ask yourself when and how you respected your fellow programmer and testers thoughts and work?

If you are a tester, 

Ask yourself when and how you respected and listened to your fellow testers word and work?

If you are a manager or director or VP or CxO role person for engineers, 

Ask yourself, when was the last time you listened and tried to understand the words and thoughts of your programmers, testers and other roles?  How did you listen and communicate?

• How did you help your teams and a team member to understand your point?
• Did you consider one of your team members as your team?
• Did you say anytime, she/he knows better than you, to any of your team member?
• Did this end or impact the communication thereon between you two?
• Further, ask yourself and list out the incidents that you could have avoided a situation and communicated well with dignity?

It is easy to say the slogan, "Think like a user".  

It is much easier to say this to your testing team.

But, it is not easy to think from the point of your colleague or peer.

Why?

What stops you?

Empathy Starts Within - A Message to Engineering Leaders

As leaders, we often say,

"Think like the user."

It is a powerful principle.

But, here is the question.

"Do you think like your engineers?"

You hired your engineers by conversing with them.  What are your efforts to make your engineers understand your thinking?  What's your principle on this?

If you cannot think and respond to the point views of your colleague or peer or team, how can you think and build the software system for a user?  Yet, say from decades, "Think like a user"!

Let me ask this.  Anytime, you tried to impose or overrule the testing team's thoughts, pain, voice and perspectives?  Or, did you talk to them to understand it and then shared why it should be the way you are deciding?  

Did you think as your test engineers and test team?  And, you want them to think like a user?  How?  

I'm not saying to agree and acknowledge to whatever the test team say and ask.  But, are you aware that, you work with test teams?  They are one among who consumes your decisions and work to deliver as a team.   What's your empathy to them?  Also reflect on what's your empathy to other teams?

If you cannot communicate well and help them understand your points and need of the business, then, how effectively as a team can we deliver value to the users who buys the service of the business?

When no empathy to fellow engineers on the team by an engineer, and, by the one who is heading the engineering teams, how can one have and express the empathy for the users who buys the service of the business?

Do you have the empathy for the engineers in your team?

Do you have the empathy for the teams you lead?

What is empathy?  What is your empathy?

I understand, in the business and with an executive role in business, empathy has scale.  What's your empathy scale for your engineers?

To end here for now, before the users, let your engineers and teams experience your empathy.

 

When Does the Community Choose Not to Respond to Questions?

I read the testing, automation and test engineering related questions posted on the social media and web.  I try to understand the question, problem expressed and collaborate to assist.  I do keep 46 minutes in a day for this activity.  

Sometimes, it is hard to assist reading the question.  I feel like not giving up; but, then I do not see the communication happening actively from other end.

What Makes It Hard To Assist?

The questions asked,

• It will lack the context.
• It does not tell who is the person and what she or he is trying to accomplish.
• It will not have information on
• the environment.
• what is the challenge he or she is facing.
• what she or he tried so far.
• It will not have minimal data as
• screenshot, exception stack trace, the complete error message and details following it, data being used, code outline, and more details to the context.

The above are minimal data needed on removing any sensitive information.  Know and understand what is sensitive information for your context when you are sharing.

Then, what do the question will have?

• Most will have a phrase or a couple or three sentences of what they are doing and what is seen on the screen.  And, asking what to do for what is seen on the screen?

Why it is hard to assist with vague details?

People who want to assist won't have any context about you -- who you are, what you are doing, or why are you doing it that way.  They won't understand your purpose or what you are actually experiencing based on the limited and vague information in the questions.

Without clear details, it is hard to connect the dots or pinpoint the problem.  Instead, people who want to assists will be guessing, making assumptions, and probably considering multiple possibilities.  Is this a way to use the time in community?

When questions follow a similar pattern but vary in challenges and context, it becomes demotivating to decode them.  Over time, people will lose interest in reading unclear questions, leading to fewer responses and missed opportunities for meaningful discussions.

What's happening at other end?

People who want to collaborate and assist will take the time to read the question.  But, when a question is too vague to understand, they often give up.  And, they feel bad for doing so.  The question remains unanswered.

When a solution is provided, there's often no update on whether it worked or not.  Those who contributed keep checking back, only to find no response.  Is that fair to those who invested their time to help?  Would you feel good if you were in their position?

Remember, in the community one can't buy someone's time to listen or solve a problem.  It has to be earned!  And, it has to be earned every single time.

How to Frame and Post the Question?

There is no one excellent way of doing it.  Then, what should I do to post my questions?

1. Know the community.
2. Read through the questions shared earlier in that community.
3. Look at the questions that have found resolutions, acknowledged and accepted.
1. Observe how the question or problem experienced is described.
2. Look at the details shared and how it is shared.
3. Look at the context details shared and how it is shared.
4. Observe how the interactions and conversation is taken forward from the two sides.
1. Closely notice the words and how the energy is kept high in both ends and how each side is pushing for it.
2. Importantly, look at the time taken to respond from both ends.

I do not want to share an example or reference saying this is the way to do it.

You figure out for your problem and to its context.  Share the minimal information said above and ask for the help.  Consistently improvise on how you ask, share and describe the problem.

Caution! Know This Before You Prompt For Your Testing

My Fellow Test Engineers,

If you are using Gen AI and LLMs as an aid to do better work, yeah, we should be exploring it.  I have no second thoughts in it.

Are you giving anything bounded by NDA to Gen AI models and LLMs?

• Like a part of software requirement, video, an image, code or anything that hints what the system is?
• That is, is this part of your prompt text which you are giving to the Gen AI model(s) and other LLMs?  If so, do exercise the below questions:
1. Do my organization and its business see any threat and risk from me for doing so?
2. Does it violate the NDA (Non-Disclosure Agreement)? If yes, how will I be impacted and prosecuted by the employer's business and organization?
3. Will I be terminated from my job or contract for doing this?
4. Will I have to face the legal consequences?

I tell you, for today's LLMs, it is sufficient to have gist of requirement or code or video or an image to isolate one's request. From there, it can monitor fairly better with additional anticipation.

My questions:

1. How would you trust the models behind?
2. Do you know how it is observing especially when you use your business identity to login and prompt?
3. Though you have customized the LLM's model and it is in within your environment, how do you know it is not connecting to its vendor environment and updating the gist?

Let us leverage the prompt engineering, Gen AI and associated LLMs. But, be aware and conscious of what we are giving out!

Also, be aware of what you tell to fellow test engineers. Not all Test Engineers or SDETs think of the consequences; instead just blindly mimic or follow what is being done or said to do by trying and using it.

Let us think about what we are passing to community by just saying to use prompts for --  to write test cases for this given requirement; read the given requirement and give a test design and strategy; review the code snippet and more.  Such loose and vague messages can be harmful if it is blindly followed!

By prompting the text and calling it out as prompt engineering, we might be giving out what we are not supposed to in the context of our employer's work. Caution!

Is Software Testing a Cost to Business?

How quick one gets to have the awareness of the cost and value in the trade, it will be of help.  I consistently exercise the below questions in my practice.

• What are the Values added from my work to the business?
• How do I benefit from this?
• What are the Values removed from my work to the business?
• What does it bring to me?
• Who is not getting benefited from the Values I'm adding and why?
• What are the loses and its impact?
• What are the benefits and gains we are losing?
• Who is getting benefitted from the Values I'm adding and why?
• What are the benefits and gains we are making?
• What are the Costs added from my work to the business?
• What are the impacts?
• How does it impact me?
• How does it benefit me?
• What are the Costs removed from my work to the business?
• How does it benefit me and what do I gain?
• How does it benefit the business and others?  What do they gain?
• Who are all experiencing the Costs from my work and why?
• What are the pains from these costs?
• Who are not having any Costs from my work and why?
• Do they need anything from my work and its value add?

This exercise will help me to know the expectations of stakeholders and business. I align myself to deliver the expectations as I exercise these questions.  

The cost and value from my software test engineering work will have impact and influences my growth with the benefits that I will make.

Is Software Testing a Cost to Business?

I witness the discussion which says testing is a cost in software engineering business.  But, I do not hear the same statement on development.  This made me to think, why?

Here are my understanding on thinking over it for now.

1. Software development is not about just programming.
1. When said development it includes every teams and their work.
2. Programming and Testing are parallel activities in the software engineering which helps each other.
3. If testing is a cost, then for sure, programming is also a cost!  It is an associated activity.
2. In business, every activity and investment on them is a cost in multiple ways.
1. These are evaluated costs and being taken for a purpose in expectation of returns.
3. Have I come across anyone saying Automation in Testing is a cost, like I hear for testing?
1. It is seen as investment and necessity. Why?
1. May be, because, in a belief if [once] automated, that is sufficient enough it goes on for itself without human intervention.
2. If this is the thought, do you think we are doing it wrong?
4. Have I seen the discussion and statements which concludes testing for performance and security is cost?
1. If yes, how?
2. If no, why these two are not seen as cost?
5. Serving and well maintained engineering system is a trade-off
1. I see, we engineers and business choose what to trade-off
1. This decision can be on logical and non-logical basis; but, there will be a trade-off
2. Each trade-off has costs and values
3. What should I trade-off in the software test engineering and why?
4. What should I trade-off in the software engineering that we are doing as a business?  Why?
6. When one is offered a offer letter from a business, there is a CTC mention.
1. CTC means Cost to Business
1. Programmer has a CTC
2. Tester has a CTC
3. Every others in different teams have a CTC including the CxOs
4. We all [and our job] are cost to a business, who can add value and get the high returns

To end for now, I learn, everything and anything business picks up is a cost.  Because, there is an investment on it.  If there is no investment, is there anything happening or progressing and changing?

I do not want to get into discussions which says software testing is a cost.  I see such discussion is lacking in understanding the software engineering and intrinsic for first.  Software Development is not all about programming; the programming is one small part of it.

There are different teams that work together in collaboration to develop and consistently delivering the usable software systems.  In this process, everything in software engineering business is an invested and evaluated cost in the interest of returns and values that are expected.

It is time to know and ask "What way of testing and its outcome is a cost?" than saying and listening to -- 'testing is a cost', which is nonsensical.  This holds good for any activity in software engineering.  

Any serving engineering marvel is a calculated and evaluated trade-off.

Logarithm and the Expression of an Algorithm

I got to know about Logarithm in my High School.  But, I never knew it would be part of an engineer's life.  As a Software Test Engineer, I encounter the discussion that involves Logarithm often when testing an algorithm that is designed and implemented to solve a problem.

What is Logarithm?

I found this definition in Math is Fun. And, I see this is simple and straight.

How many of one number multiply together to make another number?

For example, how many of 4s make 64? 4 x 4 x 4 = 64.  

That is, when multiplied 3 of the 4s, I get 64.  Therefore, the logarithm is 3.

It is represented as below and said as "the logarithm of 64 with base 4 is 3".

• log₄₍64) = 3

The same can be written or expressed as exponent in Math.  That is, 4³ = 64.  The exponent and Logarithms are related.  The logarithm tells us what is the exponent.  

The logarithm answers the question -- What exponent do we need for the chosen base to get the given number?

John Napier introduced Logarithms in 1614 as means to simplify the calculations.

What Logarithm?

In the Computer Science, we use the Common Logarithm.  In my practice so far, when talking about the algorithms, I have been using Common Logarithm which is denoted using log.

The other type of Logarithm is, the Natural Logarithm. This is denoted using ln.

What is the Base?

One of the questions which is asked in discussion of an algorithm's analysis is what is the base?  This leads to question, What is the base that we should consider in Computer Science?

In my so far experience, I see, it depends on the context of an algorithm that is under evaluation and if it is of logarithmic nature in the time complexity and growth rate.

In the context of Computer Science, I see, the base do not matter much when equating the right hand side to the left hand side calculation.  But, one can pick the base that suits to context when needs to express the relationship of an algorithm under evaluation. The base need not be always 2 here.

Note: I understand below from the peer discussions for the logarithmic base in Computer Science:

The asymptotic notation focuses on growth rate and ignores the constant factors. Any two logarithms differ by a constant factor, and the base makes no difference.  Hence, I do not see base specified for a logarithm when using asymptotic notation.  That said, when I have a logarithm with a constant base, it is okay to not specify base.

When the base of logarithm depends on parameter (an input or any external configuration) to the algorithm and which is not constant, it is a better practice to mention the base.

In my testing experience for an algorithm's functionality, performance, complexity and growth rate, I see, the engineers keep the input parameters as configurable.  That is, it is kept as a constant which can be changed based on the need basis for the context.  So the base is not mentioned in the logarithmic expression for an algorithm most times.

If you see, my understanding is not appropriate in context of logarithmic asymptotic notation, do share your thoughts as comments to this blog post.  I will be happy to introspect and learn.

References:

• https://www.mathsisfun.com/algebra/logarithms.html

Do Your Bug Report Annoy You and Fellow Testers?

I read the quotes or thoughts often about the code being written. Like, write the code for other programmer and not just for you; so that, the other programmer can pick it in ease and work from there.  You should have come across similar thoughts on code.

Have you ever come across thought[s] that speak about the bug report being written?

The bug report you write, is it for you alone? Or, is it for the audience to whom you wrote? Or, is it for someone who picks it up and work upon later?

How good are the audience of your bug report on reading it?  How did other fellow testers feel reading your bug report?  How easy it was for you to read your own bug report and work on it later?  How smooth it was for other tester to understand your bug report and test the fix?

I experience this:

• A bug report with a precise and helpful technical details did not serve the audience and fellow testers
• A bug report with no precise and helpful technical details did not serve the audience and fellow testers
• A bug report with plain English and attachments did not serve

While I say, that, I see this helped most audience sometime:

• A bug report in plain English giving the context, little or no technical information and associated details

It has happened, that I have rewritten my bug reports on reading it after an hour.  And, I have rewritten the bug report of others as well after testing the fix.  In both cases, I "prevent" the pain which I and others go through to some extent.  At least, I hope so!

To end, I recall this quote of Martin Fowler

Any fool can write code that a computer can understand. Good Programmers write code that humans can understand.

I see, this holds good for a bug report as well.  All and any of us can write a bug report.  A skilled engineer [and test engineer] can write a bug report which does not bring unwanted pain to her or his audience.

Anytime, did you read your own bug report after 3 months of writing it? How deep was the pain and annoyance to know what it was all about?  Give the same bug report to your fellow tester or programmer or product owner; ask, what did they know from it.  

Backtracking of Testing, Security and Tools

 

When I started my software testing career in 2006, I was in this thought -- What tools should I use, so that,

• I can do the testing that is sought after
• I can test for performance
• I can test for security

Moving from a search for tools to building the mindset and attitude.  It is a journey!  It took me time to see this journey.  I hopped on to this journey in 2011.  I see, this is not an ending journey, while I know where should I go and reach.  I'm on this journey.

I had no mentors.  I had no seniors in software testing to guide and discuss on my thought process.  I had developers (programmers) who had little or no interest in testing; so it did not matter to them.  But, they have helped me to be better tester.  I'm grateful to them.  Then, the community was not so connected, organized and share the knowledge as it does in 2024.  The software testing was not considered or seen as a technical activity, then.  I have stood, fought, demonstrated and delivered my testing as a technical activity.  I'm continuing it.

Today, on 24th Feb 2024, I read the below question in a community's social space and decided to write this blog post.

Hey, everyone .... Can anyone please suggest a good tool for API security testing?

This question resonates in test engineers.  Most of we test engineers still look and ask for tools when it comes to security testing.  To test engineers, the performance and security testing are still a conception and activity with tools alone.  In reality, it is not!  If you are in such thought or you come across such question to answer, this blog post is for you.

Backtracking the Problem Identification

In programming, we have an approach by name Backtracking.  It is about exploring in possible ways to find possible solutions for a problem.  And, a best solution which works in context is picked.

What's the problem here?  Testing, Security and Tools. Are you with me so far? Let us backtrack this problem.

Note: I see a difference between the words 'possible' and 'all'.  Hence, I use the words "possible ways" and "possible solutions" and not "all ways and all solutions".

Bounties and Entry

There are reputed bug bounties for security testing.  To get into this bounties one has to showcase her/his discoveries and skills with her/his recognized portfolio.

The tools are accessible to all.  The community edition and licensed edition tools are available.  We use these both editions of tools.

• But, why not all of us with tools cannot get into such invited security bug bounties?  
• You will answer this question if you ask yourself.  Hope this backtracking should have helped by now!

The Security Engineering is a vast practice area in Software Engineering. There are dedicated security engineers in role.  But, we test engineers can take up the testing for the security of software systems which the team is programming and building.

I advise, a practicing test engineer

• To start with building an interest for security engineering.
• Consistently hone and build the mindset, attitude and skills needed for the testing the security aspects.
• Pick simple problems, solve it.  Do it consistently, while you explore the layers.

While this is done consistently, it is time to find the mentors in Security Testing. The mentors will assist you in practicing how to test effectively for security making use of simple contextual necessary tools.  Also, a mentor will let you know how to test for security without tools to an extent.  The tool is effective when known how to use it.  The tools help immensely only if I can test for security. 

To backtrack in a different perspective, did any tool that you use, find a P1 security problem [or risk] by itself in its scan?  Did your programmers acknowledge to that risk or problem?  I will pause with these two question to you.

Today, my testing for security is confined to systems that I test.  I test for web application, mobile apps, web APIs, and database.  I can assist here, if you do the home work and ping me.

Database: Finding the Tables Having Specified Column Name

 

In today's pair testing session with a mentee, we were testing for Database I/O.  We were on PostgreSQL.  One of the questions a mentee had is,

How can I figure out the tables having this column name?

Running through every tables and exploring if the column being looked for is present or not, is time consuming.  It is not a approach to take as well.

I went through this when I started the ETL testing practice in 2011.

Here is the query that works on PostgreSQL to find table names which has specified column name.

Query:

select table_name, column_name
from Information_Schema.Columns
where table_catalog='database_name' and column_name like '%column_name%'

It is a better approach to know the precise column name and using the condition as -- column_name='EmployeeId'.

This query should work on MySQL and MSSQL Server.  If not working on MSSQL, need to look into the FROM and WHERE clauses if it is vendor specific.

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 Agile & Testing: We're Pulled & Hidden from "Shift Right"

Do I Understand the Agile?

If I work in a project which follows the Waterfall approach, I still can apply the Agile Manifesto and the 12 principles behind it.

But, am I adaptable to the change and uncertainty for better ways of developing software and helps others do it?  This shows the mindset of me and others involved.  Have you heard this line, "every project that claims Agile, it has [a small] waterfall in it?".

Agile Software Development is not wrong!  It has values in what it says and for what it stands.  I have no doubts in it!  It describes how I perform a activity and respond to a situation in the software development.

Frameworks and Methodology

We have picked the frameworks which are under the Agile's umbrella. We pick the methodology that suits our work and have customized it to our contexts.

This is what Agile also say, the team will always need to adapt its use of a framework to fit properly in its context.  

Dr. Alistair Cockburn, says, the Agile methodologies are the conventions that a team choses to follow in a way that follows Agile values and principles.

The Agile is Not a Problem!

We do not collaborate well in solving the problem and say Agile is not working and creating more problems.

In reality, how we respond to the uncertainties and what got prioritized, it will derail us.  We derail from what we should be achieving as team [and as an individual] in a given time frame and context.

The Agile as I Understand

In a nutshell, the Agile is about

• Balancing effectively with collaboration in the context we are.
• Identifying, learning and solving the problem as a team no matter where we are in the project's timeline.
• Being ready to face the uncertainty and responding to the changes.
• See the progress and value in what we do as a team and bring the "continuous" in practice.
• Having the consistency in the excellence of our work and the value we deliver with it.

Read the Agile Manifesto and its 12 principles.  It is the day-to-day life of a team who works to build a software in a continuous delivery having the values to a stakeholder.

Testing and the Agile

Testing is a collaborative activity.

The Agile also talks about collaboration as an essence and necessity in the continuous delivery of the software we develop.  

The Agile talks about short interval consistent deliveries.

• How should I fit myself as a Test Engineer here?
• How should I upskill myself to deliver in short intervals as part of continuous delivery?  

I ask and say to my test teams,

• Think of delivering value consistently in the shorter intervals.
• Rather saying -- releases in short intervals, call it out as a value to a stakeholder in regular short intervals as a continuous delivery
• It sounds positive, affirmative and profound.
• Upskill and help your peers to build the skills. List the skills, let us discuss and start our practice on it.
• This mindset changes the perception in how you approach the testing.
• In these short intervals,
• Let us prevent bugs in the ways we can think of.
• Finding bugs also need resources.
• Let's start investing in building and improvising the resources to prevent bugs.
• How can we prevent and where to begin?
• For what should we test and automate other than functionality in these short intervals?
• What is the priority?
• If I do not test and automate for evaluating any particular quality criteria, does it impact the value to a customer in what we deliver?
• If I do not test and automate on a particular seam and system's boundary interface, does it impact the value to a customer in what we deliver?
• How am I collaborating with stakeholders?
• Who are my stakeholders?

In short, I see the Software Test Engineering practice in the Agile setup as this,

• We [team] exploring technically and analytically;
• Evaluating collaboratively in the software development and engineering, by having the effective staged feedback loops in place to improvise the delivery;
• By responding actively to the changes and uncertainties that comes anytime in the timeline of a delivery and practice;
• Thus, the consistent continuous delivery is delivered with value to the stakeholders.

Note: This is my observations so far having worked with 46+ startups in my software test engineering practice.

We're Pulled and Hidden From - Shift Right

I and you are said to Shift Left and start the testing from the inception of a feature's discussion.  And, further we're said, we have to shift left from right.

Did the Agile manifesto and its 12 principles say explicitly to Shift Left from Right?  Who said that?

What I see, How I see and understand the Right and Left here, matters a lot!  If I see the Right within the delivery loop, I'm setting a trap to myself to be late and lag back.  And, probably this trap gets set in the work, that is, to see the Right in the [continuous] delivery loop.  At certain context in continuous delivery loop, starting from Right is a need and necessity.

I see the Right outside the [continuous] delivery loop, as well.  In this Right, I see:

• What is coming up in the tech stack and technology?
• How this is a need?
• How this [is to be and] will be adapted by tech solutions we deliver?
• How should I upskill myself here so that I fit into the loop of continuous delivery?
• In short, the Right should be observing the trend and its analysis so that I'm aligned being agile.
• I will be skilled to test and automate in this change and uncertainties.

The Agile never said to completely move or step out of the Right.  Or, I have not read it in its manifesto and principles. 

You see and learn, what is your Right and ask am I aligning to it for being agile in the Agile.  After all, the Agile says adapting to the changes and uncertainties, yet delivering the value to the stakeholders consistently in short intervals.

If seen closely, the Agile is also about balancing, isn't it?  If I'm moving towards Left and me standing in the Left, am I balanced?

In short, we are being pulled and hidden from Shift Right.

Shifting Right is important to see what is outside the delivery loop.   Are you seeing your Right?  If yes, what is the trend analysis you see?  Where you need to upskill?

Shift Right can also be to look what you can bring into your Shift Left for better development and delivery.  For example, what you see in the market and business space for your product?  Do I have anything to add now in Left from this learning?  Do you see that?  Are not we missing this when we pulled and hidden from Shift Right?

Left or Right, if I do not respond, adapt and deliver for the changes, I need to ask, -- Am I agile and testing in the Agile?

To conclude, know what is your Shift Right while you are delivering values in your Shift Left.  Strike the balance and ace.

Exploring to know the Web API - 101

 

Here is what I look when I'm exploring to learn an end point of web API for first.  I'm talking of the Web API that uses HTTP protocol.

1. What is the purpose of this end point?
• How it helps and to whom?
2. Who uses this end point?
3. Identify the host of the end point
4. Identify the path of the end point
5. Identify the API's end point
6. Identify the version of the end point
• Know the different version that are available for an end point
• What are active?
• What are inactive?
• Who are the consumers using these different versions of this end point?
• What's the difference between these versions?
7. Identify the HTTP method of the end point
• Know the different HTTP methods this end point supports
8. Identify the resources the end point interact with for CRUD activity
9. Know the HTTP Request headers it needs, uses and good to have
10. Know the HTTP Request payload or data and its format
11. Know the HTTP Response headers and good to have
12. Know the HTTP Response Status Code and what actually it should be returning
13. Know the HTTP Response content and format returned
14. Does this end point enforces any contract with the consumer?
15. Know the intent of your test on this end point
• One test in one request is useful unless the context demands otherwise
16. Is there anything cacheable in the end point's response?
17. How the request payload is?
18. How the response payload is?
19. What is the language in which the end point is written?
20. What is the language in which the resources that end point updates is written?
21. Any framework used to build this end point?

On learning this, I continue to next phase in exploring and knowing the web API.

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.

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?

JSON for Software Test Engineers - 101

 

In the practice of Software Testing & Engineering, I became aware of the below:

• UI (User Interface) is not just GUI (Graphical User Interface)
• UI is an interface through which a user interacts with a system
• UI is one of the touchpoints
• Data we exchange between the two systems is also a UI
• This data can take different formats
• Text
• HTML
• Image
• Video
• Audio
• XML
• JSON
• YAML
• PDF
• custom-defined data format
• and, more

Note: Refer to the MIME types and know what type of media is supported and used in the system you are testing and automating.

Testing Through Data

When the data can be used as a UI, it also means one can do the testing and automation through data using data.  From this perspective, it is important to know the data format.

I see JSON is one of the common data formats we use to store and exchange data between two systems.  Understanding how the data is structured in JSON is important for a software test engineer to think and evaluate the testing and automation through the data.

JSON For Test Engineers - 101

I documented my understanding of JSON and how to interpret it in the gist here. This markdown file has my learning.

Test Automation Pyramid and Its Multiple Misinterpretations

 

I Decided to Write this Post

I thought over a few months, should I write this post. I said, yes to myself for writing this post.  Before, I proceed, I want to express this:

Hello Mike Cohn, thanks for giving Test Automation Pyramid visualization to the software engineering community.  I see your thought process, experience, and work, in this model. This model's assistance to understand software systems is evident today.  

Again, thanks for giving this model as a metaphor for us.

What I See?

I see a risk for the Software Testing community especially when we use the word The Test Pyramid without knowing what it is and does it make sense. 

To keep you till the end of this post so that you get what is my point, I tell you this:

One of the common entities among Testing and Automation is the tests.  How the test's intent is expressed and executed in the testing and automation, is not similar; they are different and have to be different.  If similar, then it leads to misunderstanding -- automation as the only way of testing; or, the execution of tests by a human as the only way of testing.

Why did I Say "Yes" to Myself?

• The metaphor which Mike Cohn came up with is helpful
• I see, Mike Cohn knew what he is trying to say and it makes very much sense in today's Software Engineering
• His book Succeeding With Agile got published in 2010
• It has a chapter with title Quality
• I insist, that anyone who is involved in software development should read this chapter if cannot make the time to read this book
• This chapter talks about the pyramid
• The Test Automation Pyramid
• Mike Cohn came up with this concept
• This acts as a helpful metaphor and a heuristic
• In 2010, I don't know how much did it help then; but this model is a beautiful and simplistic explanation of how to categorize the software system's layers for test code
• In 2023, it helps everyone who is involved in the development of software system
• I have witnessed how software engineering has grown in the last 23 years
• Reading what Mike Cohn has to say about it, helps to clear the misunderstanding of The Test Automation Pyramid to The Test Pyramid, for first

Today the word "The Test Pyramid" is very common among people who are into software development. For this reason, is it misread and communicated?  Maybe!  The software engineering community refers to this model as The Test Pyramid and not as The Test Automation Pyramid.

I want to share my thoughts on the risks of calling it The Test Pyramid.

• I strongly see the software engineering community and importantly the software testing community need to know it

So, I have decided to write this post.

Quality Is a Team Effort

Mike Cohn, said this in 2010 in his book Succeeding With Agile. 

Today, who does not claim "We are Agile"?  Are your team and organization, Agile?

Yet, we see discussions on who should be owning and responsible for the quality while we are in 2023.  Especially the software test engineers ask this as they are said responsible for the quality of the software systems they are testing.

The chapter Quality has a section "Quality Is a Team Effort"; this section has the below lines:

Acquiring new testing skills, learning how to apply them within the strict timeboxes of Scrum, and paying off technical debts are the responsibility of the whole team.  These are not challenges to be sloughed off onto the testers.

Quality is everyone's effort and responsibility.

Test Automation Pyramid

Automation is one of the ways we do the testing.

Here are some of the tests (actions) that can be done through automation and asserted:

• Which are repeatable and can be asserted
• Which are run to setup, tear down, configure, create, edit, read, and delete the resource 
• Which are monitoring to inform the change in state/event/data
• Whose execution is in a defined order and trying to assert the expected outcome

Some tests are better evaluated via automation and with the help of automation.  Some tests are better evaluated by the execution of a human.

• Both are important and necessary in today's Software Engineering and Software Development

Back in 2010, the boxes were monolithic; the microservices were a theory.  Today, we are thinking beyond microservices, containers, serverless and more.

Given the complexity of  Software Systems, today, we need a model of how we can isolate it into categories and layers.  So that it is simple to learn, understand, to categorize the development of code & test, and execute the testing of same.

This is where I see the usefulness of a model given by Mike Cohn.  It shows the layered architecture pattern in a way, for a [part of] software system:

• That we are about to understand, and 
• Figure out the strategy for testing using automation in respective layers

Now, do you see the importance and help of the Test Automation Pyramid model?

Mike Cohn expressed the three layers in Test Automation Pyramid. It is as below.  I have copy pasted this below image from his book Succeeding With Agile. That way, I keep the original thought and picture of the model as given by the author.

Pic: The Test Automation Pyramid from Mike Cohn

Pic credits: Mike Cohn

Benefits of Test Automation Pyramid

• It helps to relook into the automation strategy
• It says, we need a better strategy to automate by showing us to categorize the tests in a layered pattern
• It helps to learn how the two different layers can communicate and can be used together in automation 
• For example, the service and UI
• So that tests are isolated and maintenance is manageable, while the deterministic feedback obtained from the tests automated is value-adding.

I have heard Dorothy Graham say she did automation when she started testing.  I see she has 40+ years of experience in Software Engineering & Testing.  So, automation is not new.  It is evolving.

This Test Automation Pyramid describes the automation which we talk about in day-to-day engineering to be more understandable and communicative.

Is This a Test Pyramid?

I understand, Test Automation Pyramid is not The Test Pyramid.

It is a pyramid for the tests carried out through automation.  

Test Automation Pyramid helps to identify, design, categorize, relate, map, and use the outcome of tests from another layer.  This benefit can be sought in both, that is, testing through automation and testing by a human.

This is a risk I see

• The Software Engineering and Software Testing communities are learning that automation is the only testing and the only way to test.
• No, it is not the only way to test and it is not what is testing all about
• Automation is one of the ways we do our testing and has its limitations
• Automation is a subset and a part of Software Testing
• Automation exists to assist Software Testing and to do better testing as a whole; not to replace the testing; not to claim it is the only testing and way to test in every dimension and context
• This is a problem for the upcoming generation of software engineers, and those engineers who take Software Testing as their full-time practice and job
• This sends a message that automation is testing and testing is automation
• This will be the problem to the practices of automation and testing in Software Testing
• For example, when I talk to test engineers and say, Test Automation Pyramid, I hear they are not aware of it; all they are aware of is The Test Pyramid of three layers used for automation
• As a result, there will be shallow results and benefits from both automation and testing with costs and short of value
• Here, automation and testing cannot complement each other effectively when used together

Calling it a Test Pyramid and referring it to just to talk about automation, is not right technically and logically.

I see Mike Cohn knows the differences between the value of Testing and the value of automation in testing, as different activities from his work and experiences.  I believe, for this reason, he labeled this model explicitly as The Test Automation Pyramid.

I did not find any references for Mike Cohn renaming this model as The Test Pyramid.

Also, calling it a Test Pyramid and the top of a triangle having a scoop or cloud with the name "Manual Testing" is misleading.  I see this is one more cause of confusion.  Does this triangle say to automate at every layer and just involve a human at the GUI interface for testing?

• No! We, humans, test at the service layer as well and also automate here
• At the unit layer,
• a human manages to setup/configure at the seam or/and use test doubles, stubs, mocks, and what is needed to execute the tests via code
• If you see, one pyramid, misinterpreted and misrepresented in multiple ways.

I learn, as a community, we are misinterpreting the Test Automation Pyramid model [work] and calling it by another name.  Is this right?

If one sees no difference between testing and automation, fine!  Then everything is applicable and looks alike.  Then calling Test Pyramid and Test Automation Pyramid does not make any difference.

But, actually, it is not the same [and similar].

The common thing between automation and testing is the tests.  The purpose, nature, procedure, design, strategy, and intent of the tests differ in automation and testing.

It is Test Automation Pyramid

We Software Test Engineers, think [of] [the] tests as automation most times because we believe and are said the programming and code are everything in the software system.

• The code of a software system is one of the byproducts of developing a Software System
• So are the tests.
• The test code is one of the byproducts of automation and not the whole software system

A part of the test is automatable. Which part? 

• It depends on how I express my test with its intent
• So that I will know which part and aspect of a test can be automated

Automation in testing is one of the subsets of Testing, but NOT similar to Testing in every dynamics, dimension, and aspect.

Automation has its own subsets of dynamics, dimensions, and aspects of testing.  If we practice by learning Testing and Automation are the same and if we remain in this understanding,

• We cannot identify
• The differences between Testing and Automation
• The differences between the tests identified for Testing through Automation and Testing by human
• The values each offer along with its limitations.

Referring it to as a Test Pyramid and just talking about automation out of it, is not Test Pyramid.

I call and refer it to as Test Automation Pyramid and not The Test Pyramid.  Again, I thank Mike Cohn for giving this clarity in his model and its name.

Let us refer to Mike Cohn's model by the name and understanding to which he refers it with.

If you ask/say, "it is a model; can't we improvise it to one's context?" 

• Yes, we can and a model is not fit for all contexts
• Showing the same model picture along with the same name for its attributes and expressing a different thought is a problem
• It misleads one if she/he takes this model as a reference
• This will have chains and it continues

To end,

• Embrace programming
• Practice programming
• Embrace automation
• Practice automation
• Implement automation
• Call and refer to automation as automation
• Know what is testing in automation
• Know what is testing
• Call and refer to testing as testing
• Practice testing
• Know your testing in Software Test Engineering
• Call and refer to the model with its name given by its creator/author
• That name has a purpose and intent
• Know it; understand it; learn it

References

• The book "Succeeding With Agile: Software Development Using Scrum" by Mike Cohn
• https://www.mountaingoatsoftware.com/blog/the-forgotten-layer-of-the-test-automation-pyramid
• https://martinfowler.com/articles/practical-test-pyramid.html
• https://medium.com/tide-engineering-team/the-practical-test-pyramid-c4fcdbc8b497

Maven For Software Test Engineers - 101

 

Why 101s?

In the initial days of my career, I looked and referred to multiple sources to understand the technology stack.  As I progressed, I looked for someone who can help me in understanding what I'm reading and to clarify the questions I witnessed.  The understanding of concepts took time when I actually started using it and especially when debugging.

Today, if I look at that, I ask myself

• How can I make my learning experience a happy one?
• How can I capture the fundamentals and have a smooth revision of it when in need?
• What can I have for my reference when I'm implementing the fundamentals?
• How can I increase the speed in which I do all these?

If seen, I want to help myself to be better and effective when solving a problem by implementing what I'm learning.

Maybe, other software test engineers too have same question.  Don't you?

I'm learning new stuffs, and also unlearning what I'm learning.  I create the 101s for myself.  I see the software testing community can also make use of these 101s that I'm building.

Why You Need Maven 101?

• Today, it is a common sight that one quickly picks up a boilerplate code and run it
• Especially with the software test engineers, who wants to start/practice automation
• Pick a framework and run a command
• Execute the program successfully
• Or, get stuck in between and do not know why is that command
• Or, see an error with that command and not sure what that command is doing
• What is the difference between these commands and what does it do?
• As this, one can get into different contexts where one gets trapped; not blocked
• How to help self to navigate out from here?
• I see this 101s can come to help

Anytime, you picked a Maven project and built it?  For example, a Selenium code written as a Maven project.  Do we know what Maven is and why the Maven project here?  And, what these different Maven command means and what it does?  For having this understanding, this Maven 101 comes to your help.

Maven for Software Test Engineers 101

I have my Maven 101 here.  I refer to this source when I revise my fundamentals.  This can be of help to you as well and also can be a start point.

This has helped me to understand the different build life cycles and how a Maven command is all about the plugins.

I have provided the Reference section which is also a credit that I give them for helping me to unlearn and learn better.

HTTP Request Methods - DOT 3P HCG

 

Today, in the morning session with a mentee, she asked, "I have difficulty in remembering all the HTTP request methods and what it does. How can I make it simple?"  

I had the same question in the end of 2009 when I started testing the applications built using the HTTP.

Learning, and Registering the Learning

When I read, I forget it, because it is not yet registered in me consciously.  How to learn in a way so that it registers in me? I had this question.  Especially, when I started my career, I had this challenge.

In the college days, I had formed a tricks and hacks to remember and the mnemonic was one of them.  In 2008, I came across mnemonics in Software Testing.  I saw the mnemonic used by practitioners in Software Testing as one of the learning techniques and to register and retrieve the learning.

I repeat my learning in multiple approaches until I understand a concept. Then I form a layer where I make it simple for me to register it, in me, and to retrieve.

I applied the same with the HTTP request methods.  It became simple to me to recall and use it in my test designs when needed.

DOT 3P HCG

I helped myself by framing the mnemonic DOT 3P HCG in 2010.  I had difficulty in recalling the HGC part. For this, I said to myself -- head, chest, and gut.  That HCG became smooth in registering.  Finally, I could recall all the HTTP request methods with this mnemonic.

DOT 3P HCG stands for:

• D: DELETE
• to delete the resource specified
• O: OPTIONS
• describes the communication options for the targeted source
• T: TRACE
• used for diagnostic purpose and does a loop-back test along the path to target resource

• P: POST
• to submit an entity to specified resource
• P: PUT
• to upload/update an entity that is saved on server at a specified endpoint
• P: PATCH
• to do a partial modification to a resource

• H: HEAD
• Ask for a response which is identical to GET but without a response body
• For example, fetching the expiry date in a header as a response so that it can be used in the next request's header or a payload
• C: CONNECT
• To establish a tunnel with a endpoint or server for communication
• G: GET
• To request a representation (an information copy) of specified resource

As the HTTP request methods name are verbal, I can recall easily the purpose of each method.  I shared the same today with a mentee.  She could register it in a minute and recall these HTTP request methods and its purpose.

She is happy and says it is so simple now to recall the HTTP methods and its purpose.

Technically, What is a Bug?

 

I'm mentoring the Software Test Engineers.  In one of the pair sessions with a mentee, we were discussing the technical aspects of one technology.  We started to test the application and a mentee said, she found a bug.

She explained the bug.  Further, she asked how, can I explain this bug technically.  And, going ahead, she asked, "Can you technically tell what a bug is?"  

Technically, What is a Bug?

I have come across various definitions of a bug from other software testing practitioners.  If I have to tell technically what a bug is, I put it this way:

• A bug, is a logical incident experienced
• It is logical because the programming instructions written are logical
• Technically, the bug is a logical incident