I went through my public 2010 blog posts and summarized what I had written about down in the list below. Not much for this year, not that it’s the quantity of posts that matters. But back in 2008 and 2009, I averaged about 4 entries a month. This has now dwindled to 2 entries a month.
Is this thanks to microblogging? Have I less to gripe, er write, about? Are the iTouch apps too much of a time-sink than I would like to admit? Has having to censor my work due to confidentiality clauses become a deterrent? Have I become too busy with work?
Whatever the reason is, I’ve found 2 entries a month to be somewhat manageable. So my goal for 2011 is to have the discipline to keep at it. Not just the writing, per se; it’s more of the learning. Testing blogs, social networks like twitter and the software testing club, and – more recently – the weekend testing sessions have provided me with invaluable opportunities for learning and exposure to new technologies, techniques, tools, ideas. I reckon I’ll continue tapping on to these resources in the coming year.
I’ve mentioned practice in my previous post. I had been meaning to post an addendum (current project makes use of that word a lot) but with our hectic schedule, I only got the chance to do that now. For the past few days, our team has been going on overtime and today was actually the first time I got home before 9PM! Wait, I’m digressing.
Lesson 214 is: If you really want to know what’s going on, test with your staff.
Advantages: (1) It’ll keep the saw sharp. (2) You’ll get to see what the testers in the team have to deal with — unnecessary steps in the procedures, difficult developers, problematic tools, etc. And you’ll be in a better position to offer and discuss suggestions, and evaluate solutions. (3) It’ll give you a better idea of your product’s quality, the strengths and weaknesses of your teammates, and of the team dynamics. (4) Your teammates would actually be able to talk to you about your product!
One of the testers at work uses an excerpt from Lesson 47 of Lessons Learned in Software Testing as an email signature. The lesson’s heading reads: You can’t master testing unless you reinvent it. I reread the entry in the book and the bit that struck me the most reads:
If you want to be good at this, you have to practice.
(I hear this in my head as if it’s spoken by someone with a shifu-like voice… must be because of hearing one of the character voices in Red Alert 3 in the background.) Although this may not be the main point of the lesson (or it could be), I want to reiterate the point that a prerequisite of mastery is practice. Before you can go about reinventing testing, you’d actually have to be proficient at it. Before you can “be the author of your own wisdom”, I think you need experience (lots and lots of it) from which you’ll draw that wisdom from.
I’d place a nice segue here but I can’t think of any at the moment (it’s way past my bedtime). I just want to post a couple of links here. The first link is to an article giving insights on how to practice software testing, the second link is to a blog post by a test manager who values keeping testing in practice.