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.

 

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.

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.

Performance Testing - The Unusual Ignorance in Practice & Culture

 

I'm continuing to share my experiences and learning for100 Days of Skilled Testing series.  I want to keep it short and as a mini blog posts.  If you see, the detailed insights and conversations needed, let us get in touch.

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

What are some common mistakes you see people making while doing performance testing?  How do they avoid it?

Mistakes or Ignorance?

It is mistake when I do an action though I'm aware that it is not right in the context.

I do not want to label what I share in this blog post as mistake.  But, I call it as ignorance despite having or not having the awareness, and the experience.

The ignorance said here is not just tied to the SDLC.  It is also tied to the organization's practice and culture that can create problems.

To this blog post's context, I categorize the ignorance in these categories -- Practitioner and Organization.

1. Practitioner's ignorance
• Not understanding the performance, performance engineering, and performance testing
• When said performance testing, taking it as - "It is load testing"
• No awareness on what is performance and performance engineering
• Going to the tools immediately to solve the problem while not knowing what is the performance problem statement
• Be it web, API, mobile or anything,
• Going to one tool or tools and running tests
• No much thinking on how to design the tests in the performance testing being done
• Ignoring Math and Statistics, and its importance in Performance analysis
• No idea on the system's architecture, and how it works
• Why it is the way it is?
• The idea of end-to-end is extended and used in testing for performance and having hard time to understand and interpret the performance data
• How many end-to-end your tests have identified?
• Can we test for performance to all these identified and unidentified end-to-end?
• Relying on the resource/content in internet and applying or using it in one's context without understanding it
• No idea on the tech stack and how to utilize the testability offered by it in evaluating the performance
• Not using or asking for testability
• Getting hung to most spoken and discussed 2 or 3 tools on the internet
• Applying tools and calling out it as performance testing
• No attempting to understand the infrastructure and resources
• How it impacts and influences the performance evaluation and its data
• Idea on Saturation of resources
• Thinking it as a problem
• Thinking it as not a problem
• Not working to identify where will be the next bottleneck when solving a current bottleneck
• What to measure?
• How to measure?
• When to measure?
• What to look when measuring?
• Not understanding the OS, Hardware resources, Tech Stacks, Libraries, Frameworks, Programming Language, CPU & Cores, Network, Orchestration, and more
• Not knowing the tool and what it offers
• I learn the tool everyday; today, it is not the same to me compared to yesterday
• I discover something new that I was not aware of what it offered and exist
• I learn the new ways of using the tool in different approaches
• No story in the report with information/image that is self-describable to most who reads it
• And, more; but the above said resonates with most of us
2. Organization's ignorance
• At the org level, for first and to start, it is ignorance in Performance Engineering
• Ignoring the practice of performance engineering in what is built and deployed
• Thinking and advocating, increasing the hardware resources will increase and better the performance
• In fact, it will deteriorate over a period of time no matter how much the resources are scaled up and added
• Ignoring the performance evaluation and its presence in CI-CD pipeline
• The performance tests on CI-CD pipeline should not take beyond few minutes
• What is that "few minutes"?
• Not prioritizing the importance of having the requirements for Performance Engineering

Recently, I was asked a question - How to evaluate the login performance of a mobile app using a tool "x"?

In another case, I see, a controller having all HTTP requests made when using web browser. Running these requests and trying to learn the numbers using a tool.

I do not say this is wrong way of doing.  That is a start.

But, we should NOT stay here thinking this is a performance engineering and that is how to run tests for learning a performance aspect[s].

To end, the performance is not just - how [why, when, what, where] fast or slow?  If that is your definition, you are not wrong!  That is a start and good for start; but, do not stick on to it alone and call performance.   It is capability.  It is about getting what I want in the way I have been promised and I expect; this is contextual, subjective and relative.  The capability leads to an experience.  What is that experience experienced?

Sometimes, serving the requests by what you call as slow, is a performance.  What is slow, here?

The words fast and slow are subjective, contextual and relative.  It is one small part of performance engineering.

That said, let me know, what have you been ignoring and unaware in practice of Performance Engineering & Testing?

A Test Is Not a Metric

 

A test execution by human or automation will provide information to be aware & learn.

If there is a metric, it should be for what I got to be aware of & learned.  Not for the number of tests.  If it is for a test, it is blunder, before taking it as a metric.

One can identify infinite tests; automate adding annotation @test in big numbers. Should this number be a metric?

That is a question to ask when you see a metric on this number.

What is of value to you in this outcome from a test?  That value should have a metric, and not test or the number of tests.

Identifying the metric in a context which serves, is not easy.

Number of pass/fail or green/red is a measurement; not a metric!

Anything measured cannot be a metric.

A metric helps to measure in a way that establishes rational correlation & upholds its necessity in business.

Share this awareness!

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.

Who is a Developer?

 

Who is a Developer? 

I understand the developer is the one who builds.

• A product owner builds the product by bridging the gap between market, business and consumer.
• A programmers builds the product by programming.
• A tester builds the product by testing it with her/his tests and programming the test code.
• A devops engineer builds the product by building and managing the pipelines and environment.
• A DBA builds the product by writing and managing the database environments.\
• A support engineer or executive builds the product by troubleshooting and listening to the problems being reported.

Who else do you see in developing the software system and its product as a solution?

If you see,

• With the skills and expertise we have and build consistently,
• Each of us will work with our expertise in a particular space of the problem solving as a team and business.

Each of us develop some kind of artefact that are combined to build and ship a usable software.  To me we all are developers with a specific roles.  As a developer we upskill consistently and catchup with current and upcoming changes.

Note: The above said are not the only tasks of these roles.  Each do beyond this in developing & continuous delivery of a usable software.

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.

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.

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

The Common Challenges as a Software Tester and How I Overcome -- Part 4

 

In the blog series, the last blog post is on mentoring and a mentor.  Read it here.  Find and have mentors who will help you transform into a better person and professional consistently.

The next question I had from Trending in Testing is -- "What are the common challenges that you face as a Software Tester?  How do you overcome them?".

Without challenges, there is nothing to accomplish; this is one of my consistent learning.  One has to embrace the challenges.  If one sees no challenges, it is time to reflect and ask what one is up to.

Let me pick my top three areas that I see as a priority and brief the five challenges for me in each area for today:

1. Practice
• Software Testing Practice: The Top 5 Challenges I See Today -- Part 4A
2. Business
• Business and Software Testing: The Top 5 Challenges I See Today -- Part 4B
3. Project
• Project and Software Test Engineering: The Top 5 Challenges I See Today -- Part 4C