• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

How Agile Testing work with QA Teams?

 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

 
Christopher Moura
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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?
 
author
Posts: 799
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Christopher Moura
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
@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
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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"
 
Ranch Hand
Posts: 43
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 43
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Lisa, great story - thanks for sharing it!
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic