Creatures of Testing Revealed – as Winners! :)
Ale, Adina, Levi and Mihai – our fantastic Testerus Sapiens – will be attending this year’s EuroSTAR conference in Amsterdam as winners of the TeamSTAR competition…
Blog
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…
How to use an iPhone packaging box to make an iPhone testing sled
While testing an iPhone application that is part of a bigger solution developed by teams in different locations, I came across a few issues that made me look into some of the available options for recording the application in use on a real iPhone and I decided to try to build my own testing sled using parts I already had around the office. It turned out that the original iPhone packaging had everything I needed.
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…
RoWST – Romanian Workshop on Software Testing
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.
Rapid Software Testing with James Bach in Bucharest
This one goes to all passionate testers out here: don’t make any plans for 26 -28 March 2012, as James Bach will be back in Bucharest teaching the martial art of rapid testing. So, get yourself ready for 3 days of intensive training, challenging discussions and mind-warping puzzles…
Michael Bolton open session on managing exploratory testing
Michael Bolton will be returning to Helsinki for a new round of Rapid Software Testing course, on 16 – 18 January 2012. This time, the 3-day intensive class will continue with an open session focusing on methods and techniques for managing exploratory testing…
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)…
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) |
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….