Actual experience from non-technical team members writing Selenium code: it didn't go well
We actually had this very situation happen where we had a non-technical team member (in this case, an SQA with no programming background). This unfortunately didn't go very well.
Record and play created unmaintainable tests
First our team had tried the record and play tools, but as other have said, the tests it generates are very brittle and hard to maintain. Our SQA eventually wound up falling into a pattern of just rerecording a test every time it changed, which wasn't really that efficient, especially when one change broke most of our tests (we had one change to our website's main page that broke about 60% of our tests).
Without help from those with a programming background, the manually written code was horrendous
We wrote our Selenium tests in Java and the SQA had never used Java before, so he was learning it on his own. We found that tests wound up using some really poor programming practices:
- Using public static variables when they really should have been private instance variables
- Having code blocks that didn't do anything
- Lots of Thread.sleep() instead of using WebDriverWait because he couldn't figure out how to write custom conditions
- Really awkward unit testing: I saw quite a few
assertTrue(false) lines to terminate a test
- Poor variable names
- Suppressing exceptions that should have been handled (or prevented from occurring in the first place)
- Tests that passed no matter what input you used
- Some code we never did figure out and we just wound up rewriting
When I arrived on the team, the original SQA had left and running any test resulted in a bunch of console exceptions that we were just told to ignore. After that, we wound up getting developers involved and massively rewriting a lot of the code to make it actually work correctly and be maintainable and easy to understand.
If you're going to have non-technical people write Selenium code, have a technical person help them
I think that some of these problems might have been avoided if we had someone who was technical come and help them. If they had explained why public static variables should instead be private instance variables, or how JUnit works, or how to use WebDriverWait, or why scattering Thread.sleep() around everywhere is bad, we might have had better code.
But as is, we wound up with code that was ultimately unmaintainable and in the end, we just rewrote most of it, resulting in a big waste of time and money.