software testing teams

Some tips for one-person software test teams

Last week I hosted a panel on time management for a local software testing group, IWST (Indianapolis Workshops on Software Testing). One of the questions asked during the meeting went like this: “I just started a new job and I’m at a company where I’m the only tester. Any tips for making that work?”

The entire panel was quick to point out that you’re never alone, and that you always have a team to work with. Brian Ball, a software engineer with Software Engineering Professionals, said that it’s important for you to realize you’re part of a larger team — whether they feel like it or not. He said you need to let the rest of the team know that you’re concerns are really their concerns.

Robby Slaughter, founder of Slaughter Development, a workflow and productivity consulting company, pointed out the following:

“What you really need to do in those situations is identify who are the stakeholders around you who care about the results of your work and the results of what’s happening, and find a way to leverage their expertise, their ability, their commitment and their passion towards what you do. Now that’s a problem that is magnified when you have technical expertise in some area of what you do, and the people around you — the stakeholders — don’t.”

Slaughter also pointed out that one of the most important things you can do is to help people give you information in a way that enables you to do your work better.

“You need to realize that you might have this expertise or this area of technical facility [and they do not]. You need to go back to the stakeholders and identify ways to communicate better. Maybe they need a form to fill out. Maybe they need a tracking system, your ticket tracking for the request. Or maybe you need to find a way to give them information in a more organized fashion, so they can find it more easily so they are not constantly calling you.”

Chris Wingate, principal software engineer for Liberty Mutual, summed up his thoughts on the question the following way:

“To me is seems to come down to two things…and those are trust and education. So you’re the only tester in your organization at the moment, and so it’s very important to build the trust in your competence with the rest of the team — with the developers and the managers. That way when you say, ‘Yes I can do that.’ or ‘No I can’t do that for these technical reasons.’ you don’t have to spend a lot of time explaining all of that and rehashing all of those things that you continually do.

“The other thing is educating the rest of the team about what your capabilities are, what timelines are, and they go together… you have to educate your customer in terminology. Educating your customer is going to help improve the communication and help make you more efficient.”

You can find the complete audio for the panel members’ advise for one-person test teams on the IWST website. There you can also find more information about the speakers along with additional audio from the meeting broken out by topic.

How software test teams’ people skills affect results

I wasn’t always the brilliant, charismatic, well-loved tester that I am today. Well, I’m not really any of those things today, but I often like to think I am. That’s my problem. Sometimes my ego gets in the way of my best work. I’m also susceptible to all the bad behaviors that come with tight deadlines, layoffs and work I don’t particularly like. Like everyone else, I can let stress tax my professional relationships.

Karen Johnson will be tackling this problem head on during her talk — titled “Building Alliances” — at the Pacific Northwest Software Quality Conference (PNSQC), which takes place Oct 26-28, 2009 in Portland Oregon. Karen will look at how to create and foster successful professional relationships with teams and people. That means not just fostering a collaborative spirit, but also looking for ways that teams can look out for each other and work together.

“The talk focuses on building healthy relationships at work,” Johnson told me recently. “In theory we have a relationship with everyone we work with, at least at some level. But how many relationships do you have on your team or at your company that you can count on when the going gets tough? The answer is usually a handful of carefully maintained alliances. Those alliances are the solid dependable work relationships my talk is focused on. How do those alliances get built? And how are those relationships maintained?”

Karen Johnson is an independent software test consultant and has been involved in software testing for more than two decades. She has extensive test management experience, and her work often focuses on strategic planning. A frequent speaker at major conferences, she has published numerous articles and recorded webcasts on software testing, many of them here on SearchSoftwareQuality.com. She is also a contributing author to “Beautiful Testing,” a O’Reilly book coming out later this year.

Most recently, Johnson’s focus has been on developing a sense of community for software testers working in the area of regulated software testing. She’s been studying office politics and how they affect people. In her PNSQC session, she’ll reveal her finding on positive practices of healthy, functioning teams and how those practices build good, collaborative relationships.

“I find it interesting that sometimes people in our software testing community recollect with horror painful people events that have taken place from their past work experiences,” she said. “And sometimes people talk about successful alliances at work and people they’ve been able to depend on. But what I haven’t heard people talk about is how to go about creating those healthy relationships. After a number of years of working in a variety of companies, I have a collection of positive and negative experiences. My talk draws from both.

“I don’t like politics. I’m not especially good at them and earlier in my career, I figured I could avoid politics altogether. Once I became a test manager, I realized, I couldn’t avoid politics. Much of what I wanted to say and plan to say, comes from my experiences, my stories and from my heart of what I’ve learned.”

In typical Karen Johnson style, her talk will also be well referenced. Karen told me that in addition to her own experiences, the talk also draws on the work of others. “There is an amazing amount of material on the topic,” said Karen. “These references are especially good reads…”

• “Territorial Games” by Annette Simmons
• “A Safe Place for Dangerous Truths” by Annette Simmons
• “A Book of Five Rings” by Miyamoto Musashi
• “Inspiring Others: What Really Motivates People” by Duke Corporate Education
• “Care Packages for the Workplace” by Barbara Glanz
• “Toxic Emotions at Work” by Peter Frost
• “In the Line of Fire: How to Handle Tough Questions… When It Counts” by Jerry Weissman
• “Tao Te Ching” by Lao Tzu

Clearly, her talk is not focused on the technical aspects of software development. It’s about people. For those who might not feel topics like this are important, Karen offers the following:

“Let me offer this thought: One of the skills I’ve focused on acquiring and sharpening over the years is being observant. When I test software, I’m making observations. When I work with people, I use my observation skills to notice relationships and dynamics. I need to be able to observe changes with people and teams in order to get work done. It’s not just the raw technical skills that get the job done.

“If you want to test software and quietly report defects, I suppose technical skills might be enough. If you want to be someone who has influence to improve a product, you have to be able to work with people. I think it makes sense to have talks at our testing conferences that address people topics.”

Karen will also be teaching a full day tutorial on SQL at PNSQC. The class is a more advanced class focused primarily on joins and queries. For more on the upcoming show, check out the PNSQC website. You can also learn more on Karen Johnson’s website, Testing Reflections blog or by checking out some of her Expert Responses and Tips on SearchSoftwareQuality.com.

Getting a jump start on software test collaboration

Having tested software during many projects, I’ve seen that the most effective testers are the ones who start early — and I don’t mean the ones who start testing early. I’ll explain what I mean with this step-by-step tour of a pattern I’ve noticed multiple times in software testing projects.

1. A project starts.

2. All the testers work very hard to understand the problem they are trying to solve.

3. Eventually, some small amount of “working” — a very subjective term — software gets delivered to a development environment for the developers to do their unit testing and debugging.

4. One group of testers — often those doing exploratory testing or those working in an agile project context — ask the development team if they can get involved and help test that early code. They don’t care if they can’t log “defects,” because they just want to see the product and provide feedback when and if the developers think it would be helpful.

5. Another group of testers (often those doing scripted testing or those working in more “traditional” corporate testing environments) say they want to wait until unit testing is complete before they start their testing.

6. The group that starts early develops an early collaborative relationship with the developers who let them test their code.

7. Eventually, some small amount of formally “working” software gets delivered to a test environment for all the testers to begin their first test cycle.

8. At this point, both groups of testers start their first test cycle, and both find and log issues.

9. The issues found by the first group — those who worked more closely with the developers — tend to get resolved first, not based on priority or severity, but based on the personal relationship of the tester to the developer.

10. If a defect from that first group — those who worked more closely with the developers — can’t be reproduced, the developer comes over to work with the exploratory tester to isolate the problem.

11. If a defect from the second group — those who waited to start testing — can’t be reproduced, the developer sends it back as “can not reproduce” or the ever famous response, “It works on my machine.”

Before someone points out that “it’s not always practical to start testing early,” and that “there are a lot of good reasons to wait,” I get it. I’m not advocating that in all circumstances you should start testing early. There are plenty of reasons where that might not be practical. However, I’ve never worked in anywhere I would say that’s been the case. And I’ve seen this pattern a lot. It’s not universal, but it’s very common.

The testers who get a jump-start on collaborating with the development often have a closer relationship, and are thus viewed as an asset. It is these testers who are often pressed to help isolate a defects, even if it wasn’t logged by them. They are also the testers who get invited to design review meetings, because their opinions are highly valued.

Does that mean you have to get involved early to be an asset or to have those relationships? Absolutely not. But, I suspect that if you can, you’ll have a better chance of collaborating with people on your project team before pressures are high, stress is up and your “feedback” is viewed as a call for another late night debugging session.

Software testing blog digest: Bug, team woes; memes; Ford Motors

If you don’t read software testing blogs, you’re missing some great advice and thoughtful ramblings on testing philosophies. I tap into those blogs daily, and here I’m sharing the wealth with this reader’s digest of the testing posts I enjoyed this week.

Why bugs are hard to kill

On Maverick Tester, Anne-Marie Charrett describes the mistakes she’s made when doing offsite exploratory testing under tight deadlines. Then, she reveals how she’s stopped making those mistakes in her list of offsite exploratory testing guidelines to bug reporting.

One tidbit of her advice: Write reports right away, even if you are super-busy. She writes that “it takes longer to write them up at the end, when you have to review heaps of cryptic phrases in Session Tester or in your notebook.”

I love the post’s title, “Do your bugs only glow when it’s dark?” It reminds me of the “putting out fires” metaphor. How many times have I gotten emails from co-workers, site experts and others saying they’re late with a response or a deliverable because they’ve been putting out fires? Hey, I’m guilty, too.

In my own work, I see that most of these fires were started when haste made waste. Why is it so hard to take things one step at a time? Oh yeah, there’s a deadline and not enough time to make it.

When familiarity breeds success
Moving on, two posts on Matthew Heusser’s Creative Chaos blog explore thought-provoking topics: team cohesiveness and memes. In his post on Jelled Teams, he ponders the good results of working on a team that’s been together for over a year. How much creativity and productivity is lost, he asks, when companies often shift people from team to team as casually as they do? Too few managers realize that teamwork flourishes when people know each other well enough to feel comfortable sharing their ideas. When a team works well together, it’s an added-value asset in and of itself.

So, project managers, think twice before breaking up good teams!

I see a connection between that post and Heusser’s musings today in The meme’s the thing. Wikipedia calls a meme “a postulated unit or element of cultural ideas, symbols or practices, and is transmitted from one mind to another through speech, gestures, rituals, or other imitable phenomena.” Good grief! I think Heusser’s short definition is better: “It’s an idea - a concept that spreads from person to person. “

Any married person knows that familiarity and mind-melds go hand-in-hand. It stands to reason that team members that’s been together a while will start understanding how each other thinks, and the ideas will start flowing. Community work along the same lines. That’s why, I think, the open source software community has made such great strides so quickly. Another is that open sourcers are so communicative and have created vehicles – sites, projects, message boards and so on – that foster collaboration.

Heusser believes that software testers should be thinking along the same lines and said:

“I believe that the communities I belong to…have ways to test software that are significantly better than the status quo, and we have ways to communicate them and techniques to teach them. Yet if our testing ideas are memes, we need to think about ways to package and present them to win.”

Carrying on with the teamwork theme, there’s a nice exchange on the topic of how to handle unhappy testing teams on Jerry Weinberg’s blog, The Secrets of Consulting. A software test manager at an insurance company wrote to Weinberg, and they –- and others – brainstorm on the subject in an informative message chain.

On the lighter side

Once you’re a software tester, you look at everything from that point of view. So, Software Quality Insights blogger and independent consultant Mike Kelly describes Ford Motor’s web application flaws whe he was trying to spec a new Ford truck. In his entertaining post, he concludes that it’s easier to build and buy a Toyota online. This is something Washington has missed when discussing bailouts and the state of U.S. auto companies, I think.

There were plenty of other good reads in testing posts this week, more than I can cover here. Please comment below if you read something good this week or have a favorite testing blog.