One of the bugs I was verifying included a very helpful dev comment in the bug report. The dev wrote:

“I came across this one and thought I'd just knock it out. No big deal, easy to do, easier to test.”

If you saw this dev comment in a bug report, what would you do? I’ll tell you what I did… sat down at my desk, rubbed my hands together like a fly, then attacked that fix like the world was watching. After a few tests I found the oversight I was expecting.

“thought I’d just knock it out”
“no big deal”
“easy to do”

….maybe that’s just a developer’s way of saying “Be careful, I did no testing whatsoever on this”.

I think all the project teams in my department are finally using Task Boards. We’re split between an Atlanta office and New York office so we still keep our electronic version as the master. We use Microsoft Team Foundation Server (TFS) to track all work items (Features, Tasks, Bugs, and Tests). We use Telerik Work Item Manager 2010 to print our work items into cute little cards with descriptions to move around on the task boards.

Each team came up with their own task board location and layout (e.g., column labels). Some teams use bug or test case task board items while others stick with just Features/User Stories. The variety of approaches is necessary because some teams work on smaller-scale low-risk projects while other teams work on highly complex SOX compliant applications that require more rigor.

Here are a couple good ones.

...making your velocity public is classy.

This one is way too confusing. I think that white board would be much better used as a space to diagram ideas. I just see chunks of stuff. I have no idea what is being worked on.

This one is just ugly. This was a technical debt iteration but after the initial card print-outs, everybody got lazy and just drew work item numbers with a marker. The testers wasted about 30 minutes per day trying to determine what each number represented so they could move them to the correct column as testing completed.

In Summary:

Some Disadvantages:
  • We often get TFS and its respective task board out of sync. This means the task board can mislead.
  • Adding/Moving work items on the task board is extra administrative work. Sometimes we get lazy and just write work item #’s on the white board. We quickly forget what these represent. That is one advantage to cork boards (you can’t write on cork boards).

Some Advantages:

  • Management types don’t have to ask as many questions, they can look at the task boards instead.
  • When stakeholders ask for extra stuff, we can point to the task board and say “no problem, just tell us what we should remove from the iteration”.- the team gets an extra simple view of how the work is proceding.
  • Instead of staring at each other’s ugly mugs, we can look at the task board during scrum meetings.
  • It is easier to get excited about team accomplishments when your work is public.

The most challenging presentation I saw at Stareast was by Google Senior Test Engineer, Goranka Bjedov. She makes the case that the world is heading toward developing software without testing for quality and that this practice may not be a bad thing. Scary but true!
First, Goranka pigeon-holed testing into two categories; productivity and quality. Her definitions (per my notes) are as follows:
Productivity Testing – Making sure programmers don’t break code (e.g., unit tests). Testing things consumed by machines. Anything consumed by machines is easy to automate. These tests are cheap, fast, well-defined. The problems failed tests expose do not require deep analysis.
Quality Testing – Testing things consumed by humans. Anything consumed by humans is not easy to automate and therefore difficult to test. Expensive. Tests become more flaky as the system becomes more complex. The right tests are not clear. Failed tests require deep analysis. These tests take longer.
With the promise of quicker software delivery, productivity testing has become more important than quality testing. Wake up, the world is already adapting in several ways.
For example, at Google, they know hardware and infrastructure will always fail. Instead of wasting time with exhaustive tests, their solution is to manage risk (e.g., build in seamless failovers and backups) and shield the user from the failures.
Goranka also countered that in cases where poor quality is seemingly not optional (e.g., medical software) users have already adapted by not relying on it. She claims users in hospitals, for example, know not to trust someone’s life in a piece of software. Instead, they monitor the patient as a human and understand that software is fallible.
These are excellent points, IMO, and I would have been satisfied contemplating a future where my job no longer existed...but hold on!
Goranka asked us to do a little exercise. She asked us to determine the rule used to generate these three sequences by writing five additional sequences of our own:
-25, -5, 15, 35, …
2, 4, 6, 8, …
0, 3, 6, 9, …
I don't want to give away her rule, but you can still try it on your own.
After surveying the audience, she pointed out that developers tend to write confirmatory tests more than testers, who tend to write more negative tests. Thus, perhaps testers do play an important role. She also questioned how much productivity tests actually tell us about the system as a whole. Her answer? …they tell us nothing.
In the end, she left us with this thought…
If you think (non-programmer) testers are important, you better start doing something about it.

Copyright 2006| Blogger Templates by GeckoandFly modified and converted to Blogger Beta by Blogcrowds.
No part of the content or the blog may be reproduced without prior written permission.