Development

Nov 12 2009   7:09PM GMT

Using Agile, scaling back helps software projects in recession

Posted by: Dan Mondello
Project management, Add new tag, Software project management, software development

“You are about to embark on a dynamic quality endeavor. It is time to throttle down on your already oversized and over-budget test and development teams.” That was the opening salvo of Michael Mah’s (QSM Associates) SQE Agile Development Practices Conference session, Rightsizing your project in a down economy.

Project teams are just too large, Mah said. Sure, the poor economy has prompted downsizing in this industry; but that could be a blessing in disguise. After all, there have been many years of impractical spending, mismatched teams and dysfunctional workplace goals in software projects.

For too long, Mah said, executives and managers have emphasized speed over quality, judging success by whether teams turn out code lines on time, rather than on delivering in a reasonable time frame quality code that’s free of obvious functional flaws. He’s seen promotions being given to project leaders who met deadlines without ensuring quality. The results? We are paying the ultimate price in lost jobs and market share, he said.

“Now that I have pointed out where the trouble began, let me now explain where the trouble continues,” said Mah. Today, he sees many companies using the recession as an excuse for adopting seriously questionable practices, like trying to cut steps to recovery by cutting down on employees. In the short term, this does free up some cash; but once a company has rebounded or is recovering, new team members will have to be hired. Of course, it takes precious time and money to train new employees and pay for newbie mistakes.

On the other end of the spectrum, there are the overly-cocky executives who have spent more wisely over the years, they see this time where other companies are cutting back and pinching pennies as time to throw money and software at problems. This rarely works, and usually sends these companies into the downward spiral.

In a time of recession, throwing enormous manpower and software at problems will rarely resolve issues. It is more appropriate and intelligent to scale back, says Mah.

To scale back, project leaders should build strong relationships with a small core group of commited employees. Research your service and tool providers more thoroughly, gather references and check them.

“How many of you have some fear about loosing your job?” Mah asked the audience, and nearly all of them held up their hands. “And how does that make you feel? Bad, right?” Company and project leaders are responsible for alleviating fear, not creating it. Fearful teams don’t work productively. Often fear is responded upon with aggression.

The most effective way in managing concerned workers in a recession is by showing “concerned optimism,” Mah said. Explain the situation, but encourage the team. Leaders’ optimism and relationship helps team members feel confident in their abilities and have more belief that they are capable of working on innovative projects. A motivated and innovation-welcoming team is critical to success and growth. Optimism makes for more tolerable working environments and more creative problem solving.

“I remember a good many times I would work through 70+ overtime work weeks; partly because work needed to be done, but also because there was always a chance that the company president would see me there,” said Mah. “On the occasions when he did, he would always compliment me with a thumbs up and a ‘good job.’ That was all the praise I needed.”

---

More coverage from Agile Development Practices:
Early adopters, Agile philanthropy key points in ADP keynote

Agile philanthropy, one man’s ambition for a brighter future

Nov 11 2009   10:04PM GMT

Early adopters, Agile philanthropy key points in ADP keynote

Posted by: Dan Mondello
Agile software development, agile, Agile adoption

“With great power comes great responsibility.” Those were Ben Parker’s dying words, spoken to a young Peter Parker, alias Spiderman. It was also the subtitle of Electroglide Bob Payne’s keynote on the opening day of Software Quality Engineering’s Agile Development Practices Conference in Orlando, Fla.

The keynote’s focus was Agile philanthropy, a term Payne uses to describe the benefits of Agile. Payne discussed the new Agile Philanthropy project, whose volunteers from the open source and commercial software industry assist non-profits with application coding, development and delivery. “This industry has been very kind to me,” says Payne, “I felt obligated to give back.” If you would like to speak with Bob Payne about volunteering, contact him at bob@codegreenlabs.com.

Payne’s other project is transitioning Electroglide, a Washington, D.C.-based consulting firm, and rebranding the company too CodeGreenLabs, a new brand name but one still focused on Agile software development and transitioning companies to Agile. Payne has been an Agile user since 1999, before the publication of The Agile Manifesto.

Typically Electroglide’s ideal clients have been large financial service providers and video game development companies. He’s seen that financial companies are early adopters of Agile. Indeed, he thinks the financial service provider market is in the greatest need for Agile business practices. They usually are already working together on coding projects and only need slightly more-focused guidance to fully work with the upmost agility, he said.

While financial firms are definitely interested in Agile, they can be reluctant to engage in Agile practices. Transitioning normally takes one-to-five months to complete, Payne said, but transition included two Agile projects: one related to technology and practices; another in which the company works cooperatively with Payne to learn the Agile mindset.

In Payne’s experience, the gaming industry has been the most open to Agile practices, largely because the way in which game developers have been creating games already closely mimics the Agile methodology.

While Payne is an Agile evangelist, he did not sugarcoat the Agile way, noting that the Agile approach just isn’t going to yield companies the desired results in every situation.

Nov 9 2009   3:59PM GMT

How testers can handle switching to Agile’s short iterations

Posted by: Michael Kelly
Software testing, Agile software development

Software testers today are under a lot of deadline pressure due to Agile development’s shorter iterations. I recently hosted a panel on time management for a local software testing group, and attendees asked for advice on how to handle the frustrations associated with moving to short development iterations. While the theme of “making sure you have team buy-in” underlay the entire discussion, there were some particularly insightful nuggets related to making sure people understand why the work is structured the way it is in short iterations.

Robby Slaughter, founder of Slaughter Development, a workflow and productivity consulting company, set up the problem this way: Most software professionals in highly-tactical roles — whether they are authors, developers or marketers — are used to the idea that their work is a representation of professional capacity. So, the pro has this self-concept, and then their deadlines are changed to weeks from the traditional span of three-to-six months. Instead of working on one larger task, the task is broken up into 20 smaller pieces.

“All of a sudden that way in which you represent your own professional capacity, your expertise, is now violated. Now it’s being divided up.”

Slaughter’s main point is that the work is no longer yours. It’s the team’s. The individual parts that you work on or someone else works on are not as important as the overall result. Many times people working in iterations are dealing with that frustration. They no longer have the same level of ownership of the piece that they’re working on.

Brian Ball, software engineer with Software Engineering Professionals, had a slightly different take on how you might illustrate the same point.

“There are principles to why you do things in Scrum,” said Ball. “So if they’re uncomfortable with why we’re only doing a short section of work here, why we’re breaking this up and I’m not doing the entirety of the feature, [or] why I’m only dong this little unimportant subset; then when you start throwing stuff out of the backlog because the customer changed their mind…celebrate that. Say this is work we didn’t do and we no longer have to do. Just throw it out…So they see a concrete result of why the principle was there in the first place. They get the payoff of, ‘Oh yeah, we delayed it and we didn’t have to do it.’ [That's] because it wasn’t important — really important — at the time. It just left us with this uncomfortable and unfinished feeling at the time. “

If buy-in might be part of your problem, the panel offered a question checklist for helping understand what might be blocking buy-in.

“How do you set it up to provide it to them?” asked Francine Carter, founder of Action Coaching & Training. “How do you roll it out? Because the rollout’s the important piece to get people to begin to think about how they’re going to approach it. And if you’re thinking I can’t, then you’re not going to. What about it don’t you feel good about?”

Brian Ball recommends looking at your planning meetings and making sure all the work is being accounted for in the estimates — something that takes practice and measurement. Make sure everyone understands why the work was broken up the way it was, he said. In other words, paint the big picture.

Cory Mausolf, a career coach with Authentic Business and Career Coaching, pointed out that it can be important to make sure people are separating their feelings about the work itself from how the work is being done. Are they uncomfortable about the work? Or are they uncomfortable, he asked, “because that’s not how you did it before?”

You can find the complete audio for the panel members response to this question 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.

Nov 9 2009   3:15PM GMT

How software testers can get deliverables without nagging

Posted by: Michael Kelly
Project management, people management, performance, software project

How can software testers get development team members’ firm commitments for deliverables? That question came up while I recently hosted a panel on time management at a local software testing group meeting. As testers, we rely on a lot of people: developers for code; system administrators for environments; business managers for data and oracles and so on. A big part of testers’ day-to-day life can be spent waiting on getting what we need to start test execution.

“Sometimes I feel like I’m nagging other people to get things done,” said one tester in the audience. “Do you have any techniques to help get commitments out of people to help make this process less painful?”

Panel member Robby Slaughter, founder of Slaughter Development, a workflow and productivity consulting company, provided some ways to move from nagging and silence to empowerment.

“I think that all of us have the experience of nagging, and we all know that nagging does not work. It doesn’t work to be nagged; you don’t have any desire to do the task. In fact, if you’re nagged you’re less likely to do something. If somebody calls me three times in the course of a day and asks me to do a project, I’m not going to do it for them. Because I know they’re going to keep reminding me until the deadline comes up. They just created an expectation that I don’t have to remember any more. They’re now my human to-do list. So nagging is the worst thing you can do to get something done.”

Take away nagging, though and what persuasion option do you have?

“The opposite seems like silence,” said Slaughter. “Just hopping that it happens doesn’t really work either because you really haven’t communicated what it is you need. So, I think the most helpful strategy is to try to empower the person you’re work with. And to say, ‘Hey, if you can do this really great thing that I can’t do, that would be fantastic because then I can do my job, and make you look even better.’ So if you can find a way to empower them, they’re more likely to want to get the task done for you.”

Slaughter, wanted to be clear about the difference between empowering and enabling somebody, noting that:

“If you empower someone then you’re imbuing them with the authority and the responsibility to provide you with their work that you need to do your job. And that authority and responsibility translates into satisfaction, satisfaction translates into productivity, productivity translates into a sense of ‘I can know what I do.’ If you enable them, then what you’re doing is you’re allowing them to not complete their job. Empowering is more about ensuring they have tool and resources, ensuring they have information, ensuring you understand their challenges. Whereas enabling means I’m you actually say, ‘You know what, I’m going to come and do some work for you, or come and make your life easier directly by doing the things you’re suppose to do, so I can get the things I want.’ And if you do that, the danger is that you try to take work away from them. And you give yourself more work to do. And you establish a culture in which you doing people’s jobs for them.”

Francine Carter, founder of Action Coaching & Training, extended what Slaughter said, to include getting buy-in. “If they know why you need what you need,” said Carter, “and how it will move everything else along, then you’re going to have much more buy-in.” Buy-in, she said, isn’t always as simple as saying, “I need this because….”

Carter also pointed out that you need to consider where the other person is coming from.

“You never know what they’re thinking. They may be hesitating in getting it done because they’re afraid of doing it [or] they’ve never done it before. You don’t know what their story is, either. So the more that you can go at them and try to understand where they’re coming from and why they’re not doing it, [the more you can] maybe help them and empower them along. Think about where that other person’s story is. What are they thinking? Why are they hesitating and procrastinating on this?”

Brian Ball, a software engineer with Software Engineering Professionals, gave some advice on getting commitment:

“You want to put them on the hook for what it is that you’re trying to get them to commit to, and the easiest way to do that is to let them hook themselves. If you say, ‘Hey I need this as soon as possible.’ that’s one thing; but if you turn around and say, ‘So, I need this. Here’s why. When can you have that by?’ then they’re creating a commitment to you. And if they say, ‘I have no idea.’ then say, ‘I need to know, so I can plan my schedule.’”

“The other thing is that, if it is the case that they do start blowing you off, then you at least have something to go talk to somebody about. Say, ‘They said they were going to do this and have not given me a reason, and refuse to give me a reason, as to why it hasn’t happened.’ And I hate to bring out the big guns and bring somebody else involved into it, but usually it helps just to say I got them to commit to something.”

Ball also pointed out the other side of asking people to do something for you, which is thanking them. “Conversely, when they finally do actually get done what it is you ask for them, sit there and go ‘Sweet! That’s awesome!’!!” said Ball. “Pronounce it with three exclamation points even if you don’t feel like it, because you’re trying to make them feel good about what it is they did for you.”

Chris Wingate, a principal software engineer for Liberty Mutual, provided some of the easiest advice about managing commitments. In short, get the project manager to do it for you.

“Most of my performance test engagements [are situations where] you’re always waiting on somebody,” Wingate said. “Or, you’re trying to get another resource to get more information, or do more monitoring or track down this issue or that issue. The most effective thing I’ve found to get the team focused and moving forward on things is a 30-minute meeting twice a week. The project manager is there, the developer, the lead developer is there, the architect is there, the lead tester is there, so everybody knows what’s going on, everybody knows what the delays are. Let the project manager do that work for you.”

You can find the complete audio for the panel members response to this question on the Indianapolis Workshops for Software Testers website. There you can also find more information about the speakers along with additional audio from the meeting broken out by topic.

Nov 3 2009   7:52PM GMT

Some tips for one-person software test teams

Posted by: Michael Kelly
Add new tag, Software testing, software testing teams, software, Indianopolis Workshops on Software Testing

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.

Oct 24 2009   1:41AM GMT

Drilling deep into performance testing at STPCon

Posted by: Matt Heusser
STPcon, software testing and performance test conference, performance testing, Software testing

After yesterday’s Boston SPIN meeting, I got a full night’s sleep, woke up, checked email, and it was time for the full-day workshop on performance testing.

In the morning, Scott Barber presented a half-day workshop on quick and easy performance wins. In the presentation, he split the hard engineering performance testing work — say, simulating and cranking up load –from the “easy stuff.” To do the easy stuff, Scott had four concrete suggestions:

1) Know the mission

Instead of stating with a document — “100% of web pages shall load and display within five seconds” — Scott proposes a model of conversation to collaboratively explore and figure out what the goal is – before testing begins. He calls this “accept / converse / understand.”

2) Am I annoyed?

Scott suggests (and I agree) that it’s actually pretty hard to make decisions on 4.8 seconds verses 6.5 seconds. So instead of working for hard numbers, you can simply have testers write down their annoyance on some scale, perhaps 1-5, at various key points as the test suite runs. (Ideally, do it under simulated load; but if performance stinks for one user, that will tell you a lot in and of yourself.)

3) Watch the trends

Scott suggested that developers can write timers, wrap unit tests in those timers, and simply observe trends to see if the software is getting faster or slower. Likewise, the team can do the same thing to document acceptance and human-run testing. Several people in the room observed performance with a stop watch.

That’s just the tip of the iceberg. Most of Scott’s talk wasn’t on specific technique, but instead on dynamics of projects and general systems thinking skills.

Then, in the afternoon, we had a panel on innovations in performance testing, then a quick mini peer conference where we shared our experiences with perf testing.

In my book, the peer conference idea beats PowerPoint-driven lectures by a mile. Still, I have to say, Scott’s talk was pretty good.

Oct 22 2009   5:35PM GMT

Ways Agile beats waterfall development, boosts software quality

Posted by: Dan Mondello
agile, Agile software development, waterfall, Damon Poole

“How many of you are agile-ists?” Agile expert and author Damon Poole asked attendees this at the SPIN local user group meeting near Boston this week. Then he said: “Agile-ists look like normal people… but if you don’t believe in agile, let me assure you, there is nothing wrong with you.”

Poole gave various examples and analogies of how agile development methodology works, noting that group involvement was a key of agile success. Agile developers benefit from receiving more frequent feedback from customers and having short-term, reachable deadlines, Poole said.

“Agile versus waterfall or any other methodology can be compared to touchdowns versus yardage,” he said. “Where is the credit given? Clearly you can’t win the game based on ridiculous yardage without scoring.”

This analogy points to the major downfall of waterfall, a process in which the team scrambles in all different directions and gains some ground, but often fails to complete the project on time. Agile, he said, is different; you set reachable goals for short phases, or iterations, of development.

This process of “continuous integration” involves completing one set of functional code, getting feedback and then adding new coding to it and retesting. Doing projects in phases assures a higher quality because of multiple tests and retests carried out during the SDLC (Software Development Life Cycle).

“With agile, there is an absence of confusion,” Poole said. “Do you guys remember the childhood game ‘telephone’?” As nearly every hand in the room went skyward, Poole smiled: “How did that game go?” The audience chuckled, and appeared follow his point. If one person tells a group a direction or a goal and the group collaborates there is less chance for project digression. The project is more likely to be what the customer is looking for which is the equivalent of success.

Agile doesn’t only benefit the industry or a company alone, Poole concluded. It also can benefit the individual. He listed these benefits for the agile team member

1. Less cancelled and or shelved work
2. Less pressure or stress over project duration, especially during crunch time as testing is done throughout SDLC
3. More individual ownership and feeling of involvement in a project
4. Increased project success

Poole frequently repeated the phrase, “the simplest thing that could possibly work.” Agile is the simplification of complex tasks, he said, satisfying the customer today and tomorrow, allowing for full software development team collaboration and good returns on investments.

<
Boston SPIN presenter, Damon Poole (on right) speaking with SearchSoftwareQuality.com contributing writer Matt Heusser

Oct 13 2009   6:25PM GMT

Is your software test team rigorously incompetent?

Posted by: Jan Stafford
James Bach, Software testing, software perils, Software consulting

What happens when a software development or test team’s manager preaches rigor in processes, but doesn’t make sure that team members do processes correctly? “Rigorous incompetence,” says veteran tester and author James Bach. In this video, shot at the recent Software Quality Engineering STARWEST Conference, he shares his views on managers who insist their teams look busy, but don’t ensure that they’re doing their jobs well.

---

Related Content
Testing rigorously, learning on your own: A chat with James Bach
Author and founder of Satisfice Inc., a software testing and quality assurance company, describes best practices in testing and learning.

James Bach interview: Dispelling software testing myths
The current drive for more rigorous software testing processes and more test documentation is misguided and wastes time and money, says James Bach, author and software testing veteran.

Oct 12 2009   2:24AM GMT

How software test teams’ people skills affect results

Posted by: Michael Kelly
Software testing, software testing teams, Karen Johnson

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.

Oct 8 2009   7:31PM GMT

Testing rigorously, learning on your own: A chat with James Bach

Posted by: Jan Stafford
Starwest, Software testing

My conversation with James Bach yesterday was certainly the high spot of my StarWest 2009 experience. We talked about topics dear to our hearts, such as critical thinking, self-education, wrong-headed notions about what constitutes good testing practices, Shakespeare and more.

Bach is author and founder of Satisfice Inc., a software testing and quality assurance company, but mostly he’s known as an articulate, passionate writer and speaker. His philosophy of testing is controversial, because he believes that what software testers know from experience and self-education is as valuable, if not more important, than certifications.

He knows, he told me, that certifications and degree help testers get jobs from strangers. Both “pieces of paper” serve as verification that the person has the skills needed for the job. Unfortunately, neither really verifies that the holder can think critically or creatively about what’s needed to do the job in various situations or work on a team.

That said, Bach is much more interested in personal fulfillment and the acquisition of real and not rote learning. He serves up his lifelong self-eduction journey in his new book, Secrets of a Buccaneer-Scholar. It’s taken years to write, he said, because he had to have experiences before he could write about them.

Besides self-education, Bach is currently on a quest to get test organizations to re-examine the concept of rigor in software testing. “Too often, they’re doing their testing rigorously, but they’re also doing their testing incorrectly,” he told me. Rigorously doing something wrongly compounds problems instead of solving them. He sees too many test managers equating success with the large number of tests run and defects found instead of effectiveness. You can read more of his views on test rigor in Mike Kelly’s interview with him, titled James Bach interview: Dispelling software testing myths

As I said, our conversation took off on many tangents, touching on our love for Kenneth Branaugh’s Shakespeare films and the cool things about testers, one of which is their curiosity. This experience was what actually going to conferences is all about, meeting people in person and talking about a little bit of everything.