Six of PEST2 highlights in no particular order. Some of the very good ideas were too big to fit into highlights and will have their own post.
Continue reading »
9 peers from 6 companies for 2 days with infinite amount of good ideas == PEST2
Not to count the beers and fun.
The experience reports and discussions evolved around test teams. Working in one, managing one or creating one. Following questions started the open season:
- How does your team fight boredom? (if you are one-man-army then how do you fight boredom)
- What makes your team tick? (if you are one-man-army then what would make a team tick)
- Who are the key members of a team?
Second Episode – “Crash course in test design” P1 and P2
Summary:
Running through a number of different test design techniques terminology. What they mean and what is the most important thing to know about them – how they might fail.
Mindmap from the show is: here.
Links from the show:
BBST test design info: http://www.testingeducation.org/BBST/testdesign/
The little black book on test design: http://www.thetesteye.com/papers/TheLittleBlackBookOnTestDesign.pdf
Add your questions to the comments, they will get answered! Or send them to live(at)testerstower.com
First episode of Testers Tower Live, “Tribute to Day[9]”
Summary:
“Introduction to Testers Tower Live (TTL), about the format and reason. Who is Day[9], and what is his role in inspiring this series. He talks brilliantly about learning computer game – Starcraft 2. And we talk how to use that in learning testing.”
This is link to the created mindmap.
Links from the show:
Day[9] Archive – http:\\day9tv.blip.tv
Eliminating assumptions – http://blip.tv/day9tv/day-9-daily-400-p1-special-episode-eliminating-assumptions-5888689
Dealing with ‘Tilting’ – http://www.teamliquid.net/forum/viewmessage.php?topic_id=184459
Starcraft II Demo – http://us.battle.net/account/sc2-demo.html
Add your questions to the comments, they will get answered! Or send them to live(at)testerstower.com
The problem of talking about testing
I tend to read a lot of books, blogs, forum posts and tweets related to software testing. One of the things that I keep seeing time and time again is the myriad of contradicting opinions people have about certain aspects of testing. The eternal “To automate or not to automate” question and more recently “test is dead” are both prime examples, but there are others too — whether testers should learn to code or not, the use and misuse of metrics, the advantages of one tool over another, the value of certifications, scripted test cases and test documentation… the list goes on, but you get the point.
So why is it that opinions differ so widely?
I have been pondering the subject for a while now, and here is what I came up with:
It’s probably because context matters. A lot.
I call it the context problem of talking about testing. The context problem has a chance to emerge whenever someone says something specific about software testing that is possibly true in his context, but might be a really bad idea somewhere else.
Continue reading »
Here we go again!
Date : 16-18 March 2012
Place: Tallinn, Pärnu mnt 139 (detailed description later)
Theme: “Taking one for the team”
The “Test is Dead” story is not news anymore. A lot of the good testers out there have since tried to reframe the idea, to put in into context. See Mark Tomlinson’s blog post on the subject or listen to this TWiST podcast (requires basic membership; it’s free) for good examples.
To refresh your memory, here’s a short recap:
After posting an ominous article about the death of testing this June, Alberto Savoia finally got to explain those cryptic lines in his opening keynote for GTAC 2011. In short, he believes that building the right product – the right “it” – is far more important that building “it” right. Or, to put it another way:
Testing slows you down… by the time our competitors had a well tested product, we had millions of users.”
So he appears to claim that it is far more important to test the concept than the actual product. He even wrote a book about it.
I have to admit, I can see a lot of potential in this approach. The success of twitter is just one example of how users can easily overlook even serious bugs in the product as long as the “it” part feels like warm apple pie.
Then again…
Continue reading »
I noticed a certain heuristic I have been using for quite a while now, without realizing it. So today I decided to explore it’s applications and, most importantly, give it a name.
I call it the Instance Heuristic.
Whenever I find a bug, I ask myself where else a similar problem might occur. I think of the bug as an instance of a mistake made because of code reuse, improper use of libraries or frameworks, object oriented programming or even object oriented thinking. Then I try to find other instances of the same mistake.
Continue reading »
The situation:
A game developer has been making continuous expansions for its game. Introducing cool new features, creating better immersion and giving players new ways of having fun in the sandbox.
With one of the latest expansions they also included a smaller update, fixing handful of small things that had been in the game for more than 3 years. And when I say small things I mean small things like:
- Showing a tool-tip in a accounting window
- Option for autominimizing a small menu window when activating a feature
- Ability to drag-select instead of shift or control select in certain cases.
- Moving information from one tab of info screen to the main part of the info screen.
You get the picture now. Very small changes in the huge game-world. And what happened?
Recent Comments