{"id":2052,"date":"2013-05-25T10:18:47","date_gmt":"2013-05-25T10:18:47","guid":{"rendered":"http:\/\/www.mjtnet.com\/blog\/?p=2052"},"modified":"2013-05-25T10:18:47","modified_gmt":"2013-05-25T10:18:47","slug":"test-plan-automation-101-macro-scheduler-style","status":"publish","type":"post","link":"https:\/\/www.mjtnet.com\/blog\/2013\/05\/25\/test-plan-automation-101-macro-scheduler-style\/","title":{"rendered":"Test Plan Automation 101 – Macro Scheduler Style"},"content":{"rendered":"

This is a guest post by Antonius Momac and Jana Krawiec, QA Automation Analysts at Triple Point Technology.<\/span><\/p>\n

\n

“If you don’t know where you’re going, any road will take you there” <\/em><\/p>\n

– George Harrison<\/p>\n

The main questions to ask when considering automated software testing are: \u201cWhere do I start?\u201d \u00a0and \u201cWhere is it that I want to go?\u201d \u00a0If you spend too much time on the wrong path, you\u2019re either going to fail or overspend on time and resources. \u00a0Therefore it\u2019s a good idea to get a clear picture of how information systems (applications under test) work. \u00a0I don\u2019t mean at the low-level of zeros and ones that are crunched by the CPU, but rather where human meets machine.<\/p>\n

The fundamental to any software process is that there are three main parts:<\/p>\n

the Input (start), the process (main action), and the output (end) . \u00a0From the input, some data is taken and changed by the process which generates the output; i.e. modified data.<\/p>\n

\"\"<\/p>\n

As an automation engineer, the choice of what part of the process to automate is yours. Automate as much or as little as you see fit. \u00a0Think about your particular situation and what makes sense. \u00a0Do you automate the setup? \u00a0Or is it better to automate the steps of the test plan (the driver\/autopilot) and\/or the verification? \u00a0Better yet, all three, or just one of them?<\/p>\n

We started with a manual test plan and fully automated it. \u00a0Simply because the Macro Scheduler scripting language is flexible enough to support automation from all approaches. Automating the setup, the input, the process (say clicking on a button, or some mouse actions), as well as the verification of the output and reporting went smoothly. \u00a0We created small scripts that were managed from a master script. \u00a0A full and complex four hour test plan was built. \u00a0Everything worked great until we put it to the action testing a new build. We discovered that our GUI is in constant flux, which caused major changes to wreak havoc on our automated scripts. \u00a0Real time maintenance of scripts was required, thereby slowing down the entire testing process. \u00a0Ironically, this is the exact opposite of what test automation is all about.<\/p>\n

In the end, full automation didn\u2019t work for us. Less technical minded testers were not interested nor capable of learning how to debug a failing script. \u00a0Moreover, with the introduction of new features and constant GUI changes, our major focus during testing went to maintenance of our automation routines instead of finding bugs in the new release. Knowing that we picked the best possible software for automation allowed us to start looking for alternative approaches. \u00a0We decided to bypass the GUI interaction and focus on the verification process, since we never experienced issues with it. \u00a0Before long, we were getting through the testplan faster by manual GUI interaction combined with the verification process. It allowed us to test the application quickly, accurately and in depth. \u00a0Once we got the best of both worlds, we decided to develop a tool that would handle the verification with minimal setup. \u00a0With this tool anybody could set it up and get right into regression testing and finding bugs faster. \u00a0It allows us to integrate automation into new test plans very quickly.<\/p>\n

Let\u2019s analyze a test plan of 156 US-Letter size pages in length to get a better understanding. \u00a0The Majority of the test plan, 125 pages (82.6%)<\/strong>, are dedicated to verification <\/strong>or what we call a checkpoint. \u00a0Further breakdown of those 125 pages revealed that there is 1 verification process<\/strong> is being repeated 50+ times<\/strong> consuming 108 pages. Manual verification is tedious and time consuming. Automating this one<\/strong> repetitive process eliminates 70%<\/strong>(108 pages) of the entire test plan in one shot.<\/p>\n

Best of all removing, adding or updating automated routines proves to be an efficient process. No need to reconstruct or redesigning existing scripts and routines, saving us plenty of valuable time with minimal maintenance. Clearly, this is the road anybody wants to be on when it comes to automating your test plan.<\/p>\n

So when you\u2019re thinking about automating your test plan, consider these three rules of thumb:<\/p>\n