April 28, 2010

QA Wizard Pro as a Domain-Specific Language

Helix ALM
I built a domain-specific language (DSL) in my text editor so that I don't have to remember all of the details involved in WordPress blogging. To write this article I type :save-as-blog-draft in vim, my text editor. I don't have to mess with the details of logging into WordPress, picking a post to edit, and then manually pressing the Save Draft button. Setup took about an hour and by now I've blissfully forgotten the manual labor involved in blogging. Agile development methodologies advocate using domain-specific languages not only for the time savings, but also because they allow each person to focus on what's important for his or her domain, letting programs do the hard work of translating that domain into computer talk. Similiarly, QA Wizard Pro's scripting language is a domain-specific language for automated testing.  If we've done our job correctly, you too can be blissfully unaware of how to program a mouse to move. Instead, you can focus on what to test in your application. To achieve this goal, we built bottom-up. First, we started with a general-purpose programming language core: BASIC. This core provides standard programming language features such as variables, looping, conditionals, and functions. Second, we added a large number of primitives specific to automated testing: KeyPress, MouseMove, and CheckPoint for example. Last, we combined these primitives to create a testing-specific language that matches the way people describe testing a user interface. The end result of this domain-specific language approach is that QA Wizard Pro scripts do not read like ordinary programming languages. Instead, QA Wizard Pro scripts read like test cases. For example, Microsoft includes example code in their "Find a UI Automation Element Based on a Property Condition" documentation. The example C# code, excluding blank lines and comments, is 78 lines long! And that code only finds automation controls based on a condition--it doesn't do anything with them. By contrast, the following two lines from a QA Wizard Pro script find a control, perform an action on it, verify that the operation functioned properly, and report any problems if they occurred.
Window("w").Tree("t").Item("a/b").Expand()
Window("w").Tree("t").Item("a/b").Checkpoint("Expanded", True)
QA Wizard Pro uses the domain-specific language concept because it helps users focus on the automated testing they want to do--not the programming required to pull it off. However, if you encounter difficult problems, we didn't hide the BASIC.  We simply built on top of it.  You can always use it for any reason.