*
The moose likes Agile and Other Processes and the fly likes Testing vs. agile manifesto? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Testing vs. agile manifesto?" Watch "Testing vs. agile manifesto?" New topic
Author

Testing vs. agile manifesto?

Mads jacobsen
Greenhorn

Joined: Nov 20, 2008
Posts: 7
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
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
What do you mean by "usually testing is all about process and tools"? Does it have to be?


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Mads jacobsen
Greenhorn

Joined: Nov 20, 2008
Posts: 7
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
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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
Greenhorn

Joined: Nov 20, 2008
Posts: 7
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
author
Ranch Hand

Joined: May 14, 2003
Posts: 762
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: http://www.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


Books: Agile Java, Modern C++ Programming with TDD, Essential Java Style, Agile in a Flash. Contributor, Clean Code.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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
author
Ranch Hand

Joined: May 14, 2003
Posts: 762
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
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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
Ranch Hand

Joined: Feb 03, 2009
Posts: 43
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


Co-author, with Janet Gregory: Agile Testing: A Practical Guide for Testers and Agile Teams (Addison-Wesley, 2009) http://lisacrispin.com
 
Consider Paul's rocket mass heater.
 
subject: Testing vs. agile manifesto?
 
Similar Threads
Role of Testing Automation tools in Agile Testing
* Welcome Lisa Crispin & Janet Gregory
Regarding Agile Testing, name some Automated Testing tools
Tool for agile
How-To form an Agile Team, when the knowledge bases is inhomogen?