[webignition]

I'm currently developing a test automation DSL as part of a full automation service.

My partner worked for some time running on-site test automation courses. This was for organisations where the devs were average 9-5 workers without any passion for software development. Not the sort of places that would ever feature on HN.

Manual testers transitioning to automation testers within such organisations are, in most cases, fully incapable of doing so effectively.

Such testers cannot learn to code. Many could barely type with much proficiency. All were great people and great at manual testing, but coding was generally not what they were wired for.

There is a market for something easier.

It took me some time developing a plain-English DSL to realise myself that the majority of browser automation coding isn't coding.

You can abstract away the hard parts. What you're left with is not coding but configuration.

Given the right automation system you don't need to write code to define your tests, you instead need to configure the system to test as needed.

A DSL to replace current automation coding as-is is indeed an odd task.

A DSL for a minimal-grammar configuration language within an automation system can definitely work.

Will it work for everyone? No, absolutely not. Not you and not many who read HN. We're the outliers.

Will it work for boring dusty companies that we've never heard of and which can't afford to employ people who read HN? Yes, definitely.

[ou_ryperd]

I take your point, and kudo's.

Where I'm coming from is having seen some tool vendors sell "scriptless" test automation tools. UFT has it, and what used to be Rational Functional Tester has it (I peddled RFT in a previous life). The vendors sold it very successfully to non-technical managers, and it looks cool, the dusty companies and large companies all fell for it. "Your Business Analysts can automate tests". But a few months down the line, you realise that it is a rock muffin. No modular code, but linear end-to-end scripts. The login page changed? Update hundreds of test scripts. Who looks bad? Test automation as a profession.

[webignition]

I certainly feel your pain when it comes to non-modular linear end-to-end scripts.

The DSL I'm working on is already quite modular so as to reduce repetition, to hide complex-looking things like CSS selectors behind user-defined names and to support the definition of data sets independent of the tests that use them.

A test for a given page can import test steps, adding further actions and assertions if required and injecting one or more sets of data over which to iterate.

Sets of data can be defined inline (to support quick learning) or defined in separate files and imported and referenced (more ideal).

Properties of a page being tested can be defined separately to the test itself, including aspects such as the URL and named locators expressed as either CSS selectors or XPath expressions, referenced later as needed by the user-defined name. This reduces to one the number places many page-specific details need changing, as well as allowing the tests (which reference by name pre-defined locators) to flow more naturally.

I'd greatly appreciate your feedback in a few months when we have something workable to demonstrate. My email is in my profile if you're happy to help.

[ou_ryperd]

So is mine. Send me a link when you have something.

[webignition]

Your email doesn't appear to be present in your public profile that I can see.