Google Alerts - Monitoring Your Online Reputation

Google alerts delivers periodic search results to my e-mail box. I've been impressed at how it helps me detect new bloggers that might be worth reading, and helps me manage my own reputation.

I have several topical search terms that I use to watch for interesting new authors and sites. I currently have alerts set for "Association for Software Testing", "exploratory testing" and Debian Linux testing. I'll eventually add search terms for SharePoint 2010 and evidence based management.

I also have search terms which search for specific authors I've found interesting in the past. The search results on those authors have lead to other interesting writing on topics I follow.

I even search for my own name. I realize that is more than just a little vain, but it provides one way to monitor how others might perceive me. I use an exclusion term or two to avoid the writing of the journalist who shares my name and writes at a newspaper in Nevada. Someday I may add an exclusion term for the person who shares my name in Georgia.

Simplifying is Hard Work

One of our QA managers asked a very simple question yesterday that took me through a series of twists and turns trying to find a reasonable answer. It reminded me that seeking and finding solutions to problems is hard work, and finding a workable solution can be exhilarating.

The question was "How can a tester know if a specific fix is included in this build?"

The question hides contextual information like "source code is stored in git", "bug reports are stored in a customized Siebel database", "Siebel interface or API changes are not feasible", "testers are typically a long distance (geographically) from developers", "builds are accessible from a web page of hyperlinks" and "the recent builds page also has links to gitweb".

Challenges hidden in the question:

• No API connection between git and Siebel means we need to rely on people as the carriers of information, the "information transport"
  
• Time and space separation between developers and testers complicates communication, yet complicated forms or processes are more likely to be bypassed than simple ones
  
• Complicated user interfaces are more expensive to develop than simple ones, and complicated user interfaces tend to get less interest from users
  
• Persuading people to enter accurate data into forms, fields, or even free form text is difficult. It can be made much easier if they see immediate benefit from that entry, if the format is simple, and if the results of that data entry help them
  

My proposal to my colleagues (after an embarrassing amount of thought) was:

• When a developer fixes a bug, they paste the SHA1 hash of the fix into the bug report. The SHA1 hash is a unique identifier of that commit in git, so recording it in the bug report provides a "link" between the bug reporting system and git
  
• When a build runs, it records the short form of the "git log" for that build (the list of checkins which were in that build) with the identifiers (SHA1 hashes) of each checkin and the first line of the checkin comment
  
• When a tester verifies a bug, they first verify that the log file which came with the build contains the SHA1 hash from the bug report. If it does, then they perform the verification. If it doesn't, they don't waste time performing that verification
  

During the thought process before arriving at that idea, I wandered several different blind alleys, thinking of one complicated solution or another. For example, the early wrong or overly complicated ideas and questions included:

• Why do they need this data, don't the testers "trust" developers? The question is not about trust, it is about communicating intent, and preventing the wasted time associated with testing a specific fix, reporting it is not fixed, then being told "Oh, it wasn't in that build"
  
• How can we ask git to tell us which changes are in a build when there is no API connection between the build and the source repository? I envisioned complicated sequences trying to map a build date or time or version number or branch back to the git repository to generate the list of changes
  
• How do we connect the build (performed at some independent time) with the bug report (submitted at a different time on a different system) and the source master (yet another time and system)? Programs, links, pages, all came to mind as ways to make that connection, before I realized that the unique identifier of the commit is one of the few data items which might travel reliably between all those systems
  

Then again, looking at the idea now in the "cold light of a new day", maybe I was just too tired to think clearly.