Two developers working at a rate of N hrs/day…

A friend told me an odd story. Two developers from another team were allocated at a total of 40% into a particular project. They were given a task which they’ve estimated they could complete by January.

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?

Wanting change is not enough

Occasionally, we come across folks who say they want change or who are ranting about how things are currently done. (Chances are, at one point or another, we’re one of those folks.) But then after some time, we get in touch with them and find out that nothing had changed even though it’s perfectly within their power (or their limits) to trigger the change. In asking why, we sometimes get to the sad conclusion that nothing changed because nothing was changed. They just shrugged things off, maybe, or hoped that things would somehow just get better. At best, if they had even bothered to note down, what they end up with is a growing list of problems where nothing gets crossed off.

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.

Scott Berkun’s Mindfire

Scott Berkun released a new book recently entitled Mindfire: Big Ideas for Curious Minds. It’s a collection of essays some of which were from his blog. He made it available for download for free for 48 hours; with the only catch being you’ll have to sign up to his monthly mailing list. Upon finding out about it, I went ahead and downloaded a copy. There’s still 15 hours and some more minutes to go and download.

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.

On performance evaluations

Some of the testers in our team who were sourced by our company’s “QA division” recently asked me for feedback. They provided me with the template which I assume their managers had them use. It has five items for which we’d have to rate our level of satisfaction with them on a scale ranging from “Excellent” down to “Very dissatisfied”. And there’s the fail-safe/catch-all “NA” for not applicable or don’t know.

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.

RIMGEA – 6 approaches to bug reporting

I’ve learned a very useful mnemonic from the bug advocacy class on some approaches to bug reporting. Here’s something I had written on the topic with some edits (I just linked to previous write-ups on the same or related topics).

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]

Career tips from Alan Page

There was this free webinar by Alan Page (author of How We Test Software at Microsoft and one of the chapters from Beautiful Testing) on random career tips for testers. I was keen on seeing it but it was scheduled at a different timezone. A good thing though is that he recorded and posted it on his blog. So I was able to watch it this afternoon and get some notes out of it. Here’s the link to his blog to hear or view it first hand: http://angryweasel.com/blog/?p=297.

Email != defect tracker

I suppose one could expect that having a buglist or a defect tracking system should already be pretty standard in a software project. But it’s funny how it’s the basics that gets forgotten or foregone sometimes.

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.

Perfect software, reread

While nursing my sick housemate, I took the time to read Jerry Weinberg’s Perfect Software and other illusions of software testing. It was a quick and easy read with the book being only under 200 pages, and with the content hardly wound up on technical jargon. I think the author had intended the material to be suitable for reading even for those who aren’t in the IT field altogether.

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]

Browsing through 2010

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.

 

Learning shouldn’t be a chore

Over the weekend, I met up with my friend Barry (not his real name) the baker (not his real profession). He used to tell me about how he’s not getting any new training at work. I asked him how things were with him, and he was quick to jump onto the topic of training.

“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).