Is manual testing a good career?

“The human mind is like a fertile ground where seeds are continually being planted. The seeds are opinions, thoughts and concepts. You plant a seed, a thought and it grows.” An excerpt from the book – THE FOUR AGREEMENTS 

The Confession

The Confession, starring Ben Kingsley and Alec Baldwin, is a beautiful movie in which, towards the end, a slick lawyer starts questioning his own morals by defending an honorable man. But this is not about the movie in the context of this post.

Occasionally, people often constructively criticize me for not giving direct answers on and about software testing. That’s true, and as of today, there are biases and reasons behind my current approach..

Bias #1: I first want to reasonably understand the questioner’s desh (place), kal (time), and patra (individual) itself and try to learn about the context before constructing an answer to a question related to software testing. 

Reason #1: I am an accidental, self taught tester who learned from some of the best and I come from an educational farm where the seeds of ‘Learn by doing’  were sown from the beginning.

Reason #2: As I learn better (or get worse sometimes?) every day, I mold my answers for the same question using a cleaner (or even dirtier) lens. 

Reason #3: Since, learning and unlearning is an ongoing process, I remind myself that once I fixate on an answer, even if I am exploring Physics, I may be totally wrong one day.

Most importantly, where is the mutual learning in giving direct answers if they exist and unless the context demands it?

Hence, this long post is not a monologue or some kind of cheat sheet or this vs that comparison document. This is an expression of my experiences, doubts, anecdotes, questions to self with periodic to-dos for you. I believe no one can learn to test until they do it hands-on, be it purely testing or so-called ‘manual’ testing.

Also, I am proposing my point of view purely in an organizational context here. I am a software tester and test manager. I shall suggest analogies, ideas, and to-dos and share experiences and perspectives. Finding and constructing the answer(s) is your job.

And, before we move on, I hope and wish that once you are done reading this long yet genuine efforts driven post, something like the below shall happen

1. Your chase to find the correct answers to the question ‘Is manual testing a good career?’ shall end.
2. Pursuing the right questions and building the right attitude towards software testing shall begin. 

Now let us look at some data and facts to find the answer of question ‘Is manual testing a good career’.

Data and Facts

In the last few months whenever I browsed the internet, I observed

1. There are ‘terrible’ mock interviews published on YouTube, especially on ‘manual testing’ and ‘transition from manual testing to automation testing.’.
2. ‘Misleading’ advertisements by some new and famous QA/Testing training institutes. Note that when I mentor new people coming to the software testing field either by choice or accidentally, I often hear from them that they are cheated by such institutes, suffer substantial financial losses, lose confidence, and feel disconnected from testing. 
3. The terms ‘Buy my manual testing, automation, and CI/CD course’ floating around on social media,  which include pitching master classes and a series of ‘hook’ videos. A handful of new age and highly subscribed influencing testers are involved in this game.
4. ‘Buy our product’ themed blogs by some check/test case management tools and GUI simulation automation tools builders.

In a nutshell, there are misconceptions, misinformation and continuous damage to the art, science, psychology and value of real software testing. 

So there are some victims and some culprits. I empathize with the victims and offer my sympathy to the culprits. For victims, trust me, you will read this post from a test practitioner, and you can safely assume that you are in decent company. 

For culprits (knowingly or unknowingly), I request that you unlearn the unworthy, re-learn better, think better, and act to make the testing world a better place with your social media content creation and influencing skills.

Also, the good news is that I also went through a handful of brilliant and thought-provoking articles, blogs, videos, and podcasts by some prominent and well-educated software testing wizards who already answered such questions on ‘manual testing’ very well.

If you want those article references, post a comment saying, ‘Give me those brilliant resources links.’

If you already know some of those, comment saying, ‘I can add value and here are the top three links.’

I am aware of the limits of my language…

The limits of my language means the limit of my world.

The above quote is from Ludwig Wittgenstein, Tractatus logigo-philosphicus, 1922. From the series Great Ideas of Western Man.

What languages do I choose to talk to you in? Language is not as in English or Hindi or something else but in a sense of connection and conveying my worldview. Choosing only one of the following ways to answer the question seemed like a litmus test of one of my mental models and practitioner experience in software testing. There could be answers based on

1. A binary worldview, e.g., Yes or No, types of responses
2. Analytical and Lexical dissection of this question, which is an attractive, funny, and somewhat weird exercise of picking words, meanings, synonyms, combinations, permutations, cross joins, and whatnot
3. Context(s), Experiences, and Value Proposition

I tried everything and finally chose the third option, Context(s), Experiences, and Value proposition, to answer the notorious question, ‘Is manual testing a good career?’

Ask me: Am I eligible to answer?

We are in the AI rapid evolution fiscal year. I could choose to work hard and smart for ~70 hours a week to better tame AI / LLM and data models and become more effective and efficient in testing AI or non-AI software. 

But I choose to focus on answering this burning question first. 

You should find out or ask what makes me eligible to answer this question at all? Here is a little essay on myself.

1. I am a software tester with average to decent software testing skills. These days my focus areas are test governance and delivery.
2. I work with people who are smarter than I am.
3. Most of my testing experience comes from testing in International Payments, BFSI, and data-intensive products that were ‘Financial, Regulatory and Compliance business rules and process critical.’ 
4. I often tested software that was built using
   1. Requirements that were usually explicitly documented and up-to-date and signed off by business experts. 
   2. Requirements extracted from old user manuals and Help. 
5. I discovered and often created requirement documents, stories, training videos after exploring the product features and learning from production support tickets, reverse engineering, and reading logs. 
6. I have beginner-intermediate level testing exposure to Web and Mobile GUI testing and Web APIs. 
7. Most importantly, I have worked with those so-called ‘manual’ testers who brought the most value to the table by using their curiosity, critical thinking, questioning,  applied learning, experimenting, investigation skills, and helping build the products from the ground up. Those products are running successfully and serving thousands of customers/users in the US and Europe.

Gratitude

I have deep respect for the Late Jerry Weinberg for his invaluable teachings in various forms. 

I believe that it is because of those thoughts and internalizing those teachings that I am coming near to self-awareness, sensitivity, sensibility, and understanding on and around quality, testing, people and organization. 

Assumptions 

There was a time when I was of a strong opinion that as a tester if I am assuming something then it is not good. Later I learned that a better way to think about making assumptions could be

1. Learn why do I make assumptions
2. Learn What is a safe assumption vs an unsafe assumption 
3. Learn the value of communicating assumptions in a context and build understanding 

You may be here because?

Which one below is mainly true?

You are here either accidentally or by choice for reasons that may not be directly related to manual testing as a good career choice.

Or

You landed here as you found this topic either sufficiently interesting or notoriously weird and wanted to know someone else’s views.

Or

You were actually looking for the answer(s) for the questions like

Is manual testing a promising career?

What is manual testing?

Is manual testing even a career?

There can be other reasons as well, and that shouldn’t matter much as long as we mutually agree to start our journey of finding the answer to the question, ‘Is manual testing a good career?’ 

But before that, let’s first talk a little bit about testing!

Testing?

I would like to know if you disagree with me saying that one of the ways to define testing could be like this.

“Testing is context-based (a.k.a. context-driven), risk-based, and curiosity-propelled endeavor aimed to provide valuable and consumable feedback in loops in a timely and cost-effective manner. 

The feedback could be about software, ideas, requirements, assumptions, a hand-crafted product, a food item, a vehicle, a home appliance, a human or an airplane assembling process quality, or anything under test. 

The most popular notion of such feedback seems to be ‘finding defects and bugs resulting in improving the quality.’

A real-world testing assignment usually requires curiously questioning, seriously evaluating, relentlessly experimenting, exploring, investigating, and assessing the object under test, e.g., SUT, system(s) under test, AUT, or application under test.

For some, testing is verification and validation; for some, it is (or inside) quality assurance, policing, and gatekeeping. 

Nevertheless, once we get feedback via skilled testing, we build mental models not only of the object’s status under test but sometimes how the targeted users and, often, the object producers might be reacting or responding to that feedback! 

So, it becomes essential that we as testers provide feedback that would be valued. Those mental models, necessarily to be augmented with accurate and credible data, compelling stories, and negotiations, help business and product people make some decisions, e.g., optimizing the design, refactoring the code, adding a process, stopping testing, not shipping the product, shipping this slightly buggy product right now, testing is going in the wrong direction, and so on.”

This in a nutshell is how I prefer to describe testing in my current role, capacity and knowledge.

Note: You may already have a definition that sticks with you the most, or you may choose to construct one from the ground up or derive the clues from the above statements to construct your own definitions of testing. 

Time to fire some neurons?

According to a study, based on the energy budget of the brain, it appears that the average cortical neuron fires around 0.16 times per second. It seems unlikely that the average cortical neuron spikes much more than once per second.

Before you read further and especially if you are a beginner in software testing or someone labels you as a ‘manual’ tester, let’s fire some neurons in your brain. 

So if ready, I humbly suggest a heuristic which is a feasible way of solving a problem at hand e.g. testing. This heuristic is usually very powerful in a requirement elicitation and development session.  The heuristic is called ‘mary had a little lamb’ and it helps building and document interpretations. Refer: Interpretation (fourhourtester.net)

May I ask you to use that heuristic to write  your top ten interpretations of the question ‘Is manual testing a good career?’

Can you put your interpretations and questions in the comments section?

Note: If you already know this heuristic and don’t find it useful to apply in this context, skip to the next section. So far with me? Good. The next section is going to be interesting for you because ultimately we are going to find the nemo 🙂. 

A question or a challenging opportunity?

Above is a famous quatrain verse of Indian poetry from RamcharitManas, written by Tulsidas. 

Below is a beautiful quote by Jerry Weinberg…

‘When we consider what others value, we can more clearly see the rationality behind many ‘irrational’ choices.’

I saw a challenging opportunity to answer the question, ‘Is manual testing a good career?’ This was an opportunity to express my point of view as a testing professional, a human, an employee, and a student of software testing.

While it seems  easier to interpret this question (Have you tried? If not, go back to the last section and do it now so you can appreciate what’s coming next.), it was challenging for me to

1. Imagine the experiences and emotions of people raising and/or facing this question
2. Contextualize
3. Developing a 360-degree sense to be eligible to respond. 

Luckily, as you know by now, I come from a league of testers who were labeled as ‘manual’ testers and hence I can give a digestible, practical, and yet educated response. 

And make no mistake: As a software tester, I sometimes feel terrible about what is going on in the name of ‘testing,’ ‘manual testing,’ Automated testing,’ and even’ AI-driven testing.’ Trust me, it is a terrible feeling to express in writing.

Your context and homework matter

The trick to knowing if Software testing, or, to be specific, ‘manual’ testing, is even a career for you is hidden in your desire to write your answers to the following questions.

1. Who are you, and where are you coming from and going towards? 
   1. In what phase of life, career, and situation are you in? 
      1. Absolute Beginners who are 
         1. Consciously choosing software testing as a career?
         2. Not sure what software testing is all about but see, hear something on and about it?
         3. What do you know so far? Just definitions from textbooks?
         4. Heard a lot about manual testing and think it is terrible and automation or AI is the thing?
      2. Started up in software testing who are
         1. In the industry for quite some time and so far surfed well on the waves of so-called ‘manual’ testing, but something you experienced, heard, or saw that triggered this question?
      3. Seasoned players who are
         1. Thinking about what’s happening here because you know that testing is just testing. Rather than focusing on answering this question, let’s start thinking about ‘Would software testing be a career in the long run or not? ‘
2. What’s your short-term or long-term relationship with quality and software testing in your current roles and responsibilities?
3. What immediately happens and remains in your mind for the first 70 seconds when you hear the word ‘manual testing’?

A must-do homework as you keep going

Please write answers to the above questions in free form and private, and return to this post once you think you are done. Let this post wait (affluently;)) for you until then. Yes. Please pause now, and let’s do the homework.

Back?

Questions: 

1. How many of you did a self-review of your answers? 
2. May I ask you to send those over testanalyst@live.com in a .pdf file with the naming convention as (TUC_LastNameFirstName_YrsOfExp_Designation_Location) e.g. TUC_GargSandeep_16_QA_Noida.pdf? or maybe just post a comment anonymously if you wish to. 

Beginning from here, I will stress on one thing. ‘Is Manual Testing a Good Career’ can’t be answered as a monologue unless the context demands it. 

Later, we shall see that and find the answer to the question, ‘Is manual testing a good career?’ We need context and cultural awareness of what language, ideas, practices, outcomes, and values are worth spending time, energy, and money on. 

My experience with fake advisors 

So, coming back to your (once mine) context, there is one anecdote. Irrespective of where you are and what you see, hear, and experience on a day-to-day basis, there may be times when you can come across people who are self-proclaimed advisors in software testing and quality space boasting years of experience who try to project different unhealthy ideas, statements, and declarations on software testing. 

I could be one of them 😉 but thankfully, I know I am not because I learned and still learning from some of the best in the industry and hence the courage to write on this controversial topic of manual testing.

Let me give you some actual, real-world examples from my personal experiences with advisors whose unsolicited advice has caused me temporary harm.

When I was a beginner

Beginners often get lectures from such advisors in the following form:

Advice 1: Testing? OK. Suno pahle manual testing ke concepts seekho jaise ki test case likhna, scenario likhna aur scenario se test case banana. Phir automation me move kar liyo aur wahi set rahna ya phir development me nikal lena. Testing me kuch nahi rakha, use it as an entry point. Testing easy hai isme kya rocket science hai!

[Advice 1’s English version] – Testing? OK! Listen, first learn manual testing concepts like how to write test cases and scenarios and cases from scenarios. Then, jump into automation, stay there, or ask for a development role. Manual testing has no future; use it as an entry point. Testing is easy! What’s rocket science here?

[Advice 2] Manual testing me na paisa hai na future. Automation ya Development dekh.

[Advice 2’s English version]– There is neither money nor a future in testing. Look out for automation and development.

When I was an intermediate

When you are doing well as a thinking and valuable software tester after overcoming initial confusion and fears, you still get some further unsolicited advice. 

[Advice 3] Bhai / Sir, manual testing me kuch nahi rakkha, koi future nahi hai. Sab automated ho raha hai aur ab ye AI bhi aa gaya. Ab to SDET bhi safe nahi hai. Pata nahi kya hoga. Scrum, DevOps, SRE, Agile ka koi certification kar le aur nikal.

[Advice 3’s English version] Bro/Sir, manual testing has no hope. It has no future. Everything is getting automated, and now this AI is getting traction. Now, even SDETs are not safe. Don’t know what’s going to happen. Get certified in Scrum, Product, DevOps, SRE, and Agile, and move on.

[Advice 4] Too abhi tak manual testing hi kar raha hai? Bhai kuch dekh, kuch soch.

[Advice 4’s English version] Are you still in manual testing? Think something, do something.

What we don’t know about these fake advisors?

They are still determining if they have learned, understood, and performed software testing in a valuable way!

They seem to have taken Steve Jobs’s advice, ‘Stay hungry and stay foolish,’ but in the wrong way. They are still hungry for titles, money, and fancy designations but remain foolish regarding software testing. 

Another set of individuals and institutions is damaging the reputation of software testing and good software testers; we will discuss them later. 

Reread Testing?

The Yaksha Prashna

Quality is relative

Do you know what a ‘Yaksha Prashna’ is? If you still need to, let me give you a quick brief. ‘Yaksha Prashna’ is the story of a question-and-answer dialogue between Yudhishthira and a yaksha in the Hindu epic Mahabharata. 

Yudhishthira was the eldest of the Pandavas and was known and trusted by many for his truthfulness. He was also known as Dharmraj, Dharma not in a religious sense but in the sense of righteousness. 

Those who have some awareness of Mahabharata can quickly sense that ‘Truthfulness’ and ‘Righteousness’ were driven by the Context and probably Destiny, too!

Learning and Intelligence

Now please pay attention. One of the categories of the Yaksha Prashna dialog was ‘Learning and Intelligence’. 

Let’s have a quick look into that category (As I learned from Wikipedia)

Learning, Intelligence
By what does one learn?	By Srutis (that scriptures which are heard)
How does one acquire something very great?	By ascetics austerities (tapas)
How can one acquire intelligence?	By serving the old

Since Mahabharata also falls under the great mythological epics category, and my knowledge of it is very limited, I really don’t know what Yaksha was trying to achieve. 

I think one of the objectives was

• To verify, validate, check, and probably test too if 
  • He is a learned man and
  • Has he acquired a significant level of awareness & intelligence, and
    • How does he apply all learning, intelligence, and awareness in this context?

If you have noticed, I said ‘probably test’ too. Why would I say so? What do you think? Please put your thoughts in the comments section.

As a tester, I learned that there were some questions, and answering those questions right (and probably timely) was critical for Yudhishthira and his family’s life. 

Now, for the sake of this post, imagine a scene where different stakeholders (say in your org) pose as Yakshas and ask modern-day Yudhisthiras (we, the software testers) questions like…

Is manual testing a good career?

To answer this question well, software testers need education, training, and hands-on experience in necessary and sufficient amounts. They also need to know how to answer questions like

1. What is testing?
2. What is a test?
3. What is manual in a test and testing?

If testers are incapable of answering them appropriately in a context, they also may be deprived of the opportunities and resources that are much needed to do their job effectively and efficiently. Ultimately, Yudhisthira’s reputation as a learned and intelligent man would be at stake, and the same is applicable to us.

So the first Yaksha Prashna is “Is manual testing a good career?”

Also, please pay attention before you read further and search for the (right?) answer(s) for a notorious question. 

Some of the most respected, influential, and well-known voices have already clarified and even demonstrated many times that the answer to this entire question or to its building blocks is vague, meaningless, worthless, and a time-wasting pursuit.

Let’s create our own answers?

Step 1: Question the question, please!

My first reaction (response?) to the question, ‘Is manual testing a good career?’ was not an answer at all. In fact, it was a question, or more precisely, a set of questions. The questions were not because of ‘Bias’ but because of ‘Understanding’ built over time.

Following questions that came to my mind…

1. What could be the different contexts for asking this question?
2. What’s so specific or so generic about this question?
3. What does this question’s language indicate regarding curiosity, astonishment, fear, surprise, sarcasm, boredom, worry, or frustration? 
4. Who is asking this question? To whom and for what reason(s)? 
   • What do they intend to do with the answer(s)?
5. How would they know if the answer is right or wrong or both?
   1. Right?
      • If correct, how and for how long?
   2. Wrong?
      • If wrong, why?
6. What should be my goal in answering? 
   1. Should we flip the mind and promote ‘manual’ testing, ‘automated’ testing, or just ‘testing’? 
   2. Bring Awareness and remove misconceptions? 
   3. Empowerment through education? 
   4. Bring sanity and peace to someone who might be puzzled? 
   5. Answer for the sake of answering w/o thinking of value?
   6. Helping someone understand and make the right career move?
   7. Other options?
7. Are there other questions coming up? Something like below
   1. Is software testing a promising career?
   2. Is Automated testing of software a promising career?
   3. Is SDET (Software Development Engineer in Test) a promising career?
   4. Is SET (Software Engineer in Test) a good career?
   5. Is Software development a good career?
   6. Is software a good career?

What questions would you like to formulate? Give yourself as much time as you want before proceeding to the next section. This is critical for our mutual success in obtaining the answers.

And, If you have come so far

Let’s pick up on our journey to find answers to the question, ‘Is manual testing a good career?’ and enable ourselves to create insights, associate meanings to those, and then confidently answer such questions.

Is it simple? Yes, No, and It Depends! 🙂

There are five primary reasons to respond to this question’s call in the way I will do in the following few pages. I think as a learner…

1. Creating your own answers and testing those answers and their meanings is critical for your intellectual growth.
2. Applying the knowledge gained from that creation in a given context is vital.
3. Be valuable and courageous in raising your voice and act in situations where such questions still arise, and the crowd’s answers are disconnected from the reality on the ground.
4. Remain sane and at peace while navigating the beautiful challenges of sincere and serious testing efforts.
5. Help this and the next generation to become more aware and naturally intelligent.

Step 2: Let’s find the Nemo : Identify, simplify, Decode and Code!

The keyword is ‘manual testing’. This keyword is the biggest deal, and why shouldn’t it be?

I would suggest that before we pick something to choose as a full-time or a part of our career, e.g.’ manual testing, we should know 

1. What is it, or at least what does it look like? 
   • Mental models on and about manual testing.
2. What a human is supposed to do when he/she is doing manual testing?
3. What are those different walks of business where manual testing is prominent and rewarding?
4. Who are the leaders in manual testing to follow and learn from?
5. What shape and form is available, and how much good or bad data is available? 
   • To help us test the hypotheses, manual testing is a promising career, or manual testing is not.

For further simplification, from now until I stop thinking and typing, whenever I refer to ‘Manual Testing,’ I demand that you visualize that in the following form. 

‘Manual’ Testing. 

Do you notice the difference between writing and reading ‘Manual Testing’ and ‘Manual’ Testing? 

Do you notice the space(s) between the ‘Manual’ and Testing words displayed above?

In the comments section, can you express your thoughts, findings, and observations about the above questions?

Why am I doing so? Simply because of my unfamiliarity and inability to fully understand what is manual in testing in general or specifically. Except only in those cases where I am testing and

1. I am doing what I should not do at all. 
2. I am doing something inefficiently.
3. I am not thinking and acting on what I should and shouldn’t do?

So, I decided to maintain an arbitrarily calculated distance between ‘Manual’ and Testing. Later, we will see how manulism badly shadowed testing in inappropriate and harmful ways.

I am thankful to many colleagues, ex-colleagues, friends, and known testers since 2010 to whom I asked this question occasionally. The three questions I tend to ask are, 

1. “What is manual testing according to you? 
2. Why do you call it ‘manual’ testing?

If they answer both questions reasonably well and I sense that they just need one slight push to think better about the beautiful work they are doing, I ask them.

1.  What exactly is ‘manual’ in the testing that you do?’

Step 3: Do me a favor: Find out what is ‘Manual’?

I worked with and developed testing teams, where the overall departmental effort was to conceptualize, document, build, and test in parallel until the implementation really looked like a product to deploy. I share one small hands-on testing experience from working with this team.

We were developing a customized international payment messaging processing backend system on SOA architecture with SOAP web services. Oracle was the database, and the front end was developed as a ‘utility,’ a ‘contingency’ risk-driven GUI for the bank’s support team. 

Imagine a web application on an enterprise-closed network facilitating CRUD actions triggering critical business flows.

A testing experience

1. There was a collection of 8-10 web pages with ~25 – 30 data input fields.
   1. Dependent as well as Independent input variables
2. All these alphanumeric data Inputs could be injected into the application as free-form text, drop-down values selection, and checkbox ticks.
   1. Text inputs with special characters (addresses, for example)
   2. Some input data was required, and some was optional.
   3. Input data length varied but usually had an upper limit of 3000 characters.

Techno Functional business analysts defined and documented high-level requirements. Some of the requirements were inherited from the two base product(s), on top of which customization was supposed to happen.

• Those worked as a ‘test case’ reference
  • All we had to define was permutations and combinations of variables
    • Valid and invalid

There were incoming, in-processing, and outgoing data mapping, transformation requirements based on permutation, and combinations of incoming data. To simplify, imagine an ETL (Extract, Transform, and Load) process running back and forth within one product among three different layers on a typical day.

My role was to put myself into the shoes and chappals of a payment processing operator and a tester.

I delegated that data combination and permutation decision to a Combinatorics tool called PICT and ACTS (Thanks to Dr. Richard Kuhn for giving me a free version of the product for a few weeks.

We were feeding the test data ‘by hand.’

• By typing / copy-pasting while disabling auto-fills
• By enabling autofill ‘deliberately’ 

Then, at some point

• When I was coming out of the shoes of an operator and the testing goal was to trigger and test business flows in batches, I decided to delegate this data input work to a script or a lightweight tool.

I searched for a tool, and ‘Selenium IDE’ came into the picture

• Got the IT approval
• Used it to fill data ONLY.

I further prepared a set of scripts that simulated an ‘operator’ ‘s actions, including clicking buttons, navigating screens, scraping logs, and verifying as defined in the user manual. 

We still didn’t call; we were testing manually. Two essential pieces of overall testing activity were delegated to the tool(s).

• Determining credible combinations and permutation 
• Data feeding 

Selenium IDE was not intelligent and failed often, so we had to learn Selenium IDE’s sync business and all. I then bookmarked the key transaction web pages (login required, of course), exported those in XML format, and pushed them to a shared repository where the team could download and use them. In parallel, I pushed those Selenium scripts to another repository where the Dev and QA teams could reuse the data.

Long story short. We were testing and found what efforts don’t belong to us from a creativity, cost, and efficiency standpoint. We also realized the trade-offs of the delegation. We made wise choices in that context and testing goals. Do you see ‘Brain’ at ‘Work’!

Did you find anything manual so far? If so, what’s that? 

Put that in the comments, please.

Team kept on improving our ability to distinguish between what machines could do better and what we should delegate to powerful machines. It takes observation, thinking, creativity, spontaneity, and a taste for efficiency.  Yet we never called this testing as ‘manual’ testing. For testers, it’s testing!

Yet I recall especially when the dedicated automation(s) efforts kicked off to execute tests at scale, as rapid changes in implementation and delivery supporting activities occurred. Then, at some point, we started talking aloud about what tests or simple input / output-based verifications could be delegated to test automation. 

I will give you another example. 25% of the text you are reading came from this idea 

• Create periodic dumps of thoughts using ‘Speech to Text’
  • Improved my speaking (speed, fluency, and pronunciation) skills
• Transform, refine, rearrange, and beautify using my knowledge and experience
• Find time to make sense by reading as a reader, not a writer!
• Fill the gaps, close open loops, and enrich (or shorten)

Step 4: Let’s sense: who else is experiencing ‘manual’ testing?

Immediate Stakeholders (Your Team including Developers)

As a tester, I understand that when we don’t think critically about why they are doing what they are doing, we fall into the trap of doing things the way they are. 

When more intelligent people around us clearly see us not playing smart and still banging on the keyboard for any activity that’s not worth our time, intellect, and paycheck, they may start to see a not-so-intelligent tester at work.

Another is, in my experience, and whether you believe me or not, most good developers I worked with were good at testing too. They may not have documented the ‘unit and integration’ tests, but they did it before they said, ‘It’s your Mr tester’. They took it for granted that as a tester, I would use my brain, thinking skills, resources, curiosity, investigating, questioning, examining, and ‘breaking the code’ skills in a more skilled way than they did. 

But often, since they take it for granted and might not see (through the naked eye)  you not using any particular tool, they still may call you a ‘manual’ tester who understands the product and can test it well. There is no lack of respect or worthiness because they know what you are bringing to the table, but you are still labeled as a ‘Manual’ tester. It’s time to smile 🙂 and probably laugh.

You also know that you have to use your brain, of course. You have to use thinking skills. You have to use your Comprehension, Interpretation and understanding skills.You have to use your written, verbal and other soft skills to to get the things done.

Organization

At the same time, you should constantly think about efficiency and ideas to speed up the testing processes and day-to-day testing activities. Organizations and businesses are also under constant pressure to beat the competition, time to market, reduce costs, and so on. 

They need our help with idea validation and not only testing the implementations. Idea validation may fall under a business analyst (techno-functional) or a Product Manager role, but ultimately, we are ‘Testing.’ 

We bring value to the table when we play (not on the label) but on the responsibility of ‘Risk Management’ at this level where you have a say beyond ‘we have tested this implementation and risk is minimal or that risk to be mitigated or handled in this way.’ 

So, suppose we hit refresh and see testing from a ‘Risk management’ angle. In that case, we should also consider the risk mitigation and management handling activity at the ideas, requirements, implementation, and delivery levels. 

Boundaries are shrinking, labels keep changing, and it is all about the value that you bring to the table as a skilled tester. Period!

Step 5: Think better: ‘Manual’ Testing – A confusing Territory without a trusted Map

I vividly remember professionally requesting (sort of challenging) a handful of testers to pinpoint a book, blog, article, white paper, conference talk, or something that I can factually comprehend. I still want and need to know who that credible and trustworthy test practitioner who coined the term ‘Manual Testing’ was and what the ‘reasons’ behind that were. 

So far, none has shown me a credible reference. If you can, please help me by posting your findings in the comments section.

Some of the most respected, influential, and well-known voices have already clarified and even demonstrated many times that the answer to this question or its building blocks is vague, meaningless, worthless, and a time-wasting pursuit.

1. For some of them, this question is totally irrelevant because #ManualTestingDoesNotExist. Period. If manual testing doesn’t exist, then there is no point in talking about whether it had a career, has one, or will have a career.
2. For a handful of other intelligent test professionals, it doesn’t matter whether you call it human thinking and interaction intensive testing, manual testing, exploratory testing, or something else. They are not interested in the game of words. They are focused on outcomes.
   1. Testing is testing! 
      1. Either done thoroughly by humans or a significant part of it is partially / fully delegated to some automation tools. 
3. For some busy bees, it’s another opportunity to say, Phew! They are surprised that such questions are still asked and see that it is going backward rather than progressing.
4. Yet, very few understand that the idea of ‘manual’ in testing is not only absurd but also significantly damages the craft, glory, and economics of software testing.

I respect every sane tester’s efforts, time, and energy in responding to the manual testing question. 

And it is because of those few caring intellects (names later in this post), this question still needs attention and must be addressed continuously. The people who are flag bearers and torch bearers are bringing awareness. They know their awareness campaign must continue until we get it right!

Step 6: Socialize : Designing Career can be a collective social responsibility

I also needed to address this question first by asking myself. 

1. Why does this question almost always come from and for testers only?
2. Why does this have to be addressed all the time by testers only? 
3. Are we the problem creators as well as the solvers? 
4. Why are we not involving those people who work with us in different roles and capacities and have tremendous abilities at scale to build or bring awareness on this topic of ‘manual’ testing?

So, while I take personal accountability for clarifying my view on ‘manual’ testing and its relevance to choosing a career (if it holds true), my clarifications may not suffice in the long run.

“Empowerment through education and bringing back the glory of testing it deserves” should be the Fantastic Five’s collective responsibility!

Fantastic Five (Gen X & Millennials & Gen Z)

Testers

• As long as there is a notion of quality,
• As long as there is a notion of risk,
• As long as there are failure modes,
• As long as there are assumptions,
• As long as we are imperfect thinkers,
• As long as there are values,
• As long as AI or AGI is not overtaking the human intellect wholly beyond passing initial Turing tests
• As long as we sincerely care

There shall be testing, and there shall be careers for those who are and would want to test seriously.

Suppose the notion of quality attributes and/or risks is demonstrably wiped away or desirable to wipe away from people’s minds. In that case, we might not necessarily need serious and dedicated testing efforts, but testing shall remain in some diluted forms.

Identifying, describing, and filtering out what may look like manualism in testing is a worthy effort from certain angles, though. But it is definitely not a worthy and wise choice to segregate software testing on the basis of a vague and meaningless notion of manual and/or not-so-possible automated or hybrid terminology or something else.

Brain or Mind, Strategic Investigation or Serendipity, Knowing product well or Reverse Engineering, Toolsmith or Resourcefulness, testing is always supported by various tangible or intangible tools, techniques, methods, and processes.

Fundamentally, testing is a service that culturally might take many forms, including gatekeeping and sometimes asking a professional tester to give sign-offs. In a given culture, professional testers make choices based on context, competency, and a hypocritical oath.

For practitioners who know software testing, it’s just software testing!

Managers and CXOs

I will tell you a genuine and short story. Knowing that I am influenced by context-driven testing paradigms and risk (these days primarily delivery-related risks) based testing principles, once one of my ex-bosses asked me a question in a humorous way. 

Boss, Sandeep, what would you do if our CIO uttered the words’ Manual Testing’ someday? What would be your reaction?

Me – It depends on the Culture, Context, Problem to Solve, Time, Cost, and most importantly, Timing.

Boss, It seems you are trying to be politically correct and diplomatic. But you know that there is no such thing as ‘Manual Testing’! Don’t you? So why are you not choosing to challenge that idea immediately?

Me—Yes, you are right to some degree. I would love to challenge the idea openly and immediately if I know it is culturally acceptable, safe, and not intimidating to do so! Still, it depends upon the Context, Problem to Solve, Time, Cost, and, most importantly, the Timing. 

Boss – Okay, so imagine that all odds are in your favor. What would you do then?

Me—See, I greatly respect that lady because of the value she brings to the table and her trust in what we do here. So, first, I would thank her for having us here, appreciating us, encouraging us, and protecting us from a plethora of noise about what testing can and can’t do. You know it, don’t you? 

Then, I would ask what areas and values of ‘Testing’ she admires the most and what she doesn’t. What value(s) would she like to see you and I bring to the table as testers in different quality and risk management roles? Then, as I set the stage, I would ask where she heard about ‘manual’ in testing, her experience with that (if any), and what she feels about it. 

Boss – Okay, despite all odds being in your favor, you are not directly denying the notion of ‘Manual Testing’? Why? What are you afraid of?

Me—I think I understand what you are trying to do here. It sounds like you are testing my sanity over my spontaneity regarding such questions in a given context. Is that right?  

Boss – Grin…

Me – So, in any case, because we are ‘Thinking’ testers and not as such ‘Manual’ testers. Even when everything is in favor, I need to know what problem I am trying to solve by ‘challenging’ the idea and the best ways to solve it. 

On top of that, I am human, so I need to Connect before I Correct! Once she and I know where we are coming from, it’s easy to talk about ideas, terminologies, notions, and practicality. 

It is important to have a bird’ s-eye view of each other’s mental models, levels of ignorance, and experiences before committing to fixing our meaning(s) to ‘manual’ in testing. Then, if needed, I can definitely take that ‘challenge the idea’ route.

Boss, Umm! It sounds like you failed my test because my test intent was to surface your spontaneity, but I see sanity first.

For those who know management and business, testing is about feedback, Information, Risk Management, and Business Value!

Recruiters and JD Writers

I know a handful of good technical recruiters who reasonably understand testing. I have also seen JDs from some recruiters and felt overwhelmed, and those JDs often give me an inferiority complex in some way. 

It occurred to me that, like the digital, economic, and other such divides, we deeply created a Manual vs Automation divide. 

As far as the executives, development and delivery team, and recruitment team are concerned, I hope for a strong connection between them regarding the notion and reality of speed, quality, cost, value, and profits from the product going into the users’ hands. 

Suppose recruiters look deeply inside the organization’s culture and dynamics. In that case, they shall start seeing the people skilled in testing who are now facing challenges in the name of speed and time to market, automation, and being overwhelmed with forced implementations of various iterative and incremental development life cycles and frameworks. 

When there is no time for applying thinking, exploring, investigating, and so on, your testers merely check the implementations.

Some testers prepare themselves for tier-1 organizations to get into Engineering roles, be it Quality Engineering or just Engineering, where they are paid well, treated well, and perform testing. 

When would JD writers be empowered and trained not to ignore the realities of/within the organization’s values and quality focus and then prepare JDs and hire testers accordingly? How long would it take to get out of temptation by asking for everything in One Person, and that too Immediately? 

When would you remove ‘manual’ from ‘manual testing’ while publishing your JDs?

Tool Vendors

Let’s take an example of Automation, especially GUI automation. In 2008 – 2012, I did and managed POC efforts on TestComplete initial versions and QTP 9/10 and found that automation engineers struggled with the identification and flakiness of web elements. 

Similar stories are still not unheard of today, in 2023. We are still dealing with flakiness, not being able to differentiate and articulate it well and solving it through healing mechanisms (AI). 

Even if we categorize today’s tools, available in a vast majority, based on what they 

1. Facilitate – Writing requirements, test cases, test charters, test scenarios, and test data management.
2. Simulate – User requests, GUI operations (interactions), API endpoint requests, etc.
3. Generate – HTML, Graphs, and so on

What’s Manual about the Tests? 

Thinking, Designing, Drafting, or Executing? Probably Executing. Right?

I further tend to ask them and ourselves, too, 

1. Do we have a list of what ‘intentions,’ ‘actions,’ and ‘data’ indicate manualism?
2. What about other automations that don’t seem to be talked about that much? 

To tool vendors, 

1. Build while keeping human testers in mind, solve their problems first, and sell ethically.
2. Sell with care. 
3. Solve problems by playing on Strengths and not exploiting the divide.

QA/ Testing Training Institutes

One of my friends recently saw an advertisement from a testing training institute boasting about teaching manual testing, automation, etc. He asked me this question. Sandeep, you must be pissed off when you see this ‘Manual Testing.’ 

I thought a bit and calmly said, First, Don’t judge a book by its cover, and Second, more than it pisses me off, I am concerned about the magnitude of misinformation this can spread in newcomers when they pick this idea and use it at scale on the Internet to know more about it. Imagine the enormously created misinformation and its adverse impacts.

I am a tester who performs testing in a given context and knows my constraints. Testing is Testing. 

After understanding market realities and facing a lack of skilled testing workforce, I know a handful of test leaders who are doing their best to raise good testers by creating their own internal academies. Their resources, blogs, and training departments are much better than those of these fancy training institutes mushrooming at the pace of LLMs.

In a nutshell, I hope that these Training Institutions shouldn’t be disconnected from reality. Did you ever see a report published by these institutions based on their surveys of the companies where they placed their candidates? Did they survey the market to determine what types of testers they want or need? Did they say that we supplied manual testers that we trained but got rejected even in the interview because of manualism detected?

Beyond enrolling students and job seekers in their predefined, old-fashioned ‘Manual’ first, ‘Automation,’ then courses, what else do they offer? Cracking Interviews?

To training institutes,

1. Connect the dots. 
2. Face the reality. 
3. Hire Teachers who are Solid testers and testing professionals. 
4. Build courses for solving modern age’s testing problems

Remember, Good Teachers are rare. 

Testing Communities and Ed-Techs

Some are doing well and will do excellent as long as their underlying business model is not forcing them to become just another training institute.

To communities and ed-techs,

1. You are at the center of these Fantastic Five. 
   • If Air, Water, Soil, and Sky are polluted.
     • Fire is the cure. 
       1. Become the Fire to warm up the new generation and purify.
       2. Help the new generation of testers to evolve as a headlight
       3. Help the ones who are misguided and bring them back to the actual testing world
       4. Involve the best of the best in doing all this.

The On-us is on us

Have you ever witnessed a solar eclipse? Some can’t be seen from all over the world, and some can only be seen in its entirety from certain places. Some are widely seen. Some are longer, and some are shorter. Some are in your time zone, and some are not. Isn’t it? 

I imagine this notion and myth of ‘manual’ in testing like a very long-duration eclipse of some kind, and I am hopeful that we will see the sun of ‘testing’ clearly sooner.

We are equally accountable for improving this world by educating ourselves and our people. 

Looking at the past and present of the testing, some of us will choose different paths to bring back the glory of software testing that it deserves. Removing the notion and mythology of ‘manual’ from ‘manual testing’ is one crucial step in that direction. 

“But man’s duty is to try and endeavor, success depends upon chance and environment.” 

– Bhagat Singh, Why I am an Atheist

Now I ask you

Are you still chasing the correct answers to the question ‘Is manual testing a good career?’  OR are you ready to pursue the right questions and build the right attitude towards software testing?