For a bit of fun for my team, I built up a set of tests in Runscope. The first one I wrote was a working test. I copied it so that there were 12 copies of the test (the test itself was in Javascript). I then broke it in subtle ways (including changing a pound sign for a euro, a false positive, not incrementing a variable etc) and asked them to make the tests pass properly. Does anyone else do anything like this, or have any suggestions on similar sorts of exercises I could run?
You may wish to look through Products and sites to practice testing on if you haven’t already.
Is it something you do within your team to help train them, give them a better understanding of testing, stop them from going rusty depending on the type of work they do, etc?
It also feels like you are manually performing mutation testing, changing your source and seeing if their tests are picking up the changes. If it isn’t something you have looked into (it’s still quite unknown/niche), have a look into it.
Thank you for your reply. Not all of the team write test scripts, but want to learn. I figured it would just be a way they could pick up the basics. When they’re comfortable with amending existing scripts, I’ll be getting them to write their own tests. When I said that I was changing pound signs etc, I meant in the test, rather than the code. When they’re writing their own tests, then I’ll start sending iffy requests etc.
As part of them learning how to create test scripts, do you have them pairing/mobbing to do so, or are they making them in isolation?
When they have made their scripts, do you show them how you would have done it, to give them a comparison? As it’s something I used with newer members in my team. It helped show one was very technical in what they wanted to do, but hadn’t though about “negative” scenarios, to prove something can’t/shouldn’t happen. Whereas another tester was the opposite, good at thinking about the different scenarios, but not as strong on how to make it happen.
But by pairing them up, they reinforced each other’s strengths, whilst supporting the weaknesses of the other.
2 Likes
As it’s a new thing that they’re learning, I’m more concerned with them learning to maintain scripts, so it’s only minor tweaks that are required to get them to work again. Writing their own comes next, which I may well get them to pair for.
As Runscope is not something I have experience with (or even heard of), is it suitable for them to maintain something they can’t write and fully understand?
Is there a risk they don’t maintain it in the best way, and creating technical debt going ahead, as they have to unpick the things they did?
Or that they are writing things to maintain it, without understanding what it does and why they need to have certain syntax or code in specific places?
Runscope tests are written in Javascript. The tests are not ones that they will be using in anger. Runscope sends a request, gets json back, and the tests look out for a particular bit of display text in an array. In the tests, I had simple things like changing 1s for ls, not iterating properly to scan through all the blocks and, the one that caught them out, a false positive whereby it would always return as true. What my intention is, when they feel comfortable doing so, is to create some ‘skeleton’ requests and tests that they can amend to help them with their testing. It seemed to go down well, and they seemed to enjoy it.
Hi,
It can depend upon your framework, but if your intention is to get people writing tests you can try providing them with (mostly) complete tests to modify themselves.
For example if you’re using js give them the test file with the majority of the test already written in the before / after and have them write in the missing pieces based on requirements. Over time reduce the amount that is already completed.
This is essentially the inverse of your skeleton idea, it just has people reverse engineering a test and modifying it rather than building upon it. Either approach seems sound for introducing people to automation though your skeleton one might be less overwhelming, it may just depend on the person.
Thank you for your response. The idea of reducing what is already written is the route I’m going to go down, until I can give them nothing but the expected results.