The Quality Assurance Mindset

Bruce Schneier has a new commentary at Wired, Inside the Twisted Mind of the Security Professional, in which he notes that “Security requires a particluar mindset”:

Security professionals — at least the good ones — see the world differently. They can’t walk into a store without noticing how they might shoplift. They can’t use a computer without wondering about the security vulnerabilities. They can’t vote without trying to figure out how to vote twice. They just can’t help it.

I would argue that the security mindset is a specialization of the QA mindset.
Bruce Schneier comments further:

I’ve often speculated about how much of this is innate, and how much is teachable. In general, I think it’s a particular way of looking at the world, and that it’s far easier to teach someone domain expertise — cryptography or software security or safecracking or document forgery — than it is to teach someone a security mindset.

My wife often calls me a natural-born QA engineer. In general, I take that as a compliment, which isn’t usually the way my wife intends it.

Automated GUI testing in agile

Recently, I’ve had several conversations at work about the cost/benefit analysis of performing automated GUI testing (in our case, using Borland SilkTest, of course) in our agile environment.
In general, automated GUI testing is most useful in the following situations: when the UI of the application under test (AUT) does not change much, and when there is significant regression testing to be done–where the time commitment of creating and maintaining automated tests is lower than the time commitment of repeating manual regression testing.
I’ve been working with an agile team that is in the first few sprints of a new product; this product’s UI is still changing frequently at this point and the product does not yet have much functionality for regression testing.
So, we have a resource allocation dilemma: this team would not benefit particularly from automated functional testing at this time. However, in, say, a year, when this product is more mature, automated UI tests would be very beneficial. But if we wait until then to start automating, we’ll never get caught up, so we need to start devoting steady effort to the automated testing soon.
In an agile environment, it’s difficult to get resource commitments for efforts that only have long-term results.
I’d love to hear whether others have faced this same dilemma and how you dealt with it.

Agile FUD: Frequent refactoring

This post is part of a series in which I address Bill Miller’s criticisms of agile. Please read the original post for context. In this post I take on his criticism of the role of documentation in the agile process.
Bill Miller says of refactoring:

The mantra in the Agile community is constantly refactor. This is a highly expensive approach, and in this age of globalization where costs drive decisions, it should be looked at with trepidation. This isn’t a wise approach, as market pressures to deliver quickly always constrain your latitude for refactoring.

Let’s look at one of the agile projects that I’m currently involved with.

Continue reading Agile FUD: Frequent refactoring

Agile FUD: Armchair quarterback

I recently ran across Bill Miller’s blog You Want IT When?. Bill has a lot of experience in managing software development, but in my opinion, he is way off the mark in his opinions on agile. Unfortunately, he makes a lot of claims that I’ve heard repeatedly from people who haven’t actually experienced agile or haven’t really understood its philosophical underpinnings.
Bill starts off by admitting that he’s only read about agile–which he clearly doesn’t see as a problem:

After reading many articles published by Agile proponents, I remain steadfast in my beliefs that something is wrong, and rather than advancing the state of the art practices in Software Development, Agile proponents are setting us back, and in this world where jobs easily cross international boarders, especially easy in software, we need practices that demonstrate the value proposition for keeping teams here in the US: practices that deliver reliably and predictibly [sic] on commitments and practices that can demonstrate improvements in productivity and quality.

In the next few posts, I’d like to address Bill’s criticms one by one.
UPDATE: Here are the follow-up entries that I’ve completed:

Is agile adoption leveling off?

There has been a big discussion the last few days in the Agile Testing Yahoo! group about this article from The Industry Standard: Agile progress report shows adoption has hit a wall.
I don’t buy the premise that agile adoption has peaked, but the article mentions some of the challenges that some organizations face when considering agile:

Some organizations, however, cannot adopt agile methods, Ambler said. “It’s simply because of their own organizational culture.” He said. “They have systemic challenges,” said Ambler.
…
“It’s a good way to do small projects, at least from my perspective,” said Rich Peters, senior software engineering manager at Braxton Technologies. “In our environment, we can’t use that technology because we have government requirements about how we do our development. But for internal projects, it would be fine.”
…
Ambler cited issues with agile. “One of the biggest problems right now in the agile community is we’ve gotten really good at developing siloed systems. That’s not useful,” he said.
Some challenges to agile development include entrenched processes, enterprise discipline, compliance requirements, team size, and application complexity.

I particularly loved this line:

Ambler also said research found a disparity in what developers and managers thought was happening with agile; 61 percent of developers thought they were doing agile development while 78 percent of management thought agile development was in use.

My adventures in agile software development

I started work at Borland in April, 2006. Around that time, the company had decided to convert the entire R&D organization to the agile/scrum methodology, and since I was working in a brand new division, it was a natural place to start.
Of course, Borland wanted the predictability, productivity and quality increases that come with agile, but Borland had an additional reason for adopting the agile process: Borland’s business is selling products and services for managing the software application lifecycle. Adopting agile was a case of eating our own dog food. We were charged with developing agile processes that served our own and our customers’ needs.
So far, the company considers the agile implementation a great success, and it has started converting other divisions to agile. Stay tuned to this space for more details on the lessons we’ve learned from our agile implementation.