Last year I was working with Tiest, a former colleague of mine at a bank working on a system with an internal API. It was quite an experience, though I will save that for another (set of?) blog posts for another time. The application was centrally hosted with a client API that allowed people to interact with the server side. The testers needed something to help them do more exploratory testing and my former colleague came up with a great solution to this problem that I thought would be worth recording here for posterity.
Our solution had these characteristics:
- Provided through a web browser – Installing items onto the testers machines became a bit laborious, namely because they didn’t have rights to install, change or run anything with administrator privileges. It was easier to deploy the tool centrally, and then let the testers prod from afar. This was as simple as writing a page that submitted some code to a web server, that than executed it and returned the results back to the client.
- Supported dynamic execution – We could have written a web layer on top of the client API but we didn’t really want to add another layer for maintenance. We simply used the javax.script package to turn our standard POJOs into a scriptable/dynamically invokable system.
- Built in reflection functions – Using the scripting interface meant that the server would not store any state. So the server had a number of built in functions such as a
listAll(object)that would show all available property/methods to the user - Example queries stored on a wiki – When a tester would ask for something to be checked against the test environment, I would convert it into an appropriate query they could paste into the query browser window. They could then execute it, tweaking parameters, etc and learn to compose things. They didn’t have to really understand how java (as script) worked, just build on what was there.
Although I won’t be reaching into my testing patterns toolkit for this pattern too often, I feel it worked well to enable our non-technical testers to get at something given a number of environmental constraints.
Unfortunately the day to day reality is that the testers were not that technical enough and found this solution a little complex and sadly the website was not maintained.
Even a full blown java solution proved difficult so I’m not sure what the solution is…
More technical testers? A more non-technical solution? Not sure.
Hi Chris!
Thanks for the update. Whilst I, too, guessed that the tool wouldn’t be used without the social support of the devs, it was a first step in giving them something they *could* use. To me, the problem was fundamentally people problems (surprise surprise!). It was a very technical application so either getting technical QAs would have helped, or working to educate and provide more easily accessible things to them and showing them how it worked would be a good start.
I wouldn’t discard this testing pattern because I think given a different environment, it could have been useful. Hope you’re doing well!