As we started to use Angular.js and REST services in our company, the idea was to give some insight about some potential bugs that may appear in these technologies. Participants didn't have any documentation or specification – just the application with very simple functionality and a lot of bugs with different level of complexity, so every tester could find at least one bug. Testers worked in pairs, so there was an opportunity to share experience. Pairs had about 1 hour for testing, after what I revealed known bugs and some pairs shared their bugs that I didn't mentioned about. Also in the middle of the workshop we published some tools, that we suggested to use to explore the application – it was a little hint for testers, who were out of ideas.
Alla Tarnovskaja drew beautiful pictures specially for the workshop. This bug is defeated by Nortal team.
My main fear before workshop was stability of servers – application uses web and REST servers (on Node.js) and as I didn't write them before I was scared that testers will put them down with some injections or special symbols. And they did. They put REST server down about 10 times and web server – 2 times. But during the workshop I constantly monitored logs, so I managed to put them up again in a very short time (1-2 seconds), so general downtime is not more than 2 minutes. The problem is, that all pairs used the same servers, so if one pair managed to put it down all pairs didn't have access to application anymore. I was thought about giving source code of services and application to all pairs, so they could launch them on their own machines (or on virtual machines) and don't depend on others injections, but these things usually take a lot of time in the beginning and we didn't had that time.
One idea that came up during the workshop – it will be fun to do some beautiful logs of servers and put them on big screen, so every pair during the workshop could see what is going on on server. But you can do this only if pairs use one general server, which is risky.
Also I got a lot of ideas about bugs that I can put into application from workshops in Let's Test conference.
There is 2 things that I really liked in our workshop and didn't see in other similar workshops. First one – very detailed documentation about known bugs and how to reproduce them (documentation was opened at the end of workshop), so every participant could try to reproduce them at home, after the conference. Second one – one very interesting and hard to find bug, that nobody found. It's always a little bit boring to hear about revealing the known bugs if you have already found them by your own. More interesting is to see how to find bugs that you didn't found.
Doing workshop is fun and useful – usually I start to ask myself right questions only if I have responsibilities and fears. So making workshop is way more productive for me, than participating in it.