Maura van der Linden – Blog

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.

I have the dubious pleasure of trying to provide documentation for a small application that is basically a helper application for our product. It’s NOT complicated and it shouldn’t be causing nearly the amount of drama that is currently occurring. This has been probably twenty times more frustrating than my big project.

Now, one thing to understand is that the doc team (of which I am a member) is not integrated with the project team officially. We are a separate organizational unit. With the product team of my big project, they use Scrum and I attend their weekly planning meetings and the daily standups if I feel I need to. They are very transparent and I can check the tracking log at any time to update my plans.

This little project (a single program manager, dev and tester) keep telling me they are “agile” but they have no idea what they are doing beyond having a daily meeting which seems to take an hour every day, pestering everyone else and changing schedules and basic assumptions so quickly I swear I am getting whiplash. There is No Clue here.

I’m frustrated – VERY frustrated – at this point. My team does run on a Scrum process and I keep having to defend my prioritization, my schedule and deal with each time they change their minds and (often) never tell me. The following seems to be unclear to them:

1. Changing schedule dates – drastically – at least once every week or ten days does NOT mean you are agile. It means you have no idea what the scope of your task is and you are allowing schedule creep and bad planning to win while you rush to try to get this project out the door.
2. Changing core deliverables and/or concepts without talking to those you depend on to provide you with something you must have before you can ship and which these changes affect does not make you agile. It means you are risking your project, your shipping and your working relationship with these people you are dependent on because you either think you can push them into doing your will or you are incapable of remembering your dependencies.
3. Refusing to provide the requested information so a team you are dependent on can do their job and “rolling your own” version of what you think they need instead does not mean you are agile. It means you are unwilling to work with that other team and can come across as passive-aggressive or ignorant and the other team still needs the information they requested.
4. When given a schedule by another team, pestering for updates constantly when they are meeting their schedule does not mean you are agile. It means you are annoying them and making them less likely to try to get things done early because they are spending that precious time responding to random emails on things that have already been discussed multiple times.
5. Trying to push a release out the day before a three day holiday that backs up on a week when most staff are on vacation does not make you agile. It means you are foolishly focused on the earliest date you might bully people into shipping instead of having contingency plans for when things may go wrong
6. Asking for documentation to be done off a non-finalized UI to “speed things up” does not make you agile. It means you are asking your doc team to write documentation at least twice and hoping they catch any instances of the non-final UI before the docs ship. Skeletons are okay, but you won’t get RTM ready docs.
7. Shooting of wild plans from the hip does not make you agile. Disorganization, lack of ability to plan and think through processes as well as a lack of ability to track issues, decisions and schedules makes you a project from hell and someone that quickly becomes the person no one wants to work with.

That is all. My tongue may bleed soon from biting my tongue at work.

Today I was asked an interesting question about how I felt as a female tester and whether I thought I needed or wanted a group focused on Women in Agile.

I had to think a bit about my own history in test and remember the few bad times I’ve had as a female tester. Most of the times I had problems was not because of my skills as a tester but because of other people’s impressions of what a female tester was or could do. Their own prejudices were the issue. What did I do? In one case the person was outright disrespectful and I personally confronted them. In the other two, I did my job and I did it well and I refused to worry about what they thought of me.

When I think of any group called “Women in X”, I immediately try to figure out what the purpose of the group is. I am never a fan of any type of diversity quotas or rules. But I consider that there are HUGE numbers of ways to be different from another person. Things like skillsets, experience, interest, hobbies, etc. Being a female is a part of my makeup but it’s only a small part of the puzzle. I’m more likely to consider myself an Agile tester or a security tester than I am a female tester because I don’t think being female is a major point I bring to the table.

Is that wrong? I don’t think it’s wrong or right, per se. It is how I strongly believe in selling myself and how I try to judge others.

Another aspect to consider is that having a group like this also tends to polarize people (mostly men but some women as well). It carries undertones of political correctness, quotas and reverse judgement. A Men in Agile would do the same to some women, if you’re honest. It’s similar to the argument of why to have a Black Music Awards and not a White Music Awards. Someone is always left out and offended. It’s not unifying, it’s divisive.

As a female tester who works in an Agile environment, I’m not sure I’d appreciate the idea that someone put a divide between myself and my team, at least in some people’s perception. Agile is a much more collaborative and peer environment for test than many, does it need a division like this? Why just in Agile? Why not at a much higher and broader level?

I’ve been a member of diversity councils before and, in fact, worked with the women’s organization within Microsoft for over 8 years. I do believe that women should be given early exposure to all the variety of professions they could enter. Too many women don’t consider fields they could enjoy and be successful at because of misconceptions of those professions for the women in them. I believe this is a valid effort but I think this is true for some socio-economic groups and ethnic groups as well. Being women isn’t much different from any of those other groups other than it’s an identifiable social programming. I have issues when an effort to become and foster technology and technical skills becomes more about fostering resentment and a victim mentality than anything else. And it’s very tricky not to fall into that trap.

In this case, I do NOT know the charter of the group Women in Agile. I have no idea what they are trying to accomplish, why they feel it’s needed and what they think they can do. I’m purely talking about my own experiences here. They may have a great plan, I’ve not had a chance to check it out yet. Agile doesn’t seem to pose a unique challenge to women – most problems appear to be more women in IT than Agile in particular.

Diversity is valuable – ALL diversity is valuable. In my co-workers, I want as diverse a set of skills, knowledge, experience and aptitude as I can get. Yes, gender is a part of that but it’s not a huge piece. At least in my own case, I’m content with being a “tester” (though more a programmer-writer anymore) than a “female tester”.

This week the rodent program managers have become Nutria:

When I stopped to talk to them on Thursday, they told me that one of the development leads had confessed to both the capybara and nutria monikers and they think another PM had started it off with the squirrels tag but they’re not sure who labeled them hamsters.

Have to see what happens next week!

As in most offices, there is a bit of a tradition of pranking at my office. Pranks that cause physical damage, make it impossible for the victim to work or which are mean are discouraged but some fun pranks still take place. It does help lighten the day, I’ll admit. Right now there seems to be an ongoing prank being perpetrated on two program managers who share an office but it’s a mystery as to who is doing it.

Each office in our building at work has what’s called a relight. It’s a floor to ceiling, about 12 inch wide window that runs vertically next to the door to allow light into the hallway and the office. It’s also very useful for seeing if the person you need is busy if the door is shut for quiet. Right now our building is crowded and all non-managers are sharing their office with at least one other person. It’s not ideal but it’s not horrible.

Two members of the product team I work as a writer for share an office. These are two of my absolute favorite team members and they are true rockstars. They have a great sense of humor and it’s a Good Thing that they do.

About 4 months ago, I think, I walked by their office to discover that someone had taken a whiteboard marker and written “Squirrels” on the relight. I asked why but no one seemed to know the reason or who had done it. Guesses were made that it had to do with the movie “Up” but most people just shrugged. The funny thing is, the two PMs are a bit like squirrels. They are industrious, busy, and running about getting things done.

I will confess that I started calling them “The Squirrels”. Hey – don’t glare at me! I did tell them that if it bothered them, I’d try to stop but they said they didn’t mind. I guess that’s a good thing because it spread. Pretty soon my co-workers started calling them The Squirrels, too. Then when we were speaking about just ONE of the two, we had to differentiate — I tended to use “Tall Squirrel” and “Not-So-Tall Squirrel”. They took this with incredibly good graces, I’ll confess. Everyone seems to know who I mean when I say I need to talk to the Squirrels or run by the Squirrels’ office.

(I felt relatively safe with calling them that because they didn’t erase the moniker from their relight for months. I figured they couldn’t be too annoyed if they left it there.)

Then about a month ago, “Squirrels” disppeared from their relight. I inquired when I noticed the deletion because if they had gotten sick of it, I wanted to TRY to not call them that anymore. But they said they hadn’t erased it – they’d just come in and it was gone. It seemed to be the end of the prank. I was sad. A little humor goes a long way sometimes.

Two days later, I walked by and a new word had been written on the relight – “Hamsters”! They asked me if I wrote it and when I asked why they thought I did, they said it looked like female writing. (There’s female writing??) For some reason they seemed more eager to figure out who had dubbed them hamsters than squirrels – did they consider it a step back? Hamsters are cute too but I couldn’t see them so much as hamsters – most hamsters I knew were only energetic at night and slept a lot of the time. I continued to call them the Squirrels, in defiance of their new moniker.

I’m not sure they ever followed through on their idea of gathering writing samples from various suspects’ whiteboards, though. Last I heard they’d narrowed in on a couple of people and were asking questions.

But, again, they let the writing stay.

Yesterday I stopped by to ask a few questions and “hamsters” had been replaced by a new moniker – “Capybara”. I’m afraid I DID crack up at this one. Plus someone had written “Python food” and drawn an arrow pointing to “capybara”. They just shook their head when I managed to point at the relight and shrugged. One of them did admit they had to look up what it was. (It’s actually a giant South American rodent. Think 140lbs or so giant.)

I wasn’t paying a lot of attention but I think the three different names were each in different handwriting. I’m not sure who is responsible or what group of people might be but it’s truly hilarious and I can’t wait to see what the two PMs are dubbed next. The combination of the escalation (or maybe descent?) of rodent species and the way the two PMs can take a joke makes it a lot of fun and has really livened up what has otherwise been a highly stressful and incredibly busy few months.

I was just in a meeting at the Evil Day Job where we met with representatives from Author It. Author It is a software suite designed for documentation management and production and I’ve only heard a few rumbles about it before. I’m quite interested by what I heard and saw because it’s based on an object-oriented method of documentation design and reuse which fits in with my programming background. I’m hoping to have a trial version to play with soon so I can report back on what I find out and think.

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

If you want to know where your Ruby installation is looking to do Gem installations, you can enter the following at a command prompt to find out:


gem sources




You’ll get back a message that looks similar to this:


*** CURRENT SOURCES ***


Bulk updating Gem source index for: http://gems.rubyforge.org

Today marked the last edition of the Rocky Mountain News, a print newspaper that has been in business almost 150 years. While I am saddened by its demise, it does make me ponder the ways technology and society have changed how we receive and seek out information.

For myself, I’m a news junkie. I grew up with parents that received multiple newspapers and I still read the news every day. But I don’t subscribe to or purchase a newspaper. My own experience has been that once I’ve read the paper, I have to make time to recycle it and they clutter up my house (more so than before). I don’t need the hard copy and it’s actually a nuisance.

Instead I read my news online in multiple locations.

The advent of being able to access your news at your leisure and for free as well as different delivery mechanisms like electronic subscription, etc., have changed the way many people I know get their information.

But now the newspaper publishers are faced with a bad economy on top of ever dwindling subscription numbers which, in turn, affect advertising revenue. I’m not sure they will survive even the next decade. It’s sad, indeed, but I’m not sure how they can cope with the changes to society and technology without making changes that may mean electronic only.

We’re on cusp of changes and I mourn the past. But I can only look forward to the future.

There’s a common myth in software QA at the moment that if you hire an SDET and they whip you up some test automation, you’ll have achieved “good” testing. Honestly, I’m not quite sure why this myth still exists. Just common sense says it’s not true.

Test automation is a good thing but should be used with planning and a knowledge of the pros and cons of doing so. If used appropriately, it’s a definite bonus to your test efforts but anyone who judges their test efforts solely by the amount of test automation in place is deceiving themselves.

Developer and Tester Mindsets are Different
Developers have an ingrained mindset that slants toward examining code to see that it does what it is supposed to do. Testers have a slant toward examining code to see what it does that it shouldn’t. This just has to do with how they are trained to operate.

Automation Tends to Not Find New Bugs
Test automation generally finds new bugs only while being written. It can (and is good at) looking for recurrences of bugs already found and fixed but it doesn’t tend to find new bugs after the initial run.

Automation Cannot Judge Esthetics or UIs Well
Testing a UI or web page cannot be done solely with automation. This is because some of the important aspects like appearance, alignment, and visual appeal are either not able to be tested via automation or so very expensive to automate that they just aren’t worth it.

Automated Tests are Only as Good as the Test Case
Writing a bad test case and then automating it still means you have a bad test case – just a more expensive one. Test automation needs to be written by testers who know how to design test cases.

Automation is Expensive to Write and Maintain
Test automation is often very fragile and prone to breaking during changes to the product under test. The costs of writing new automation and maintaining old automation can be prohibitively expensive. So test automation needs to be worth the costs.

I do feel that smart use of automation can improve test efforts but having lines of code is not a way to accurately judge a tester or test effort. Unit tests and BVT tests are good examples of test automation that is worthwhile because it’s reused and run so frequently that it pays off.