Peers of Estonian Software Testing (PEST): Peer Conference #6
Theme: “Gaining consciousness”
When: December 3 , 2016 (Saturday)
Location: Tartu, Estonia
Testers take hundreds of decisions every day, but most of them go unnoticed by themselves. Shadowed by intuition, clouded by experience, we think we know what we are doing and why. But a big part of learning is done through analyzing and understanding one’s actions, not to mention the possible mistakes that can have a huge impact on the work we are doing.
This PEST looks into how to be conscious about the work you are doing. Do you really use the testing methods you think you use? Do you actually ‘stop and analyze’ in time of crisis? What are the mnemonics or other “tools” you use to remind yourself to cover all of the aspects of the problem, and how do you use them? What has happened when you don’t use them?
We are looking for stories around these topics.
Send your abstracts to email@example.com by September 30, 2016.
Your friendly organizers,
Kristjan Uba, @kristjanuba
Helena Jeret-Mäe, @HelenaJ_M
In my “Let’s Learn: Experience learning through gaming” tutorial I distinguished between learning a skill and learning about a system/object:
Learning a skill – Ability to use the skill on different targets well
Learning a product – Ability to use different skills on target product efficiently
This differentiation might be better as they definitely have some overlap, but it seems to be clear enough for focusing on one of them for the remainder of this post. Learning a skill, especially physical activity, has different focus points and is more difficult, I think. At the end of the tutorial I summarized the learning steps (or phases) as following:
Last weekend Estonian Context-Driven Testers gathered for the 5th Peer Conference. The event was not pure LAWST style, as we started with workshops which were inputs for the presentations that were then discussed during open season.
The theme was about testing skills – what are used in different testing situations, which problems do they solve and are they “social” or “technical”
The three workshops were, details in the links:
- Hands-on testing
- Bug triage
- Release planning
Every team had 1 observer in the team to give feedback after they had ‘done’ the assignment, and then all of them were putting together a list of skills they used to solve the problems.
This is one of the assignments used in PEST5. If you plan to use it, you probably need to buy a BeoPlay A2 product first.
Tester – Testers who have not seen the product before.
There is a new software version in internal testing, Project manger asks the testers to look into 2 major concerns:
- Issue reported from the market that “Sometimes no sound when switching between Bluetooth and Line-In, turning product on-off sometimes. No good reports have come in, this is general ‘feedback’. Otherwise good product.
- We updated the power On-Off button handling a bit, due to known issue, that sometimes it does not react to quick key-presses.
Please investigate these so we would know what to do in next iteration. We don’t need a full blown investigation and details, but enough to understand what is going on from your point of view. You are on your own as developers are out of reach – offsite company, in Bangladesh, in different time-zone, etc.Make a small report for the Project manager on what you make of these issues, and why.
: BeoPlay A2
Although the product is real the 2 issues mentioned in the assignment are entirely fictional, any correlations with real life are coincidental.
This is one of the assignments used in PEST5, the post contains all the info for the all the roles. If you plan to use it, make sure you don’t spoil yourself.
Product Owner – Business and Market Quality representative
Project Manager – Development side manager, knows the team and development problems
Test Lead – Testing side, knows the team and testing problems
Analyze your info, talk to instructor regarding details. Think through what you want to achieve and how.
Your assignment is to get these bugs classified ( Critical, High, medium, Low) and agreed if they will be (planned to) solved in this Release. Critical means it must be solved *now* with a hotfix. High means, it must be fixed for current release. Medium means, it must be fixed in next release, unless market incidents grow, then it is High. Low means, we fix it when we get to it.