Things I saw (and sketched) at Let’s test
A report on what sessions I went to and what keynotes I saw at Let’s test 2013. I’ve also included some of the sketch notes I took during these sessions and keynotes.
Author: Levente Balint
Help us get to EuroSTAR!
We entered a video competition to win tickets to EuroSTAR 2012! We made a short documentary about the newly discovered testerus sapiens (played by us) as they go about their daily lives. They are presented in their natural habitat, the jungles of software development, where they test software either as a group or alone, living for the thrill of the bug-hunt…
My BBST experience – the musings of a student
This is an account of some of the activities I wish I had focused more on during the one-month Foundations course. The article is peppered with nostalgia for my fellow students and the activities we did together, but it ends with something awesome to look forward to: signing up for Bug Advocacy, the second part of the BBST course…
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)…
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….
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! 😀
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: …