Archive for February, 2010

High Heels in High Tech part 2: Becoming One of the Boys.

You move into your new office space (which you share with a guy named George) and start to unpack and set up your computer.  Your boss seems nice, your office has a window, and the lunchroom fridge is stocked with soda. You’ve made a mental note to request diet coke.

George is friendly, but a little awkward as he clears off his collection of army men that seem to have been launching a full scale attack on the corner of your desk. He offers to show you around and introduce you. Somewhere between introducing you to Mark, Brian, Greg and Dan, he leans over and says “I’ve always wanted to walk around the office with a girl on my arm.” It is right then that you realize you are in strange territory. This isn’t an ordinary office- this is a tech office and until you started – this was a place for jeans ,“that’s what she said” jokes and hot wings lunches.  While you are introduced to Dan, you can tell people are looking at you, and it isn’t because you are the new person- its because you are the first woman on their team and everyone wants to know what that means.

You are the new dynamic. Your coworkers might be a little worried that you will radically change the office culture. They might be uncomfortable making jokes like they used to. You might be uncomfortable wearing feminine (office appropriate) clothes. Nylons, necklaces, and necklines are all new.

They have lots of questions, but so do you. How do you act around these men? Are you supposed to fit in and be one of the boys or are we supposed to step up the professionalism? What do you wear? Is a knee length skirt too short when no one else is wearing them? There may be no HR policy about open toed shoes. When the guys wear shorts in the summer – is it ok if we do? How sensitive should people be about professionalism? Will there be a women’s bathroom or will you all share? Most of that depends on the culture of the office- but a lot of it you will define yourself as you find your spot on the team.

I read an article about women in the work place and how if there are more men, women will actually subconsciously speak in a lower voice and stand with their arms crossed more often in an attempt to fit in with the men.  We don’t need to be one of the boys to be one of the team. It is important to remember that even though we are all coworkers- women and men are still wired a little differently- but that’s a good thing! If we think differently, work together differently or test differently, that just makes us a valuable asset to team.

At some point, you end up managing men. Sometimes much older men. When I was 23, I found myself – as the youngest team member and the only women in the group– in charge of men old enough to be my father. Age is a factor, but so is gender. There were a few rocky releases for us, but eventually, we were all up together on late nights testing, we learned to work together and over look the generational and gender gaps to make a great team.

It feels strange to talk about it, but gender is defiantly a factor- at my company, a new female engineer came on to lead one of our development teams and said one of the biggest challenges was coming on and taking over a man’s role on a team with all men. She had to work to find her place- both as a new employee, and the only female engineering lead.  It can be uncomfortable for you and the people you have been assigned to manage. There are different boundaries, It can be intimidating to stand up and take charge in that situation, but as a leader, it is important address the issues and face them so that your team does not suffer.

Once you find a comfortable fit though- the joys of being one of a few is apparent. I have found the offices to often be more laid back and less cliquish. After few late releases together, (or after you win your first chicken wing eating contest) you are suddenly part of a team that can use its differences- in age, gender or background- to its advantage and work together.

High Heels in High Tech: Women Working in the Software Field

“Oh! You’re… a girl” said a remote member of a QA team I worked for out of college the first time I talked to them on the phone. “I didn’t expect that.”

It is something you get used to, working around computers- as do, I’m sure, women in other male-dominated fields.

“I walk in the door and everyone thinks I’m the secretary,” said one female programmer I know.  Another – a QA manager- kept threatening to bring in her degree and hang it on the wall to prove she belonged. I ‘ve shown up for interviews and had people say “actually, I’m waiting for an interviewee right now, but he isn’t here” and had to explain that I was, in fact, that interviewee.

If you have come from an office with more gender diversity, you may find yourself suddenly questioning the length of your skirt, feeling suddenly very aware of the sound of heels clicking on the office floor or wearing lots of turtlenecks. It is obvious you are in a different world here – the office is like a bachelors’ apartment (ok, honestly it is sometimes like a frat house). Some days you are one of the boys, and some days you get asked out three times by the same co-worker (who you refused each time). At first one of them tries explain to you how to work a mouse and a file menu, but eventually, they learn that you can match them in discussion about requirements and software behavior.

I’ve been lucky. In general, I’ve worked with really accepting and easy going guys- but regardless how great the guys are; being the only woman in your company is a unique experience. So this week I’m going to look at what it is like working as a woman in the tech field- whether you are the only woman or one of a few.

(Read the complete, published version of this article in TEST magazine here.)

New CubicTest and Firefox?

I love experimenting with new testing tools and CubicTest’s selenium plug in for eclipse has kept coming out in my readings lately. So this week, I decided to give CubicTest a try. I already use Selenium and I’ve been hopeful about Cubic Test adding value to that tool. I downloaded the program and wrote a simple test to export via Selenium – anxious to see if we could adapt our current tests to the new tool. It didn’t take long for the first glaring red error to occur- firefox wasn’t even launched.

As it turns out, this seems to be an issue for the latest release of CubicTest- as I discovered from their forums:

I’ve just installed Cubictest using the update site on my Mac OSx.

I’ve just created on simple test which launches a website. When I click run, I get the error message ‘firefox-bin quit unexpectedly’. I also get a subsequent error message about

‘Check that

– The browser is installed (if in non-default dir, set it in PATH)

– The initial URL is correct

– There are no background (non-visible) browser processes hanging’

After discovering my issue echoed on the forums, I set to work looking for fixes. I ran through the whole battery of debug options. I tried different browsers, changed PATH and directory and adjusted settings. It seems utterly unable to export selenium tests.

I also came across this fix, which finally shed more light on the issue -but even with the steps suggested here, the issue still appears.

The issue is mostly related to libsqlite3.dylib that resides on the Mac OSx.

When Firefox starts, it modifies the system’s DYLD_LIBRARY_PATH to point it to its own, this allows FF to run with the latest versions of all its libraries. However as you’ve seen in Eclispe, when Selenium starts up, it forces FF to use the system’s DYLD_LIBRARY_PATH (thus the system’s libraries), causing it the crash.

The solution is to prevent that and make Selenium/CubicTest plugin launch FF without the above. There are a couple of steps to get there:

  1. Create a bash-script in your user directory. Call it firefox-bin (the same name as that used by firefox). This is not really necessary but it helps keep things tidy and neat.
  2. Add the following content to the script file:
    • #!/bin/sh
    • /Applications/Firefox.app/Contents/MacOS/firefox-bin $@
    • exit $?
  3. Next, edit eclipse.ini to use:
    • -DfirefoxDefaultPath=/Users/<username>/Scripts/firefox-bin
  4. Restart Eclipse and try to run your test. It should launch FF fine. The first instance launched will not run the test (not sure why yet). AppleCMD+Q to quit. It will by itself launch a second instance after you’ve quit the first one, that instance would run your test / tests.

The program looks really interesting. Selenium has worked well on our project before- and extending it capibilities and maintainablility is an exciting prospect. I’ll keep checking back to see if this issue is resolved.

Has anyone else had luck with this program?

I may give it another try on a windows virtual box -but with less than exciting results so far, I may keep an eye on this issue to see if it is resolved first.

Goals

Now that choosing a new team member is complete, it is time to formalize goals for the QA department moving forward. When I started here, QA was a footnote to the development process. The engineers ran unit tests and the production team “clicked through” some functionality at the end. But no one was really focused on what a QA department should look like or what that role should be. I think one of the biggest challenges I faced when I came on was carving out a bigger spot for QA within the existing environment. It is an ongoing process, but in the past six months, I’ve seen vast improvement. It is amazing to see processes start to take shape and make an impact. This position has been incredibly rewarding, in a large part, because I can see improvement every day. The whole team here has been flexible, even when I tried something that didn’t really fit, everyone gave me time to try it and then quickly adapted to something new until we found the processes that worked for us. It is nice to reflect on that progress. But no matter how much further we are now than when I started, there is still so much that can be improved upon.

What I hope to accomplish next is opening up the QA process more to the development team. There is a review process now,  but it is loosely followed. I’d like to finish a test plan and have a round table time for people to review, critique and discuss risk areas and test cases. I think it could help in so many facets. Engineers can think more about risk areas when programming and QA can hear about trouble spots or areas of confusion and revise test cases to be more complete in those areas. The production team will have a more complete picture of what needs to go on before a deploy and most importantly, we all get a chance to sit and talk about quality together. I think its really important for such a discussion to occur before the official testing period.

I keep coming back to where QA teams can add value to the whole process, not just the end product. In an interview, I had one candidate define QA’s role as “Reactionary” to the development process. I have to say, I really don’t want that in this department. I want the QA team to be integrated and active throughout the development process – proactive about reviews, discussions, risk areas and testing. There is no reason to wait until the end of a cycle for that, especially not on an agile team. So here is to a larger team, new goals, and hopefully some more great progress like we have seen in the past six months.

Software Testing is not a craft

This weekend, while reading Whittaker’s book, How to Break Software, I came across the following quote:

“My conclusion is that testing is an intellectual endeavor and not part of arts and crafts. So testing is not something anyone masters. Once you stop learning, your knowledge becomes obsolete very fast. Thus, to realize your testing potential, you must commit to continuous learning.”
– James A. Whittaker, How to Break Software: A Practical Guide to Testing, 2003

Something about it stuck with me through the weekend and I found myself thinking about it while pondering the next workweek, while cleaning and while watching the Superbowl. Software testing is not a craft. I thought of the techniques that one can learn and become an expert at applying in different scenarios. I thought about the intuition testers develop about where bugs are lurking and about the practiced critical reading of requirements documents. It seems like a craft. A skill you can hone in on, develop, improve and apply. I imagine expert software testers settling in to that calm space that I suppose a master craftsman enters when beginning a project: a sphere of control, understanding for their role.

But then, I thought of some of the best testers I have known. They are the ones who never learned “how to test” but rather learned the theory of how to approach testing. Their great knowledge seemed to fuel different techniques depending on what they were testing. They were often the first ones to come up with a new solution. They were often the most excited about their work, most adept at finding issues and most importantly, the most genuinely invested in making the software better.

Then I understood- good testers try to master their craft- try to learn the techniques and apply them correctly and diligently to every project with the care and skill of a craftsman. But great testers are the ones who never plan to master anything. Instead they approach each project as something new to solve, based on their previous knowledge, sure – but as something new that must be actively perused to be understood. That pursuit – not of mastery, but of knowledge and application – is the difference. The approach to testing makes all the difference between verifying correct behavior and seeking out bugs. Changing the way you think about what you are trying to achieve changes the bugs you find.  So of course, changing the way you approach learning about software testing will change what you achieve- mastery or the continuous pursuit of improvement and knowledge.

The Worth of a QA team

Why have a QA team? Developers can run unit tests, project managers can approve the look of the site, and clients can have ask for enhancements or updates.  So why do you need a whole group of people dedicated to checking other people’s work? Sure, a good QA can reduce bugs in production, but they can also review requirements early and reduce the appearance of bugs at all.  A good QA can shine a light on problem areas, can reveal missing functionality or irrational features. A good QA can save the team the time and money of post launch bug fixes, not to mention the direct cost of some bugs, if illegal configurations are allowed or something incorrect is ordered or purchase processes are not secure enough.

But when it comes down to it, a QA is the only person on the team responsible to the user. The Business unit imagines new features and requirements and the design team works to make that a reality, the engineers create it and project managers make sure the company’s and the clients deadlines are met but at the end, no one is watching out for the users. Sure, you may do it for your bug count, because you get personal enjoyment out of filing bugs on a certain developer, or perhaps because you need to prove your tests were worthwhile- but really, it is the users you are watching out for. There is one team on the project whose job it is to make sure that everyone elses’ work is actually going to work for the end user.  If they have a bad time with the product, it comes back to you. Of course, if they love it, it probably comes back to the other teams. But somewhere you sit, reviewing that list of issues they would have encountered, and you know that you made in impact, that your team has worth that not only affects your company, but trickles down to other business and other users who are unknowingly happy that you are doing your job. And that is a great feeling- and really, a great job to have.