The PM Prodded and pushed. “Finish it by December,” he demanded. Eventually, after tireless nagging, the two conceded and said they will deliver by December as requested.

“How will they do that,” I wondered. Apparently, nothing changed — only the deadline. The amount of work to be done is still the same. Their measly 0.25 and 0.15 allocations were retained as is. What was the January estimate then? Had they padded their initial estimates such that it would actually be feasible to complete the task by December? Or will they have to render overtime work to cope and meet the deadline?

Instances like these make me wonder whether the PM ever did math problems while he was back in school. Joe works at a rate of N hours per day. A given task takes X hours. How many days will it take for Joe to finish his work?  Judith needs to complete a task that requires X hours in N days? How many hours per day will Judith have to work? How many Judiths are needed if each Judith can only work Z hours per day?

That list of wants or rants won’t magically get resolved. Stating the problem is not enough to get it solved just as stating the goal is not enough to get it done. It’s a start. But there’s got to be a change in mindset from simply just saying “I want X!” to coming up with something like “I want X so here’s what we can do…” I think Antoine de Saint-Exupery said it best: A goal without a plan is just a wish. Of course, planning won’t suffice — there are still the harder parts of following through with the plan (personally, I go by plan-do-check-act). But unless someone drives the change, you’re pretty much stuck to just waiting for nothing to happen.

For starters, I like the title of the book.  Mindfire.  I can so tie it up to one of my favorite quotes (yes, just because it has the words mind and fire in it): “The mind is not a vessel to be filled but a fire to be kindled.” – Plutarch. I read the first essay this morning. It was something I’ve already read from his blog but didn’t mind rereading because it was one of the posts I liked from his blog. Cult of Busy. I remember how I set my chat status to “Busy” by default. Initially, I didn’t get what that status was for. Wasn’t everyone supposed to be working on what they’re supposed to be working on ergo busy should be the default? Are those who are on “Available for chat” idle? As I went along, available or busy didn’t make any difference. If folks had something to ask, they just went right ahead. Anyway, I’ve digressed.

Back to the essay… I like how the it echoes (much nicely) my disdain for being busy as an ideal state. Say, dudes A and B were working on the same stuff. A slacks off, works carelessly, and then does overtime for rework and to compensate. B works efficiently finishing the task ahead of time, giving him time to go over some tech blogs that he follows. From some perspective, A would probably appear busy while B is slacking off; and A might even get rewarded, while B goes unrewarded and gets more tasks dumped onto him. Sucks.

Taxi has arrived. Got to cut this short. But do check out Scott Berkun’s writing. This post does not do him justice.

I’m not really so much of a fan of performance evaluations (perf evals — hey, coincidentally this does sound like perf evils). I reckon feedback should just be given whenever and only as needed. In the past I’ve had experiences wherein the mandatory quarterly evil forms were filled in way too late. This produces a couple of problems: (1) it’s way more difficult to recall the individual’s contribution and areas for improvement, and (2) the feedback is no longer as relevant as it could have been. Oh, and there’s also the overhead of gathering and deriving data to quantitatively objectify the ratings. Ultimately, these are subjective anyway.

On the other hand, I also acknowledge that giving feedback doesn’t come so easily particularly when it’s negative. We have a tendency to hold back out of fear of offending, fear of conflict, fear of retaliation, or out of altruism, or we can just be that forgiving (“it’s probably a one time thing”, “I’ll give her another chance”). And so, for some, these mandatory evils provide an excuse to unleash.

But the bottom line is feedback is feedback and its value diminishes with delay. To remedy this, here are some stuff to try:
(a) Explicitly welcome feedback. Say how you’d like to receive it or what’s the best way to give it to you.
(b) Condition yourself to offer positive feedback when there’s an opportunity to do so. And just as you must give that positive feedback, you must give that negative feedback when the need also arises. In both cases, say it nicely!
(c) Remind yourself to do (a) and (b) as these gets forgotten especially during crunch time.
(d) Foster or support an environment wherein giving feedback is the norm, and where people feel safe in giving and receiving feedback. Encourage others to try (a) and (b).
(e) Others? Please feel free to suggest via comment.

The 6 factors or approaches to bug reporting are:

1. Replicate it – Try to see if you can replicate the bug.
If you can’t replicate it, it might be more difficult to provide information to the developer and persuade her to provide a fix for a problem she can’t see.

[Link:  How helpful are my bug reports]

2. Isolate it – Try to limit the steps or the conditions that trigger the bug.
Here you try to narrow down your repro steps or to find what exactly are the critical conditions. Here you want to get to the bug in the easiest way possible.

[Link: Bug isolation]

3. Maximize it – Try to do follow-up steps to see if you can trigger a worse failure.
The bug you find might be just the tip of the iceberg, or a symptom of an even bigger bug. Follow-up tests could help to uncover the bigger problem if there is indeed one. There are various tactics that can be tried:

• vary your behavior – e.g., instead of doing A then B, try changing the sequence; or try a different way of doing the task like using a shortcut key instead of the button
• vary your program settings – e.g., there could be program settings that you can toggle on or off or adjust; for browser testing, you can try adjusting the zoom sizes or enable/disable caching
• vary your inputs – e.g., if the bug was encountered when file X was used, try a similar file Y or another file Z
• vary your configuration – e.g., try using a different OS/browser combination

4. Generalize it – Try to broaden the extent of the bug
Here we try to uncorner corner cases. We try to find other ranges in which the bug can be reproduced. For instance, we find that a bug occurs when we have 1M records. In generalizing, we try to see if the bug occurs at lower more realistic values or if the 1M records is truly a critical condition.

5. Externalize it – Try to go see the value/impact of the bug in other stakeholders’ perspective.
Here we try to go beyond our roles as testers and try to get a sense of the bigger picture. In understanding the value that could be lost, we could paint a more compelling picture of why the bug needs to be fixed in our bug reports.

6. And, say it clearly and dispassionately – Try to have our bug reports as easy to understand and as neutral as possible.
Clarity will make it easier for the dev/triage team to find out what exactly needs fixing and hopefully why it needs fixing. Neutral bug reports will make our work easier to read as opposed to reports that are angry or disrespectful in tone. It is difficult enough to have to deal with a problem in the product, antagonistic reports don’t help as they can only increase the difficulty, cause conflict and discredit the reporter for lack of professionalism.

[Link: Article: How to report bugs effectively]

It’s about 50-ish minutes long inclusive of some Q&A at the end. Here’s a five-minute read on my notes on those random tips. Some notes may be verbatim, some paraphrased. Italicized stuff is all me.

1. Learn, learn, learn
Challenge yourself to learn. Practice testing (via weekend testing, testing dojos). Just don’t let yourself stagnate.

2. Learn your A-C-B’s
Categorize the work that you do according to (1) how much of it is ABOVE i.e., stuff that challenges you; (2) how much of it is CURRENT i.e., what’s expected of you; and (3) how much of it is BELOW e.g., things that aren’t really difficult but you have to do them anyway. Percentages he suggest are 30-40% for A stuff and 5-10% for B stuff. If you’re doing far too little A work, then you may not be advancing in your career. Too much of A stuff and you might be spreading yourself too thin.

3. Find the steepest learning curve
Seek out huge challenges. These offer huge learning opportunities. For his case, he cites taking on a project that might be well over his head every 1 or 2 years. This reminds me of a Courage Wolf quote: Bite off more than you can chew, and chew it!

4. Ride the gravy train
If you have a good manager, you’re working on an exciting product and you feel well taken care of, then just enjoy it. This tip only helps those who are in that good place though, but there /was/ a disclaimer at the start of the talk that not all tips apply.

5. Who do you know
Network! There’s twitter, blogs, software testing club, test republic, etc. Try to be involved in the testing community. In knowing who’s working on what, in case you come across some problem, you’ll either know someone who knows the answer or someone who can point you to someone who does.

6. Follow the leader, Lead the follower
Influence others. Help make changes happen. Help someone be successful.

7. Find a mentor
What the mentor brings to the table is fresh perspectives, more ideas. It doesn’t have to be someone in the same work place or someone senior. What’s important is having someone to talk to about testing. Likewise, look for opportunities to be a mentor but do it without being an ass.

8. Never let yourself get blocked
When you feel blocked or stuck, find a work around or another way to do things. He also cites a story wherein as he was drafting an email over something that got him blocked, he realized one or two things that he could try to actually solve his problem. This is rubber ducking at work!

9. Try a new way
Sometimes folks follow a certain way of doing things just because it’s how it has always been done. That reasoning shouldn’t keep you from trying new things because sometimes why they did it that way to begin with is no longer relevant. This reminds me of sacred cows (i.e., “something considered (perhaps unreasonably) immune from question or criticism”).

10. Don’t flip the bozo bit
People sometimes do or say things that could easily pass off as stupid. For that single instance, some of us might be too hasty and flag them as dumb or stupid right away. He suggests, “Don’t.” Try to understand why they would say something like that or where they are coming from. My friend asked me though, “but what if it’s chronic?”

11. …And don’t burn bridges either
You never know when you’ll have to work with (or for) someone again. So play nice.

12. 3 P’s
Seek out the 3 P’s: People — folks you like working with; Person — work for someone you respect; Product — or technology that you’re passionate about. These drive happiness at work.

13. A career is a journey, not a sprint
These tips have someone who is looking at testing as a career and not just a short-term job. With a career, you’re looking for continuous growth, challenges, and ways to get better.

14. Have fun
Fun != goofing around. This is more about enjoying what you’re doing.

15. There’s nothing wrong with self-promotion
With this last slide, he promotes two of the books he has worked on and mentions one more is on the way.

Well, we did have Quality Center set up, but one of the concerns was that the devs weren’t paying attention to it and testers weren’t logging into it. It was a chicken-and-egg thing. Email got inundated with issues, follow-ups and such which kinda sucked since I always got copied into issue email. Eventually, our PM (he got cc’d too) put his foot down and we’ve made the shift back into QC with me goading the testers to use our defect tracker as intended, and with someone from the dev team monitoring the defects with respect to dev assignments. Thankfully, the team has been quite cooperative.

This has also pushed me into tinkering a bit with the reporting capabilities of QC. There are built-in reports that I found to be of use, and I’ve also created my own queries for generating my own reports on defects and test case status.

So far, it’s been working out. With the shift to QC, our email is no longer as abused or misused for defect tracking. We can now misuse it for something else (jk). One major advantage is that we can now, if needed and as needed, easily extract defect data. Instead of having to dig through old email, getting the list of open issues across the many applications that we’re handling at a time is now quite easy. Having all bugs logged into QC also allows for easier detection of red flags e.g., if several testers are reporting similar issues at the same time it’s possible that there’s already a global issue; or if devs are deferring a significant number of defects as non-issues, that could be a red flag on the quality of defect reporting, or that valid issues are getting dismissed.

The lesson learned is simple: use things as intended. Email for comms and the defect tracker for defect tracking. They’re there specifically for those purposes so use them accordingly. And, this is a team thing, so even if the testers were so disciplined in logging the defects, it won’t be as efficient if the devs aren’t using the tool as well. Work to have an alignment within your team so that the available tools can be optimized.

The book discusses and dispels some myths on software testing. These myths and not really knowing what testing can or cannot do probably contributes to the headaches that software testers often encounter. Headaches being stuff like irrational (if not impossible) expectations – test everything exhaustively and do it fast, prove the program works, do it faster, capture all the bugs, do it faster still – among many other things. Each chapter of the book has stories to tell and a common mistakes section. For those who’ve been testing or working on software development projects for a long time, a lot of those stuff could be all too familiar. While the book doesn’t directly address how to go about with these problems when you’re already knee-deep in them, it does give a fair explanation of why things tend to go that way (for some) and a list of common mistakes to be wary of.

Overall, the book is a pretty good read. I reckon a newbie tester might not appreciate it as much as another tester who’s already had a couple or so projects under his belt. Still, it helps to have things explained.

[Dec 2010]

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.

Summary of the year’s posts…

January

• Tagged along to a pinoyjug meetup (though i’m not a java dev) and one of the topics was on automated testing with selenium.
• Mentioned that the last official training I had was way back in 2007, and it wasn’t even on testing. For this I have an update, my latest training is now the BBST Foundations class I took from Jul-Aug 2010.
• Posted links to chapter excerpts of Beautiful Testing. Back then, I mentioned that the digital version of the book sold at $33.99. I managed to get a copy for only $9.99 through one of those O’Reilly deals/promos.

February

• Posted on feedback

Mar

• Posted on helpful bug reports

April

• First time to join a weekend testing session (anz chapter)
• Tried and wrote about a testing exercise involving ParcCalc
• Posted on risk analysis

May

• Posted a couple of wtanz-related topics, one of which was on tools

June

• Started decluttering my testing-related feeds
• Posted on the Jarlsberg exercise from a wtanz session
• Posted a couple of posts on responsibility, integrity, contribution, and motivation (awesome Dan Pink video)

July

• A few wtanz-related posts: using watir, modeling, and accessibility testing
• Plus a post on a case of attentional blindness

August

• Still decluttering my testing-related feeds

September

• Posted on being busy

October

• Posted on the “test automation series” we were having at wtanz
• Posted on the topic of training and Barry the baker

“Well, we now have a lot of training lined up for us,” he said in a tone that was far from enthusiastic. “Just not the ones that I was expecting,” he added sullenly.

I asked him to elaborate. He told me he was expecting more technical training. Something along the lines of baking design patterns, introduction to other baking frameworks, new technologies, or essentially training that would help them learn to bake better. What they got instead were mostly soft skills training that had nothing to do with baking altogether.

I asked him a few other questions like do they have a say about the classes they’re assigned, do they have a means to feedback on the value they get from the training, how do they gauge whether the training had been worth it, were the topics something you can just as easily find better if not more concise resources on from the net, what do your peers think about the training, etc.

From his responses, I got reminded about Dan Pink’s talk about motivation being best driven by autonomy, mastery and purpose.

• Autonomy – getting to choose for yourself the classes that you’d take, or having a say on that matter
• Mastery – getting trained on areas that you want to improve
• Purpose – getting training that’s relevant to your you, your craft, your role, your career path; getting some alignment on why you’re getting a particular training especially if it’s something you’re not interested in to begin with

While it was a good move to provide more training, I guess it wouldn’t hurt to look into these three things so that attending those classes wouldn’t be such a chore and so that they won’t be as forgettable either (as in the case of Barry’s co-baker who remembers nothing else but having good coffee on training day).