As a manager of testers I got a question, what is the difference between seniority levels. So I tried to make my expectations for different roles explicit. Well, at least as much as I can.
PEST5 in now planned for 28-29th of March, 2015.
C4P extended until end of January.
PEST 5 is a Peer Conference styled workshop with the purpose of trying to sort out different testing skills and their importance for testing roles.
You don’t need to prepare a presentation beforehand, you’ll create it during the first part of the workshop with a team. And then you will present it as usual – not standing down until all the questions have been answered.
Call For Papers
To take part in the best event for Context-Driven testers in Estonia write a short essay on the topic “Testing craft – social or technical?”. We expect sound reasoning, multiple viewpoints, good grammar and clear conclusion. Keep in mind the theme of PEST5. Around 250 words is enough, don’t get carried away. (Or use 20 words and admit that you are lazy).
We’ll expect your essays until end of January at info(at)testerstower.com.
Date 27-29 March 2015
Place: Tallinn, Pärnu mnt. 139, “Bang & Olufsen”
27 March – 19.00 Social event,”Maurus” (or some other pub)
28 March- 9.30 – 17.00 ,12.30-13.30 Lunch
29 March- 10.00-15.00 – open for discussion, maybe we’ll do it in one day.
For brief overview what was it all about read:
I threw my creativity at the first task:
* Feature/area vs bugs/severity (how to show you have major and minor bugs in different areas of the product/system under test)
A Peer Conference styled workshop with the purpose of trying to solve the problems in visualizing testing.
You don’t need to prepare a presentation beforehand, you’ll create it during the first part of the workshop with a team mate. And then you will present it as usual – not standing down until all the questions have been answered.
The problem areas/topics will be presented by Kristjan Uba, along with some of the context. He will also present how he visualizes testing at B&O.
Hopefully we have ideas for visualization that everyone can adapt for their specific needs knowing the pluses and minuses of them.
Date: 26th of April, 10.00 – 18.00
Place: Tartu, will be announced.
Price: Hopefully none, depends on place and food solution.
I know it’s a bit late.
It is very difficult to give good summary from a 2 day discussion full of details and questions. Most topics were very specific to each area but that was exactly what I was looking for when coming up with the topic. The discussions and suggestions seemed to be helpful and it was nice to see many of the “oh, I had not thought of that” moments. And even better was that fact that people had already thought through their problem and it was difficult to suggest anything which had not already been tried.
That said, the problems surrounding the technical issues were still quite similar for most presenters. All of which could have helped in sorting out the testing issues as well. The conclusion, I think, is that no matter where you are working or what kind of technical problem you have – most problems can still be helped a lot by talking and listening to other people. Being respectful and doing your homework. And being able to show (or visualize) your work.
Take a look at this video, the part I’m referring to is from 2:08 to 6:46
There are other problems with the game as well, but this “workaround” is wonderful example of using bugs for solving other bugs. And the showcase of imagination of users.
We as testers need to be able to find these kinds of situations, to have the imagination and creativity. To find the true implications of different “small issues”, if used in a specific way.
More PEST3 notes, this time about debriefing in session-based test management.
For working with novice testers, it is a way of coaching. Few ideas what to do:
- Check if report is formatted and written in usable / readable way and there is balance between what is said during debriefing & what is written
- Question every sentence
- why is it written down
- why is this relevant
- Look for what is not written as people omit “common sense” things
- Find out what was actually tested
- how tested, what data used, etc
- what way the tester thought about the testing
- Give out own ideas about the test area
- special domain knowledge
- test ideas how to think about
With experienced testers, it more of a information sharing/peer review:
- About the product/feature/etc
- About the (possible) problems, tiny details, etc
- “Remarks section” analysis and questioning is very useful
- How other people test, their insight and ideas are fascinating
Pro tip on how much to write in session report:
Write as much you need that after 2 weeks (or months) you could clearly remember (by reading your own report) what was tested & why it was tester.