Learning How To Do Automated Testing: The Diary of a Manual Tester

This is the story of how I learned to start automated testing. I share my day-to-day experiences and how I got on.


Day 1: Starting Automated Testing

I’ve been dreading today.  Today is my first day of learning automation testing.  I’m scared!  I’ve been a manual tester all this time, and everything’s been fine.  I’m at the top of my game.  I have tons of experience.  The only times I’ve ever done automated testing has been to either run a recorded macro a gazillion times to look for a memory leak, or when I had to stress test a telephony switch box and needed to hammer it with different call flow sequences.  Like the switchbox, my response is ACK!  And I hated the way that the X,Y coordinate mouse picks had to be so precise, even if I edited them in the recording before re-execution.  I think I’ll make a bet with myself now – I’ll learn this, but I won’t like it.  I mean, how can anyone test automation user Interface when you take the user out of the equation?  This record and playback stuff is a joke!


Day 2: Learning Automated Testing

Guess what?  There’s a lot more to this than record and playback.  You can modify the recordings a lot, but the goal will probably be to script things myself instead of modifying a recording.  This is starting to look like my old coding days.  It is slow, but it is not totally boring.  I guess that means no dangers of misinterpretation by whoever executes this – what I write is what gets tested, exactly as I specify, which means that I have to specify it right. I am fully responsible.  This is a good thing.  And the recordings show that I can map straight to the elements.  No more stupid X,Y mouse picks!  And it looks like I can query properties precisely – we’ll learn that in a few days.  Ever try to verify pointsize or hex color by eye?  Yeah, we just kind of checked those off after eyeballing them.  But now we’ll know for sure – this adds functionality I could never do manually!  And apparently I code it right into the script.  OK, I’m only getting a little excited here, I mean, I made a bet only yesterday.  I’m learning it, but I can still hate it in general.


Day 3: Learning Scripts 

You know what?  If I made a suite of scripts, I could execute them over lunch or overnight.  I don’t have to run the tests myself, or dump them on another tester here.  And I know that what gets checked will be exactly what I specify.  I see an advantage here.  Especially for scenarios where are many variables, meaning lots of long boring test cases (I’m still OK with the short boring ones though).  But I can see already that time will be spent very differently.  We will do the work upfront, coding the test cases (which can even happen before we have a build to test).  We were expected to read and execute how many steps a minute manually?  Well, all the reading time is now gone, and the execution is being done by script.  I mean, there’s still valid work in building the test cases … I still have a purpose here.  But the pressures of the SDLC time crunch, after Business has made their designs, and Development has programmed their code, mean that we just have to write our test scripts in parallel instead of worrying about having our testing time cut when we get the code late!  And when regression testing hits, there is a LOT to test.  But now, we could run our regression tests after every build!

Manual Tester How to do automated testing


Day 4: Testing Features

Today we looked at a feature I had not even thought about.  It can look at a webpage and tell if the URL’s are valid.  I don’t even have to know how many are on the page!   And then I can walk through all of the pages on our site!  There are other kinds of webpage validation that it does too, and all of the results get logged.  And of course automation gets used for data injection!  How else would you do it?  And performance testing can log the times, instead of me falling asleep with my stopwatch (well, I can also go into the logfile, and the number there seemed to be pretty accurate, but one day I’ll be testing something that does not log the time in the app’s logfile – especially if I’m not in verbose mode).

Day 5: How to do automated testing

You know what?  I think I like this automated testing thing.  It just means working smarter not working more unpaid overtime.  There is so much less pressure now; I will not miss the pressures of rushing lengthy boring testing before a final release!  The regression tests will need to be maintained for real, but the execution will no longer be a time drain on our department.  I look forward to the rest of my training!  Manually testing is so primitive!

About the Author


Scott Andery is an expert marketer, author and consultant who specializes in software testing tools and resources.
Find out more about @scottandery