Is it important to know manual testing before starting to learn how to do test automation?

Test automation is a part of testing activity, so obviously you need to be aware of testing concepts and have a quality mindset.

The catch here is – first, industry created this divide between manual testers and automation testers and now industry itself has bridged that gap to expect just a ‘tester’ who knows both manual and test automation.

Nowadays, most of the companies are looking for automation profiles only. So, as person who wants to start a career in software testing, is it necessary to know manual testing before starting test automation?

  • 4
    Updated title to make it a little easier to read, hope that is ok, change back if you want Mar 6, 2020 at 12:35

17 Answers 17


It's not mandatory but It would be beneficial to know Manual testing before starting Test Automation.

Test Automation is mostly used to reduce manual effort. Usually, in automation testing we don't actually test anything, most of the time goal is to automate manual tests.

While in Manual Testing you will have to actually test the functionalities with different scenarios. In manual testing, you will identify scenarios, with your product and domain knowledge.

In testing, it is very important to find the maximum number of important/relevant scenarios. So, before transitioning to test automation if you have experience in manual testing then it is going to help you in understanding automation testing in a better way. You will be able to think of better ways of going around your test scripts.

So, I would rather rephrase it as “Yes, it is important to know Testing concepts before starting Test Automation.”

  • "Test Automation reduces manual effort" Not necessarily, many automatic tests can't be done manually (think of parallelism) or are highly inefficient when done manually (although this is related to "reduce manual effort" it's not the same)
    – Rsf
    Mar 6, 2020 at 12:31
  • "While in Manual Testing you will have to actually test" again this is not entirely accurate, sometimes you'll use automation as tools for doing testing (as opposed to checking, even if I don't like the wording)
    – Rsf
    Mar 6, 2020 at 12:33
  • 12
    "In testing, it is very important to find the maximum number of scenarios" that's over simplification, usually the maximum number of scenarios is infinite (well, not really but really big and unpractical) and what you want is the maximum number of relevant or important scenarios
    – Rsf
    Mar 6, 2020 at 12:34
  • 1
    @Rsf I also took issue with that sentence. It is easy to come up with a gazillion unimportant scenarios. It is hard though to divide the parameter space properly into equivalence classes and identify the loci where problems are most likely. Mar 6, 2020 at 20:08
  • 1
    I think this reflects the changing landscape. I see test automation as something that was traditionally seen as replacing manual effort, but over time has developed to providing rapid feedback to developers writing the code (and now often the tests). Because of this change, the meaning of the terms and the purpose of the testing is now complex and depends as much on your organization as to any notions of abstract terms being definitive. May 14, 2021 at 11:31

It depends, but I would like to argue that it is not that important.

Test Automation Team: As a test automation engineer, you could get detailed testcase steps from someone else and just implement them. I see companies who do this as they have a seperate test automation team. In this situation understanding the tooling and how to build maintainable automation is more valuable then manual testing skills.

Agile team: If you have a quality minded people in your team. If the team practises test-first, eg tdd or bdd. Now the automator does not need manual testing skills. The whole team approach makes sure the right test-cases will be designed.

But great software builders understand howto go from requirements to production. This includes good testing skills, manual and automated.


The simple answer would be that,

If you see your self as a Manual tester, then you don't have to

If you see your self as a Test engineer, then you have to


Manual testing:

If you like playing around with the system, doing repetitive tasks, etc you don't have to learn automation testing.

Automated Testing

  1. But If you see your self as 'Test engineer' and want to improve your skills then you would properly automate things that need to be automated and utilize the saved time for doing things that would help you to improve your knowledge.

  2. From a product quality perspective, automating stuff will ensure more test coverage in cases of tight deadlines. You can be more confident in releasing stuff even when you don't have much time to manually tests things.

  3. As a manual tester, if you automate things that you already expert in, then you can find time in concentrating on product areas which require more rigorous testing.

  4. From an organisation perspective, you can reduce the workforce needed when you have fair automation test coverage


Automation testing is just a way to make your work easier, its not a run away from manual.

Remember the slogan:

"Automated tests are only as good as the manual ones"

So, all organisations need expert manual testers who can right excellent test cases. And they also need excellent automation testers to automate these and avoid repetitive works and missing out test coverage during tight deadlines.


This depends on a particular company, in some, they are pretty happy if you come from say a developer role, in other, they want you to be more of a tester with some skills of automation. In some companies they have exploratory testers and then test automation team that automates those scenarios that are handed to them by the exploratory testers. But in many other companies, you're the only tester on a team, so you need to cover both exploratory testing and test automation. So obviously, this hugely depends where you go, what company you work for, and how they organise software development.

I think that a good mindset is to be aware that testing is both exploratory (also manual as many refer to it) testing and test automation. If some companies want only one or the other, I'd start asking questions about their development process and expectations they have.

So, as a fresher to start career in software testing, is it necessary to know manual testing before starting test automation?

No, it's not necessary. For your own benefit, it's something you want to have at least some experience with, but as I said, you can find companies where you'll be assigned on a test automation team where the test scenarios will be devised by someone else and your job will be to just rewrite them into a programming/scripting language so they could be run automatically.

All in all, I don't think this could be generilized. For every company that wants just test automation profiles, there are many other companies that want a combination of automation and exploration, or just exploration. On the other hand, what I see around in my particular environment is almost all companies want at least some skills of automation, so it seems that having no experience with this poses a bigger threat to your employment than having no manual testing skills.



Everyone is already a manual tester becuase we all now use devices all day long and we experience what happens when they work and when they don't.

Sure, there are some formalities to learn such as test plans, happy vs sad, etc, but the underlying principle of trying to use something and see if it works is the same.

Automated testing requires a long set of technical skills in order to achieve a 'does it work?' objective.

One area that manual testing does help automated testing in, is that when doing UI automation you can learn a lot about the application from manually using and testing it. You will also need to interact with the application a lot while writing the automated tests and in my experience this always involves a manual testing portion, at the very least to examine state and errors manually as you build the actual automation.

  • 1
    While through use people do check software, that is not testing. A professional tester has an understanding of ideas like Exploratory Testing, Bounds Testing, and Penetration Testing. Those are a unique thought and skill set that professional testers provide - and not "everyone" brings that skill to the table.
    – CKlein
    Mar 6, 2020 at 13:46
  • Everyone is not a manual tester ,then there won't be good tedters n bad testers
    – PDHide
    Mar 6, 2020 at 18:52

The actual question being asked here ...

What proficiency of manual testing should be achieved before attempting automated testing?

0% proficiency?

Sure, that's technically possible if you're just translating pre-written tests into automated ones. You don't have to think about anything because the steps and expected result of the test are already written out.

100% proficiency?

It's hard to say what that is, but it's reasonable to assume you probably don't need to know everything there is to know about manual testing to do automated testing.

1%-99% proficiency?

Somewhere in this range lies the skills of a manual tester who knows how to do only one thing:
A manual tester must know how to record the exact steps to check on a specific feature.

This is required for automated testing – which involves writing code, and natural language rarely translates into code. That means that at a minimum – automated testing requires the ability to write a precise set of unambiguous steps.


If you know how to write a precise set of steps and an expected outcome for a particular feature – then you have fulfilled all of the manual testing skills you need for automated testing.

There are, however, other skills needed to write automated tests – such as writing code, setting up IDEs/projects to use libraries or knowing something about the page-object model.


I've been testing embedded devices since 1999, and I started from scratch as a manual tester and I'm now a full-time automated test software engineer developing both tests and systems/frameworks, so I hope I can offer a little perspective from my own viewpoint.

I started out testing credit card machines (entirely manually), moved to mobile phones (mainly air interface stuff initially, but I moved into automation during that time - and there was manual testing involved). Now I create automation test systems for TETRA radios (emergency radios - also used in oilrigs, mines etc. Hazardous environments.).

I've been a programmer longer than I've been a test engineer, so the programming side was always there, but when I started testing manually I realised how interesting testing was from the point of view of knowing the system under test.

When you test something manually and you have to raise a bug against it, you also want to raise it with the most detail possible - logs, reproduction scenario, etc. This means less work for you later, and the best possible start for the engineer working on the issue. Knowing the system under test is vital for this.

That set of skills means you are able to define actions, timings, and system setups which reproduce the issue. You need to codify the test, as it were.

If you're of a particular mindset (remember, I've been a programmer longer than a test engineer), then eventually you get interested in how to reproduce scenarios automatically, if only so you can easily retest or create regression scenarios you won't have to run yourself. You progress to looking at automation naturally (I certainly did).

In summary - if you start out in manual testing you're actually building towards working in automated test. So yes, manual testing is a good discipline to work in before working in automated test.


"Manual testing" is better phrased as simply "testing"; and "test automation" actually means "use of certain tools for testing".

So, by definition, to use certain tools to test you must know how to test.


There are some fields where you cannot test manually at all (systems which have no user interface, like parts of machines).

What's more important than experience in manual testing is a sufficient background in testing theory and of the specific subject domain.

  • Can you give a more detailed example? I think even if you have, say, a car engine... if you turn the ignition key by hand and then put your foot on the peddle, that is manual (end-to-end) testing. Automated would be if there was some test harness (machine) where you could plan a test ahead of time (turn on ignition, vary throttle thus) and then it would run the test for you. (I'm sure these exist in engine manufacturing facilities, especially for testing part lifespan, etc.) Mar 9, 2020 at 0:45
  • @user3067860 The backend of a car navigation. The OEM devices at least around year 2000 were modular: There is the frontend, the "head unit", with display and keys; and in the back is a slot like for an extension card, and if you shell out 2000 dollars they'll plug in a box which contains a CPU and memory which is attached to CAN and MOST, two automotive data buses. No human interface whatsoever. All manual tests go through the head unit, i.e. you cannot test the backend on its own manually at all. All embedded car devices on the CAN are like that. Mar 9, 2020 at 6:57
  • Why aren't you counting integration testing (with a head unit) as manual testing? Last time I updated my head unit, I certainly tested the whole system manually...connect all connectors, push play, wait to hear music... (swear, adjust connections, push play again... repeat as necessary). I wasn't expecting problems in the back end, but if there had been any they would have been revealed. And it certainly wasn't automated, since it required me actually adjusting controls (push play, adjust volume, etc.) for every test. Mar 9, 2020 at 18:05
  • @user3067860 It depends what you want to test. A manufacturer of such a plug-in unit will certainly at some point test it integrated in the head unit; but they will also, for example because the head unit does not yet exist, test the plug-in standalone through e.g. a MOST or CAN interface. But I agree: If you build a test harness or integrate an embedded device in some other way you can always at some point test it manually. For example, at some point a tester will drive the navigation device around in a car, currently still manually ;-), together with the motor control etc. Mar 9, 2020 at 18:53
  • I'm just trying to relate to "cannot test manually at all"... I still can't imagine a system where that's true. Mar 10, 2020 at 16:50

No, it is not necessary but, I would say it is beneficial.

Knowing the basics in testing is mandatory because, with the experience of test processes, test scenarios, test cases, test steps, and execution, you will be sturdy to write automated test scripts more efficiently. The transition will get smoothened if you start your career with manual testing and later moved on to automation testing.

But, I do not conclude that you have to learn manual testing to get into automated testing.

Even if you are beginning automated testing without knowing manual testing methods, you won't see any problems as you will be trained with the essential application knowledge to write the test scripts based on the test plan.

So, both have unique features that are suitable for various circumstances of the application.


It is not the requirement that the engineer should have the knowledge of manual testing before entering into automation in a software testing company. But it would always be beneficial if you have basic idea about manual testing things like:
1. Defect reporting
2. Test case creation
3. Regression Testing etc..

So before entering the automation part if you have an idea of the above things then it would be easy to make the scenarios for automation and will give the picture idea of the Application part.


Yes, just like you need to know A to Z before forming words similarly Manual Testing is important before starting Automation testing.

With Manual testing, you learn about the different scenarios that you have to test. We have basically Happy Flow and Negative Flow scenarios while testing any product. These cannot be learned directly with automation testing. When you test a product manually you see the exact functioning of the product, possible inputs that you can give in, and always manual testing takes a little less time when you have tested multiple inputs for a functionality. With automation coding and then changing input values take time.

Automation testing has its own advantages. It reduces your manual effort. Automation is basically used for Sanity testing wherein you want to see if all the functionalities are working fine, you can’t manually test each and everything daily. Automation should be learned as it is one of the most important requirements these days.

Hope it helps!


Having a basic understanding of the underlying concepts of any Topic is always going to help you understand this Topic. It will also help you to cross read about information were this Topic is used, why it is necessary and why it was developed (The Theory and the History of the Topic).

If you do that, you will become an expert in a given Topic.

So for your particular Question:

Yes! Having a basic understanding of manual Testing is a necessity to truely be good at automatic testing. What level of Proficiency you think is necessary, solely depends on how much motivation you have to get an Expert in Testing or Quality Management in general.


A effective tester needs to know both to know how to use one to amplify the effectiveness of the other and gain the momentum.


As mentioned from various answers above, there is not right or wrong here. It depends on what you want to achieve, what you want to become.

The testing industry has advanced a lot in the last decade and various roles have appeared, test analysts, manual testers, automation testers, etc.

I am old fashioned and believe that balance is the key to achieve anything. If you want to become just a coding machine that does not "care" about the context behind what you are writing about, then no, you do not need to know how to manual test.

But to do a good job, you will need to be supported by an appropriate team structure. You will need to have specific and very detailed test instructions provided to you, so that you do not need to make assumptions or lose time asking questions. Does this team structure exist in many companies? Or many are asking for "automation engineers" and require also test analysis parts?

Context is important and testing automation is not the solution to all our problems. It is a tool and should be used as a tool.

When a new product release arrives, you should have a good automation suite built up to cover your regression testing and manually test the new features. During manual testing, you also build your test cases which will be eventually used to enhance your regression suite by automating a part of them or all.

So, if you want to reach a state where you are a complete engineer and not a tester or a coder, you will need to work on all the potential paths initially and achieve fundamental knowledge on all available aspects. You will need to know the basics of exploratory testing, know how to write a test case, how to report a defect, understand the context of the work product at hand and how it needs to be tested and then, this knowledge will guide you to automate your scenarios. You would know the risks, know the pitfalls and work on those when automating, focus on what is important and not lose the big picture.


I have a slight difference of opinion here with you. Since I have been associated with Quality Assurance and Software testing services for quite a long time, I believe the best way to test software demands the perfect balance of manual testing and automated testing. It is not possible to completely automate the entire process of software testing due to the limiting capabilities of technology due to varying environments and functionalities.

However, if someone is planning to progress their career in the direction of automation, I would surely recommend them to go for the basic understanding of manual testing and coding. This would help prospective automation testers to feed the automation tools with the right test conditions while allowing them to get over minor issues on their own rather than taking every issue to the development team.


No You don't. Automation is just a value added knowledge that you can use while doing the software testing. These days its mandatory to have automation knowledge or experience so that's a different story.

The truth is if you are having good analytical skills then that's it, That's all you need to become a good tester.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.