So its been a year since I have been studying Python, and just recently I started picking up web driver. It was a long journey, and I am still a pretty noob, but I finally understand how to use it lol. I have made some tests to automate my manual testing, which took a long time, but worked!

I am wondering what kind of tests QA automation engineers make daily. I made simple ones like logging in, creating a ticket, creating alarm, verifying other stuff. I can see it getting complex, but in general, am I ready to apply for an automation job? I don't want to look like a fool and say "hey I made a script to login!", but I honestly have no idea what kind of work an automation engineer would do. I can only assume it's similar to what I am doing now, and that it seems pretty basic.

My goal was to learn some Selenium, so that I have SOME automation experience, and put that on my resume. I feel I can automate a lot of what I do with WebDriver, but it wouldn't exactly be efficient, just mainly good for experience. Do any automation jobs not mind finding a novice that they can teach? Or will most require someone who can do everything right off the bat. Would be nice if a QA automation engineer can respond with what kind of tests they write and what level they would require, thanks!

  • Are you currently testing a product, and can you apply your new automation skills to your current job? That is one place to start.
    – jruberto
    Commented May 24, 2013 at 14:28
  • my company makes a web app that is strictly manual testing, I have asked if we will ever do automation, and he said if anything, not for several years. I have started automating it, but its not very efficient, plus we have several servers with different settings
    – user3043
    Commented May 24, 2013 at 16:29
  • Definitely there's nothing wrong in moving to automation from manual testing. I believe in if there's technology then why not to use. I've share a guest post of mine regarding why test automation is better choice. You can have a look at the article here to get some ideas on automation benefits. Here's the link http://www.reqtest.com/blog/why-is-automated-software-testing-is-a-better-choice/ Commented Nov 14, 2013 at 13:41
  • while the article is nice I don't think it really answers the question being asked. My take is that he is wondering if as it stands now he has the skills to move into an automation role.
    – Dan Snell
    Commented Nov 15, 2013 at 2:35

5 Answers 5


All the learning starts from step1. You have learned based on your own interest. I had a lot of support from this community and StackOverflow when I started writing automated tools. I can share my experience. 5 Rules for beginners getting into test automation:

Rule#1 - Do not worry about design, error handling when you start writing your automation suite. Write pieces of functionality and integrate it slowly. Refactoring, Applying OOPS principles, logging can be learnt once you get your code working.

Rule #2 - If you want to write selenium automation follow seleniumtests.com, select recommended tutorials / articles in this forum. There are a lot of resources you need to select and read good info articles. A mentor, in this case, would be of great help.

Rule #3 - Explore Tools - Focus on learning TestNG Basics, JUNIT basics, SOAP UI and other tools. Divide automation into multiple layers - Framework Design, Execution Layer, Logging, Reporting Layer. Allocate time and try out freeware tools, GTAC talks, Tools demo sessions.

Rule #4 - Ask for help if you are stuck. Ask for help on best practices, approach design in forums. Accept your mistakes and learn from them, keep improving your knowledge continuously.

Rule #5 - Review your own framework based on below guidelines:

  1. Re-runnable - All tests are re-runnable without any hard-coded / static data not used.
  2. Do not repeat your code/duplicate code, re-use same methods whenever needed (you are applying OOPS here).
  3. Results Reporting - Results are readable, able to drill down the steps of each test case.
  4. Error logging and reporting - You have the option to enable/disable logging to different levels to debug issues.
  5. Configurable - Able to run the system against any environment with minimum configuration changes.
  6. Apply Design Patterns / OOPS Principles / Best Practices and Keep Improving your Automation Suite.

Hope it helps!!!

Using an existing automation tool QTP, Winrunner most of the items reported will be taken care of by the product itself. Primary work would be recording, writing cases.

Developed a mature in-house automation framework takes several iterations but working code is always best to ship it, to begin with.

  • thanks, this definitely helps. I don't have access to anything except selenium, but was wondering if knowing selenium will mean I will know qtp, besides using the software itself.
    – user3043
    Commented May 24, 2013 at 16:34
  • 1
    Knowing Selenium will not get you any knowledge on QTP. Both tools are poles apart. Though knowing automation may help you in learning any tool quick.
    – Tarun
    Commented May 28, 2013 at 4:15

My experience with automation is that it's invaluable for regression, particularly the kinds of regression that are tedious and painstaking to perform. A login script is usually a utility that happens as part of a larger script suite - which must, as Siva said, be object-oriented and data-driven if you don't want to create yourself a maintenance nightmare.

Phil is 100% correct - you don't want to simply code your manual tests. Some types of test are better handled manually, others make more sense to automate.

My suggestions are:

  • look to the 80/20 rule - good automation targets involve the 20% of your application that's used by 80% of your users 80% of the time. My last employer, the application had massive amounts of setup, which was largely once and done, and a relatively small transaction component where almost all the activity occurred. Regression focused on the transactions.
  • each component identifier should appear exactly once in your code, preferably as a defined constant or an object mapping. That way, when the component changes, you're only updating your automation in one place and you know which place you're updating. (My current position, I'm storing it in a database and have built a crude web app to edit the database).
  • look at ROI - not so much $$$ but tester time and business value. If you've got a set of manual tests that take days or hours to complete, and they'll hurt your employer's reputation if a regression escapes, they're a good target for automation. My last employer, this was tax calculations in transactions. Bare-bones manual regression of that was 3- 5 testers for a week of tedium with a high probability of errors. Once the automation was in place for it and the misery of validating the baselines completed, a more comprehensive set of tests run every night (on three machines, for a total run-time somewhere over 24 hours), so that anything affecting tax calculations were caught within a day of it being introduced.
  • keep aggressive maintenance and refactoring program - My experience is that aggressively maintaining and improving your automation code is the only way to keep it from becoming a headache. My last employer, some of the automation was over 10 years old and I was the only person there who understood how it worked because there wasn't enough of a priority on maintenance.
  • automation is code - You'd be surprised how many people don't get this. You see tools advertising code-free automation - what they mean is that they code it and limit your ability to build scripts to the things they've coded. Even using these tools you still need to keep your tests granular and reusable or you'll end up with a mess.
  • do not record/playback - Even the most advanced record/playback tools can't do the things well-constructed code can do.
  • automate the tedious tasks - I can't stress this enough. If you're doing something boring multiple times over, it's a good candidate for automation.
  • don't forget the utilities - Utility automation can get overlooked in favor of automated regression, but it's just as useful. Automating a lengthy application install process saves everyone time and effort. Automating configuring standard data sets is another good one to consider. Automated database backup/restoration, bulk file copy operations, virtual machine setups and the like are huge time-savers. Automating the test reporting is another good one to work with - instead of using the tool's result reporting, export the test logs to a central repository in a format that everyone can read. Feed them into a dashboard your managers can use.
  • if it repeats, automate it - with obvious exceptions like checking printed output (which is faster and more accurate using the mach-1 eyeball), if a defect slips to production more than once, consider automation to test for it.

Hopefully, these will give you some ideas to start with.

  • I am very curious as to what the automation scripts look like, do you have any examples? it will help me a lot in designing my own, so I have something to go off of. Nobody at my work talks about automation, or even knows how to do it :(. I am asking for examples used in everyday work, not tutorials.
    – user3043
    Commented May 24, 2013 at 16:36
  • @JacobHong what I have looks like code. I use a switch structure that feeds each type of test automation action to its own routine with the test object and test data object passed in as parameters. Getting to the switch involves pulling information from the database and running through the recordsets.
    – Kate Paulk
    Commented May 24, 2013 at 17:11
  • hmm interesting, sounds a lot different than what I was expecting.
    – user3043
    Commented May 24, 2013 at 17:31

Hopefully someone will come along with their experience but you might like to be aware that automation is not just a case of coding up your manual tests, the full benefit of automation is when it does more than that...

  • 1
    Can you please elaborate?
    – Eugene S
    Commented Jun 19, 2013 at 1:45

For Automation testing, you will be requiring complete knowledge of the domain or project you are testing. Knowing the actual/expected behavior will help you a lot in writing automated test scripts.

You can use Selenium IDE for writing or practicing simple test scripts. Once you are through the scripts then you can confidently write test scripts using IDE or RC etc.


All great stuff above but its seems in isolation. Automation is whole dev dept activity, if the objects are not uniquely identifiable then you may end up one of a large number of people that get frustrated with automation, believe me, it's not nice being a lone voice calling for help.

You will need to manage expectations, it takes time to put together something that works well in anything other than the first few weeks.

When trialling any new tool try to do so for at least 2 weeks, a month is better and try to do the hard stuff, table cells with objects in, procedurally generated images that are buttons, third party control that looks good.

You will need nerves of steel when discussing the fact that record and playback are still not that good with most tools.

Test automation doesn't necessarily write all the tests, they may maintain the tool more than write tests, they could be there to enable others to write the tests. Handcrafting tests is the way to go as mentioned above.

If your tool does not have an object repository then make one. Get developers to put in unique Id's for ALL objects, after all, using objects is the primary goal of automation. Better yet abstract out the repository and get the devs to maintain the object repository spreadsheet or however you keep it.

Make sure that you can pin down an error as close as possible from the test log. Always take a screen/application shot when a test fails and any other information that you can.

Try not to use static waits in code to overcome a problem of load times of 'glitches', wait for something to happen in the loop if you have nothing else. Even though an object appears it may not be loaded and ready fully.

Always test the test on two machines, especially a min spec machine, you will get different results.

Put timings in the report at debug level o lengthy tests can be looked at to see where they take too long. Always expect a demo to fail :) its like magic!

If a company is serious about automation then the Automator should NOT fill in for other testers when other projects are 'pushed' for time, its a slippery slope unless automation is well established.

Abstract the tests and repository ( much as possible) from the automation engine so a new one can be plugged in to do the donkey work if t company decides to go in a different direction.

Good luck.

  • Hi, Skepsis, there's a fair number of good suggestions here. Some of them could have used a bit more detail, and the OP did mention that his environment is not one where a whole department activity is viable. Welcome.
    – Kate Paulk
    Commented Jul 17, 2013 at 11:43