Pro-Tip: Do what I do... No, really...

One thing that I've found is common among people starting up with test automation is this tendency to not fully think through what they are automating.  Either they make it too complicated or they don't add enough detail.  The rule of thumb that I tend to use when automating is: do what I would do.

 

For example, let's say I'm tasked with writing an automation test to check to see if, after I click a button, a particular bit of text shows up on the screen.  As a manual tester, I would:

 

1) Go to the form in question

2) Click the button

3) Look for the text field

4) Make sure the contents are what I expect to see

 

Translating this to automation should basically be the same thing.  There are some technical details involved (object identification, etc).  But I would translate all that into some sort of code.  It would, perhaps, look like this.

 

function testButtonText(){
    try {
        //I'm assuming I've already navigated to the form.
        var myApplication = Aliases.myapp;
        var myForm = myapplication.myForm;
        myForm.myButton.Click();
        var myTextField = myForm.WaitAliasChild('myTextField', 10000);
        if (!myTextField.Exists) {
            throw Error('The text field didn't display on screen');
        }
        aqObject.CheckProperty(myTextField, 'wText', 0, 'My test text');
    }
    catch (e) {
        Log.Error(e.message);
    }
}

Now, this seems straight forward but you would be surprised at how many times I've counseled my co-workers that, when automating a test case, automate what they would do when testing it.  Think through what steps they would do to conduct a validation and then translate that into the code and the tool.

 

There is a skill that is necessary here, and this is regardless of the tool, and that is the skill to translate the decision processes we make as manual testers when executing a test case.  And with that comes a fairly extreme awareness of the granularity of the that process.  

 

Just some tips:

1) Think about the decisions being made.  Any decision where, depending upon the result in the application determines a different course of action should translate into an "if..then" statement. This could mean multiple branches, else statements, etc., to fully translate the decision tree.  Don't rule out switch/case statements either.

2) Don't over think things.  Validating all the properties of an object may be fine if you are specifically tasked with making sure the object matches a whole variety of things.  But if all you're tasked to do is check one property, only check that one property. Do what is necessary for a solid test case but keep it within the scope of what would be done for a manual test.

 

Again... this all seems obvious to many of us but this is, in essence, what functional test automation is... making the testing tool do what we do naturally as manual testers. I would suggest, perhaps, that if you are jumping in to test automation and haven't spent a lot of time as an actual manual tester, talk to your superiors and see if there is a way you can jump in and help your manual testing team for a time so you can build up those skills.  Your automation efforts will benefit from this greatly as your tests become more solid and bring more value to your overall testing efforts.

 

Cheers!