SUB my_func
    COMMAND1
    COMMAND2
ENDSUB
CALL my_func
[download]

Oh, macros. How, exactly, is this easier for them to learn to do than the following:

sub my_func {
   command1;
   command2;
}
my_func;
[download]

In your case, they're learning a very simple language; in my case they're learning a very simple language that just happens to be an extremely limited subset of Perl but is not fundamentally more complicated than the language you want to teach them. (The syntax is very marginally more involved (mainly, the need for semicolons between commands), but there are no extra concepts at all.)

They only have to learn the bare minimum they want to use. If they don't want to call macros with arguments, then they don't need to be able to write macros that take arguments, then they don't have to know about @_. If they don't need to maintain state either (apart from state your procedures maintain automagically, like the current web page or whatever), then they don't have to know about variables either (much less hashes, references, and so on). They don't need to learn about control flow unless they start asking things like, "How can I make this happen twenty times in a row, without just copy and pasting it twenty times?" or "How can I make something only happen under certain circumstances". As long as they're content to stick to a strictly procedural paradigm, they don't need to know about return values, context, list transformations, or a a whole mess of other things that an actual Perl programmer would need to know.

So far, I've only introduced them to two Perl builtins (include and sub), and one of those only because they (err, you) asked for the ability to write macros. They don't need to know ANY other Perl keywords, unless they start asking things like, "How can I output a message to the person running the test script, to tell them what it's about to test?". If they did that, I'd teach them to write print "Message Text Here";, but they wouldn't need to know anything else about the print operator (for example, that it's an operator, or that it operates on a list, or that it flattens the list and evaluates the arguments in string context, or that it can optionally take a filehandle, or what it returns, or any of the other stuff you'd learn about print if you were actually learning Perl, which they're not).

An advantage of my approach is that if they do ask for certain more advanced capabilities, you don't have to extend your language; all you have to do is show them the feature they're asking for. Plus, it saves you from needing to write a parser. I don't think it's worth inventing a language and writing a parser just to avoid the need for semicolons between commands.

If they want to learn to write functions (i.e., subroutines that return meaningful values, as opposed to procedures or macros, which are executed only for their side-effects), there are, irrespective of what language and syntax you teach them, some extra concepts that they would have to learn. Even macros are a concept, but not so advanced a concept as functions. (Though, when you start wanting to pass arguments to your macros, you probably need variables, which puts you almost halfway to what you need for functions. But these QA people don't want to learn Perl, so they are probably not going to be wanting to write macros that take args in the immediate future, much less functions that return values. That smacks almost of being borderline on real programming. Throw in conditionals and it might even be Turing-complete.)

$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,".rekcah lreP rehtona tsuJ";$\=$ ;->();print$/
[download]