The fun part is stamping each step with the big green checkmark or the big red "X" as I complete each step.
I'm on step 368. In the interest of saving a few keystrokes/bytes/pages, Step 368 tells me to "Repeat steps 132 through 138." Step 368 also tells me what values to use for this section instead of the values that were used in steps 132 through 138.
Great, I have to split the screen (took a while to find that command, why can't I just double-click a toggle on the pane containing the page?), then scroll the top half back to find step 138, then mentally substitute the new values for the old ones, while eyeballing the HMI to make sure I'm clicking the right buttons and fields.
This is DRY for humans. I think Don't Repeat Yourself is great for software. Who wants to chase around through sixteen different configuration files or print statements to change a value? But humans benefit from repetition, especially in a tedious list of test steps.
Yes, we use automated testing on the application level. This is more functional testing - do the right values show in the right fields (are the fields even there to begin with?), can I click a button, does the right thing happen... stuff that's tricky to automate and stuff that automation might not catch. When I have to stop the flow, scroll up through screen after screen of identical-looking steps, find the old steps, substitute the new values, make sure I don't lose my place, well, it's no wonder I go off and rant about it.
Now the troubling thing is, the test procedure document was generated by an application that sucks in XML data files that spell out the content of each step, then spits out the PDF all nicely formatted and tabulated.
For the sake of exercising a few more CPU cycles, the scripts could include the repeated steps from a template, substituting in the new values, thus saving my limited brain cycles for understanding why the HMI doesn't match up to the values in the steps. Or something more important.