4 ms·

One reason, from our similar experience is that showing non-Technical business people (in some environments) text with brackets, semicolons and the general code

One reason, from our similar experience is that showing non-Technical business people (in some environments) text with brackets, semicolons and the general code annotations you show here effectively “scares” them. This isn’t always true. But it tends to be institutional when it happens. In some places people learn deeply that code is the realm of the tech teams and they should not engage with it. Getting them to engage with the executable tests can be fantastically useful but it can also be a delicate sales game, where simple things like using a DSL can be key

phtrivier 7y ago
That's assuming the "non-tech businness people" are actually going to spend time writing and reading such scripts. I've never seen a situation where that ended up happening (because they're going to write the script wrong, they're going to need help debugging, etc...) Their time is probably better spend doing something else. So they will write english in mails and powerpoint, and a tech will write code in a programming language. The closest thing I can imagine to having biz people "write scripts", is if it's done in a GUI with a lot of assistance and a quick visual feedback loop (think Excel macros.) Maybe writing the GUI is a better investment than writing a compiler.
- lolinder 7y ago
  The parent comment doesn't say the non-technical people wrote the scripts, but that they were shown the scripts. Think of it this way: Writing iambic pentameter is hard. Without practice, you're almost certainly going to get the meter wrong at some point. However, reading it is easy, because it's just English. The same can be true for scripts. You don't need to be able to have business people write them, but it's nice (and in some domains critical) to be able to have them read and validate them.
- deleted 7y ago
  [deleted]
- jimbokun 7y ago
  "So they will write english in mails and powerpoint, and a tech will write code in a programming language." This reminds me of the old movies where the Executive calls in the secretary to transcribe his words. "Miss Parker! Take this down!"
twic 7y ago
Something i've done in the past is write multiple backends for an internal DSL like this. One runs the tests, another one prints out the steps as nice-looking HTML to show to The Business. It means they can't read and edit the source code directly, but in practice, this doesn't matter. We even had one that produced Excel files that could be handed over QA as manual test scripts, so they could reproduce what we were doing. An old boss once pulled off a hack where code drove a browser test, but you could run it step by step, with the element being inspected or interacted with being highlighted with a red border, and a separate window explaining what was happening in natural language. Non-technical people could follow along with what the test was doing. It was an amazingly effective way of explaining what automated testing was all about.
a_wild_dandan 7y ago
So show the laymen cute text without Scary Symbols, no? Heck, these days my tests with certain frameworks are automatically inundated with unsolicited fire emojis and green check marks. I'd imagine that isn't particularly difficult with C++, right?

phtrivier 7y ago

That's assuming the "non-tech businness people" are actually going to spend time writing and reading such scripts. I've never seen a situation where that ended up happening (because they're going to write the script wrong, they're going to need help debugging, etc...) Their time is probably better spend doing something else. So they will write english in mails and powerpoint, and a tech will write code in a programming language. The closest thing I can imagine to having biz people "write scripts", is if it's done in a GUI with a lot of assistance and a quick visual feedback loop (think Excel macros.) Maybe writing the GUI is a better investment than writing a compiler.

lolinder 7y ago
The parent comment doesn't say the non-technical people wrote the scripts, but that they were shown the scripts. Think of it this way: Writing iambic pentameter is hard. Without practice, you're almost certainly going to get the meter wrong at some point. However, reading it is easy, because it's just English. The same can be true for scripts. You don't need to be able to have business people write them, but it's nice (and in some domains critical) to be able to have them read and validate them.
deleted 7y ago
[deleted]
jimbokun 7y ago
"So they will write english in mails and powerpoint, and a tech will write code in a programming language." This reminds me of the old movies where the Executive calls in the secretary to transcribe his words. "Miss Parker! Take this down!"

twic 7y ago

Something i've done in the past is write multiple backends for an internal DSL like this. One runs the tests, another one prints out the steps as nice-looking HTML to show to The Business. It means they can't read and edit the source code directly, but in practice, this doesn't matter. We even had one that produced Excel files that could be handed over QA as manual test scripts, so they could reproduce what we were doing. An old boss once pulled off a hack where code drove a browser test, but you could run it step by step, with the element being inspected or interacted with being highlighted with a red border, and a separate window explaining what was happening in natural language. Non-technical people could follow along with what the test was doing. It was an amazingly effective way of explaining what automated testing was all about.

a_wild_dandan 7y ago

So show the laymen cute text without Scary Symbols, no? Heck, these days my tests with certain frameworks are automatically inundated with unsolicited fire emojis and green check marks. I'd imagine that isn't particularly difficult with C++, right?