Back to an old new team

Last October, I rejoined a former team but this time as a test lead. Previously, I was a tester in this team but I got pulled out in Nov 2010 to lead another test team. That other project had come to an end, and the options that my manager had for me was to either go back or join QS (another division). I ended up going back. It was like joining a new team altogether though. Only 1 of the original set of testers I knew remained.

One of the first things I did was try to collect my bearings. I wanted to know where is what, how do I find this, and so on. It was a bit all over the place. My OC-ness kicked in and I ended up centralizing the available testing-related materials and tools, and deploying the structure to the team. I didn’t want any new guys feeling lost as I was, and I don’t think you should need to ask more than 1 person for stuff that should be readily accessible to you.

Next up, I worked on the training materials. Again, I remember having received a lot of references (some obsolete) and not knowing where to start. So I made a visual outline. In the course of doing so, I also identified needed training topics with no available references. I prepped a couple or so slides for some of the topics, and also revisited the older ones. Still a long way to go, but at least the ball is rolling. My teammate, Tin, has taken over the training area so that’s one thing off my back.

In one of our earlier test team meetings, Tin facilitated a rant session to identify potential areas for improvement. The thing with rant sessions though is they’ll only work if someone drives the initiatives for improvements, otherwise you’ll end up with just a list of rants. There were nice ideas, but there weren’t any plans on working on them. Those things won’t just happen. I asked for a copy and posted them in a tab in my excel task list. That was another thing the test team didn’t have prior, btw, a task list or a less forgettable way of tracking the stuff they were doing for the test team. So far, I’ve picked off some of the low-hanging fruits marking them off to indicate whether something was or is being done for them.

(I’m nearing the edge of the page, need to wrap up.) Feeling lost or frustrated has been the starting point for all these. There are some things that shouldn’t have to be as difficult as they are. There’ll always be something to complain about. But you either let it defeat you (in which case you’ll just keep complaining about it) or you actually do something about it. It doesn’t have to be so radical so as to change things overnight– baby steps are fine — as long as you’re heading towards something.

Be not afraid of going slowly; be only afraid of standing still.

[Notes, Feb 2012]

A mashup of 2 writings on meetings

Last year, in my more personal blog, I ranted about meetings. Currently, I’m down to 3 regular meetings per week. For the testers’ meetings, I think they previously had the meeting manager role rotate across the members. But I opted to just preside over the meetings for now and so far we’ve been starting on time, I prepare beforehand for whatever needs to be announced or discussed so I reckon the meeting goes smoothly, and we end earlier if not on time.

So I mentioned I had ranted about meetings, here are just some excerpts from the rants…

[Jul] …What turns me off about meetings anyway. Here’s the stuff I loathe about meetings… all center on it not being done right:

1. Meetings that don’t start on time. Time is eaten up waiting for everyone to arrive. And just as you’re about to start someone excuses themselves so that’s yet another delay.
2. Meetings with no agenda. No point, no objective, no direction.
3. Meetings without someone presiding well over it. When the discussion has gone off track, it simply continues to go downhill.
4. Meetings wherein attendees are ill-prepared.
5. Meetings wherein attendees are there but aren’t really present.
6. Meetings with no minutes. Yes, commit everything to memory.
7. Meetings wherein the same things are being said over and over again. This happens when folks aren’t really paying attention, or when someone comes in late and asks the same thing.
8. Meetings that drag on for hours.
9. Meetings that were set on a short notice without the slightest hint of apology for being called at a short notice. Yes, my life revolves around you — I have no other plans that would have to be moved around.

[Nov] …In instances like these, I feel penalized for actually being on time and for even bothering to book the conference room ahead of time. Which is weird because those should be as expected. So no more Ms. Nice Punctual guy. I’m setting some meeting policies.

1. Be there on time! +/- 5 minutes. Especially if you’re the one who called the meeting.
2. Notify! Notify in advance if the meeting is canceled. Notify if there are changes to the meeting. Period.
3. One third to two thirds in and the meeting hasn’t started buys me the right to consider the meeting canceled.
4. If the meeting location was initially set as TBD, let folks know where the venue is even before the meeting starts.
5. If you’ve hijacked my room reservation, I can politely kick you out of the meeting room.

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]