Hi Shelly I'm new to the Agile world as well, I took a "intro to Agile project
management" self study course and it helped to clarify a lot of the Methodology
that comes along with project management. Not to sure where you are located but
Agilepm.com might be a good place to start there are also webinars there if
locations are too far for you. hope it helped and good luck!

--- In agile-testing@yahoogroups.com, Shelly <shellyfld@...> wrote:
>
> Does anyone have any recommendations for finding an Agile coach?  Is there
> a list out there that has coaches broken up by region? I just joined a new
> organization that is trying to adopt Agile with Scrum and is struggling.
>  In particular, the mainframe development group is resistant, they're sure
> Agile is an object-oriented programming "thing" and it doesn't apply to
> them.  ;-)  We're hoping to find a coach in the southeast US.
>
> What is the usual timeframe between sprints?  On my last project (first
> exposure to Agile), we did 15 day iterations with two days of
> retrospective, planning, and catching up on general admin stuff between
> each one.  This organization is talking about taking a week to plan, but it
> seems to me that is too long?  Or is my experience skewed due to the
> intensity of my last project?
>
> Thanks,
> Shelly
>

Hi Karthikeyan,

I just found this group and in checking out messages yours caught my eye. One of
the teams I work with as Scrum Master works with Rails; prior to being full-time
SM I was the tech lead of this same team.

I definitely have some thoughts about your situation, and also some technical
suggestions you could bring to the developers. In Rails 3 there is simply no
reason to not test every application layer; it's just so fast and easy!

Let me know if you'd like more information and I'll put some more thoughts down.
Since this thread is almost a month old now I just didn't know if you're all set
with the (great) answers below :)

-kevin

--- In agile-testing@yahoogroups.com, karthikeyan M <gotukarthik@...> wrote:
>
> Hi George, 
>
> Apologies for the delayed reply, somehow this e-mail ended up in my spam
folder (Yahoo!!!!!). Your summary of my situation is correct. Users rely on the
QAs here to test the functionality and they only are concerned about the look
and feel of the app (Users are Artists and Art Dealers). 
>
> After my 3 days of working with the team what I have understood is when story
is being developed, the developers have a minimum UI required for it and during
the dedicated UI development phase what happens is mostly CSS changes - so I
would now be writing tests which would assume specific UI element names and for
dynamically generated elements, ask for a fixed pattern to be prefixed/suffixed
so my tests would run regardless of style changes (font size, color, location
etc.. is modified in the style changes) - these tests would be testing the
wiring up of UI and functionality. 
>
> There would be other set of tests which extensively tests the functionality
 without the UI by using the controllers (the piece which does the wiring up of
UI and functionality) directly.
>
> We haven't thought about using BDD will have to talk to my team about this.
Thanks for pointing it out. 
>  
> -
> Regards
> Karthikeyan
> twitter: @pragmaticqa blog:myblog 
>
>
> ________________________________
>  From: George Dinwiddie <lists@...>
> To: agile-testing@yahoogroups.com
> Sent: Thursday, 16 February 2012 12:55 PM
> Subject: Re: [agile-testing] What should be automated stories / user scenarios
>
>
>  
> Karthikeyen,
>
> Let me see if I've got this right:
> - Testers wait until the UI is finished to start testing.
> - Developers think that there is no point to testing before the UI is
> finished.
> - The users are very picky about the colors of the UI (but you don't
> say anything about them being concerned with the functionality)
> - You are concerned about functionality, and the risk created by not
> testing that functionality.
>
> Is that right?
>
> If so, I think you will always have this problem if you wait until after
> development to start testing. See
> http://blog.gdinwiddie.com/2010/02/16/the-testers-get-behind-at-the-end/
>
> You may also find
> http://manage.techwell.com/articles/weekly/three-amigos helpful.
>
> I think your idea of testing under the UI for the functionality is a
> good one. I suggest generally testing the business functionality at the
> lowest level possible.
>
> Having a few tests that go through the UI to verify things are wired
> properly is also helpful, in my experience. Using well defined names for
> UI elements, and expressing the tests in business terms instead of web
> element terms, makes these tests easier to maintain.
>
> When testing business functionality, it's important to express the tests
> in business terms. You might find
>
http://benmabey.com/2008/05/19/imperative-vs-declarative-scenarios-in-user-stori\
es.html
> helpful in this regard. The Cucumber Book also has some very good advice.
>
> - George
>
> On 2/16/12 1:15 AM, karthikeyan M wrote:
> >
> >
> >
> > Thanks for the inputs Ulrich, Yes the team has gone into a waterfall
> > mode because of a bottleneck with UI development and this being a ruby
> > on rails application, developers are of the opinion that testing before
> > the UI is available is not worthy and the QAs have to be re-working once
> > UI is in. I am not sure of this claim as I am new to ruby world as well
> > as new to this project hence a lot of study is still pending.
> >
> > To begin with I am exploring an option to create and run functional
> > tests without the UI to reduce the bottleneck with UI development.
> > Keeping my fingers crossed on how it would turn out.
> > -
> > Regards
> > Karthikeyan
> > twitter: @pragmaticqa blog:myblog <http://mkarthikeyan.com/blog>
> > ----------------------------------------------------------
> > *From:* Ulrich Freyer-Hirtz <u.f.h@...>
> > *To:* agile-testing@yahoogroups.com
> > *Sent:* Thursday, 16 February 2012 2:44 AM
> > *Subject:* Re: [agile-testing] What should be automated stories / user
> > scenarios
> >
> > Karthikeyan,
> >
> > your description sounds a little bit water-fallish... You should start
> > testing before development. Sounds difficult? Ok, consider, that testing
> > has some phases, too:
> > - identify a test, should be initially done as acceptance criteria
> > before the sprint starts
> > - define a test, means a kind of sketch of the steps and the expected
> > results.
> > - run manual or automate (and refine and expand the tests)
> > - document, yes, this should be done....
> >
> > Most phases you can start without having any code running! With good
> > practices it is possible to have the automated tests, even GUI tests,
> > ready with the application code. It's an iterative approach and needs
> > pairing of coder and tester. But that's the champions league....
> >
> > Your idea, to emphasize the tests "under" the GUI layer (hopefully there
> > is less business logic in the GUI..), is the best answer to your
> > problem. Tests without the GUI are fast, less complicated to automate
> > and will help you from the beginning. Try to establish test first here.
> >
> > hope that helps
> > ulrich
> >
> >  > -------- Original-Nachricht --------
> >  > Datum: Wed, 15 Feb 2012 19:03:20 +0000 (UTC)
> >  > Von: "gotukarthik@... <mailto:gotukarthik%40yahoo.com>"
> > <gotukarthik@... <mailto:gotukarthik%40yahoo.com>>
> >  > An: agile-testing@yahoogroups.com
> > <mailto:agile-testing%40yahoogroups.com>
> >  > Betreff: [agile-testing] What should be automated stories / user
> > scenarios
> >  >
> >  > Sent from Samsung Mobile
> >  >
> >  > -------- Original message --------Subject: [agile-testing] What
> > should be
> >  > automated stories / user scenarios From: karthikeyan M To:
> >  > agile-testing@yahoogroups.com
> > <mailto:agile-testing%40yahoogroups.com> CC:
> >  >
> >  > Hi,
> >  > I would like to gather some thoughts to decide on the approach for
> >  > automating a web application. Its currently in-dev and is in
> > Iteration 6.
> >  > There are some tests which have been automated already by the QAs on the
> >  > team and I am joining the team mid-way. The story life-cycle is In-Dev
> >  > -->
> >  > Ready for UI --> In UI Development and after UI is developed the story
> >  > comes to QAs. The app is UI Intensive (I should say the users are more
> >  > choosy about even the slightest color code and hence a specific
> >  > requirement
> >  > for a UX developer).
> >  > QAs so far have aimed to automate a story after it completes the UI
> >  > development and not before that. And I did not see any end to end
> >  > scenarios
> >  > being automated as well. Which means there is a risk that not all user
> >  > scenarios are tested. In this case I believe we should be moving the
> >  > functional tests to a layer below the UI (there is a services layer),
> >  > write
> >  > end to end scenario tests at the UI level and add a basic story level
> > test
> >  > as well. I would like to understand if my suggestion would work or not.
> >  > Suggestions / references would prove to be of help. -
> >  > Regards
> >  > Karthikeyan
> >  > twitter: @pragmaticqa blog:myblog
>
> --
> ----------------------------------------------------------
> * George Dinwiddie * http://blog.gdinwiddie.com
> Software Development http://www.idiacomputing.com
> Consultant and Coach http://www.agilemaryland.org
> ----------------------------------------------------------
>

We've got a new blog up for your perusal, which is about a question we get a
lot... what is the real difference between acceptance test-driven development,
and test-driven development itself?

http://www.sustainabletdd.com/2012/03/atdd-and-tdd.html

Let us know what you think!

-Scott (and Amir)-

 

We've got a new blog up for your perusal, which is about a question we get a lot... what is the real difference between acceptance test-driven development,
and test-driven development itself?

http://www.sustainabletdd.com/2012/03/atdd-and-tdd.html

Let us know what you think!

-Scott (and Amir)-

Absolutely. I work with 2 teams. 1 is using Rails and the other a mix of Java
backend and a Flex front end. I'll outline what they are both doing so you can
get an idea of the 2 approaches we're taking.

The team working in Rails has the benefit of Rails' incredible test support.
They also got to write their app from the ground up, full TDD. They've slipped
off this a bit in response to critical production issues, though they've always
been able (with the support of the awesome PO) to backfill the tests.

They have coverage at every layer of the app: routes, models, controllers, and
views, and even 3rd party API integration (these are *a lot* harder to pull off.

As far as tools used: rSpec is the core; it's used to write the model tests,
which since models hold the substantial bulk of business logic is where the most
tests are. Controller methods are also tested with rSpec using mocks and stubs.
Above that actual HTTP requests are generated into the app and the responses
tested. The group uses Capybara with Culerity to parse the generated HTML and
interact with the app. For functionality requiring JavaScript Capybara switches
to driving an instance of Google Chrome.

It all works very well technically, though it requires a tremendous amount of
discipline from the team and support from the PO (that whole pesky first line of
the Agile Manifesto at work :)

The java group on the other hand is working with a legacy app that they
inherited from other developers who are no longer with the organization.
Automated tests ranged from very limited to non-existent. They write jUnit tests
for their functional testing, and since they deploy a FLex UI they use a
combination of Cucumber and a Flex testing framework that I can't recall the
name of. They're still exploring ways to write their tests first. I've only been
working with that group for a couple months, so adoption is still pretty early.


I recently also finally got a Jenkins CI server up and running, which runs the
full set of tests on the Rails app. It does this both on a schedule at midnight
every day, and git also has a post-receive hook that is configured to trigger
Jenkins builds on the QA code branch. Code in this branch should only be
committed when all tests pass and it's ready for manual QA.


Which brings me to our final stage of testing: manual tests. The Rails team has
a full-time team member specializing in tests. The team and I have been actively
attempting to reduce the role barrier between dev and test (though that's
another whole huge topic). Anyhow, once a dev has committed passing code, he
coordinates with the tester to establish a window to push to the QA server, as
well as the functionality of the code in the push. We're working toward
involving the tester more in the design and test authoring phase so that she has
a better understanding when she starts testing exactly what's going on.

The java team is looking to gain a full-time test member; in the meantime our
head of QA is helping them by doing much of the same role as the Rails group.


OK, that is a lot of info; I hope it's not too overwhelming though we've been
taking this agile testing stuff very, very seriously :) Let me know if this was
helpful of just an overload of content. If there are questions that I didn't
answer please let me know; it's helpful for me to go through all this as well...

-kevin


We've recently brought a dedicated tester into the team; she's been able to
begin learning Capybara so she can help the developers write the test scaffold,
which they then flush out before writing the implementation code.

The other team I work with works with Java and uses Cucumber for their testing.
The test person working with that team has been doing amazing work identifying
not insubstantial holes in the test coverage prior to the tests being written.



--- In agile-testing@yahoogroups.com, karthikeyan M <gotukarthik@...> wrote:
>
> Hi Kevin,
>
> We are now proceeding to automate tests at the controller level (without the
UI) and also tests at the UI Layer. It would be great if you could let me know
your suggestions - I am curious to understand how you managed to implement the
same.
>  
> -
> Regards
> Karthikeyan
> twitter: @pragmaticqa 
>
>
> ________________________________
>  From: kevincallahancsp <kevmocal@...>
> To: agile-testing@yahoogroups.com
> Sent: Thursday, 8 March 2012 1:12 AM
> Subject: [agile-testing] Re: What should be automated stories / user scenarios
>
>
>  
> Hi Karthikeyan,
>
> I just found this group and in checking out messages yours caught my eye. One
of the teams I work with as Scrum Master works with Rails; prior to being
full-time SM I was the tech lead of this same team.
>
> I definitely have some thoughts about your situation, and also some technical
suggestions you could bring to the developers. In Rails 3 there is simply no
reason to not test every application layer; it's just so fast and easy!
>
> Let me know if you'd like more information and I'll put some more thoughts
down. Since this thread is almost a month old now I just didn't know if you're
all set with the (great) answers below :)
>
> -kevin
>
> --- In agile-testing@yahoogroups.com, karthikeyan M <gotukarthik@> wrote:
> >
> > Hi George, 
> >
> > Apologies for the delayed reply, somehow this e-mail ended up in my spam
folder (Yahoo!!!!!). Your summary of my situation is correct. Users rely on the
QAs here to test the functionality and they only are concerned about the look
and feel of the app (Users are Artists and Art Dealers). 
> >
> > After my 3 days of working with the team what I have understood is when
story is being developed, the developers have a minimum UI required for it and
during the dedicated UI development phase what happens is mostly CSS changes -
so I would now be writing tests which would assume specific UI element names and
for dynamically generated elements, ask for a fixed pattern to be
prefixed/suffixed so my tests would run regardless of style changes (font size,
color, location etc.. is modified in the style changes) - these tests would be
testing the wiring up of UI and functionality. 
> >
> > There would be other set of tests which extensively tests the functionality
 without the UI by using the controllers (the piece which does the wiring up
of UI and functionality) directly.
> >
> > We haven't thought about using BDD will have to talk to my team about this.
Thanks for pointing it out. 
> >  
> > -
> > Regards
> > Karthikeyan
> > twitter: @pragmaticqa blog:myblog 
> >
> >
> > ________________________________
> >  From: George Dinwiddie <lists@>
> > To: agile-testing@yahoogroups.com
> > Sent: Thursday, 16 February 2012 12:55 PM
> > Subject: Re: [agile-testing] What should be automated stories / user
scenarios
> >
> >
> >  
> > Karthikeyen,
> >
> > Let me see if I've got this right:
> > - Testers wait until the UI is finished to start testing.
> > - Developers think that there is no point to testing before the UI is
> > finished.
> > - The users are very picky about the colors of the UI (but you don't
> > say anything about them being concerned with the functionality)
> > - You are concerned about functionality, and the risk created by not
> > testing that functionality.
> >
> > Is that right?
> >
> > If so, I think you will always have this problem if you wait until after
> > development to start testing. See
> > http://blog.gdinwiddie.com/2010/02/16/the-testers-get-behind-at-the-end/
> >
> > You may also find
> > http://manage.techwell.com/articles/weekly/three-amigos helpful.
> >
> > I think your idea of testing under the UI for the functionality is a
> > good one. I suggest generally testing the business functionality at the
> > lowest level possible.
> >
> > Having a few tests that go through the UI to verify things are wired
> > properly is also helpful, in my experience. Using well defined names for
> > UI elements, and expressing the tests in business terms instead of web
> > element terms, makes these tests easier to maintain.
> >
> > When testing business functionality, it's important to express the tests
> > in business terms. You might find
> >
http://benmabey.com/2008/05/19/imperative-vs-declarative-scenarios-in-user-stori\
es.html
> > helpful in this regard. The Cucumber Book also has some very good advice.
> >
> > - George
> >
> > On 2/16/12 1:15 AM, karthikeyan M wrote:
> > >
> > >
> > >
> > > Thanks for the inputs Ulrich, Yes the team has gone into a waterfall
> > > mode because of a bottleneck with UI development and this being a ruby
> > > on rails application, developers are of the opinion that testing before
> > > the UI is available is not worthy and the QAs have to be re-working once
> > > UI is in. I am not sure of this claim as I am new to ruby world as well
> > > as new to this project hence a lot of study is still pending.
> > >
> > > To begin with I am exploring an option to create and run functional
> > > tests without the UI to reduce the bottleneck with UI development.
> > > Keeping my fingers crossed on how it would turn out.
> > > -
> > > Regards
> > > Karthikeyan
> > > twitter: @pragmaticqa blog:myblog <http://mkarthikeyan.com/blog>
> > > ----------------------------------------------------------
> > > *From:* Ulrich Freyer-Hirtz <u.f.h@>
> > > *To:* agile-testing@yahoogroups.com
> > > *Sent:* Thursday, 16 February 2012 2:44 AM
> > > *Subject:* Re: [agile-testing] What should be automated stories / user
> > > scenarios
> > >
> > > Karthikeyan,
> > >
> > > your description sounds a little bit water-fallish... You should start
> > > testing before development. Sounds difficult? Ok, consider, that testing
> > > has some phases, too:
> > > - identify a test, should be initially done as acceptance criteria
> > > before the sprint starts
> > > - define a test, means a kind of sketch of the steps and the expected
> > > results.
> > > - run manual or automate (and refine and expand the tests)
> > > - document, yes, this should be done....
> > >
> > > Most phases you can start without having any code running! With good
> > > practices it is possible to have the automated tests, even GUI tests,
> > > ready with the application code. It's an iterative approach and needs
> > > pairing of coder and tester. But that's the champions league....
> > >
> > > Your idea, to emphasize the tests "under" the GUI layer (hopefully there
> > > is less business logic in the GUI..), is the best answer to your
> > > problem. Tests without the GUI are fast, less complicated to automate
> > > and will help you from the beginning. Try to establish test first here.
> > >
> > > hope that helps
> > > ulrich
> > >
> > >  > -------- Original-Nachricht --------
> > >  > Datum: Wed, 15 Feb 2012 19:03:20 +0000 (UTC)
> > >  > Von: "gotukarthik@ <mailto:gotukarthik%40yahoo.com>"
> > > <gotukarthik@ <mailto:gotukarthik%40yahoo.com>>
> > >  > An: agile-testing@yahoogroups.com
> > > <mailto:agile-testing%40yahoogroups.com>
> > >  > Betreff: [agile-testing] What should be automated stories / user
> > > scenarios
> > >  >
> > >  > Sent from Samsung Mobile
> > >  >
> > >  > -------- Original message --------Subject: [agile-testing] What
> > > should be
> > >  > automated stories / user scenarios From: karthikeyan M To:
> > >  > agile-testing@yahoogroups.com
> > > <mailto:agile-testing%40yahoogroups.com> CC:
> > >  >
> > >  > Hi,
> > >  > I would like to gather some thoughts to decide on the approach for
> > >  > automating a web application. Its currently in-dev and is in
> > > Iteration 6.
> > >  > There are some tests which have been automated already by the QAs on
the
> > >  > team and I am joining the team mid-way. The story life-cycle is In-Dev
> > >  > -->
> > >  > Ready for UI --> In UI Development and after UI is developed the story
> > >  > comes to QAs. The app is UI Intensive (I should say the users are more
> > >  > choosy about even the slightest color code and hence a specific
> > >  > requirement
> > >  > for a UX developer).
> > >  > QAs so far have aimed to automate a story after it completes the UI
> > >  > development and not before that. And I did not see any end to end
> > >  > scenarios
> > >  > being automated as well. Which means there is a risk that not all user
> > >  > scenarios are tested. In this case I believe we should be moving the
> > >  > functional tests to a layer below the UI (there is a services layer),
> > >  > write
> > >  > end to end scenario tests at the UI level and add a basic story level
> > > test
> > >  > as well. I would like to understand if my suggestion would work or not.
> > >  > Suggestions / references would prove to be of help. -
> > >  > Regards
> > >  > Karthikeyan
> > >  > twitter: @pragmaticqa blog:myblog
> >
> > --
> > ----------------------------------------------------------
> > * George Dinwiddie * http://blog.gdinwiddie.com
> > Software Development http://www.idiacomputing.com
> > Consultant and Coach http://www.agilemaryland.org
> > ----------------------------------------------------------
> >
>

We are practicing Agile methodology in our project. I need to track my team
testing efforts. So please suggest my what all testing measurements i need to
consider to show the quality of the product.

Thanks & Regards,
Kish

 

The ultimate measure is the number and severity of defects in the working software delivered each iteration.  But, this is a metric for the whole team, not just the testers.

In order to minimize this metric over time and eventually reach near 0, it is not sufficient to just increase testing efforts or just develop with more skill or discipline (or just do even both).  It is essential to root cause the defects that are being delivered and work together to resolve those root causes.  In many cases, the root causes of defects will show the need to try to do things a bit differently instead of just doing them the same way only "better".

Over time, it will be impossible to do enough manual testing to maintain quality and velocity - ramping up automated testing is essential for long term success.  Nothing comes for free, so the team may have to commit to delivering a bit fewer stories for several iterations in order to increase quality and put into place the practices that will allow it to maintain that level of quality.

SteveG

On Sun, Mar 11, 2012 at 11:44 PM, kish_abb <kish_abb@...> wrote:

 

We are practicing Agile methodology in our project. I need to track my team testing efforts. So please suggest my what all testing measurements i need to consider to show the quality of the product.

Thanks & Regards,
Kish

--- In agile-testing@yahoogroups.com, Michael James <mj4scrum@...> wrote:
>
> Adding to what SteveG said, there isn't one "Agile methodology." In Scrum, the Product Owner should not consider any Product Backlog Item to be *done* unless it's properly tested. A team that is diligent about limiting work in progress (or doing "Kanban" perhaps) wouldn't start coding a new item until the previous one is proven to work properly. Building a properly tested product is the whole team's responsibility.
>
> --mj
>
>
> On Mar 12, 2012, at 11:00 AM, Steven Gordon sgordonphd@... wrote:
>
> > The ultimate measure is the number and severity of defects in the working software delivered each iteration. But, this is a metric for the whole team, not just the testers.
> >
> >
> > In order to minimize this metric over time and eventually reach near 0, it is not sufficient to just increase testing efforts or just develop with more skill or discipline (or just do even both). It is essential to root cause the defects that are being delivered and work together to resolve those root causes. In many cases, the root causes of defects will show the need to try to do things a bit differently instead of just doing them the same way only "better".
> >
> > Over time, it will be impossible to do enough manual testing to maintain quality and velocity - ramping up automated testing is essential for long term success. Nothing comes for free, so the team may have to commit to delivering a bit fewer stories for several iterations in order to increase quality and put into place the practices that will allow it to maintain that level of quality.
> >
> > SteveG
> >
> > On Sun, Mar 11, 2012 at 11:44 PM, kish_abb kish_abb@... wrote:
> >
> > We are practicing Agile methodology in our project. I need to track my team testing efforts. So please suggest my what all testing measurements i need to consider to show the quality of the product.
> >
> > Thanks & Regards,
> > Kish
> >
> >
> >
>

Hingesh,

you hit the nail :-) Combining it with the posts before, we have the complete
answer: keep in mind that these are testing metrics and testing is a whole team
approach. The testing tasks can be done by any team member, not only the
dedicated tester. So this measurements gives a hint for the quality of the teams
test process not for the quality of a single team member!

thanks
ulrich

@Adam: I really like your quote :-))

-------- Original-Nachricht --------
> Datum: Tue, 13 Mar 2012 05:13:08 +0530
> Von: Shailesh Hinge <hingesh@...>
> An: agile-testing@yahoogroups.com
> Betreff: Re: [agile-testing] Re: What are the measurements to consider while
tracking my testing in agile

> I would track the following
>
> Open Defects for the product - Should be close to 0
> unit test coverage - Should be close to 80 %
> Acceptance/ Regression test automation - Should be close to 80 %
> hrs of users playing with your product sprint over sprint - Should be more
> :)
> Manual hrs of testing needed to validate the product if we were to release
> today - gives a sense of what it takes to release.
>
> On Tue, Mar 13, 2012 at 2:40 AM, adam_peter.knight
> <adam.knight@...
> > wrote:
>
> > **
> >
> >
> > Hi,
> >
> > Elisabeth Hendrickson wrote a great post recently on what metrics you
> use
> > in Agile.
> >
> >
> >
>
http://testobsessed.com/blog/2012/02/23/question-from-the-mailbox-what-metrics-d\
o-you-use-in-agile/
> >
> >
> > I'd suggest starting with the excellent advice she gives. Look at why
> you
> > feel that you "need to track my team testing efforts." and limit
> yourself
> > to gathering information that helps to highlight status and improve
> future
> > efforts. Gathering information to judge work remaining in the sprint and
> > provide feedback to improve future estimates is one thing, collecting
> > information to measure individual performance is quite another. I'd
> suggest
> > heeding the advice from the above article, particularly my favourite
> quote
> > :-
> >
> > "The best way to screw up the usefulness of any process metric is to use
> > it to judge people"
> >
> > Adam.
> >
> > ----------------------------------------
> > http://a-sisyphean-task.com/
> > twitter: adampknight
> > ----------------------------------------
> >
> >
> > --- In agile-testing@yahoogroups.com, Michael James <mj4scrum@...>
> wrote:
> > >
> > > Adding to what SteveG said, there isn't one "Agile methodology." In
> > Scrum, the Product Owner should not consider any Product Backlog Item to
> be
> > *done* unless it's properly tested. A team that is diligent about
> limiting
> > work in progress (or doing "Kanban" perhaps) wouldn't start coding a new
> > item until the previous one is proven to work properly. Building a
> properly
> > tested product is the whole team's responsibility.
> > >
> > > --mj
> > >
> > >
> > > On Mar 12, 2012, at 11:00 AM, Steven Gordon sgordonphd@... wrote:
> > >
> > > > The ultimate measure is the number and severity of defects in the
> > working software delivered each iteration. But, this is a metric for the
> > whole team, not just the testers.
> > > >
> > > >
> > > > In order to minimize this metric over time and eventually reach near
> > 0, it is not sufficient to just increase testing efforts or just develop
> > with more skill or discipline (or just do even both). It is essential to
> > root cause the defects that are being delivered and work together to
> > resolve those root causes. In many cases, the root causes of defects
> will
> > show the need to try to do things a bit differently instead of just
> doing
> > them the same way only "better".
> > > >
> > > > Over time, it will be impossible to do enough manual testing to
> > maintain quality and velocity - ramping up automated testing is
> essential
> > for long term success. Nothing comes for free, so the team may have to
> > commit to delivering a bit fewer stories for several iterations in order
> to
> > increase quality and put into place the practices that will allow it to
> > maintain that level of quality.
> > > >
> > > > SteveG
> > > >
> > > > On Sun, Mar 11, 2012 at 11:44 PM, kish_abb kish_abb@... wrote:
> > > >
> > > > We are practicing Agile methodology in our project. I need to track
> my
> > team testing efforts. So please suggest my what all testing measurements
> i
> > need to consider to show the quality of the product.
> > > >
> > > > Thanks & Regards,
> > > > Kish
> > > >
> > > >
> > > >
> > >
> >
> >
> >

--
\//
@@  <<<<<<<<<<< u.f.h@...  >>>>>>>>>>>>
  ~
ulrich freyer-hirtz
engineer and musician

margarethenstr. 62
D-47198 duisburg
+49 (0) 2066 / 502848
+49 (0) 172 / 8356750
<<<<<<<<<<<<<<<<< U F H >>>>>>>>>>>>>>>>

NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!
Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a

Agilistas,

again wise words and a useful discussion on this list! Let me just add one
pragmatic distinction:
* TDD is an incremental development process. Designing the tests interacts with
developing the code, so (automated) TDD tests are placed in between the
development project
* ATDD focusses the users/business view, so the (automated) tests are placed
outside the development project. They communicate with the app only via official
interfaces (API, Web-Serivces, GUI) and never touches the application code.

cheers
ulrich

-------- Original-Nachricht --------
> Datum: Sat, 10 Mar 2012 14:48:23 +0330
> Von: Sam Serpoosh <ssjesus287@...>
> An: agile-testing@yahoogroups.com
> Betreff: Re: [agile-testing] ATDD and TDD

> Very interesting post, I recommended it to few friends. Most of the times
> people don't understand the real and actual difference between these two
> and also think that one of them is enough.
> Putting TDD as a requirement for developers was a new and interesting
> point
> of view which can solve a lot of problems in explaining this approach and
> show its importance even better.
>
> Well DONE ;)
>
> --
> Sam Serpoosh
> Software Developer: http://masihjesus.wordpress.com
> Twitter @masihjesus

--
\//
@@  <<<<<<<<<<< u.f.h@...  >>>>>>>>>>>>
  ~
ulrich freyer-hirtz
engineer and musician

margarethenstr. 62
D-47198 duisburg
+49 (0) 2066 / 502848
+49 (0) 172 / 8356750
<<<<<<<<<<<<<<<<< U F H >>>>>>>>>>>>>>>>

Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

Hi all,
yesterday i was in the office and tired of the long discussions onto which
gherkin/cucumber scenario we should implement and add in our CI system, I said
probably is the way we do BDD to be wrong...

After a short silence a QA manager and my line manager started to laugh saying
well we don't do BDD at all.

I'm wondering now if doing BDD means only write scenario, step definition, make
them fail and write code that get them green, or a raw form of BDD can even be
developing by having in the hands the gherkin scenario written previous as a
living documentation to be followed during the development???

Thanks for any reply, suggestion, Lorenzo (Developer in Test).

I would like to invite you to join and interact with Paul Gerrard (Principal of
Gerrard Consulting Limited) in an online event.

This webinar is a short introduction to the use of Business Stories in Software
Development so people can get a first approach to this method.

By attending this webinar, analysts, developpers and testers will be able to:
- Understand how stories can be used as a common language between analysts,
developers and testers
- write good Business Stories that capture accurate examples of a system in use
- find faults in requirements and create system and acceptance tests using the
Business Story Method

Schedule your agenda, come up with questions and hope to see you online!

http://bit.ly/BusinessStoryMethod
29th March 2012

Hi, Lorenzo

I'm not sure why you thought your team is "doing BDD wrong". Maybe you don't yet
have agreement about using BDD at all.

But you ask a good question, and I think the answer is "Yes". If you use BDD
techniques to create a conversation among stakeholders about what you expect the
system to do, and if you capture your mutual understanding using a small set of
key examples that describe the system doing things, and if you express each
example in the form of a test case (for example, using the Given/When/Then
pattern), then I believe you've gotten most of the benefit of BDD. Even if you
never actually implement any of those examples using Cucumber or similar tools!
Just building that shared knowledge is huge.

In fact, I think it's usually a big mistake to blindly automate all of your BDD
examples directly via Cucumber or similar tools. Better to automate all of the
unit and component tests that these examples imply. You'll find most of the same
defects earlier and faster, and you will get quicker feedback on whether your
examples are correct and complete. Given such tests, you will usually find that
the remaining tests you need at the full-system level are different from your
BDD examples. There may be more or fewer of them, depending on if you have a GUI
and how effectively you can isolate the GUI layer under test.

The naive approach to automated acceptance-test-driven development is a based on
a fantasy that product owners will write the tests themselves and that those
tests will be all the tests you need. They won't and they aren't.

Hi Everyone,

I want to tell you about The Art of Agile course in NYC April 23-27.  It's a
really unique course for Project Managers because you work in cross functional
teams, and use Agile to plan releasable features in 90 minute iterations. Pretty
intense but you learn a ton. If you can come together as a group and release
something that is releasable and has real value for stakeholders in 90 minutes,
you walk away with lessons you can apply in the real world when you have a week
or longer.

http://www.cyrusinnovation.com/index.php/art-of-agile-nyc

It's taught by the folks that literally wrote the book on this stuff - James
Shore, author of The Art of Agile Development and Diana Larsen, author of Agile
Retrospectives and Liftoff.

You learn how to help your team achieve predictable, productive velocity.  It's
the only course that I know of that forms cross functional teams and teaches
people how to plan at the iteration level, make commitments, and manage
technical debt.

Anyway, I think the course is a great value for any Project Manager looking to
take their Agile proficiency to the next level.  It's going to be a really
small, focused class so that you can get hands-on attention from Jim and Diana. 
If you think you and team can benefit from it, I'm happy to answer any questions
you have.

Best,
Marc

Hello Karapogosyan -

It would really help the audience here react to your post if they understood the
test strategy approach at Disney, your vision for the role, and the possibility
of relocation assistance.  (I think that info would benefit everybody, which I
why I am posting it on list)

regards,

--
Matthew Heusser,
Principal Consultant, Excelon Development
http://www.xndev.com


thank you!

--- In agile-testing@yahoogroups.com, "Karapogosyan, Anna"
<Anna.Karapogosyan@...> wrote:
>
> Hi All - The Walt Disney Parks & Resorts Online team in Glendale, CA is
looking for a two (2) Sr. QA Engineers.
>
> Please email me your resume if you are interested in hearing more about this
opportunity!
>
>
> Sincerely,
>
>
> Anna Karapogosyan
> Sr. Technical Recruiter
> The Walt Disney Company
> Direct Line - 818-549-4954
> [cid:image001.png@...]  8250-4954
> Anna.Karapogosyan@...<mailto:Anna.Karapgosyan@...>
>
> [cid:image002.png@...]
>

At 2:26 PM +0000 2012-03-28, Matthew wrote:
>Hello Karapogosyan -
>
>It would really help the audience here react to your post if they
>understood the test strategy approach at Disney, your vision for the
>role, and the possibility of relocation assistance.  (I think that
>info would benefit everybody, which I why I am posting it on list)

Are you suggesting that the post was Mickey Mouse?

Sorry, just had to respond.

Walter

ha!

Good one.  No worries.

--heusser

--- In agile-testing@yahoogroups.com, Walter Gorlitz <wgorlitz@...> wrote:
>
> At 2:26 PM +0000 2012-03-28, Matthew wrote:
> >Hello Karapogosyan -
> >
> >It would really help the audience here react to your post if they
> >understood the test strategy approach at Disney, your vision for the
> >role, and the possibility of relocation assistance.  (I think that
> >info would benefit everybody, which I why I am posting it on list)
>
> Are you suggesting that the post was Mickey Mouse?
>
> Sorry, just had to respond.
>
> Walter
>

• Adoption
• Agile Games
• Agile Mindset
• Architecture
• Automated Testing
• Coding Practices
• Continuous Delivery
• Craftsmanship
• Kanban
• Leadership
• Lean
• Lean Startup
• Operations and DevOps
• Quality
• Scrum
• XP
• Agile Beyond Software Development

Hi all,

If you are interested in Acceptance Test Driven Development (ATDD,
a.k.a. Specification by Example) in general, or using the process with
Robot Framework, please take a look at the demo project [1] created by
Janne Härkönen, Juha Rantanen and I. The project contains example test
cases as well as resulting reports and logs during different phases of
the project. You can also checkout the project source code, navigate
in the project history, and run tests yourself in different phases.

For more information about ATDD with Robot Framework you can see
introduction slides [2] and an excellent article by Bas Vodde and
Craig Larman [3].

[1] http://code.google.com/p/atdd-with-robot-framework
[2] http://www.slideshare.net/pekkaklarck/atdd-using-robot-framework
[3] http://a-tdd.org

Cheers,
    .peke
--
Agile Tester/Developer/Consultant :: http://eliga.fi
Lead Developer of Robot Framework :: http://robotframework.org