Resolved To Test

(Cross-posted from my personal blog as it’s germaine to testing.)

Last week, in the course of commenting on James Bach’s blog, I explained that I liked to learn by laying my beliefs and understandings in front of others for them to question things I may not have questioned and, in turn, to question them to see if knowledge or views they have fill in something for me. James responded that this was called “transpection.”

It has a name? Who knew?

Transpection basically means to learn by putting yourself in place of another (to quote James’ blog post on transpection). This is different from introspection (contemplation of one’s own thoughts and feelings) and extrospection (examination of things outside oneself). It’s also different than the often-referred to “put yourself in someone else’s shoes” because you need to put yourself in someone else’s brain, really. It’s less role-playing where you imagine what that person might be thinking (which I think would be still be highly subject to your own views) and more based on really asking questions of someone else about a subject you are interested in.

Honestly, this truly fascinated me. I was not only interested in the fact there was a word for this process but the fact there was spurred me into reading and thinking about the process of transpection. As with many things that catch my interest, I mentioned it a few times and James kindly pointed me at a few other definitions of it.

Then James invited me to join him on skype to have him run me through a transpection session with him. This was a really interesting experience – not terribly comfortable in some ways and yet quite eye-opening in others. Now, mind you, this is coming from a person who has experience with James’ personality and does understand what he’s trying to do in advance. I got frustrated once or twice and felt obtuse several times but it was really fascinating to experience it and, at the end, hear what James’ response to the questions he asked me were.

I’ve read James’ list of problems with transpection on his blog and thought I’d give you my views:

• Feeling interrogated or tortured – I did feel a bit interrogated but wasn’t that part of the point? On the other hand, because I can see what the goal was, I knew repetition of a question/set of questions meant either that I had an interesting view or I really needed to look at my answers. Tortured, no – other than when I could NOT, even to myself, validate a stance I had taken. Time for that stance to go.
• Being judged – We all judge each other all the time. I expected it but, in return, I was judging my reactions and James’ approach too. It was definitely a two-way street.
• Being treated like a lab rat – Yep. But I had a psych minor and undergrads are the lab rats of the psych world. So it was familiar ground and I don’t feel demeaned by it at all. I learned and James learned and that’s the point.

What did I learn?

• I have fallen a bit into a trap of reliance on metrics and my own fixed idea of what a test/test case consist of. This is more limiting than I would have guessed, actually. This is probably rooted, at least in part, in having done test automation recently.
• My particular order of examination seems to put visual appearance lower on my list than many people would have it. I need to consciously push it further up my list to compensate. This is almost certainly rooted in the fact I have no real visual memory so it can be quite difficult for me to deal with visual appearance and it’s never my default behavior.

I saved our skype session so I can examine it a few more times to see what else I learn from it. I will note that I did experience a bit of James’ excitement when he hears something interesting. In this case it was my mentioning the fact I had no visual memory. The questions were rapid and many but I didn’t interpret it as sharp or angry – just very curious and wanting to gather information.

I will point out that this type of questioning does require that the need to “be right” or “win” be analyzed as well. I suggest that if you go into a transpection session to prove you are right, you will limit the benefits you can get from it. I also think this desire could be at the root of people feeling attacked or offended. Being right is not the point. Learning is the point and, to learn, you need to be willing to examine what you think you know and your views and reassess them in light of new information. If I went into this session with something to prove, I would not have gotten out of it what I did.

After the skype session with James, I ended up thinking more about my lack of visual memory and ended up trying a somewhat clumsy version of it on my husband, Chuck. I asked him questions about how he finds things around the house and remembers where they are. It sounds simple but it can be cause for friction. I thought it might be interesting because he, unlike myself, is highly visual.

• We both start by looking for an object in its designated “home” if it has one.
• If it is not in its home or has no home, Chuck pictures where he last saw it and looks for it there.
• If it is not in its home or has no home, I remember where I last put it and look for it there.
• If that fails, we both try nearby areas to the one we expected to find the object in.
• If that fails, we both resort to trying to figure out where the other person would have decided to put in instead and then check there.

It’s a very simple example but it pointed out something interesting to us. It answers the question of why if I cannot find something, Chuck usually can and vice versa. It also points out a symptom of my lack of visual memory. I cannot picture where I saw it. Instead I rely on where it SHOULD be or where *I* put it.

Since then I’ve done a lot of thinking about how I cope with my weird brain wiring and compensate for it, when necessary. I’ll have to write a separate post on that.

The current project I am working on involves working on the CHM (Microsoft Help Files) for Windows Embedded Standard 7. This was a project underway before I joined the team and it had even changed managers during that time, which always creates at least a bit of chaos.

We just dropped our CHM files to the product team for integration last week and then discovered we had not completely purged the contents of the project’s internal name and prior release same in favor of the final release name. This happened despite having myself and four other people all search the Help for the string. It even happened despite a tool that would automatically check for the strings you tell it to at build time.

After dealing with the aftermath and rebuild/redrop (my boss was out of town), I looked into why this had happened and discovered I had let my tester mindset go to sleep and had not really thought in depth about how the searches were being done and the potential holes in these approaches.

The stage is set by:

• The tool was checking for the term in the files at build time.
• The individual searches done ad-hoc were using the search functionality provided in the Help by Windows when reading the CHM file.

The following discoveries were made as we looked into where this failed:

• The tool does not check the index. Several instances of terms entered into the tool were found in the index.
• Not all “bad terms” were entered into the tool’s database.
• The Search functionality in Help does not search the index and no one thought to look there because the index was generated from files thought to be clean.
• The Search functionality in Help is a regex-base search. All ad hoc searches were done with the same string, but no one thought to look for substrings with use of a wildcard before, after, or both in relation to the “bad string.” This meant no instances where the “bad string” was a substring could be found, though quite a few existed.

It seems obvious now, of course, but it really does help to look at these occurrences and see what the root cause was so that it can be caught in the future. In this case, we took away the following actions for the next release:

• All terms must be entered in the tool’s database.
• The CHM must be decompiled and the HTML contents searched for the “bad terms”. This will catch substrings and index occurrences.
• Ad hoc searching must be done with wildcards and regex to also look for string and substring occurences.

Lesson learned and I paid the price. Both in terms of this instance’s particular issues and in terms of forgetting to look for holes in the process/testing – even if it’s not my job.

In April 2009, I changed roles at work from being a tester to being a contract programmer-writer. As many of you know, this is not my first experience with writing or instructional design, but it is my first experience with being an official member of a documentation team.

The product team we work with is using Scrum and when I joined the documentation team, it was advertised as also using Scrum. Only when I joined did I discover that the team was using a mutant form of Scrum + Waterfall that could perhaps best be described as Stuff Flowing Downhill at Great Velocity and With Little Organization. The only real resemblance to Scrum was the daily “huddle” – except it typically lasted a half-hour for a team of four and was more concerned with approaches than purely status.

The first several months were confusing and prone to bouts of frustration. Work was getting done but, while I couldn’t speak for the other team members, I was certainly not signing up for my own deliverables and setting my own timeframe. I was catching things as they were being tossed at me. Since my personality doesn’t allow me to just sit back and not become personally invested in a project, I offered to help move my team more toward proven Scrum practices but my offers were not accepted. Instead we muddled along and I fought back my desire to help

Mind you, I do not think this was because of any ill will or evil intent but I think the situation had roots more in the inexperience of the lead that hired me and in the fact that lead did not have training in Scrum. The lead had read a book about Scrum but I’m not sure which. I was the only team member who had done significant reading and investigation of Scrum, let alone taken a class on it.

About three to four months after I joined the team, the lead that hired me resigned and I gained a new lead. This new lead had no experience with Scrum but did have a lot more experience with leading a documentation team and shipping product documentation. He really got tossed into the morass with a team he didn’t know and a project already at risk. Our product team had no idea what we were doing and where we were and thus were (justifiably) nervous. The lead had no idea where we were either and what had or had not been done. There was no plan, there was process documentation beyond some emails and it was a mess. One lead, a team of three contractors and a huge lot of bugs and legacy documentation – it didn’t look good, I admit.

The day I got the email of the change in leadership, I stopped by his office and introduced myself, then told the new lead I had a lot of feedback on the team, the project and our processes that I’d love to share with him whenever he was ready. He just nodded, looking a bit shell-shocked, and said to give him a few days to get a handle on what was going on. It actually took a few weeks but I was able to start feeding him bits of Scrum processes and suggesting changes to help us. After a few months of introducing change, as well as taking a full time job with my team instead of my contract job, we’re now running a much more Scrum process.

We put up a corkboard in the new lead’s office and went with the visibility of notecards and columns for stages of our process – Writing, Initial Edit, Tech Review, Final Edit, Done. Each team member was responsible for moving their cards and the standup was used for real status updates and blocking issues only. No more talking about how to do something or implementations. I took over running the standups and serving as the Scrum Boss to keep the meeting on track. We stuck with one week sprints because we HAD to get and stay on track and because the documentation team needed to learn Scrum. I felt longer than a week’s sprint was too long given the black-hole history of the team members’ deliverables.

I wrote up a process document to send to the product team members so they would know what our dates are and how the documentation process works. This helped to clear up misperceptions and helped them understand what to expect.

Each of our team members began attending the weekly leads meeting that relates to what section of the documentation they are working on. This helped increase visibility and cooperation with the product team members.

The next step took a lot longer than I’d have liked. I had been pushing my lead into the role of Product Owner. He had the best knowledge of the documentation process overall, the best knowledge and access to the product team’s schedules and needs. And he was the boss He was really nervous at not knowing exactly where we were, how we were doing, what progress we were making, etc. His reaction to this nervousness was to suggest scrapping Scrum and going back to waterfall but he did realize it wouldn’t work when I pointed out that it would not help at all to make the switch – instead we would have to start over again. We made a pact to give Scrum a chance.

A month had passed without the product backlog being generated by my lead, despite my promptings. I believe, in part, this was because he wasn’t sure what to do but also because he was involved in trying to hire another team member as well as dealing with the other products he still owned as well as mine. In the third week of my being a full time employee again, I took all the information I had on the parts of the documentation project I owned and made a backlog spreadsheet for it. I wrote some assumption at the top, prioritized in batches according to those assumptions, and did a rough cost estimate on each line item. Not surprisingly, I had about twice as much work TO do as I did time to DO it in.

Once my lead had seen the spreadsheet, the lightbulb really came on. He worked with the other two writers to create the same sort of product backlog for their sections. Because we don’t have enough people for true cross-training, we kept the sections separate for now.

The last two days have been the fruits of all that labor. My lead seemed a bit worried at how the message would be received that we were NOT going to get everything done by the release date. My mantra was constantly “better the devil we know” – at least now we knew exactly where we were, could communicate that and could communicate progress. We came up with a plan for the items that would not make the cut as well. Each project team group has been great when presented with our backlog list. This was the transparency they’d been wanting all along.

Right now I’m waiting for the product team to look at the list items and calling out any changes made in the batch prioritizations I’d made. In the meantime, I’m working from the top of the list.

We stopped the sprint board when I was interviewing, the Thanksgiving holidays hit along with a product preview release, and things got out of hand. My lead has already agreed it will be restarted right after the Christmas holidays. In the meantime, people are working from their backlog lists as well and the standups are reporting status from the writers to the lead.

My lead has gained enough time back to be able to do some writing again, instead of only managing. We will be on the same page as the product team and will have set reasonable expectations of what we will produce by ship time. We even have a plan of how to handle the post-release work that must be done.

I’ve not announced it yet but my boss will soon find out about the sprint retrospectives we need to have

As both an author and a consumer of technical documentation as well as having some background in instructional design, I have some strong opinions about the role of documentation for a product. Over a decade in testing has also had an effect on how I view that documentation.

The most basic documentation is the help file that ships with the product. In Microsoft products, this is called a .chm (“chum”) file. Yes, I’ve probably thought of my share of bad jokes about that slang, too. I find myself currently involved in cleaning up the previously written .chm file for a new product as well as authoring new content for it and there have been some challenges.

Out of these challenges have come the start of my own personal list of DOs and DON’Ts for technical documentation.

• DO know your consumer and know HOW they use the product to do their jobs.
• DON’T sacrifice your reference sections in favor of only user story or scenario-based content.
• DO use a more conversational voice to make the documentation easier to consume.
• DO review customer feedback for opportunities to update your documentation to cover problem areas when appropriate.
• DO produce other documentation besides just the .chm help files.
• DON’T use the excuse of having other documentation to short-change the help files.
• DO edit for professional voice and errors.
• DON’T over-edit and lose technical accuracy in favor of prettiness of language.
• DO offer tips and make sure gotchas are included.
• DO make content easily findable and clearly identifiable by the consumers.
• DO have your content thoroughly reviewed by the product team.
• DON’T let the process of creating documentation get in the way of doing the right thing for the customer.

My background in shipping products has given me some valuable insight and gives me a solid base on which to work with the product team. I understand what they are talking about and don’t need a lot of hand-holding. They know I take deadlines seriously and am honest with them about where I am on my deliverables.

But I think documentation teams also really need to be able to turn on a dime. Things can change rapidly and you have to be able to roll with those changes.

Processes are required, both within the documentation team and where the documentation team has to interact with the product development team, but you really have to watch for signs that the process may be causing more overhead and pain that it’s solving. When a five minute task takes three days, an email thread of ten or more emails plus several requests being filed…you may have a problem.

You have to keep your eyes on the prize. The prize is excellent documentation to assist your consumers – not how well processes were followed or how many you have. No one will judge your documentation by how many people worked on it, how many processes were followed, who did what tasks or what tools were used to produce it. All consumers care about is how well it meets their needs.

It can be useful to view the RDoc information for the various gems you may have installed on your local system. RubyGems provides a way to do this by starting up a local RDoc server.

Local Gem Server
To start the server, open a command window on the machine that has RubyGems installed and type:

gem server

Once the you get a message that the server is starting, you can minimize this command window (don’t close it or the server will stop).

Using your browser of choice, navigate to http://localhost:8808.

When you open this page, you will see a list of all the gems you have installed on the local system and each one will have an WWW link that will open the project’s homepage as well as an RDoc link that will open the RDoc information for that particular gem. At the top of the page are three columns: Files, Classes and Methods. I tend to find Classes and Methods the most useful when trying to discover usage and syntax for a gem.

If you click on methods displayed in the RDocs, an small pop-up will open to show you the code relating to the method. This can be even more useful if you are trying to figure out how to use a method.

Missing RDoc Information
There might be a situation where you have a gem installed that does not have RDoc information but you can force RubyGems to generate RDoc information for already installed gems.

gem rdoc --all

This will generate the RDoc information for all installed gems. You can also generate RDoc for select gems only by using:

gem rdoc GEMNAME

Ruby Gems can be a little interesting to manage, especially to someone as new to it as I am. In the course of my own self-education, I’ve compiled a little list of what I consider the basic commands. Hopefully this will be of some help to others as well.

Gem Sources

To see which gem servers or repositories your installation of RubyGems is using, open a command prompt and type:

gem sources

The system will return with a list of the repositories and caches Ruby is using to look for gems. In the case of my local system, I got back:

C:\>gem sources
*** CURRENT SOURCES ***



http://gems.rubyforge.org/

Which shows that my system is only looking at RubyForge for its gems right now. This can be useful to know if you get errors that gems cannot be found.

Installing Gems

To install a new gem, you can open a command prompt and type:

gem install gemname

This will install the latest version of the gem gemname from the repository(ies) your local system knows about.

If you have a local copy of the gem and you need to install that particular one, you can open a command prompt, navigate to the directory that contains the local copy and type:

gem install gemname --local

If you need only a particular version of a gem that might not be the latest version you’d get by default, you can open a command prompt and type:

gem install gemname --version #.#.#

This will install version #.#.# of gem gemname.

Uninstalling Gems

Uninstalling a gem can be done by opening a command prompt and typing:

gem uninstall gemname

This will uninstall the gem gemname. If you have more than one version of that gem installed, RubyGems will display a numbered list of the versions and you can enter the number of the version you want to uninstall or choose to uninstall all versions of gem gemname.

Updating Gems

You can update installed gems by opening a command prompt and typing:

gem update gemname

This will update the gem gemname to the latest version in the gem repository RubyGems is pointing to.

Updating the RubyGems System

Sometimes you will need to update the actual RubyGems management system. To do this, open a command prompt and type:

gem update --system

If you are having problems updating your gems or using them, it usually won’t hurt to try to do this update.

Check Gem Dependencies

If you need to know what the dependencies of an installed gem are, you can open a command prompt and type:

gem dependency gemname

This will list the dependencies of the gem gemname.

Gem Help

There is a good amount of help embedded in the RubyGems system. Often you can answer your own questions on how to manipulate your gems using this help. To access the list of commands, open a command prompt and type:

gem help commands

To get help on an individual command, open a command prompt and type:

gem help command

This has been an interesting week for me. I am immersing myself in Watir (Web Applications Testing in Ruby), an open-source library for automating web browsers that works with Ruby, an open-source, object-oriented programming language I’m starting to really like it!

This is a great boon to those of us who have to write automation quickly that need to also be maintainable and not cost an arm and a leg to buy tools for. While some tools do exist, they tend to be expensive or brittle – or both.

The one thing I really am discovering is that there is a mixed bag of documentation and a lot of room for better documentation and training materials. Maybe it’s a place I can turn my writing skills.

Bug reports vary greatly in length and complexity depending on your product, corporate culture and needs but there are some fields that I believe are a must for any bug report. A bare minimum, if you will. This happens to be my own list and other testers will have different fields they consider mandatory but I tend toward a bit of minimalism.

Title
A clear and concise title helps everyone. I make it a practice of putting unique information in the title like error codes or exe names. This makes it easier to later search the bug tracking system for duplicates or regressions rather than file a new bug.

Environment
A summary of the environment the bug occurs in as it relates to what you are testing. It could be as simple as the operating system or as complex as the os, browser, version of flash, etc.

Priority
How important do you think this bug is to fix? This should be important to the overall product and it may be higher priority if it’s blocking other testing or progress.

Product or Feature Area
What product (in a shared tracking system) or what feature area this bug occurred in. This serves to help when deciding who to assign bugs to or what areas of the product need concentrated attention.

Assigned To
This is the current owner of this bug and who is responsible for the next action with it.

Repro Steps
These are the steps, in order, required to reproduce this bug. They should be complete enough that someone unfamiliar with that bug can accurately reproduce it. I recommend a numbered list. If an additional file or script is needed to reproduce the bug, the location of that should be noted here or the file or script attached if the bug tracking system supports it.

Summary
This is a clear statement of what the issue is and why this is a bug. This is the place to make a case for this bug to be fixed so customer impact as well as expected behavior should be listed. If the bug is not high priority, that should be listed here as well. This is not a place to try to game the system and artificially cry wolf on bugs that really don’t deserve it.

Opened By
Who opened the bug. This allows questioning of the person, if necessary.

Opened Date
Date the bug was opened. This is useful for determining bug age.

Opened Version
This is the version of the product the bug is being reported for. It tracks what version was tested, no matter the date the bug was filed.

Fixed By
Who fixed the bug.

Fixed Date
Date the bug was fixed.

Fixed Version
Version of the product the fix will appear in. This allows the person verifying the fix to know when to expect it to be fixed instead of guessing.

Closed By
Who verified the bug was fixed.

Closed Date
Date the bug fix was verified.

The basic purpose of creating and tracking bugs is to improve the product you are testing. It seems really simple, almost too simple, but every other purpose bugs and bug tracking is made to serve in addition to this one can dilute this focus and create problems. You have to take each choice to use the bugs and your bug tracking system and consider what that choice can mean to the goal of product improvement.

Here are several real-world examples of situations where a secondary use for the bugs and bug tracking system affected the primary focus:

• Zero Bug Mandates
  There’s a very common rule on teams I’ve worked on that the product cannot be shipped if there are any open bugs. Obvious and makes sense, no? It does make sense in theory, but what I’ve seen happen in practice is that the team focus shifts from making the right decision for the product to making sure that bug count is at zero and stays there. Good bugs are discarded with inadequate investigation or review. Bugs are closed instead of deferred. Bugs aren’t filed because the tester doesn’t believe they will receive the correct attention and instead they are forgotten or scrawled on a notepad so the tester might file them later-if they remember to do so.

  If your project has a Zero Bug Mandate, you have to make sure you have a process that supports bug retention, addressing the bugs that don’t make the cut for the current release but which do need to be addressed. You also need to encourage people to still file the bugs they find right away. Depending on how you track bugs, you may want to create a new database or release for the next iteration of the project for these bugs. If you are using an agile process, this are part of the product backlog.

• Bug Metrics as Indicators of Individual Performance
  Sometimes a decision is made to use bug metrics as a way to measure the performance of team members. The typical logic is that bug activity correlates to “work” on the part of the various team members and there should be a way to use these concrete bug metrics to judge how much work any team member is doing relative to other team members. It sounds good, but what it does not take into account is that all bugs are not created equal in terms of severity, work to find, work to fix or effort to find or regress. The effort moves from a focus on finding and solving bugs as expeditiously as possible to finding and fixing a large quantity of bugs, regardless of their quality or the quality of the fix.

  If you are using bug metrics as a measure of individual performance, you need to insure it’s not the main way performance is judged. Bugs should be assessed for root cause and similarity and duplicates or related bugs identified as such to prevent cluttering the bug tracking system and unduly influencing your measurement process. Honestly, bugs are a very poor measurement of performance and I never advocate using them for that purpose for individual team members.

Stay tuned for Bug Report Basics!

As part of the January 22, 2009 layoff at Microsoft, my postition was one of those eliminated. A brief interruption and distraction is unavoidable as I hunt for a new job.

Will manage projects, test or write if you have a position for me!