Let’s take a look at a tester:
Jim is doing well in his current position, he is considered a good colleague (also by developers). No-one is saying Jim is lazy or incompetent. He browses a few blogs every so often and figures out how to slightly improve he performance at work. So why should he try new things?
I’ve found that in my work I deal with 2 types of situations:
a) Simple – something I can handle due to experience, skills, knowledge of the context, etc.
b) Complicated – something that I can’t handle easily. Due to new context or time/peer pressure or lack of skills, etc.
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.