RoWST - Romanian Workshop on Software Testing

Why RoWST?

Last year, together with Catalin Anastasoaie, we started a series of one-day events under the umbrella of Tabara de Testare ("TdT") with the purpose of building a testing community in Romania. It was a very interesting experience that helped us meet clever and skillful people from Bucuresti, Iasi, Cluj and Timisoara willing to share their experiences and learn from the community.

While talking to James Bach about his upcoming visit to Romania for his public Rapid Software Testing Training Course, he offered to help us organize a two-day Peer Conference with the purpose of promoting this type of events in Romania.

James presented some of the ways a Peer Conference can help testers do a better job in an interview for uTest:

"[...] rhetorical skill. This includes verbal self-defense as well as story-telling skill. This is a skill that requires practice, and apparently testers aren’t getting it, because many of them look like frightened bunnies to me when I challenge them to give a professional test report. Rhetorical skill improves when you practice giving presentations to your colleagues. This is why I try to start peer conferences wherever I go [...]".

What is RoWST?

RoWST stands for "Romanian Workshop on Software Testing", and it is a two-day Peer Conference organized by Altom and Tabara de Testare. 

The first edition of this workshop will be held in Bucharest, on March 29-30, at Hotel Parliament and will have two noteworthy guests: James Bach and Maaret Pyhäjärvi.

For those who've been following TdT, there are a few differences between RoWST and the events we organized at the end of last year:

• duration: being a two-day event will allow us to get to know each other better and have richer discussions.
• fees: there is no participation fee, but every participant will have to pay for his/her own lunch. Altom will take care of the meeting room, equipment, coffee/tea and water.
• number of participants: we'll have only 15 participants, James and Maaret included, to ensure a high level of interaction and knowledge exchange.
• presentations: we'll be selecting presentations more carefully, so that each one is an experience report.
• participation: a number of invitations have been sent based on your level of involvement within the testing community. If you have not received an invitation and you want to attend the event, please contact me at alex [dot] rotaru [at] altom [dot] ro.

RoWST Theme - "Everyday Software Testing Challenges"

What are the things that bother you most in your day-to-day work environment? We want to hear from you experience reports of everyday problems you’ve stumbled upon, the way you dealt with them, and the solutions you have come up with. 

In case you haven’t found a solution to the issue, even better, because we love a good challenge! You can present the details of the situation and the steps you’ve taken and we’ll try to identify solutions together/discuss it further.

What we’re looking for: challenges and the ways you chose to deal with them, and not just complaints.

What we’re NOT looking for: 

• theoretical ideas you’ve read about but have never applied or experienced, 
• generic stories with no practical bearing, 
• stories for which the context is not available.

Examples of presentation topics (to guide you in identifying and naming your challenges): 

• Documenting your testing efficiently 
• How to deal with the false belief that the solution to every problem is a tool (magic tool to solve any problem)
• Fighting against unreasonable requests/expectations from managers/clients (100% automation, complete coverage)
• The shift from the traditional mode to more effective and relevant approaches. 

As a result of the workshop, we will have a summary report of key learning points and conclusions to share with the testing community through http://tabaradetestare.ro.

Exploratory testing - a rookie's thoughts (part 3)

Q: What other testing activities have you done besides pair testing?

A: Well, we also did something I named parallel testing, which involves less teamwork but can be just as engaging as pair testing. I’ll try to explain what this means using a similar analogy I used for pair testing. I compared pair testing to a car ride, where one tester is the driver, while the other is a passenger in the same car. Parallel testing is similar, with both testers being drivers (both with their own keyboard/computer), in slightly different cars (this can vary between using different browsers/OSs/computer configurations), driving parallel to each other (testing the same piece of software/section of application), with a communication link between them (both testers are within earshot of each other - in same office or room).

One aspect of this method is that each person tests the same section or even features that overlap with one other. This makes it possible to test things in more detail, knowing that there is another person that is doing tests on the same piece of software.

Instant feedback is another aspect to consider. A different tester is basically testing the same part of an application you are, so when you would normally ask someone to help test something the entire introduction to what you are doing can be skipped. Of course there are some cases where you just end up diverting their attention to something less significant you want them to try out and they might miss something important...

Googling parallel testing turned up finds pointing to a different procedure than what I was referring to, (testing an old version of software in parallel with a new version, checking for inconsistencies between the two), so the name might not be the most appropriate, but it will have to work until someone suggests a better one. :)

A mindmap of my Eurostar 2011 experience

Having just returned from my first Eurostar conference, I've made a mindmap of all the sessions and tutorials that I attended and tried to include all the notes I had (if any) on each of them:

(opening the image in a new tab will allow zoom-in)

The mindmap is also shared online here: http://www.xmind.net/share/rucindrea/eurostar-2011/

I also want to thank all the people that I met in Manchester this year and that made this first Eurostar experience a very special one. 

-Ru

Exploratory testing - a rookie's thoughts (part 2)

Q: How about reporting issues? How did you go about logging bugs while pair testing?

A: Logging the bugs we found took longer than expected. This means, that we found something, determined that it was a bug, investigated its cause, then spent too much time logging the said bug (even if we agreed on the cause and the effect of the bug, as well as on the steps to reproduce it); I guess you could say we didn’t agree on what information to include in the report, what order was the most appropriate, and what was relevant as far as that particular bug was concerned.

I don’t have a concrete example for this, but I seem to recall logging a tricky bug that overlapped with another one and my testing partner suggested adding information from one bug in the other’s report, while it was clear - to me at least - that the piece of information they wanted to add was not relevant to the bug report at hand. I realize this is quite biased, seeing that this is only my side of the story I suppose….

Bug reporting may have been slow because when I write things down, I constantly revise it until it starts to resemble a coherent thought (this fails at times though... miserably even). Or it may have been because my level of English was different than that of my testing partner. It was probably a little bit of both. :)

Or maybe this is a personal thing, I don’t know; I tend to be a perfectionist when it comes to putting my words on digital paper and I consider committing anything to words to be mainly a solitary activity, after all it’s your ideas on digital paper. Besides, two people can have very different ways of writing the same thing down, even if the main idea is identical. So you would have a train of thought and your partner would have a different one, and oftentimes they would rather collide instead of combining into a cohesive bug report.

All in all, my conclusion is that having someone next to you can help a lot during testing, while it could be a hindrance when logging bugs.

Exploratory testing - a rookie's thoughts (part 1)

Here are some of my thoughts in the form of questions and answers, which mostly come from feedback I gave Alex and Oana on exploratory testing when I first started out as a tester, and although much has changed since, I still have a lot to learn in order to become better at my craft… Enjoy! :D

Q: So… pair testing; comparing the experience to testing alone, what are the things you did differently when testing with someone else?

A: Pair testing? Err… don’t you mean peer testing? Hm…

*thought about this for a while, then googled a bunch of stuff regarding peer/pair testing*

Okay, let me try to explain why naming it peer testing makes sense to me: if someone is your peer that means the person is of the same level as you (viewed as your equal, if you will). So if two peers sit down together to test a piece of software, there is no hierarchical difference between them, one tester does not simply oversee the other tester’s progress, both testers are interchangeable. I’m not saying pair testing implies inequality between the two participants, but it does not exclude that possibility either (one could be a developer or a business analyst - according to the Wikipedia page on Pair testing, anyway). I also did a Google search on peer testing, turns out it’s also used in the way I’ve used it, but pair testing is more widespread, so I guess for the sake of familiarity, I’ll change the name.

Regardless of how you call it, one thing is certain: there are far more questions raised by two people looking at the same piece of software than going at it alone. Instead of sitting in front of a monitor and wondering what this feature does, you engage in conversation. The testing partners enter a kind of dialogue in which the third participant is the application itself.

Another thing is you bounce ideas off each other about how a user might act in a certain situation or what might be considered a bug in what situation. There are also occasions where you just look at each other perplexed and wonder what had just happened and how you could make the application do that again.

The way I see it, the person sitting at the keyboard focuses on the task (or scenario) while their partner takes notes and can look at the overall changes happening in the application. It’s kind of like driving a car really, the driver, as in the person at the keyboard, focuses on the road ahead, and is basically in control of what the application is doing, and sure there are times when the person next to them tells them what to do or where to go, but backseat driving is never popular. :P

Meanwhile the passenger can look around freely, without any focus in particular. They can look at different things that happen throughout the application, not just what the “driver” is looking at. This is where most of my ideas for possible tests came from. When you are focusing on one thing happening (or waiting for some particular thing to happen), you can’t see all the possibilities for bugs just waiting to happen. Of course some of the ideas are a little far-fetched, and wouldn’t necessarily discover bugs in most situations.