Automation Testing: Why are we making it so complex? Part 2: all modules big and small

belize.pngI hope  everyone enjoyed my last post on Frameworks and it caused you to take an inventory of how you are currently approaching automation testing today. The post spurred some good conversations and I figured why not go ahead with the next step (I bet you thought I would get lost in the jungles of Belize. No such luck!)  Now that I have returned home safely, we can look at modules and modularity in automation testing. This is something that we (HP) have been preaching and supporting with Business Process Testing (BPT) for years.  I have watched clients embrace modules to some extent over the years; and again I am wondering why we make this so complex.

                                                                                                                                                                         

Let’s first start off with what we would define as modules within automation. If you asked a group of testers what a module was, you would get a number of similar, but different answers. That might be part of our confusion and an answer as to why complexity keeps growing into our solutions. Instead of asking about modules in automation testing,  first lets define what it means to modularize something:

 

Modularization: is decomposing an test flow/case into a number of unique components that may be mixed and matched in a variety of configurations to provide high degrees of reusability not just for the original test flow/case, but for the product and application set in general.

 

Whew, that was a lot of words. Let’s simplify it: when we modularize, we want to focus on breaking our tests into parts that can be easily used by other tests. That’s the whole point of modularization, to make reusable parts out of each test case we have.  But what is a module then?

 

Module: is a collection of steps in a test case that will always be executed in the same series to achieve a set result.

 

It’s the collection of those steps, not a single step.  A module that presses a button on a specific page (or a specific button on ALL pages) doesn’t provide a ROI at the same level as a module that fills in all the fields on a page.  Sometimes these are tests, sometimes they are functions; but they are always reusable and always a series of steps to become a module.

 

What we see, however, is that modules are becoming far too simplified or are they becoming so enormous that their reusability is being compromised. Once modules start to become either too small or too large, script maintenance costs increase, testing supportability goes down, and overall automation performance suffers.  To prevent this, here are some simple guidelines that I follow every time I am performing any new automation, or doing a review of existing automation on projects.

 

Brian’s Dos and Don’ts of Defining Modularization

 

  • Always make modules out of the smallest number of steps that will always be acted on in series. Look at a set of steps in test cases that show up in multiple different test cases, but are always executed in the same fashion. This is the groundwork for modules. They are never too small; they are always reusable and never bloated to increase maintenance.

 

  • Always document pre- and post-conditions of all modular test cases. This will ensure that other testers who use them will know where in the application flow they need to be and where they will be left in the application when they are done.  Never assume that you are the only tester that will reuse this code. Always write and document as if someone else is going to take over once you win the lottery.

 

  • Always look at this modular test case with the same set of standards that one would review any test case. This means that all the principles that are covered above need to be reviewed on the newly created test cases made from this step. This covers peer reviews, proper naming conventions, validation of data inputs and everything else that is essential to getting the most reusability and reduction of maintenance costs associated with this asset.

 

  • Never have a module that is only one execution line long.  That is, you wouldn’t build a module to perform a single task; you have a module to perform a series of tasks to address a need.  This is the same reason why test cases are not just one line long. They are not descriptive/useful enough and would not warrant a separate test case. You would not build modules that are single execution lines either.

 

 I hope that you all got something, positive, out of this article. Feel free to reach out to me in the comments section below. I would love to continue the conversation around module size. Next month, I will talk about the selection process and the criteria for deciding what type of automation and when to introduce it into a product development lifecycle. 

Comments
vaishnavi_alm | ‎03-18-2013 08:08 PM

I am currently implementing business process testing for my customer and the timing is right for me to have landed at this article. Very well put. Thanks for sharing the best practices.

 

I would like to differ on one point, though. "Never have a module that is only one execution line long". I think it sometimes helps. A simple scenario that comes to mind, is this: When a website changes a one-click Exit process to a two-step process. Earlier the users could click on one button - "Exit" to exit a page. Now, they are presented with a message that reads "This will navigate you away from the page" and two buttons: Ok and Cancel. If the business flow involves multiple calls to Exit process, wouldn't it help if this was modularized?

 

| ‎03-18-2013 08:26 PM

Thanks for the comment and for reading!

 

I see where you are going, but if you think about it, when you have a single module that ‘just’ clicks exit?  You would more than likely have additional steps (exit and clean up, exit and reset to home page, exit and review check out … ), at least I feel that you would.  Then we see the problem with allowing modules to have single steps is it’s a slippery slope to then have a module for any ‘OK’ button or a module for ‘NAME’ field, because these are repeatable steps and become single clicks or actions.  Once you allow these, then you are starting to build a module for every object in your Shared Object Repository, which isn’t what you want either. It’s like building with LEGO building blocks, you can use the very small ones to (the ones that are the 1x1’s) to build a building, but it will be BEYOND tedious and the benefits of larger blocks are not being leveraged.  You want these modules to have enough meat on them to make the useful.  There are exceptions to any rule, but I would be VERY careful in allowing them and make sure you have fully investigated the whole of the testing scenario before proceeding.

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
About the Author
I have more than 12 years in IT, with over 10 years working with the HP Quality Management suite of tools—seven as a Professional Services c...


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation