Last Friday evening, two Assurity colleagues and I took part in the Software Testing World Cup
It was tough – we only had three hours to test a system we knew nothing about called Social Text.
We were testing a release that had not gone live yet and were asked something along the lines of “Is this release ready to be deployed?” (well that’s what I heard anyway). Based on that, we decided to use the Information Objective Block Premature Product Release. Therefore, throughout testing we were asking ourselves – does this bug impact whether or not we would go live with this product?
We were fortunate enough to have access to the Video Conference at the Assurity Office. While I was based in Auckland, the rest of my team was based in Wellington and the great thing about video conference is that the quality was great (spectacular actually) the whole way through.
Below are two photos that Alice and I took while we tested (in it, is also one of our friends who had just gone out drinking for a farewell party and wanted to pop by and say hello while she surfs the net).
Here are some of the few key things I learned from this about Testing in a short period of time:
Use your time wisely
Don’t underestimate how quickly time flies and have a good idea what you want to accomplish in 30-minute intervals. (like little mini-sprints)
It’s safe to safe that my perception of three hours seemed a whole lot longer before the competition than after. We spent the first 45 minutes running around like headless chickens with almost no idea of what we’re doing and kind of ‘winging’ it.
Just as we felt like we properly got into a rhythm, I saw we were already halfway through our time.
Lastly, even though we started our report 45 minutes before the closing time, we had trouble saving it to a Word document so we ended up sending the report to the judges with just a Subject.
It’s hard to multi-task and do things well
If possible, focus on one task at a time – but note that some tasks may naturally go hand-in-hand together. e.g. Testing the system and Raising Bugs (Mind you I prefer to write on post-it notes when I find a bug, then keep testing while I’m on a roll – I prefer to only post bugs when I’ve lost my rhythm).
Put simply, STWC showed me how bad I am at multi-tasking.
Here’s a list of what I was doing while I tested, I continuously switched from one task to the other for 3 hours:
- Check Twitter to see if others are asking good questions there, that I would like the answer to
- Listen to Youtube as the Judges and Product Owner answer questions and talk about the SUT
- Add Bullet Point Ideas to the Test Report so we had everything in one place
- Test the system
- Raise Bugs
- Bounces ideas and questions with my team (both verbally and through Instant Message)
- Try and go on the Prod version of SocialText
- Go on Yammer and Twitter to compare SocialText to them
Looking back I wish I was a bit more focussed in doing my tasks, I found it difficult to constantly switch tasks. As a result, I lost time switching because I had to accustom myself to the new task before getting into it (this happened almost every time, but I have no idea how to quantify how much time was lost as a result of this). I don’t regret what I did – but I would’ve definitely refined the how part.
This was a great opportunity to put BBST into practice
Relish an opportunity to apply what you learned.
I completed the BBST Foundations course about 3 weeks ago (which I just found out today that I passed).
About 20 minutes in, I realised hang on, I can apply some consistency principles to this! I chose these consistency heuristics because they were the easiest to apply and ‘made sense’ at the time given our resources and limited time. With a quick process of elimination in my head, I realised that the following two consistency heuristics would serve me best as I tested this release of SocialText
- Consistency with User Expectations
- Consistency with Comparable Products (I referred to Twitter and Yammer. Twitter because the Judges and Product Owner said so. Yammer because SocialText reminded me a lot of Yammer and I confirmed with the Judges that it would be an acceptable Oracle.)
Also, I remember hearing one of the judges say something along the lines of “Is this release ready to be deployed?” Based on that, we decided to use the Information Objective Block Premature Product Release.
According to BBST, Testing can have many objectives – you have to decide which objective you are testing against and how your strategy/approach helps you achieve that objective.
For what it’s worth, knowing you have three hours to test something doesn’t do your memory a whole lot of good and there’s a lot more I could’ve applied from this course that would’ve benefited our team. But it was great to have these lightning bulb moments.
A Team is meant to be Diverse
A team with various skills, ways of thinking and backgrounds are likely to find different sorts of bugs.
Sure, our team wasn’t the most diverse. After all, it consisted of three people from the same company who are roughly the same age. But I did find it interesting to hear about the sorts of bugs we raised as a result of our discussions when we were bouncing potential bugs off each other.
- Jad was much more security focused.
- Alice was into the details.
- I focused on usability and how it compares to similar systems.
Short and Sweet
It’s amazing how much information you can fit in two pages.
Our Test Report was two and pages long. It was my first (and hopefully not my last) time writing a Test Report. So I simply asked myself:
If I was the Product Owner, what would I want to know?
If something could’ve been said in 5 words instead of 10 – it was.
You see, I could’ve technically referred to Test Reports I’ve seen before, but for this situation – I don’t think they would’ve been much help.
Here’s a bullet point summary of the FAQs:
- It’s Free
- Teams of 1-4
- Your team don’t all have to live in the same city, country or even continent
- There are Prelim Rounds for each co
ntinent - HP Agile Manager is the Bug Tracking Tool
- You can hear/read questions other teams ask the judges
- Registrations are limited to 250 per continent
If you get through the Prelim Round, you get to go to Germany and attend Agile Testing Days in Berlin. You also get to compete against the winning teams from the other continents.
Interested? Register here
(Note that Oceania and North America have completed their Prelim Rounds, registrations for Asia are full and registrations for Europe would go on a Waiting List)
Recent Comments