Click here to increase or decrease font size: A  A  A  A







Home Biography Published Works Blog Message Board Newsletter Guestbook Contact

Archive for the 'Testing' Category



Friday, June 25th, 2010
An Experiment in Transpection

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.

Saturday, June 5th, 2010
Diversity Groups

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”.

Saturday, March 7th, 2009
Where is Ruby looking for Gems?

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

http://gems.rubyforge.org



Friday, January 30th, 2009
Test Automation != Good Testing

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.