One of the challenges for a test automation newbie is the change of mindset; from a developer to tester and vice versa. I encountered this the first time I wrote my very first test automation script. I did some manual exploratory testing using mouse and keyboard, I visualized a certain repeatable intact scenario, recorded mouse and keyboard interactions, then played back the script and a neat automated test report popped with the passed and failed results, and I couldn't be happier :)


As I finished my delicious launch, an email popped with an unpleasant content: Please test the functionality when the bla bla bla is not bla bla bla. Now wait, recording will not do me this. The only way I can do it is by writing my own new java class. So I rolled my sleeves up and started coding.


Hours and hours passed, and noticed that my thinking is dangerously drifting into a developer mindset. I remember some testing guru saying : "A good developer is not a good tester", but am I not a developer now? How can I develop a good automation script and keep in mind my third eye sharp and active?


Through practice, I learned that in order to write a good automation script, and at the same time, the automation script tests it's intended functionality, you need to learn to change the way you think and to keep remembering that you are after all a tester and not a developer.

While writing an automation script that involves coding intervention, think as a developer and keep yourself contained in the quality theme. This is manifested when you run this script against your application. At this moment, abandon your developer mindset and think only about the test results.


This may seem easily said, and yes it is, but through practice an oxymoron of test developer can be achieved.