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.

 

My Advise to a Software Test Engineer

I was discussing with a Software Test Engineer post meetup.  We two stayed back for a couple of hours conversing on various topics and how to approach the problems.  He was assisting a recent graduate to get started in Software Testing.  His question to me was, "What all should I share and where should I start?".

I ask the same question to myself when I sit back and observe my practice and journey.  That is, 

"Ravi, what is the one advise you give to your younger self when you are starting career and practice in Software Testing?"

That question of him resonated in me as I listened to him.  I said him, 

"I ask the same to myself. I align; I'm a beginner resetting and starting over everyday using the learning of till date.".

Note this; what I'm saying here it is my experience and learning.  I feel, it make sense to me in my contexts.  You evaluate it and take it to your context.  Nevertheless, I see it is sensible advise and it should be must in your practice the day you start to practice Software Testing & Engineering.

My Words and One Advise

This is a advise I give to younger myself who is starting the career in Software Testing & Engineering,

 "Practice programming!  This should be your day to day activity [practicing programming] to improve your testing skills.  It is critical and elemental to be a better Software Test Engineer.  Do not ignore it.  Embrace programming and leverage your testing."

Any other skills that you hear or said, you can apply them on your programming practice work.  Evaluate it.

For example, if you hear skills as questioning, thinking, critical thinking, lateral thinking, and whatever, apply them to the programming activity and the code you are writing.  Take help of mentors here.  Know the boundaries to set and unset as you progress here.

That said, do not be biased and get stuck to just programming alone. The programming should aid your testing practice and skills, and vice versa.

If I'm testing a software and the general [contextual] systems with which it associates, I should know how the software is being implemented, how it communicates, and manages.  This is essential and necessity for a Software Test Engineer.  This is a need!

Being away from programming, I will fall short in the ways I think of the tests and how I test.  The software that I'm testing is composed from the programming along with other general [contextual] systems integration [specific to the contexts].  If I cannot identify, learn, write and understand the composition of software, I have to think about my testing and question it.

For example, how would this blog post get saved and published when I publish this draft?  What goes behind and in front?  If I cannot see the layers here and understand them, I cannot test better.  Maybe, I can see them to an extent without programming skills.  But, the programming skills gives the different perspectives to the testing, automation and test engineering.  The advantages of these perspectives are unparallel and helps immensely when identifying and designing the context's priority and critical tests, and its samplings.  Hope this makes sense to you and tell how critical it is.

To end this post, I summarize it as,

• I do not have to practice programming in the scale for being a full time skilled programmer.. I practice programming to be a full time test engineer whose testing is sought after.  I stand here for today.
• Practice programming to engineer your testing better.
• Apply all other skills which you see as important to test the code that you are programming in your testing practice.
• If you are starting to practice Software Testing, start from programming and test your program.  In testing this programming of yours, apply all other skills which are said critical for testing better, and upskill them in parallel.

Functional Testing Is Must In Performance And Security Testing

 

I'm sharing about how I missed to test for functionality while I was immerse focused on testing for performance of a Stored Procedure.  I was unhappy for a couple of days as I missed something that I practiced for years.  

I'm glad for reinforcing this learning with much more awareness into my testing's MVT and MVQT, now.

Context of Testing

A Stored Procedure was optimized for better execution time.  No change in the functionality.  This part of the system is not touched for a long time (years?).  There was no change in functionality here for long time (years?).  The time taken by SP was of concern.  I was asked to test for the optimization.

The complicated area, here, is the test data to use.  It took me days, for identifying and building the test data to test this optimization by mimicking the production incidents, use cases, and data.

When I got the test data ready, it was the fourth day of my testing this change.

Where Did I Go Blind By Being Focused?

The test data that I prepared is solely for the evaluation of the execution time.  This test data helped to test functionality as well.  But, my focus was on evaluating performance not functionality from this test data.

The change in SP did impact the functionality.  I was supposed to use the large data range to test for functionality of this feature which includes two SPs.  But, the task assigned was to test just one SP which is optimized.  I got blind here!  

Are you asking, what is the impact of this functional problem?

• In the one complete business work flow, this functional problem added the same data into different sets in the subsequent iterations.  Redundant Data -- This is not an expected behavior.

I just spoke performance, traces, data I/O and execution time, because that was a pressing problem.  Why?  That was the objective given to me.  

My testing mission fell short in redefining this objective.  If I had redefined it, I would, have added functionality in the better scale.

If I had redefined it, I would have pulled the other SP into functional testing which is also part of this feature's work flow.  These two SPs are expected to handle the data by eliminating the redundancy.

It was a simple test, but, I did not include/had that in my testing mission that day.

Why Did I Go Blind?

The performance test blinded me for functionality, as I saw the basic functional flow looked functioning.  But, the data count was going wrong when a bigger data range is used in the context.  

See here, how stupid I was in my testing!  I'm testing for a SP that has a change as part of its optimization for execution time.  I never brought the functional testing in.  Why?  I focused on the testing objective.

I just looked into one SP that is optimized.  I did not look the other SP which has to work along with this SP later to complete functional flow of the feature.  Why?  How is that even possible?  I was asking myself this.  I see, this is okay from the perspective of the testing objective I had.  But, not okay from the perspective of a test engineer who is supposed to think the impact and prevent the problems.

My immersed and concentrated focus on performance and its related activities on a SP for four long days did not let me see this.  

What Am I Saying Here?

While I have tested for DBs and ETL systems for years, I did not use my learning here.  What is that learning?

When there is a change in any part of the ETL, SP or DB of a system, testing for the functionality for the business workflow is equally important.  Vary the data dimensions and evaluate the counts.

I was completely hooked into the execution time and the test data while switching between the environments for four days.  The chaos in data between environments is something that misleads easily.  I fell to it this time.

I say to myself, if it is a fix for the performance optimization or a security [or any quality criteria], testing for functionality is equally important and of priority as running the tests for performance or security.

When a DB layer is picked for fixing and optimization, testing for functionality in a equal scale is must.  There is a change in the code or/and infrastructure and it has to be noted with additional attention.

To add on this, this time, I did not go through and analyze the SP.  I took this call from the test team.  This call of me costed and had a major part in letting me not to think of functionality.

My fellow colleague ran a test with varying data size by completing the business workflow and observed the problem, and informed me.  I give the credit to Sandeep.

If I had brought this performance test under the automation, I would not have done this.  Why?  I will evaluate and assert for each data returned for different sizes.  I did not automate here and there was no need for it in this context.

Redefine the testing objective that you have got; it helps when you see the model of a system and test.

Respect all the fix and suspect all the fix.  This helps in a longer run!  

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.

Behind the Every Test Data, There is a ?!

 

Read this blog post to have a perspective about the Test Data and Test Data Management.  The point is, if I'm not aware of a test and what does it tell me to explore, I cannot think of a Test Data.

That said, if I know what I should be evaluating as part of performance, why, when and how, this will help me to come up with a thought for identifying the tests and its test data for the same. 

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

What role does data management play in performance testing, and how do you ensure the availability of suitable test data sets?

Testing and "Ensure"

We test and have tests in testing, because, there is no "sure" and "ensure" idea in software.  But, we presume on a rational basis upon, "if, these are this", in a given context when the software processes.

Now, ask yourself, how can we ensure the availability of suitable test data sets?

In my opinion, the Test Data is often misunderstood.  This is the primary problem and should be the first problem, when asked "what are the challenges in creating the test data?".

When you read the concluding lines of this blog post, you will learn why I say this.

Test Data and Immunity

In my opinion and experience in practicing the Test Engineering, I see, the Test Data should be a viral strain and it should have its variants.  When this test data is used to test [experiment, test investigate, and debug], how do the software and its ecosystem respond?

• Does the software and its ecosystem is immune to this test data?
• Does it exhibit any risks and problems?
• If yes, then, do the purpose of my testing and automation is accomplished with this test data?

This puts me back to question, what is the purpose [intent] of my test?  It drives me to derive the test data which helps me to know -- What am I supposed to learn and on priority?  With this, I get an idea for what kind of test data I should be creating knowing its pattern.

If the system is immune to Test Data and not reveling anything new in the context, I classify this pattern of test data as "Immune" to the context.

In my practice and research work in Test Engineering and Software Testing, to start, I categorize Test Data into two areas.

1. Immune
2. Not Immune

Further, I have categories, under these two, where I classify the Test Data deterministically for the context.   Get in touch if you want to learn more about this.  I'm just one ping away!

The tests should help me to evaluate for the immunity and also non-immunity; both are essential and necessity.  

The credit is to me for such classification of Test Data.  It is my research work out of my practice.

Note that, Test Data is not just the input [characters or files] entered or given to a system.  Test Data has its association to tech stacks, infrastructure, ecosystem, business workflows and people.  To craft such Test Data, one has to have the understanding of the system and its internals, and, the problem it solves by knowing how it solves.

Performance Testing and Test Data

1. What is that I'm testing as part of performance?
2. What do I want to evaluate in the name of performance?
3. What part of the system is evaluated for its performance?
• Should I evaluate this in isolation or as a wholeness of the system?
4. What domain knowledge and information I should have when testing for performance?
5. What system's architecture and internal details I should understand and be aware to test for performance?
6. Is this the first delivery?  Or, do we have this system running in the production?
• If it is first delivery,
• How will I create the test data to suit the consumers of this application?
• What are the key workflows of business that we should be evaluating for its performance?
• Do all workflows and sub-systems need the evaluation for performance, and on priority?
• How do I map the fragmentation of users and their data [with its patterns]?
• What are the infrastructure and ecosystem characteristics that should be part of the test data identified?
• Does caching have any effect if the same pattern of data is used?
• If it is a running version in production
• Can I refer to the DB to figure out the pattern for the particular workflow that I'm evaluating?
• How can I match the test data to have the production data's characteristics and attributes?
7. What is the backup strategy for the Test Data?
• How do I version control the Test Data?
• Which version of the Test Data I should be using?
8. What is the threshold I'm targeting with Test Data?
• What should be the size of the data in DB when I make the IO and RW operations?
• What should be the network capability when I make the IO and RW operations?
• What should be the hardware capability when I make the IO and RW operations?
• What should be the geographical traffic and its pattern when I make the IO and RW operations?
• More of such factors will be considered when identifying and deriving the test data.
9. What is the client error yielding Test Data that I should have for the workflow?
10. What is the server error yielding Test Data that I should have for the workflow?
11. What is the redirection yielding Test Data that I should have for the workflow?
12. What is the no-response and no-change Test Data that I should have for the workflow?

And, more.  It is simple; get in touch to discuss and know beyond the listed.

To conclude and stop here, all these questions, do not ensure or assure or make sure that I will have test data for evaluating a characteristic of performance.

• It helps me to know:
• What are the tests I should be doing?
• What kind of preparation I should be having in my practice to create the Test Data for these tests?

The, Test Data should challenge the available Testability and its limits.  If it is not doing, then, we are having a test data no doubt about it; but, it is of shallow. Shallow!?

One has to ask self, "Is this sufficient enough and effective Test Data for the system [and workflow] I'm testing?"

The, Test Data should drive the engineering team to add more layers of Testability into the system.

Test Data is Not [Equal To] a Test

 

Not every release is a critical release!

There are releases which are critical from technical and business interests.  In such critical releases, most of my time is spent on understanding the technicalities of the system and the test data identification on identifying what are the priority tests.  Identify and building the test data takes major chunk of the testing time. This effort has helped me, testing, stakeholders, projects and products immensely.

Test Data != Test

Looks like the word "Test Data Management" has become a buzz and marketing word.  In how the word "Test Data Management" is pushed, to me it looks like the intent is missing for -- how to identify the tests and its test data?

• If I cannot think of tests, how can I think of Test Data?
• How can I think of tests, the right tests in the context, and the priority tests out of it? 
• If I cannot get this, how can I get the Test Data for all these tests?

Before talking of Test Data Management, we need to talk about the intent and goal of the test.  If I have a clarity here, by being aware of the product's technical internals, architecture and its eco system, I can think of test data in a better sense.  For first, the PaaS which provides Test Data Management solution has to push and enforce for learning and mentioning -- What is the intent of the test?

When I know, for what to evaluate and how should I be evaluating it, those test intent will lead me to the Test Data and its dimensions which should be vectoring the tests.  

Test Data is not [equal to] a Test.  Test Data is one of the variance, in fact, it is a multi-dimensioned variance that a test will [need to] have.  While a test has one deterministic objective, the test data will have multi-dimensioned vectors that instruments a test.

Test Data has its role in a test, and, it is a critical role.  Hence, we practicing Test Engineers talk and spend our time on Test Data in equal importance as we give our time to identifying, designing and execution of tests.

Test Data is not a test; but the test data is an expression of the test's intent.  Test Data is one of the byproducts of a test.  Having this clarity is important.

Note this, the test data is not the only expression of the test's intent.  A test will have multiple touch points; these touch points express, advocate and can show the intent of a test.  A test data is also a heuristic as a test is.

 

Test Data Management

The word "management" is underrated and not attempted to understand from context where it is being spoken.  How do this word sound -- "Test Data Leadership"?

In engineering, especially in the software engineering, the word "management" inherently talks primarily about design.  On day-to-day operation, the management designs its strategy and approach to solve the problem and challenges.  

When said "Test Data Management" in software engineering, it is about strategizing and approaching the problem of identifying and categorizing (subsets) the data to test.  A kind of leadership at one layer.  It has its role and critical to the deterministic outcome for a test.

In machine learning, we can see this categorization -- training data and test data.  Then, is training data not a test data?  It is!  The training data is designed [managed] to train and this data as well identifies the problem as the training progresses.

The data which are identified, designed, categorized and collected as Test Data, are well sampled data in the context, for the intent of a test.

To conclude, Test Data Management is one of the correlation in software engineering to solve a problem; it is contextual in how and what tests and testing is executed.  The different teams and organizations has their own way of managing the test data.  How they do it, it is their way of doing it.  We have to look Test Data Management from point of Test Engineering and not as an another buzz word to sell just as a product and business's service.

Is Performance a Perception to an Engineer and User?

 

When hearing about performance from customers and engineers on team, I see each are having a perception of it on using a product.  To one it was fast enough, to another it was as usual and for one it was too slow.  Each are expressing their perception.  But, what is the performance?

What is Performance?

I see, understanding and knowing "What is performance?" is important for everyone who is involved in building the software system and product.  In my opinion, this should be the start point.  It is beneficial, when everyone has a shared common understanding to it as a team and business.

Performance is an emotion to a user!  Technically, the performance has multiple facets to it for understanding the capability of a system and its sub-systems.

Facets of the Performance

What facet do you consider and call it out as Performance?  This is another point where most of us do not align.  For example, below are the different facets that we usually hear and read a lot:

• Heap and Memory
• Threads
• Not supporting for concurrency
• Not handled well in concurrency
• Holding up other processes and causing bottleneck cases
• Memory Leaks
• Concurrency
• Memory not reclaimed
• and, more ....
• CPU consumption
• Open connections and its I/O
• Held up in processing requests
• No enough resources to process
• and, more ....
• DB I/O
• Open connections
• Unindexed data
• SPs and Queries holding the transactions
• Incorrect configurations of DB Server and nodes
• and, more ...
• Disk I/O
• Running out of space
• RW I/O not responsive
• Network consumption
• Unmanageable transactions
• Transaction's data, size and time
• Latency
• Latency in which interfaces?
• Ineffective caching, queuing and messaging
• GUI not rendered or painted
• GUI exhibiting jank behavior
• GUI partially rendered
• GUI not in a interactive state
• GUI not responding to an action
• GUI and UI loading multiple times with no room for interaction 
• Terminal yet to return and show the prompt
• Older and deprecated libraries with latest dependencies
• Server, orchestration, and sub-systems configured incorrectly
• Hardware resources and its specifications used in a context
• Display refreshing rate and frames lost with GUI rendered
• Heat dissipation
• From the hardware
• Experienced in the environment
• Time taken for a request to reach the actual end point
• Execution time on receiving a request
• And, more...

Further we have classified it to frontend and backend; both are important and equally needed.  The webpage has got different KPIs and metrics to determine where do its performance stand.  Likewise, for backend.

Which facet of performance need to be evaluated and in which phase?  Why?  The perception will be established when testing, on how we test it, and how one uses the product.

With all these for performance, where to start and what to look at?  This is one of the question with which we are left in Waterfall and Agile.  That is where the eighth question of 100 Days in Skilled Testing comes in -- Can you share some best practices for conducting performance tests within an Agile development environment?

Have you asked these questions to yourself and team?

1. What is performance to you and to your stakeholders?
2. What should I consider in evaluating for the performance of your software system?
3. What is the practice I want to pick to evaluate the performance?
4. Where do I start and how?  

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.

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.

Business and Software Testing: The Top 5 Challenges I See For Today -- Part 4B

 

I offer my skills, expertise, and time in exchange for the pay I get from a business [employer].  You too do that, right?  That's how I make a livelihood and take care of myself and my family.

That means the business is a critical entity to me!

If I do not understand the business, 

• I cannot do software testing and automation that adds value
• I will not be in a position to lead and deliver
• I cannot help myself to grow in the professional and competing world

This blog post is a sub-part of the blog post "The Common Challenges as a Software Tester and How I Overcome -- Part 4".

The business and its service as a software solution are in need of software testing

• But, what the software testing is supposed to be and what it has to do, is mostly driven from the project management and decision to the business
• That way it looks like a business problem
• It is a project management and decision problem that is made to appear as a business expectation
• This is a different and unique problem statement; the business carries it 
• I will share my experiences and learning on this in the next blog post -- Project and Software Test Engineering: The Top 5 Challenges I See Today -- Part 4C

In Software Testing,

• We focus on the risks as well
• With the help of my testing, I try to learn the risks and help the stakeholders to know about them

The same here!

• I try to learn the risks of the below five challenges
• Because, it impacts me, my team members with whom I work, and my family members
• By learning the risks, I will be better informed to make decisions so I can deal with the impact and have control of the situation

Here are the first few challenges that I witness in Software Testing around the Business context

1. My Work, My Fit, and Company Goals
2. Whose Opinion of Me Weighs and Influences My Growth?
3. Understanding the Decisions and Moves in a Project and Org
4. Sighting and Understanding the Dynamics of Changes
5. Being Hard to Replace -- The Myth

My Work, My Fit, and Company Goals

Why it is a challenge?

• I can get easily deceived here
• By believing I'm adding value to the organization
• And, get into thought I and my work is valued and needed
• But the manager and organization may have a different opinion
• It does not get communicated until one day when I'm called into a meeting that includes the HR staff

How I'm solving it?

• Read this blog post
• It is about learning how my work fits the company's goals
• I evaluate this consistently with my manager and her/his stakeholders
• Yet, there will be differences and mismatches based on multiple factors
• The business is one such critical factor

Whose Opinion of Me Weighs and Influences My Growth?

Why it is a challenge?

• Of course, how I see myself stands first and it is more important
• This is a challenge I have to balance throughout my lifetime
• In the business and political world, to be in a better position for what I earn, it is important for me to know -- How am I perceived by the one who is more authoritative, powerful, and influential in the decision?
• There is a person above my manager and all other managers, whose decision matters and maybe final
• Do I, my work, and the value addition from my work to the organization, are visible to this person?
• How does she/he perceive my work?
• How will my work be rewarded?
• This matters to me because my growth in the company and what I earn, depend on it
• I work for this!
• We all work for this, right?
• Yet not all get what one wishes for! Why?

How I'm solving it?

• To be honest, for most of the years, I said to myself  -- "My work speaks for itself, and no need to bring visibility to it"
• But, in reality, it does not go that way always
• Most times the manager who does One-on-One regularly will not have a clue about what I'm doing though we meet every month to discuss
• Then how someone else will know?
• This is the reality!
• Today,
• I step up and talk about my testing team's work and value
• Also I talk about the work and value added by other teams with whom I work as a team
• I step up and talk about my work and its value
• I step up and say how we are solving it as a team
• I step up and say what's my contribution to the team's work
• I find ways to bring visibility into my work, my role, and my value addition
• I advocate for it
• In a way, I'm a sales and marketing person for my work and presence
• If I do not sell and market my work and presence, no one will do it unless I have a supporting and strong manager
• I show how fit I'm to the equation of the organization's goals and plan of execution
• Yet, this is a challenge of [for] everyday
• I will be evaluated every day by different stakeholders
• My past accomplishments are history and it does not work in the long run
• What I do today and how I'm doing it, matters in alignment with the organization's goal
• Do I make a fit with my work and the value I bring and add? How?
• I will have to balance myself here in the business and political space

I ask and discuss with my manager -- How I and my work are perceived by the person who has the authoritative decision?  This helps me to see how I and my work are interpreted by different people. It helps me to discuss and clarify if it is being perceived in other ways.

I also talk and discuss with the authoritative person about

• My work
• The value being added from my work and my role
• My fit to the organization's goals and how I'm aligning with it

Understanding the Decisions and Moves in a Project and Org

Why it is a challenge?

• The decisions and moves that happen in a project and organization will have an influence on everyone
• Sometimes we will not be said why the decision is made, or, we will not even know a decision is made
• I will be annoyed and uncomfortable with the outcome and happenings from the decision made
• The decision can be in terms of
• What one draws as a salary and benefits
• The termination of certain roles and people
• Cut down on benefits and compensations
• How we work and deliver
• And, more
• This can make me be off trail and not align with the goals and decisions of project management and organization
• This sends a different perception about me to the project management and business
• This will surely not do good to me

We tend to talk or be annoyed about certain decisions.  But there will be some reason behind it; just we are not said or we do not see it

How I'm solving it?

• There will be reasons behind the decision made and changes happening or to happen
• My manager will also not be aware of why certain decisions are made
• I have to accept it
• I talk to my manager asking why a decision and change in the priorities when I observe it
• This is important to know
• Sometimes my manager may not share about it if it is not disclosable to my role and I respect it
• Talking and conveying the direction with what can be shared and cannot be shared is a skill!
• As I say, awareness is a skill
• When we are involved in the work we do, we lose sight and attention to what is happening outside the work on the floor and organization
• There are certain heuristics that we can use to identify the changes happening
• With whom we work
• With operations that are executed in our work
• For example,
• the number of meetings [increased or decreased],
• the calendar of my manager and of the authoritative person,
• the project and business tabulation,
• and more

The functioning of a service company is different from a tech product company.  Be it an enterprise or a start-up or a mid-sized setup, how the floor runs, is different.  I will have to tune myself to be a better observer and spot the changes.  The quicker I do it and discuss about it with my manager and the authoritative person, it helps me.

Figure out ways to know why certain decisions and changes are done in priority.  I do the same!  I use to get lost in my work and practice.  I would be unaware of what's happening in project management and business decision.

I'm learning and building the skills here for the last seven years.

Sighting and Understanding the Dynamics of Changes

Why it is a challenge?

• The outcome of decisions, changes, and changed priorities need not be bad always
• But, certain decisions and changes affect badly and it will be unexpected
• This will have long-term effects on mental health and physical health
• Being a leader, I should help my team to navigate through it with awareness
• At least, I should be in a position to give the heads-up
• This may not be possible always, but my team trusts me and I need to keep it practical and in the business orientation
• I should be in a position to handle it with my emotions in control
• The growth of my team people, my growth, and the benefits we earn can be impacted
• Business and its dynamics are so unpredictable, it changes and it brings an impact on people who are with it
• I have been impacted by it!
• In a way it is good that it happens
• But, can it be prevented and get off from being impacted?
• How to spot and understand the change and the dynamics of the change?

How I'm solving it?

• For first, I need to remain calm and not in the anxiety when there is an impact or when I spot the changes
• The floor reflects the changes; just I have to be observant
• I share the same with my team and tell them to spot a few heuristics
• For example
• If someone on your team who did not bother about what you are doing comes all of a sudden and asks for a demo of your testing, automation, and any of your work
• The regular catch-up or one-on-one is no more done or its frequency has increased
• The type of questions coming to you and what is expected in an explicitly said time period
• The body language
• How I'm included in the project and team for my role?
• Is my work appreciated in public on the floor?
• Did I get a personal message or email as appreciation and not as public as others in the team receive?
• And, more
• I should be in a place where I can spot it if something of this kind is happening
• Talking to people helps
• This is okay if it is something to do with me; that way I can fix it
• What if it is nothing to do with me or my work, but happening?
• I seek clarity from the person whose opinion matters and from my manager
• I see nothing can be done in much
• All is, I need to be skilled and be aware so that I don't put myself into the worst situation
• Today, I work to be a better observer in these areas each day
• I have not done it in the past as I was lost very much in my work and practice
• I missed the indicators which I could have used for my benefits and the team's benefits

As I said, know your organization and its business. Know your team and its people.  It is different from other organizations, businesses, and people.

Being Hard to Replace -- The Myth

Why it is a challenge?

• We are said and expected -- to be skilled and be so skilled it is hard to replace
• This is a myth!
• Software Testing is also helpful to break illusions and know the myths to which we are blind and biased
• When the software versions we build are replaceable, we, who are developing it are also replaceable
• If not by another version, the competitor will come up to replace
• It is about serving value that is needed and building the strengths to sustain being resilient enough
• I was in assumption, it is hard to replace if I'm skilled
• 10 years back, I learned, that's not actually the story
• I'm easily replaceable given the context demands it
• I saw my fellow team members being replaced
• I saw myself getting replaced
• We all are replaceable
• It is a norm in business, competitive and political space
• There is always a valid reason and necessity for business to do so
• It is easy to fall into the illusion that I'm contributing and adding value
• Well, I will be actually contributing and adding value
• But, it may not be needed anymore for the business and organization
• If not needed, what's next?  I need not say that to you, right?

How I'm solving it?

• I accept, I'm replaceable no matter
• what are my skills, expertise, personality, and 
• what value I bring and add to the board, organization, business, team, and product
• I keep myself in a position to not spoil my mental health and physical health
• I'm learning and being much more courageous than yesterday
• I ask for help when I need it with my network and communities
• I find alternative ways to have an income so that I help my family with the basic needs
• I also replace, what I see -- it has to be replaced
• By being better in
• Awareness
• Being contemporary
• Upskilling
• Being "the match and approachable"
• Being focused

Click here for returning to the blog posts:

• The Common Challenges as a Software Tester and How I Overcome -- Part 4
• Software Testing Practice: The Top 5 Challenges I See Today -- Part 4A
• Project and Software Test Engineering: The Top 5 Challenges I See Today -- Part 4C

Software Testing Practice: The Top 5 Challenges I See Today -- Part 4A

 

The practice is one of the areas where I dwell, fall, and rise again.  I'm part of the practice. I'm, what I practice.  It redefines me every day.  This blog post is a sub-part of the blog post "The Common Challenges as a Software Tester and How I Overcome -- Part 4".

Here are the first few challenges that I witness in the Practice context

1. Awareness
2. Being Contemporary
3. Upskilling
4. Being "the match and approachable"
5. Being Focused

Awareness

Why it is a challenge?

• If I'm not aware
• I cannot be contemporary
• I will not know why it is the way it is
• Without the awareness of what's happening,
• I cannot help myself with what to unlearn, learn and upskill
• Multiple sources exist that "appear" as an awareness source

How I'm trying to be aware?

• I find the sources that help me to be aware
• I get involved with the sources
• I learn and understand what these sources have to say and offer
• I keep asking myself
• What I'm aware of here?
• What should I be aware of here?
• What I'm not aware of here?
• Being aware of the different ideologies, thoughts, and schools in
• Software Testing & Engineering
• Software Engineering
• and, its businesses ...

Being Contemporary

Why it is a challenge?

• If I'm not contemporary
• I may not fit well for the needs of today's industry and business
• I will have content, experience, and skills
• But, I may not be able to offer them in a way it is expected
• My practice, thoughts, and mindset will appear as not matching or not aligning with the organization or/and stakeholders
• To an engineer,
• This is an everyday challenge!
• The landscape of technology changes so fast, that upskilling is a necessity
• Being adaptive and upskilling is a necessity for remaining contemporary
• How to be a specialist? How to remain a specialist while being a generalist?
• How to be the contemporary and T-shaped full-stack engineer that the industry looks for?

How I'm trying to be contemporary?

• I don't see the programming languages, tools, platforms, libraries, architecture patterns, and business as contemporary
• But these are byproducts of what defines -- being contemporary
• And these changes with time and problems to be solved
• There are no defined and particular ways to be contemporary
• Hence it is a challenge!
• For today, in my opinion, there is no solution to be contemporary in Software Engineering
• And, being contemporary is not a problem to solve
• It cannot be solved
• Being contemporary means evolving, adapting, and growing in the environment -- to the need or to the need created and manifested
• It is a context
• Who is fit to the context with the value expected to add, will have a better opportunity
• Growing and adapting with time by learning the day's engineering problem and drawing a solution, is a headlight in the journey which shows what is contemporary
• I focus here
• I will try to be aware and upskill consistently here
• Being aware and evaluating how the business and money are getting tabulated in the balance sheet at the workplace
• It is a critical detail and skill needed after certain years in the industry for one
• If not known, one may not pivot to a better position and opportunities for being contemporary and see [and get] its benefits
• Being contemporary in what area?
• One has to figure out what are her/his areas to be aware of to be contemporary
• This is another set of problems to identify
• Is the T-shaped full-stack engineer a contemporary term today?
• I do not think so!
• What fills in the T-Shape and the Stack changes consistently for the need and to the need created
• Meet people in your areas; network with them
• Also meet people who are not part of your area
• Talk! Network
• See what you can catch here and learn

Upskilling

Why it is a challenge?

• I do not want to remain in the same learning, role, and earning
• Status Quo is not possible here
• All who are on the payroll need consistent and pragmatic upskilling, today
• Upskilling in Software Testing & Engineering has always been under debate in my last 17 years
• The practice is different within teams in an organization
• The understanding and practice between two testers in a team are not close, forget being the same
• What to practice in Software Testing?
• Testing?
• Automation?
• The blend of every role in Software Development?
• This confusion is being fostered here
• This confuses and gives the space for arguments and not a healthy discussion
• Eventually who are getting better identity and benefit, her/his thoughts get promoted in that place
• And, more likely these thoughts and practices get followed
• Does this influences the people who are practicing Software Testing?
• Information is abundant today on the web for Software Testing
• As said whose content gets better likes, reposts, and shared, that information gets more visibility
• How I consume this, influences my upskilling
• Few of my friends moved from Software Testing to different roles
• Maybe your friends too in your org and team
• Does this challenge your aspiration to continue in Software Testing & upskilling here?
• I get calls from the training startups asking to switch to other roles saying Software Testing has hit the roof
• Further, they try to influence me by saying
• No career progression in Software Testing
• I cannot make money
• I can make money if I move to different roles where I do full-time coding
• I can grow in my career and move to different positions
• And more ...
• We have the people who say to not choose software testing
• This influences those who are fresh, experienced, and finding rough times in the practice of Software Testing
• For example, how many times do I speak and hear about the Test Design?
• It is one of the most ignored, unaware, and unspoken areas of Software Testing
• This is one example of where to upskill

How I'm trying to upskill?

• One of the strengths of a Software Test Engineer is to not get easily influenced
• I get lots of factors and people who influence me to their interests and intents
• As a Software Test Engineer, I have to pick anything upon questioning and scrutiny
• This is one skill that I try to upskill everyday
• To upskill, I see a determined self as a need for the first
• The key area of upskilling is the unlearning part
• Knowing what to unlearn is not evident most of the time
• In the journey, I discover what I should unlearn
• The faster I discover, I help myself to save time
• I evaluate where I stand on the path of -- where I want to continue my journey
• I do it consistently
• While I do this, I classify the areas of my upskilling
• I observe,
• For every 18 months the list in this area gets outdated and updated as well
• This is like the tests getting retired or taken off the execution list, while the new ones are added
• I collaborate with the community and people who can help me to upskill
• This is not a straight and simple task
• I unlearn a lot
• I fail a lot
• But, importantly I learn in this journey and it builds me with an experience
• I share the learning I make here with the software testing communities
• I have a map, territory, and details of where should I be upskilling for the next 6 months
• I refer to Open Source works which is consumed by the tech organizations
• I refer to how tech organizations are building their services
• I identify the layer of testabilities in the technologies
• I refer to tech blogs and books, and I relate them with the help of programming
• I do more here
• My map, territory, and what to explore keep refining and get updated every 6 months

Being "the match and approachable"

Why is it a challenge?

• For first I should be visible and identifiable that I'm a match
• How to be so?
• How do I build myself to be approachable?
• After a certain point in the career, 
• One can navigate further only if she or he is seen as approachable
• My words, thoughts, what I speak and write, and how I respond, all of these can set a different tone and personality for the stakeholders
• This can give an image of me that I'm actually not
• In fact, those who are with me  at work and in communities for years can frame a different image of me
• This is a tough ask
• Perceptions of stakeholders and what stakeholders need, influences in what and how they perceive me for -- Am I approachable?
• We will have a gap here no matter what
• How do I bridge the approachability with the people with whom I want to associate and work? This matters!
• Whether it is a job or association or organization, what primarily differs are
• The people, culture, and how I associate with them and their expectations
• This changes the dimensions of how approachable and visible I'm in their perceptions

How I'm trying to be "the match and approachable"?

• I try to understand the expectations and needs of the stakeholders
• The needs and expectations are two different sets in my experience
• I consistently work on my communication and how I share my thoughts
• Also, I keep watch on the words I use in a given context knowing who all are in the discussion
• Communication is not just spoken and written words and language
• Being practical, pragmatic, and empathetic helps to an extent
• By upskilling, I try to balance the equation of "the match"
• By being approachable and contemporary
• I learn to know the people, organizations, and communities with whom I want to associate, work and grow
• I learn to be aware and have awareness so that I'm focused
• This is not a cycle; all these happen in parallel and drive each other
• Awareness
• Being Contemporary
• Upskilling
• Being "the match and approachable"
• Being focused

Being Focused

Why it is a challenge?

• There are distractions outside and inside
• We want to fulfill and meet someone's perception and expectation
• 
  
• The changes that we see every day in the space where we work and at the family end
• It will have an impact on the focus and awareness I want to be with
• Every day I work to keep my focus and awareness to be fit and healthy
• So that I can identify and mitigate the distractions
• Having mental and physical health balanced is crucial

How I'm trying to be focused?

• I'm learning to prioritize and decide what I have to work upon
• By improvising and developing the skills of having and using:
• The clarity, decision-making, and accomplishing the milestones that I set
• Goals with the timelines and milestones
• Not skipping or postponing my priorities and losing sight of what I should be focusing
• I have a daily check on my focus on what I have gotten into
• I evaluate and align with it
• I use multiple and ideate with the strategies to be focused and evaluate the same
• And, I tell myself it is okay when I fail
• But, I look for the lessons when I fail and why I failed
• I do not give up unless it is a necessity

Click here for returning to the blog post:

• The Common Challenges as a Software Tester and How I Overcome -- Part 4
• Business and Software Testing: The Top 5 Challenges I See Today -- Part 4B
• Project and Software Test Engineering: The Top 5 Challenges I See Today -- Part 4C