When I first started testing I wasn’t happy. I was writing automation code and running test scripts without any sophisticated tools. This was okay, but it wasn’t interesting. I went to a Software Testing Club meeting where, out of the blue, James Bach was there and he stood up and talked a fair amount of sense at me. I went home and looked him up. The rest is a long story of interesting work, learning, engagement and community that makes me glad of my job every day. I write occasional blog posts, I chat on twitter and forums, and none of this is a chore… and best of all I started to see all sorts of benefits to my interaction with the community – and I hope that you’ll get involved too!
Testing is a thinking profession. You need to think. You need to think about thinking. You need to learn about thinking about thinking. A testing community can give you interesting blog posts and twitter posts to read, and book suggestions and video links and lecture materials. You’ll find yourself agreeing and disagreeing and in so doing you’re testing your own knowledge about testing – you’re helping to shape your opinion by testing your mental models against received wisdom.
Read more about utilizing software communities here.
What is the major difference between testing an application or a software system compared to testing a game? This is the question I asked myself when I switched jobs after ten years of working with software testing and quality assurance within mobile phones, to start working with games. I have read almost everything there is to read about software testing in general, but I have no real knowledge about game testing. So I have bought two books on game testing to get some basic understanding, and worked a few weeks to get some practical hands on experience. This post will outline what I have learned so far.
Software testing is an engineering discipline. This is also true for game testing. Yes, you can play games and find bugs without structure or expert knowledge just as you can test that a mobile phone works, but if you want to exceed you need to become a professional tester.
To read more of software and game testing click here.
Is the best way to interact with your team in person, with your teammates right next to you? It seems reasonable on the surface. Had you talked with me a year and a half ago, I might have agreed. Now? While I do feel in-person, immediate communication is valuable, I have switched my thinking completely about the idea that proximity automatically equals more effective.
Our company makes a product that is also called Socialtext. It’s a collaboration platform built around a wiki engine where users can edit documents, communicate with each other, and perform many business functions together.
My company is a lot of things, but the most important attribute from the very beginning has been distributed. Socialtext formed around the idea that there was no central office. Our engineers are all over the map. We meet up each year for true face-to-face interaction, but the key to Socialtext’s efforts has been the idea that we can be anywhere, and we expect anyone who works here to be effective anywhere.
That’s great, but what does this have to do with better testing? To read more of the blog post click here.
As a tester I realize that I’m not going to find every bug. But even so, when a problem does slip by to find a home in production I often ask myself, how did I miss it? What could I have done better? What can I do in the future to prevent this from happening again?
These are all good questions, but there needs to be some level of pragmatism and we need to realize that bugs will often sneak past us undetected. There are ways to help us reduce the number of these undiscovered bugs, but there are no ways I know of that will guarantee a completely bug free product.
When I first started testing I was very sensitive to others finding bugs in areas of a product that I had already tested and I often heard the dreaded phrase echo around the office – “Who tested this? Why didn’t you find this bug?” Back then I wasn’t experienced enough to be able to argue in a reasoned manner as to why not all bugs could or would be found in any product over any given time period.
In some ways though, these experiences have helped me to become more thorough in my testing approach. To read more on detecting bugs early on click here.