Lessons from the Black Ops Testing LTG Workshop!

A few weeks ago I attended the very first London Tester Gathering Workshops sessions – a 2 day event hosted by Tony Bruce in partnership with Skills Matter, along with some more of the leading testers in our industry.

Initially, I didn’t know what to expect of the workshops… I thought that it might be like the usual conference structure, where you have some talks and maybe some round table discussions. But that there would probably be more focus on group discussions. But when I was sent an email reminder telling me to my laptop, I was intrigued and excited! That could only mean that it would be a lot more hands on, and that I’d get to experience some new tools! 🙂

On the first day, I opted to sit in the main room. This was the room with the “Black Ops Testing” workshop, which was hosted by Tony Bruce, Steve Green, James Lyndsay and Alan Richardson – a power house of great testers, with a good variance of the skill sets and mindsets that they are known for! Alan clearly comes from a more technical testing mind-set, whereas James is more of a strategist and Steve and Tony have fantastic exploratory testing mind-sets.

So the session began with an overview of their skills and what their expectations and challenges were for bringing together this workshop. They then went on to describe what we’d be doing – testing “Redmine” some software that is currently live and in use by some companies (and is available here).

Redmine is a tool that can be used for project management and bug tracking.

Our mission was 3 fold:
– to discuss what we had learned about Redmine’s functionality after 30 minutes of initial investigation,
– to plan what we aim to test in the next 45 minute session
– to then discuss what we actually tested and what bugs we found after the testing session.

In the initial investigation phase, I set out attempting to create a user so that I could discover what functionality was available to my basic level user. I knew there was an admin user available, and James happily supplied the log in credentials for that admin user, so I could see which functionality was specific to them too. I also looked at what was available to a non logged in person browsing the site and started drawing all this out on a mind map.

On creating my basic user, I thought I’d try to test the validation rules as I went along (to see if there was any), so I decided to paste in a bundle of ASCII characters from my test data generator. Straight away after pasting, the website became unresponsive… I had managed to take down the site completely (which I’m sure many people found annoying since they could no longer access it). James restarted it for me to bring it back up again.
So that was my first bug…

as I continued to explore the site, I mapped out the functional areas available to the user types, before our time boxed investigation session came to an end.
This naturally stemmed the basis of a plan for me for the second part of the challenge – what we aim to test… I decided to focus on the main functional areas/selling points and risk areas of the Redmine web app.
For this phase, me and my colleagues who were in attendance decided to test in a group. There were 4 of us, with 2 laptops… Between us, we stemmed some great test ideas and found some great bugs. Paired testing is something I rate very highly and hope to write a future blog post about regarding my experiences of pairing!

After we had finished, each group then went on to discuss what they opted to test and the approach they took along with some of the bugs they found. It was interesting to hear how some people focused on different areas as they had different perspectives of the application which led to them focusing on a different starting point.

Some started with hooking up some proxy interceptor tools to take a look at what was being sent and received between the site and the server and to try to manipulate that. Some started combing through the source code. Others looking at as much help documentation and sales claims as they could find online and in the application. Some started on the various functional areas of the application and some even started looking for security vulnerabilities such as XSS and SQL Injection. It was interesting to share our experiences and perspectives on the software.

After that, Alan and James then shared their own exploratory notes with us from their testing session. They ran through exactly how they approached the system, the areas that they focussed on and the issues and possible risks that they noticed along their way.

As anticipated, Alan started with hooking up a proxy tool (I think it was Fiddler he said he used… It might have been Burp Suite or even both together!). James’ notes were very interesting too, as he walked us through his approach of testing the system which was very different to Alan’s. There note taking was quite similar though, where they seemed to highlight various areas to indicate tagged sections and also used timestamps. It looked very much like they were using a Session Based Test Management approach.

We were able to have a great conversation about SBTM, which I thoroughly enjoyed as it’s something that I’ve used before and am keen to introduce to my colleagues in my current place of work.

Overall, the workshop was great! I had a great time and learned lots of new ideas and tools to take back with me to my work! Tony has done a fantastic job and I’m really looking forward to attending the next LTG Workshops next year!

One thought on “Lessons from the Black Ops Testing LTG Workshop!

Please leave a comment!

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s