This week's book giveaways are in the Java EE and JavaScript forums.
We're giving away four copies each of The Java EE 7 Tutorial Volume 1 or Volume 2(winners choice) and jQuery UI in Action and have the authors on-line!
See this thread and this one for details.
The moose likes Agile and Other Processes and the fly likes How Agile Testing work with QA Teams? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "How Agile Testing work with QA Teams?" Watch "How Agile Testing work with QA Teams?" New topic
Author

How Agile Testing work with QA Teams?

Christopher Moura
Greenhorn

Joined: Jul 30, 2005
Posts: 3
I've been working with TDD and BDD for a while and it has been great. I have a good test coverage and this practice integrate well with other practices such as Continuous Integration, Refactoring and Incremental Design among others and personally I can't see how a QA Team can improve my development process.
Wich kind of contribution (regarding tests) the QA Team will bring to my process?
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Your developer tests make sure that the system does what you think it does - so that you don't introduce bugs, can safely refactor etc. pp.

The role of testers in an Agile team typically is helping the customer to define tests that the make sure that the system actually does *what the customer wants/needs it to do*. Those tests form kind of an executable specification for the system.


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
Christopher Moura
Greenhorn

Joined: Jul 30, 2005
Posts: 3
Ilja Preuss wrote:... The role of testers in an Agile team typically is helping the customer to define tests that the make sure that the system actually does *what the customer wants/needs it to do*. Those tests form kind of an executable specification for the system.


I understand, but I create these kind of tests using BDD (Behavior Driven Development), which tests the behavior of the system and are part of the "executable specification" of the system...
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Christopher Palma wrote:
Ilja Preuss wrote:... The role of testers in an Agile team typically is helping the customer to define tests that the make sure that the system actually does *what the customer wants/needs it to do*. Those tests form kind of an executable specification for the system.


I understand, but I create these kind of tests using BDD (Behavior Driven Development), which tests the behavior of the system and are part of the "executable specification" of the system...


Can your customer read and understand those tests? How does he contribute to them?
Jeff Langr
author
Ranch Hand

Joined: May 14, 2003
Posts: 762
I think this is an interesting question if you are thinking about just the programmer's side of tests. There is some small amount of overlap that is going to exist--mostly at the "front edge" of the system, if you will. It's here where tests for the end-to-end functionality might be very similar to tests for session beans (for example). And there will also be overlap with respect to business rules which have to be built somewhere in domain classes (not one-to-one, necessarily).

I can imagine that in a good highly-collaborative environment, i.e. where we're all part of one team just working to get product out the door, a programmer might ask an agile tester to review such BDD tests. In some such environments where testers are capable, they might even pair with programmers to help them derive and implement the BDD tests.

Once you push further into a system, a good development team will have decomposed and distilled domain-level concepts into many more classes (particularly if you're pushing SRP) that a domain-focused tester wouldn't give a whit about--such as how to traverse a cursor or parse a configuration file entry. While these can be built using BDD, I can't imagine that testers would need to be involved with them.


Jeff


Books: Agile Java, Modern C++ Programming with TDD, Essential Java Style, Agile in a Flash. Contributor, Clean Code.
Christopher Moura
Greenhorn

Joined: Jul 30, 2005
Posts: 3
@Ilja Yes, my clients can read (and understand) my BDD tests cause they are almost plain sentences...

@Jeff I completely understand you point. The question is that my team doesn't have "fixed roles". My client is present (when possible) and work together with the designer, somethimes a programmer writes user stories, and so on. My team is not composed by functionally, but by quality...
We use BDD mostly to test "business behavior" and TDD to test everything else.

The question is that we always "Test First"... ;-)
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Christopher Moura wrote:@Ilja Yes, my clients can read (and understand) my BDD tests cause they are almost plain sentences...


Sounds to me like you are already "part of an integrated QA team"
Lisa Crispin
Ranch Hand

Joined: Feb 03, 2009
Posts: 43
Christopher Moura wrote:@Ilja Yes, my clients can read (and understand) my BDD tests cause they are almost plain sentences...

@Jeff I completely understand you point. The question is that my team doesn't have "fixed roles". My client is present (when possible) and work together with the designer, somethimes a programmer writes user stories, and so on. My team is not composed by functionally, but by quality...
We use BDD mostly to test "business behavior" and TDD to test everything else.

The question is that we always "Test First"... ;-)


Christopher,
Jeff and Ilja have already made some excellent points about how testers add value. If your team is delivering the right value to your customers, and you aren't having problems such as missed or misunderstood functionality, then you probably have all the expertise needed on your team. Every team is different. I recommend to teams that they use retrospectives to figure out any areas of pain and experiment with different ways to address them. It doesn't sound like you are feeling any pain in this area!

The programmers on my team are experts in our domain, but they are focused mostly on the technical implementation of a story. I've found that I often think of test cases they didn't think of, or ask questions they didn't think to ask. I also am more able to identify possible impacts on other parts of the system that are seemingly unrelated to the functionality being developed, because I have my hands in different parts of the app all the time.

Here's an example from a meeting today where our product owner was trying to explain a complex calculation. We were all confused and asking questions and he was trying to explain. Finally I asked if he would work through a real example on the whiteboard. Anyone could have asked that question, but only I did. I think it's just a tester mindset that some developers don't necessarily have.

My team could probably get along ok without testers. But it would mean that the programmers spend a lot more time eliciting examples and requirements from the customers, and thinking about them from multiple viewpoints. They don't mind doing other testing activities such as test automation or even manual testing, but they don't like to have to write up the high level requirements, examples and test cases for a story on the wiki.

I've been wanting to try BDD because I do think this would provide a lot of advantages, just as you have described. We use TDD but our tools are not so friendly to the customers. They often give us test cases in spreadsheets that we turn into FitNesse tests, but that is different than BDD.

Thanks for an interesting discussion! I'd love to watch your team at work.
-- Lisa


Co-author, with Janet Gregory: Agile Testing: A Practical Guide for Testers and Agile Teams (Addison-Wesley, 2009) http://lisacrispin.com
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Lisa Crispin wrote:
My team could probably get along ok without testers. But it would mean that the programmers spend a lot more time eliciting examples and requirements from the customers, and thinking about them from multiple viewpoints.


Mhh, somehow that sounds like a good thing to me... ;)
Lisa Crispin
Ranch Hand

Joined: Feb 03, 2009
Posts: 43
Ilja Preuss wrote:
Lisa Crispin wrote:
My team could probably get along ok without testers. But it would mean that the programmers spend a lot more time eliciting examples and requirements from the customers, and thinking about them from multiple viewpoints.


Mhh, somehow that sounds like a good thing to me... ;)


I have to give our programmers credit, they work hard to understand the business. Today we had a long meeting with our product owner to work out an algorithm to determine Internal Rate of Return for each retirement account. The PO had an incredibly complex calculation, taking into account things like interest on loan payments when participants take a loan from their retirement account, and interest from dividends paid to the mutual funds in which they are invested.

Did our programmers simply accept the PO's solution? No, they did not. We all questioned it and asked for specific examples to be worked on the whiteboard. The programmers proposed many alternatives - they understand the business and are able to do that. We questioned what the real purpose of the IRR was, and we felt that participants wanted to know how well they did at choosing the right mutual funds, so that shouldn't be altered if they took out a loan.

In the end, the programmers prevailed with a much simpler solution. As a tester, I didn't have a lot to do with that, other than having prompted the PO to work through some concrete examples to start with, and asking other questions about the true goal of the story.
-- Lisa
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Lisa, great story - thanks for sharing it!
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: How Agile Testing work with QA Teams?