Testing vs. agile manifesto?

[Mads jacobsen]

Hi
The agile Manifesto clearly states "Individuals and interactions over processes and tools" but usually testing is all about process and tools.
Does Agile Testing discuss this in any way?

Thanks in advance

Mads

[Ilja Preuss]

What do you mean by "usually testing is all about process and tools"? Does it have to be?

[Mads jacobsen]

I guess testing doesn't have to be about that, but i think there is a lot of examples of testing done with many many tools.
And Test Driven Development for instance, have a pre-defined process for your work, and this is considered to be very agile.

but i guess theres a big difference between automated test and non-automated here.
usually automated test will involve a lot of tools and frameworks.

[Ilja Preuss]

Of course tools and processes are important. The only thing the Manifesto states is that individuals and their interactions *are more* important. It's "over", not "instead of".

In particular, my take on it is that the tools and processes should *support* the individuals and their interactions (instead of the other way around, which too often is the case in non-Agile environments).

[Mads jacobsen]

in particular, my take on it is that the tools and processes should *support* the individuals and their interactions

my point excatly.

But often TDD is described as a methodology itself, ofcourse we can still conclude that if given the chance, individuals and their interactions should be more importent then the process itself.
Thats why i was a bit curious about whether a book on agile testing whould have something discussion about this, as i often see people new to TDD getting caugth up in the process and forgetting about everything else

[Jeff Langr]

Ilja Preuss wrote:In particular, my take on it is that the tools and processes should *support* the individuals and their interactions (instead of the other way around, which too often is the case in non-Agile environments).

Greetings Ilja,

Can you be more specific? Of course the tools and processes should support individuals and interactions, but I think a good question might be (and maybe what the OP was really asking), how specifically is testing an activity that is better focused around "individuals and interactions?"

Arguments to the contrary might include things like:

- good testing (and generation of tests) is highly methodical, particularly if you look to "automate everything" (a silly goal, see the other thread: https://coderanch.com/t/431531/Agile-Other-Processes/Role-Testing-Automation-tools-Agile#1916902), and thus in a sense subservient to "a process"
- manual testing work is usually decomposed so that individual testers go off and verify things on their own

Arguments to the positive might include things like:

- the tests should be a central form of negotiation and agreement, and thus agile testing becomes a highly collaborative activity--it is the centerpiece of definition of what specifically we will be building, after all.
- as such, testers must work closely with the dev team and each other, with the goal not to deal with "stuff thrown over the wall," but instead to work as a team to help deliver each piece of business value in turn, before moving onto the next

Regards,
Jeff

[Ilja Preuss]

Mads jacobsen wrote:
But often TDD is described as a methodology itself

Well, it certainly is a process. And as every process, it should only be used when it serves the people working on the project.

On the other hand, the only way to really know when it will serve you is to have followed it by the book for some time. Following a process by rote is an essential phase of learning that process. But even when following a process by rote, the reason to do that is because it serves the individual (in this case his learning process). See http://en.wikipedia.org/wiki/Shuhari

[Ilja Preuss]

Jeff Langr wrote:
Can you be more specific? Of course the tools and processes should support individuals and interactions, but I think a good question might be (and maybe what the OP was really asking), how specifically is testing an activity that is better focused around "individuals and interactions?"

A contrived example: In a project, the test manager sees that a specific tool, let's call it X, has improved tester's performance significantly. He thinks that it would make sense to use that same tool in other projects, too.

One way to do that would be to have the testing tool made mandatory in the companies' testing process. Another to organize a forum where testers can exchange their experiences with different tools and techniques and let each team decide for itself what to do with that information.

I have a hunch that one of those approaches would be "more Agile".

[Jeff Langr]

Ilja Preuss wrote:A contrived example: In a project, the test manager sees that a specific tool, let's call it X, has improved tester's performance significantly. He thinks that it would make sense to use that same tool in other projects, too.

One way to do that would be to have the testing tool made mandatory in the companies' testing process. Another to organize a forum where testers can exchange their experiences with different tools and techniques and let each team decide for itself what to do with that information.

Hi Ilja--

Ok, that's another one (to add to my couple above), although as you suggest narrow. I do think this is a valuable exercise. What else, in a day-to-day sense, changes the testing group to embrace "individuals and interactions" in favor of the tool/process?

Here's another one: replacing the tedious process of manually-executed scripts with tests that could be automated is all about a focus on the health of the individual.

And another: Freeing up time for exploratory testing (once we've automated what can be automated) is a move away from dependence on tools, and one that emphasizes the expertise that an experienced tester brings to the team.

I hope the book tackles some of this.

Jeff

[Ilja Preuss]

Jeff Langr wrote:
And another: Freeing up time for exploratory testing (once we've automated what can be automated) is a move away from dependence on tools, and one that emphasizes the expertise that an experienced tester brings to the team.

It is also a move away from having an individual simply execute a rote process (like a test script), to making use of his individual skills and creativity.

[Lisa Crispin]

Mads jacobsen wrote:Hi
The agile Manifesto clearly states "Individuals and interactions over processes and tools" but usually testing is all about process and tools.
Does Agile Testing discuss this in any way?

Thanks in advance

Mads

Hi Mads,
There are already some interesting responses to your question, but here's my two cents' worth.

I don't think I'd say that testing is all about process and tools. Maybe that's a more traditional view of testing. In our book, we emphasize that the whole development team needs to commit to delivering a high-quality product, and the whole team is responsible for ensuring that all necessary testing activities get done.

The first section on our book deals with "ten princples for an agile tester", which are taken directly from the principles behind the Agile Manifesto. The next section is on organizational challenges that affect testing, including culture, team logistics, and transitioning the traditional testing processes to an agile setting.

We have a large section of the book devoted to the Agile Testing Quadrants, which are Brian Marick's way to categorize the different types of testing needed on a project. While many different tools and processes could be applied to accomplish these tests, the main thing is to make sure you plan for doing these tests, know who will do them, when, whether a tool is needed, and so on.

Our seven key success factors in the last chapter aren't only about processes and tools. They're about the whole-team approach, the agile testing mind-set, collaborating with customers, looking at the big picture, providing and obtaining feedback. Of course, regression test automation and building a foundation of core agile practices will involve tools and process.

I hope that helps give an idea of our approach to agile testing.
-- Lisa