Migrating traditional testers onto an agile team

[markpetronic]

I'm the SM for a new agile team in our company. This is the first team
doing agile in our company that I am aware of. In keeping with building
a cross-functional team, I am trying to now pull in someone from testing
to contribute. We have really just started and are in our third sprint
(about 2 months into the project). We already have a nightly build
engine basically working, are using JUnit and Emma for the Java part for
unit testing and coverage, and CxxTest on the C++ client side
development. We want to do CI and are trying to really do things right
from the onset because this project will be looked at from other side
this group and I want us to succeed and inspire a cultural change in the
company. The team is 6 developers at this point. The product is a client
(embedded C++) and server (Java on Linux) application with no real UI to
speak of. Think of an HTTP proxy web acceleration kind of thing. So, we
will need to have some significant end-to-end testing that I hope to
automate for performance, stability, compliance, soak testing.

Would like to hear from the community on ideas about how to transition a
tester who comes from the traditional process model with "big bang"
integration and testing at the end into an agile team. The tester would
probably not have many development skills but is a very good exploritory
tester (however, could become proficient at developing testing fixtures
in various scripting languages). I am already reading "Agile Testing"
and it's a good source of information from this perspective.

Thanks,
Mark

[Glenn Halstead-2]

Hi Mark,

I'm not a regular poster here (although I am a regular reader).

I'm a test automation guy (historically) and I'm currently working with the
dev teams on a project where we're trying to improve our early testing.

I think of my role as being there to help 'demonstrate, as soon as possible
after the software is created, that it does what it's intended to do.'

Making the tests automated and using continuous integration helps us to
demonstrate that the now existing software continues to do what its supposed
to do whilst allowing me to focus on new code rather than on manually
re-testing existing functionality.  It's a real challenge to keep existing
functionality working as new development continues.  The continuous
integration approach helps achieve this but the team has to 'care' when
passing tests start to fail (an area that we've found challenging).

This 'demonstrating that the software works' is in the first instance
demonstrating to myself and where the software doesn't work as intended,
demonstrating to the developers.  I feel that the 'demonstrating' mindset
helps in providing confidence to anyone who's interested in the status of
the software being developed.

I find that thinking and using the word 'demonstrate' rather than 'test'
helps the collaboration between testing and developers in our more
traditional organisation.  It feels more like I'm 'helping our team show
that we've got working software' rather than 'showing the dev guys that
their software doesn't work'.

Just a few thoughts from my own experience.  I hope it helps.

cheers

Glenn

2009/10/3 markpetronic <markpetronic@...>

>
>
> I'm the SM for a new agile team in our company. This is the first team
> doing agile in our company that I am aware of. In keeping with building
> a cross-functional team, I am trying to now pull in someone from testing
> to contribute. We have really just started and are in our third sprint
> (about 2 months into the project). We already have a nightly build
> engine basically working, are using JUnit and Emma for the Java part for
> unit testing and coverage, and CxxTest on the C++ client side
> development. We want to do CI and are trying to really do things right
> from the onset because this project will be looked at from other side
> this group and I want us to succeed and inspire a cultural change in the
> company. The team is 6 developers at this point. The product is a client
> (embedded C++) and server (Java on Linux) application with no real UI to
> speak of. Think of an HTTP proxy web acceleration kind of thing. So, we
> will need to have some significant end-to-end testing that I hope to
> automate for performance, stability, compliance, soak testing.
>
> Would like to hear from the community on ideas about how to transition a
> tester who comes from the traditional process model with "big bang"
> integration and testing at the end into an agile team. The tester would
> probably not have many development skills but is a very good exploritory
> tester (however, could become proficient at developing testing fixtures
> in various scripting languages). I am already reading "Agile Testing"
> and it's a good source of information from this perspective.
>
> Thanks,
> Mark
>
>  
>

[markpetronic]

Thanks for the reply, Glenn.
I would like to hear what your role looks like through the course of a
typical sprint. With developers doing TDD, the until tests are pretty
much done by each individual developer.
    * Do you spend time working to develop acceptance-level tests and
end-to-end tests?
    * Do you develop the test scripts or help in their development?
    * How do you interact with the developers as these are working on
completing stories?
    * Are you part of all sprint planning meetings, reviews, and stand
ups?
Guess I'm trying to determine to what extend the tester engaged from a
resource loading perspective. Adding a full time tester to the team for
a project that might run for 12 months will probably be met with
resistance by upper management when they would typically expect them to
maybe spend 6-8 weeks doing release testing at the end in the
traditional process. That's never really successful and is typically a
bug finding exercise. I expect they will want to see some proof of the
ROI there. But, on the other extreme, I'm finding it hard to see having
a full time tester for 12 months when developers should be doing a lot
of the testing themselves. And, at this time, there's no way I could
even get a full time tester. Being the first Agile project in the
company that is a grass roots driven project that I have instituted, you
know how management is, they want to see the proof before they commit.
So, I've been working with our test lead to discuss how I could use one
of her people part time to at least start to create a more
cross-functional team. I'm just short on details regarding the
day-to-day activities that this person would be responsible for with the
team.
Any thoughts here?
Mark
--- In agile-testing@..., Glenn Halstead <glenn@...> wrote:
>
> Hi Mark,
>
> I'm not a regular poster here (although I am a regular reader).
>
> I'm a test automation guy (historically) and I'm currently working
with the
> dev teams on a project where we're trying to improve our early
testing.
>
> I think of my role as being there to help 'demonstrate, as soon as
possible
> after the software is created, that it does what it's intended to do.'
>
> Making the tests automated and using continuous integration helps us
to
> demonstrate that the now existing software continues to do what its
supposed
> to do whilst allowing me to focus on new code rather than on manually
> re-testing existing functionality.  It's a real challenge to keep
existing
> functionality working as new development continues.  The continuous
> integration approach helps achieve this but the team has to 'care'
when
> passing tests start to fail (an area that we've found challenging).
>
> This 'demonstrating that the software works' is in the first instance
> demonstrating to myself and where the software doesn't work as
intended,
> demonstrating to the developers.  I feel that the 'demonstrating'
mindset
> helps in providing confidence to anyone who's interested in the status
of
> the software being developed.
>
> I find that thinking and using the word 'demonstrate' rather than
'test'
> helps the collaboration between testing and developers in our more
> traditional organisation.  It feels more like I'm 'helping our team
show
> that we've got working software' rather than 'showing the dev guys
that

> their software doesn't work'.
>
> Just a few thoughts from my own experience.  I hope it helps.
>
> cheers
>
> Glenn
>
> 2009/10/3 markpetronic markpetronic@...
>
> >
> >
> > I'm the SM for a new agile team in our company. This is the first

team
> > doing agile in our company that I am aware of. In keeping with
building
> > a cross-functional team, I am trying to now pull in someone from
testing
> > to contribute. We have really just started and are in our third
sprint
> > (about 2 months into the project). We already have a nightly build
> > engine basically working, are using JUnit and Emma for the Java part
for
> > unit testing and coverage, and CxxTest on the C++ client side
> > development. We want to do CI and are trying to really do things
right
> > from the onset because this project will be looked at from other
side
> > this group and I want us to succeed and inspire a cultural change in
the
> > company. The team is 6 developers at this point. The product is a
client
> > (embedded C++) and server (Java on Linux) application with no real
UI to
> > speak of. Think of an HTTP proxy web acceleration kind of thing. So,
we
> > will need to have some significant end-to-end testing that I hope to
> > automate for performance, stability, compliance, soak testing.
> >
> > Would like to hear from the community on ideas about how to
transition a
> > tester who comes from the traditional process model with "big bang"
> > integration and testing at the end into an agile team. The tester
would
> > probably not have many development skills but is a very good
exploritory
> > tester (however, could become proficient at developing testing
fixtures
> > in various scripting languages). I am already reading "Agile
Testing"
> > and it's a good source of information from this perspective.
> >
> > Thanks,
> > Mark
> >
> >
> >
>

[Steven Gordon-2]

On Sun, Oct 4, 2009 at 8:37 AM, markpetronic <markpetronic@...> wrote:

>
>
>
> Thanks for the reply, Glenn.
>
> I would like to hear what your role looks like through the course of a typical sprint. With developers doing TDD, the until tests are pretty much done by each individual developer.
>
> Do you spend time working to develop acceptance-level tests and end-to-end tests?
> Do you develop the test scripts or help in their development?
> How do you interact with the developers as these are working on completing stories?
> Are you part of all sprint planning meetings, reviews, and stand ups?

Ultimately, what you do should /not/ be driven by what testers do on
other teams, but instead by what your particular team is
needing/lacking. (Then, it might make sense to see how other teams
address these specific needs.)

What issues come up in your team's retrospectives?  Does it seem to
the team that somebody with experience as a traditional tester can
help the team address these issues?

If not, forcing a tester onto the team will probably not be very
effective yet.

If so, these issues drive what a tester should be doing.  Of course,
no matter what else a new team member will be doing to help the team,
they absolutely must participate in stand ups, customer collaboration,
retrospectives to be effective.

SteveG

....

> Any thoughts here?
> Mark

[Beaton, Malcolm-2]

Hi Mark

I actually did a presentation on this at Agile 2009 believe it or not. And I agree with Glenn - especially around the automation of tests - This will give your tester more time to explore the app and come up with crazy scenarios that the developers may or may not have thought about

There are a few things in your response that I'd like to discuss,
"when developers should be doing a lot of the testing themselves"
Assuming you are referring to the TDD practices they are following it might be worth reading some of Dan North's posts on BDD and about TDD itself, It is actually more of a design process than a testing process, It does give greater confidence in the code overall but it would be rare for a Unit test to pick up an error caused by a browser renderer or a fatal conflict with Outlook for example.

Following on from the other points (As a tester myself)


 *   Do you spend time working to develop acceptance-level tests and end-to-end tests?
Yes, A great deal of my time. I find helping the Product owner and the team define acceptance criteria before the sprint is estimated makes sprint planning quicker and easier and also gives the Dev team obvious delivery points to test as well as obvious automation points

 *   Do you develop the test scripts or help in their development?
I work with the clients acceptance tests that we have defined together, If you are referring to Automation I don't always work on these but I always have someone who is if it isn't me. I also work with the developers to help them come up with unit test scenarios for their unit tests, which also helps me in making sure boundary conditions and obvious common failure points are addressed

 *   How do you interact with the developers as these are working on completing stories?
We work together to get the story done - It is not a case of "They are completing stories" one of the most important roles a tester will have is the evaluation and re evaluation of your "Definition of done", If your definition of done is "Written and has some unit tests" would that be good enough to ship it or put it live? What if your product owner said "I don't want to see it - I trust you - If you met your definition of done then just go live!" would you be confident enough to that? Every single sprint? So for me it is a partnership - We work together to flush out the edge cases and the unobvious conflicts, I wouldn't expect them to catch every one any more than I would expect to catch every one but between us we catch more than either would

 *   Are you part of all sprint planning meetings, reviews, and stand ups?
I am (as I am sure glen is) a member of the team! Yes I am part of everything the team is
Which brings me back to one of the central points of the presentation we did - The tester doesn't work in a vacuum and the most agile tester will find it impossible to work effectively in an environment that wont enable them to, Forget the delineations between roles and push that your team as a whole needs a full skill set, How this is organised is up to you but any where you start doing things like (And I have seen all of these)


1)      A separate tester back log

2)      Testing a sprint behind the current sprint

3)      Saving all your bugs till the end

Your project will naturally de agaileise faster than you can say Prince 2.

Get a full time tester in to your project - Hire one if you need to and get them to help define the stories with acceptance criteria, Get them to challenge the developers on their definition of done, Get them to enforce the Shippable in "Potentially shippable and not the potentially, Get them to help the Product owner to think about the cross system impact of changes they ask for.

And if they do half of the things above I think you'll agree they will have been a valuable member of your team, no?

</rant>
Apologies - Is a subject very close to my heart!



From: agile-testing@... [mailto:agile-testing@...] On Behalf Of markpetronic
Sent: 04 October 2009 16:37
To: agile-testing@...
Subject: [agile-testing] Re: Migrating traditional testers onto an agile team



Thanks for the reply, Glenn.

I would like to hear what your role looks like through the course of a typical sprint. With developers doing TDD, the until tests are pretty much done by each individual developer.
Guess I'm trying to determine to what extend the tester engaged from a resource loading perspective. Adding a full time tester to the team for a project that might run for 12 months will probably be met with resistance by upper management when they would typically expect them to maybe spend 6-8 weeks doing release testing at the end in the traditional process. That's never really successful and is typically a bug finding exercise. I expect they will want to see some proof of the ROI there. But, on the other extreme, I'm finding it hard to see having a full time tester for 12 months when developers should be doing a lot of the testing themselves. And, at this time, there's no way I could even get a full time tester. Being the first Agile project in the company that is a grass roots driven project that I have instituted, you know how management is, they want to see the proof before they commit. So, I've been working with our test lead to discuss how I could use one of her people part time to at least start to create a more cross-functional team. I'm just short on details regarding the day-to-day activities that this person would be responsible for with the team.

Any thoughts here?

Mark

--- In agile-testing@..., Glenn Halstead <glenn@...> wrote:

>
> Hi Mark,
>
> I'm not a regular poster here (although I am a regular reader).
>
> I'm a test automation guy (historically) and I'm currently working with the
> dev teams on a project where we're trying to improve our early testing.
>
> I think of my role as being there to help 'demonstrate, as soon as possible
> after the software is created, that it does what it's intended to do.'
>
> Making the tests automated and using continuous integration helps us to
> demonstrate that the now existing software continues to do what its supposed
> to do whilst allowing me to focus on new code rather than on manually
> re-testing existing functionality. It's a real challenge to keep existing
> functionality working as new development continues. The continuous
> integration approach helps achieve this but the team has to 'care' when
> passing tests start to fail (an area that we've found challenging).
>
> This 'demonstrating that the software works' is in the first instance
> demonstrating to myself and where the software doesn't work as intended,
> demonstrating to the developers. I feel that the 'demonstrating' mindset
> helps in providing confidence to anyone who's interested in the status of
> the software being developed.
>
> I find that thinking and using the word 'demonstrate' rather than 'test'
> helps the collaboration between testing and developers in our more
> traditional organisation. It feels more like I'm 'helping our team show
> that we've got working software' rather than 'showing the dev guys that
> their software doesn't work'.
>
> Just a few thoughts from my own experience. I hope it helps.
>
> cheers
>
> Glenn
>
> 2009/10/3 markpetronic markpetronic@...
>
> >
> >
> > I'm the SM for a new agile team in our company. This is the first team
> > doing agile in our company that I am aware of. In keeping with building
> > a cross-functional team, I am trying to now pull in someone from testing
> > to contribute. We have really just started and are in our third sprint
> > (about 2 months into the project). We already have a nightly build
> > engine basically working, are using JUnit and Emma for the Java part for
> > unit testing and coverage, and CxxTest on the C++ client side
> > development. We want to do CI and are trying to really do things right
> > from the onset because this project will be looked at from other side
> > this group and I want us to succeed and inspire a cultural change in the
> > company. The team is 6 developers at this point. The product is a client
> > (embedded C++) and server (Java on Linux) application with no real UI to
> > speak of. Think of an HTTP proxy web acceleration kind of thing. So, we
> > will need to have some significant end-to-end testing that I hope to
> > automate for performance, stability, compliance, soak testing.
> >
> > Would like to hear from the community on ideas about how to transition a
> > tester who comes from the traditional process model with "big bang"
> > integration and testing at the end into an agile team. The tester would
> > probably not have many development skills but is a very good exploritory
> > tester (however, could become proficient at developing testing fixtures
> > in various scripting languages). I am already reading "Agile Testing"
> > and it's a good source of information from this perspective.
> >
> > Thanks,
> > Mark
> >
> >
> >
>

[Heather Tinkham]

Having worked as the "first" tester on several agile projects for clients, I
heartily second Steve's statement about participation in the stand ups,
customer collaboration, and retrospectives. I have also talked to several of
our clients who are trying to incorporate "traditional" testers in to agile
projects and have seen several key points of resistance, particularly where
the culture is to jump testers from project (product) to project just before
release time. Participation in the stand ups and collaboration meetings is
typically one of those points of resistance, but it really is important for
several reasons:
- it is essential to reaching a point where the tester is seen as a member
of the team, working *with* the rest of the team to produce the software as
opposed to just coming in to "evaluate" it after the fact
- generally there are so many fine points that the tester will need to know
that may not be in the documentation that they need to be around in order to
prevent long and frustrating repetitions of conversations already had to
work things out
- it gets very difficult to get the transparent and rapid feedback if you
expect them to do periodic big bang style testing

For one of our clients, we approached the transition by considering my role
to be an "embedded tester/developer" that complimented their existing QA
structure instead of trying to replace it. This allowed them to see the
"proof" by observing the differences in bug rates and types, smoothness of
releases, and reduced (traditional) "testing" time. I was full time on the
project, but I did multiple projects concurrently to satisfy the perception
that a FT person could not be justified. (That meant little end-to-end
automation and a LOT of exploratory testing, which is not at all optimal. It
was better than not having a testing presence at all, though. It was also
moving in the right direction and as big a change as they wanted to handle.)

I have a tech talk that I have done with one of our developers that covers
this in more detail. If anyone is interested, just let me know and I can
send you the slides.

-Heather

Heather E.C. Tinkham
Senior IT Consultant
Object Partners, Inc.
cell [phone]


On Mon, Oct 5, 2009 at 8:19 AM, Steven Gordon <sgordonphd@...> wrote:

> If so, these issues drive what a tester should be doing. Of course,
> no matter what else a new team member will be doing to help the team,
> they absolutely must participate in stand ups, customer collaboration,
> retrospectives to be effective.
>
> SteveG
>
> ....
>
> > Any thoughts here?
> > Mark
>  
>

[Prashant Chavan-3]

I completely agree with your all statements!!!!!!!!!!

In fact Testing should happen in this way!

Testers are the POLICE MEN and they should be free to catch the bugs in all the process and NOT just at the END

--Prashant


From: Beaton, Malcolm
Sent: Monday, October 05, 2009 7:55 PM
To: agile-testing@...
Subject: RE: [agile-testing] Re: Migrating traditional testers onto an agile team


 
Hi Mark



I actually did a presentation on this at Agile 2009 believe it or not. And I agree with Glenn - especially around the automation of tests - This will give your tester more time to explore the app and come up with crazy scenarios that the developers may or may not have thought about



There are a few things in your response that I'd like to discuss,

"when developers should be doing a lot of the testing themselves"

Assuming you are referring to the TDD practices they are following it might be worth reading some of Dan North's posts on BDD and about TDD itself, It is actually more of a design process than a testing process, It does give greater confidence in the code overall but it would be rare for a Unit test to pick up an error caused by a browser renderer or a fatal conflict with Outlook for example.



Following on from the other points (As a tester myself)



  a.. Do you spend time working to develop acceptance-level tests and end-to-end tests?  
Yes, A great deal of my time. I find helping the Product owner and the team define acceptance criteria before the sprint is estimated makes sprint planning quicker and easier and also gives the Dev team obvious delivery points to test as well as obvious automation points

  a.. Do you develop the test scripts or help in their development?
I work with the clients acceptance tests that we have defined together, If you are referring to Automation I don't always work on these but I always have someone who is if it isn't me. I also work with the developers to help them come up with unit test scenarios for their unit tests, which also helps me in making sure boundary conditions and obvious common failure points are addressed

  a.. How do you interact with the developers as these are working on completing stories?
We work together to get the story done - It is not a case of "They are completing stories" one of the most important roles a tester will have is the evaluation and re evaluation of your "Definition of done", If your definition of done is "Written and has some unit tests" would that be good enough to ship it or put it live? What if your product owner said "I don't want to see it - I trust you - If you met your definition of done then just go live!" would you be confident enough to that? Every single sprint? So for me it is a partnership - We work together to flush out the edge cases and the unobvious conflicts, I wouldn't expect them to catch every one any more than I would expect to catch every one but between us we catch more than either would

  a.. Are you part of all sprint planning meetings, reviews, and stand ups?
I am (as I am sure glen is) a member of the team! Yes I am part of everything the team is

Which brings me back to one of the central points of the presentation we did - The tester doesn't work in a vacuum and the most agile tester will find it impossible to work effectively in an environment that wont enable them to, Forget the delineations between roles and push that your team as a whole needs a full skill set, How this is organised is up to you but any where you start doing things like (And I have seen all of these)



1)      A separate tester back log

2)      Testing a sprint behind the current sprint

3)      Saving all your bugs till the end



Your project will naturally de agaileise faster than you can say Prince 2.



Get a full time tester in to your project - Hire one if you need to and get them to help define the stories with acceptance criteria, Get them to challenge the developers on their definition of done, Get them to enforce the Shippable in "Potentially shippable and not the potentially, Get them to help the Product owner to think about the cross system impact of changes they ask for.



And if they do half of the things above I think you'll agree they will have been a valuable member of your team, no?



</rant>

Apologies - Is a subject very close to my heart!







From: agile-testing@... [mailto:agile-testing@...] On Behalf Of markpetronic
Sent: 04 October 2009 16:37
To: agile-testing@...
Subject: [agile-testing] Re: Migrating traditional testers onto an agile team



 

Thanks for the reply, Glenn.



I would like to hear what your role looks like through the course of a typical sprint. With developers doing TDD, the until tests are pretty much done by each individual developer.

Guess I'm trying to determine to what extend the tester engaged from a resource loading perspective. Adding a full time tester to the team for a project that might run for 12 months will probably be met with resistance by upper management when they would typically expect them to maybe spend 6-8 weeks doing release testing at the end in the traditional process. That's never really successful and is typically a bug finding exercise. I expect they will want to see some proof of the ROI there. But, on the other extreme, I'm finding it hard to see having a full time tester for 12 months when developers should be doing a lot of the testing themselves. And, at this time, there's no way I could even get a full time tester. Being the first Agile project in the company that is a grass roots driven project that I have instituted, you know how management is, they want to see the proof before they commit. So, I've been working with our test lead to discuss how I could use one of her people part time to at least start to create a more cross-functional team. I'm just short on details regarding the day-to-day activities that this person would be responsible for with the team.



Any thoughts here?



Mark



--- In agile-testing@..., Glenn Halstead <glenn@...> wrote:

>
> Hi Mark,
>
> I'm not a regular poster here (although I am a regular reader).
>
> I'm a test automation guy (historically) and I'm currently working with the
> dev teams on a project where we're trying to improve our early testing.
>
> I think of my role as being there to help 'demonstrate, as soon as possible
> after the software is created, that it does what it's intended to do.'
>
> Making the tests automated and using continuous integration helps us to
> demonstrate that the now existing software continues to do what its supposed
> to do whilst allowing me to focus on new code rather than on manually
> re-testing existing functionality. It's a real challenge to keep existing
> functionality working as new development continues. The continuous
> integration approach helps achieve this but the team has to 'care' when
> passing tests start to fail (an area that we've found challenging).
>
> This 'demonstrating that the software works' is in the first instance
> demonstrating to myself and where the software doesn't work as intended,
> demonstrating to the developers. I feel that the 'demonstrating' mindset
> helps in providing confidence to anyone who's interested in the status of
> the software being developed.
>
> I find that thinking and using the word 'demonstrate' rather than 'test'
> helps the collaboration between testing and developers in our more
> traditional organisation. It feels more like I'm 'helping our team show
> that we've got working software' rather than 'showing the dev guys that
> their software doesn't work'.
>
> Just a few thoughts from my own experience. I hope it helps.
>
> cheers
>
> Glenn
>
> 2009/10/3 markpetronic markpetronic@...
>
> >
> >
> > I'm the SM for a new agile team in our company. This is the first team
> > doing agile in our company that I am aware of. In keeping with building
> > a cross-functional team, I am trying to now pull in someone from testing
> > to contribute. We have really just started and are in our third sprint
> > (about 2 months into the project). We already have a nightly build
> > engine basically working, are using JUnit and Emma for the Java part for
> > unit testing and coverage, and CxxTest on the C++ client side
> > development. We want to do CI and are trying to really do things right
> > from the onset because this project will be looked at from other side
> > this group and I want us to succeed and inspire a cultural change in the
> > company. The team is 6 developers at this point. The product is a client
> > (embedded C++) and server (Java on Linux) application with no real UI to
> > speak of. Think of an HTTP proxy web acceleration kind of thing. So, we
> > will need to have some significant end-to-end testing that I hope to
> > automate for performance, stability, compliance, soak testing.
> >
> > Would like to hear from the community on ideas about how to transition a
> > tester who comes from the traditional process model with "big bang"
> > integration and testing at the end into an agile team. The tester would
> > probably not have many development skills but is a very good exploritory
> > tester (however, could become proficient at developing testing fixtures
> > in various scripting languages). I am already reading "Agile Testing"
> > and it's a good source of information from this perspective.
> >
> > Thanks,
> > Mark
> >
> >
> >
>

 

[Steven Gordon-2]

On an agile team, /everybody/, not just the testers, should be free to catch
bugs in the process, the design, the tests, and the software.  Everybody is
responsible for what the whole teams does.

Testers just bring some experience and skills that are complementary to
those of other team members, but should have no different responsibility for
quality as anybody else on the team.

SteveG

On Mon, Oct 5, 2009 at 10:41 AM, Prashant Chavan
<prashantraoji@...>wrote:

>
>
> I completely agree with your all statements!!!!!!!!!!
>
> In fact Testing should happen in this way!
>
> Testers are the POLICE MEN and they should be free to catch the bugs in all
> the process and NOT just at the END [image: Smile emoticon]
>
> --Prashant
>
>  *From:* Beaton, Malcolm <malcolm.beaton@...>
> *Sent:* Monday, October 05, 2009 7:55 PM
> *To:* agile-testing@...
> *Subject:* RE: [agile-testing] Re: Migrating traditional testers onto an
> agile team
>
>
>
>  Hi Mark
>
> I actually did a presentation on this at Agile 2009 believe it or not. And
> I agree with Glenn – especially around the automation of tests – This will
> give your tester more time to explore the app and come up with crazy
> scenarios that the developers may or may not have thought about
>
> There are a few things in your response that I’d like to discuss,
>
> “when developers should be doing a lot of the testing themselves”
>
> Assuming you are referring to the TDD practices they are following it might
> be worth reading some of Dan North’s posts on BDD and about TDD itself, It
> is actually more of a design process than a testing process, It does give
> greater confidence in the code overall but it would be rare for a Unit test
> to pick up an error caused by a browser renderer or a fatal conflict with
> Outlook for example.
>
> Following on from the other points (As a tester myself)
>
>
>    - Do you spend time working to develop acceptance-level tests and
>    end-to-end tests?
>
> Yes, A great deal of my time. I find helping the Product owner and the team
> define acceptance criteria before the sprint is estimated makes sprint
> planning quicker and easier and also gives the Dev team obvious delivery
> points to test as well as obvious automation points
>
>    - Do you develop the test scripts or help in their development?
>
> I work with the clients acceptance tests that we have defined together, If
> you are referring to Automation I don’t always work on these but I always
> have someone who is if it isn’t me. I also work with the developers to help
> them come up with unit test scenarios for their unit tests, which also helps
> me in making sure boundary conditions and obvious common failure points are
> addressed
>
>    - How do you interact with the developers as these are working on
>    completing stories?
>
> We work together to get the story done – It is not a case of “They are
> completing stories” one of the most important roles a tester will have is
> the evaluation and re evaluation of your “Definition of done”, If your
> definition of done is “Written and has some unit tests” would that be good
> enough to ship it or put it live? What if your product owner said “I don’t
> want to see it – I trust you – If you met your definition of done then just
> go live!” would you be confident enough to that? Every single sprint? So for
> me it is a partnership – We work together to flush out the edge cases and
> the unobvious conflicts, I wouldn’t expect them to catch every one any more
> than I would expect to catch every one but between us we catch more than
> either would
>
>    - Are you part of all sprint planning meetings, reviews, and stand ups?
>
>
> I am (as I am sure glen is) a member of the team! Yes I am part of
> everything the team is
>
> Which brings me back to one of the central points of the presentation we
> did – The tester doesn’t work in a vacuum and the most agile tester will
> find it impossible to work effectively in an environment that wont enable
> them to, Forget the delineations between roles and push that your team as a
> whole needs a full skill set, How this is organised is up to you but any
> where you start doing things like (And I have seen all of these)
>
> 1)      A separate tester back log
>
> 2)      Testing a sprint behind the current sprint
>
> 3)      Saving all your bugs till the end
>
> Your project will naturally de agaileise faster than you can say Prince 2.
>
> Get a full time tester in to your project – Hire one if you need to and get
> them to help define the stories with acceptance criteria, Get them to
> challenge the developers on their definition of done, Get them to enforce
> the Shippable in “Potentially shippable and not the potentially, Get them to
> help the Product owner to think about the cross system impact of changes
> they ask for.
>
> And if they do half of the things above I think you’ll agree they will have
> been a valuable member of your team, no?
>
> </rant>
>
> Apologies – Is a subject very close to my heart!
>
>   *From:* agile-testing@... [mailto:
> agile-testing@...] *On Behalf Of *markpetronic
> *Sent:* 04 October 2009 16:37
> *To:* agile-testing@...
> *Subject:* [agile-testing] Re: Migrating traditional testers onto an agile
> team
>
>
>
> Thanks for the reply, Glenn.
>
>  I would like to hear what your role looks like through the course of a
> typical sprint. With developers doing TDD, the until tests are pretty much
> done by each individual developer.
>
> Guess I'm trying to determine to what extend the tester engaged from a
> resource loading perspective. Adding a full time tester to the team for a
> project that might run for 12 months will probably be met with resistance by
> upper management when they would typically expect them to maybe spend 6-8
> weeks doing release testing at the end in the traditional process. That's
> never really successful and is typically a bug finding exercise. I expect
> they will want to see some proof of the ROI there. But, on the other
> extreme, I'm finding it hard to see having a full time tester for 12 months
> when developers should be doing a lot of the testing themselves. And, at
> this time, there's no way I could even get a full time tester. Being the
> first Agile project in the company that is a grass roots driven project that
> I have instituted, you know how management is, they want to see the proof
> before they commit. So, I've been working with our test lead to discuss how
> I could use one of her people part time to at least start to create a more
> cross-functional team. I'm just short on details regarding the day-to-day
> activities that this person would be responsible for with the team.
>
>  Any thoughts here?
>
>  Mark
>
> --- In agile-testing@..., Glenn Halstead <glenn@...> wrote:
> >
> > Hi Mark,
> >
> > I'm not a regular poster here (although I am a regular reader).
> >
> > I'm a test automation guy (historically) and I'm currently working with
> the
> > dev teams on a project where we're trying to improve our early testing.
> >
> > I think of my role as being there to help 'demonstrate, as soon as
> possible
> > after the software is created, that it does what it's intended to do.'
> >
> > Making the tests automated and using continuous integration helps us to
> > demonstrate that the now existing software continues to do what its
> supposed
> > to do whilst allowing me to focus on new code rather than on manually
> > re-testing existing functionality. It's a real challenge to keep existing
> > functionality working as new development continues. The continuous
> > integration approach helps achieve this but the team has to 'care' when
> > passing tests start to fail (an area that we've found challenging).
> >
> > This 'demonstrating that the software works' is in the first instance
> > demonstrating to myself and where the software doesn't work as intended,
> > demonstrating to the developers. I feel that the 'demonstrating' mindset
> > helps in providing confidence to anyone who's interested in the status of
> > the software being developed.
> >
> > I find that thinking and using the word 'demonstrate' rather than 'test'
> > helps the collaboration between testing and developers in our more
> > traditional organisation. It feels more like I'm 'helping our team show
> > that we've got working software' rather than 'showing the dev guys that
> > their software doesn't work'.
> >
> > Just a few thoughts from my own experience. I hope it helps.
> >
> > cheers
> >
> > Glenn
> >
> > 2009/10/3 markpetronic markpetronic@...
> >
> > >
> > >
> > > I'm the SM for a new agile team in our company. This is the first team
> > > doing agile in our company that I am aware of. In keeping with building
> > > a cross-functional team, I am trying to now pull in someone from
> testing
> > > to contribute. We have really just started and are in our third sprint
> > > (about 2 months into the project). We already have a nightly build
> > > engine basically working, are using JUnit and Emma for the Java part
> for
> > > unit testing and coverage, and CxxTest on the C++ client side
> > > development. We want to do CI and are trying to really do things right
> > > from the onset because this project will be looked at from other side
> > > this group and I want us to succeed and inspire a cultural change in
> the
> > > company. The team is 6 developers at this point. The product is a
> client
> > > (embedded C++) and server (Java on Linux) application with no real UI
> to
> > > speak of. Think of an HTTP proxy web acceleration kind of thing. So, we
> > > will need to have some significant end-to-end testing that I hope to
> > > automate for performance, stability, compliance, soak testing.
> > >
> > > Would like to hear from the community on ideas about how to transition
> a
> > > tester who comes from the traditional process model with "big bang"
> > > integration and testing at the end into an agile team. The tester would
> > > probably not have many development skills but is a very good
> exploritory
> > > tester (however, could become proficient at developing testing fixtures
> > > in various scripting languages). I am already reading "Agile Testing"
> > > and it's a good source of information from this perspective.
> > >
> > > Thanks,
> > > Mark
> > >
> > >
> > >
> >
>
>  
>

 

[Glenn Halstead-2]

Hi Mark,

I've answered some of your questions below.  I completely agree with some of
the other posters that what we do in our world (I hesitate to say 'what
works for us' because we're still trying to get there) may not be applicable
to yours.

    Thanks for the reply, Glenn.

    I would like to hear what your role looks like through the course of a
typical sprint. With developers doing TDD, the until tests are pretty much
done by each individual developer.

        * Do you spend time working to develop acceptance-level tests and
end-to-end tests?
My focus is on testing soa services.  My tests incorporate the esb,
(enterprise service mus, IBM MQ), and often multiple backend applications,
whereas the developers tests do not test through the esb and do not interact
with other backend apps.

        * Do you develop the test scripts or help in their development?
I do develop the test scripts. Where I run into problems developing the
tests I interact with the developers to determine correct usage of the
service operations or to confirm that the behaviour I'm seeing is
incorrect.  I'll often drag one of our other testser in where they've got
more experience in a particular area or just to get 2 heads on a problem.

        * How do you interact with the developers as these are working on
completing stories?
When development of a service operation is completed the devs release it
into our development integration environment and let me know it's available
to test.  Sometimes I need to wait for the esb guys to expose the service
before I can get at it.  These service operations have not yet been released
to our customer, the portal development team.  Its fairly easy to get the
developers attention at this stage as the dev work is only just been
completed.  At this time they seem to be quite keen to answer questions and
look into unexpected behaviour.  (We've only been working this way (testers
with the services dev team) for a few weeks.  Previously we weren't testing
the services until after they'd formally released.  When working this way I
found it much more difficult to get the developers attention and interest in
my testing as they were busy developing the next iteration.)

        * Are you part of all sprint planning meetings, reviews, and stand
ups?
As yet I'm not in the sprint planning meetings.  I was invited to the most
recent one but didn't attend because we had some specific panics on that
day.  I am at the stand-ups and do a good bit of the talking; what tests are
failing that were previously passing (my pet focus), what's blocking test
development & execution, etc.

    Guess I'm trying to determine to what extend the tester engaged from a
resource loading perspective. Adding a full time tester to the team for a
project that might run for 12 months will probably be met with resistance by
upper management when they would typically expect them to maybe spend 6-8
weeks doing release testing at the end in the traditional process. That's
never really successful and is typically a bug finding exercise. I expect
they will want to see some proof of the ROI there. But, on the other
extreme, I'm finding it hard to see having a full time tester for 12 months
when developers should be doing a lot of the testing themselves. And, at
this time, there's no way I could even get a full time tester. Being the
first Agile project in the company that is a grass roots driven project that
I have instituted, you know how management is, they want to see the proof
before they commit. So, I've been working with our test lead to discuss how
I could use one of her people part time to at least start to create a more
cross-functional team. I'm just short on details regarding the day-to-day
activities that this person would be responsible for with the team.

Tester resource: Where I use 'I' above, there are 4 of us full time doing
this.  There are 5 different backend services teams and an esb team
producing services.  We're playing catchup at the moment.  As I mentioned,
we're only been working this way a few weeks.

If there is a full time dev team why would there not be a full time tester?
As you say, the drive for this would be  dissatisfaction with how things are
currently working.  There's clearly a desire to improve you're current dev
process and putting a tester in there could help.  Who that tester is is of
major importance (in my opinion).  They need to have a vision of how things
should be / could be and the drive and tenacity to get there.  They need to
be able to change that vision as they go along, learning with the dev team
and they need to be part of the dev team, part of the creation of the
software.

There's a clear gap in my world between the testing I do and the testing the
devs do.  Integration... thats the big difference.  I test all the
components (sub systems) together  The devs test their components in
isolation.  I find things they don't and could not with theyre testing.



Regarding what a day for a dev tester might be like, I've sumarised my day
today  it's been a fairly typical day.  No doubt I've left out things but
thats not important.


A brief summary of my day (today)...

- Arrive @ work around 8am.  Look at the hourly smoke test run on the
radiator display.  The screen shows the hudson junit results for my smoke
test pack (I use junit format to leverage hudsons built in reporting).  The
test job is still running, it was kcicked off at 7am.  It should be
finished.  I suspect theres a major issue in the environment causing the
test pack to take a long time because tests are waiting for the time out
when no response message is received from ESB.  I run a single test from my
pc that touches a couple of the main env components.  One of them is not
responding.  I email the dev lead for that component and the env manager
They won't be in till around 9am.  I leave the test pack running as I should
see a fail spike in my results graph in the radiator when the test run is
complete.

- I take a look at the test of a new service operation I was trying to get
working on Friday.  The app is not responding as I expect.  I raised this
with the dev guy on Friday, he couldn't see a problem but it's an area of
the code that he reused so hes not 100% familiar with it.  I'd begun to
suspect that maybe some of the prior data prep in my test is not right.  I
work with one of the other testers on this and we figure out how we should
be prepping the data.  We've both learned a bit about how one of the other
service operations should be used.  I let the dev guy know there's nothing
wrong with the app in this area and I ask him about the two othere area's
that seem to be wrong that he's having a look at.  He's planning to release
a fix today, he'll shout when I can retry my test (he didn't shout by the
way... note for tomorrow).  I finish the current test and create one for the
the last operation of this service.  I commit the new tests and label them
to be included in our smoke test job.

- We're using a fitnesse based service test framework based on service
fixture, jaxb, automatically generated java code (generated based on the
wsdls) and lots of other javaery stuff I only partially understand.

- I have a 'sit around our desks meeting' with the other 3 test devs on the
team.  I sit beside one of them in the esb dev team area, the other 2 sit
across the corridor in the test area.  We have a brief chat about major
blockers / failure causers.  There are 4 main faults causing our 20 or so
test failures (out for th 100 or so tests in the smoke pack).  We cover what
we're gonna be doing today.  The purpose of this chat is to focus on the
info we want to provide and the questions we want to ask at the stand up.
We limit the meeting to 30 mins.

- I pull out the per operation test results from our test run... by the way
the earlier env problem is resolved.  the test pack has run again and the
radiator shows a big red spike where all the tests (~30 out of 100) affected
by that component failed and now pass again.  I update our per service
operation test status spreadsheet with the results from the lates test run.
A manual process but fairly trivial now, it's gradually become less and less
effort over the last 2 weeks as I've improved our test results parser and
summariser script.  This is all about providing information that answers the
questions people ask us.  "Do you have a test for this operation?", "How
many oerations pass / fail / aren't tested?", "Why are those not tested?",
etc.

- There's no dev standup today.  This seems to be a Monday pattern because
some of the contract devs haven't arrived yet.  The dev manager and one of
the app dev leads stop by for a status update.  The dev guys want's to know
if there's anything we need his help with.  the dev guys are about to embark
on the next iteration and we still have failing tests and incomplete tests.
He's keen to get things in as good shape as possible before firing into the
next iteration.  I share a couple of issues and questions and get a couple
of pointers re. things I'm investigating.

- Blimey it's lunch time already....

_ The delivery manager stops to look at our radiator with one of the other
managers.  I pipe up about the big red spike and have a chat about the
trends... number of tests increasing, number of failed tests decreasing,
this is good, we're making progress.  This is good news but remember this is
only smoke tests though, there's a lot to do.  We chat about the broader
coverage test packs and the gui tests that one of the other testers is
heading up.  We chat about the Continuous Integration build that's being
worked on to build a test environment from scratch and what tests will be
included.  All of them is the conclusion, passes AND fails.

- I meet with the build engineer / env guy who's doing the donkey work of
pulling together the environment build soluton with components from all
teams.  How are our tests going to plug into this.  We agree a few first
steps and there's some action on me to complete so we can move along on
this.

- I need to build a new service model jar for the CI environment based on
the latest dev versions of the wsdls.  In future the jar will be environment
independant but this will get us up and running.  While this is building I
start work on the next of the new services that don't have tests yet.

- Our dev integration environment is down as a deployment is running  I
can't progress my test development  The new jar build is finished so I try
running a test in the CI env to check it.  It doesn't work either.  I
suspect that env is not working, either that or I cocked it up.

- Blimey its 5pm already  the env is still down, my tester buddy, desk
neighour and care sharer suggests we call it a day.  We head off home.  I
annoy hiim with chat about testing, ruby and my new android phone during the
journey.. more tomorrow, wahey.


I hope sharing this is of some interest / help but again I emphasise my
agreement with others that this is very specific my my world and may well be
completely irrelevant to yours.

I hope you're successful

Glenn




    Any thoughts here?

    Mark

2009/10/4 markpetronic <markpetronic@...>

>
>
> Thanks for the reply, Glenn.
>
> I would like to hear what your role looks like through the course of a
> typical sprint. With developers doing TDD, the until tests are pretty much
> done by each individual developer.
>

>
>    - Do you spend time working to develop acceptance-level tests and
>    end-to-end tests?
>    - Do you develop the test scripts or help in their development?
>    - How do you interact with the developers as these are working on
>    completing stories?
>    - Are you part of all sprint planning meetings, reviews, and stand ups?
>
> Guess I'm trying to determine to what extend the tester engaged from a
> resource loading perspective. Adding a full time tester to the team for a
> project that might run for 12 months will probably be met with resistance by
> upper management when they would typically expect them to maybe spend 6-8
> weeks doing release testing at the end in the traditional process. That's
> never really successful and is typically a bug finding exercise. I expect
> they will want to see some proof of the ROI there. But, on the other
> extreme, I'm finding it hard to see having a full time tester for 12 months
> when developers should be doing a lot of the testing themselves. And, at
> this time, there's no way I could even get a full time tester. Being the
> first Agile project in the company that is a grass roots driven project that
> I have instituted, you know how management is, they want to see the proof
> before they commit. So, I've been working with our test lead to discuss how
> I could use one of her people part time to at least start to create a more
> cross-functional team. I'm just short on details regarding the day-to-day
> activities that this person would be responsible for with the team.
>
> Any thoughts here?
>
> Mark
>
> --- In agile-testing@..., Glenn Halstead <glenn@...> wrote:
> >
> > Hi Mark,
> >
> > I'm not a regular poster here (although I am a regular reader).
> >
> > I'm a test automation guy (historically) and I'm currently working with
> the
> > dev teams on a project where we're trying to improve our early testing.
> >
> > I think of my role as being there to help 'demonstrate, as soon as
> possible
> > after the software is created, that it does what it's intended to do.'
> >
> > Making the tests automated and using continuous integration helps us to
> > demonstrate that the now existing software continues to do what its
> supposed
> > to do whilst allowing me to focus on new code rather than on manually
> > re-testing existing functionality. It's a real challenge to keep existing
> > functionality working as new development continues. The continuous
> > integration approach helps achieve this but the team has to 'care' when
> > passing tests start to fail (an area that we've found challenging).
> >
> > This 'demonstrating that the software works' is in the first instance
> > demonstrating to myself and where the software doesn't work as intended,
> > demonstrating to the developers. I feel that the 'demonstrating' mindset
> > helps in providing confidence to anyone who's interested in the status of
> > the software being developed.
> >
> > I find that thinking and using the word 'demonstrate' rather than 'test'
> > helps the collaboration between testing and developers in our more
> > traditional organisation. It feels more like I'm 'helping our team show
> > that we've got working software' rather than 'showing the dev guys that
> > their software doesn't work'.
> >
> > Just a few thoughts from my own experience. I hope it helps.
> >
> > cheers
> >
> > Glenn
> >
> > 2009/10/3 markpetronic markpetronic@...
> >
> > >
> > >
> > > I'm the SM for a new agile team in our company. This is the first team
> > > doing agile in our company that I am aware of. In keeping with building
> > > a cross-functional team, I am trying to now pull in someone from
> testing
> > > to contribute. We have really just started and are in our third sprint
> > > (about 2 months into the project). We already have a nightly build
> > > engine basically working, are using JUnit and Emma for the Java part
> for
> > > unit testing and coverage, and CxxTest on the C++ client side
> > > development. We want to do CI and are trying to really do things right
> > > from the onset because this project will be looked at from other side
> > > this group and I want us to succeed and inspire a cultural change in
> the
> > > company. The team is 6 developers at this point. The product is a
> client
> > > (embedded C++) and server (Java on Linux) application with no real UI
> to
> > > speak of. Think of an HTTP proxy web acceleration kind of thing. So, we
> > > will need to have some significant end-to-end testing that I hope to
> > > automate for performance, stability, compliance, soak testing.
> > >
> > > Would like to hear from the community on ideas about how to transition
> a
> > > tester who comes from the traditional process model with "big bang"
> > > integration and testing at the end into an agile team. The tester would
> > > probably not have many development skills but is a very good
> exploritory
> > > tester (however, could become proficient at developing testing fixtures
> > > in various scripting languages). I am already reading "Agile Testing"
> > > and it's a good source of information from this perspective.
> > >
> > > Thanks,
> > > Mark
> > >
> > >
> > >
> >
>  
>

[markpetronic]

First, let me say I'm impressed by the passion you all have for your
roles.
I have someone in mind that I would love to get on our team that shares
this
same passion. I /REALLY/ appreciate all our your feedback in this thread
-
it's very helpful.

I would be interested in your tech talk, Heather. You could
send it to me (markpetronic@...). Thanks!

I very much agree that the tester needs to be integral to the team and
not like
some outside add-on just for a silo'ed set of activities. The person I
have in mind
is very much a "test-minded" person but wants to contribute in the early
phases
to ensure the product that is ultimately designed and built is
ultimately testable.

I think you've all given me a nice glimpse into the various ways in
which you all
are key contributors to your teams that will help me have more
constructive dialogs
with the current test lead and upper management concerning getting
someone
engaged soon. I already talked to my VP today and got budget approval
for a part
time slot for a tester on the team.  :-)  That's a good first step $$$.
Once we get going, I think
the role and responsibilities will get clearer for all on the team as to
how to make
everyone work as one team solving common problems and enjoying group
successes.

Thanks again for all your thought provoking responses...

Mark


--- In agile-testing@..., Heather Tinkham
<heather.tinkham@...> wrote:
>
> Having worked as the "first" tester on several agile projects for
clients, I
> heartily second Steve's statement about participation in the stand
ups,
> customer collaboration, and retrospectives. I have also talked to
several of
> our clients who are trying to incorporate "traditional" testers in to
agile
> projects and have seen several key points of resistance, particularly
where
> the culture is to jump testers from project (product) to project just
before
> release time. Participation in the stand ups and collaboration
meetings is
> typically one of those points of resistance, but it really is
important for
> several reasons:
> - it is essential to reaching a point where the tester is seen as a
member
> of the team, working *with* the rest of the team to produce the
software as
> opposed to just coming in to "evaluate" it after the fact
> - generally there are so many fine points that the tester will need to
know
> that may not be in the documentation that they need to be around in
order to
> prevent long and frustrating repetitions of conversations already had
to
> work things out
> - it gets very difficult to get the transparent and rapid feedback if
you
> expect them to do periodic big bang style testing
>
> For one of our clients, we approached the transition by considering my
role
> to be an "embedded tester/developer" that complimented their existing
QA
> structure instead of trying to replace it. This allowed them to see
the
> "proof" by observing the differences in bug rates and types,
smoothness of
> releases, and reduced (traditional) "testing" time. I was full time on
the
> project, but I did multiple projects concurrently to satisfy the
perception
> that a FT person could not be justified. (That meant little end-to-end
> automation and a LOT of exploratory testing, which is not at all
optimal. It
> was better than not having a testing presence at all, though. It was
also
> moving in the right direction and as big a change as they wanted to
handle.)
>
> I have a tech talk that I have done with one of our developers that
covers
> this in more detail. If anyone is interested, just let me know and I
can

> send you the slides.
>
> -Heather
>
> Heather E.C. Tinkham
> Senior IT Consultant
> Object Partners, Inc.
> cell [phone]
>
>
> On Mon, Oct 5, 2009 at 8:19 AM, Steven Gordon sgordonphd@... wrote:
>
>
> > If so, these issues drive what a tester should be doing. Of course,
> > no matter what else a new team member will be doing to help the

team,
> > they absolutely must participate in stand ups, customer
collaboration,

> > retrospectives to be effective.
> >
> > SteveG
> >
> > ....
> >
> > > Any thoughts here?
> > > Mark
> >
> >
>

[markpetronic]

Ok, Glenn, this is pretty intense - that you would go to all this detail
to communicate a "day in the life". Pretty awesome! Thanks!!!
You are obviously passionate about your job and I do appreciate that.
This was very helpful to me and I will definitely
turn on the guy I'm hoping will join our team to this thread and group.
I'm really looking forward to just seeing how
someone who really wants to be successful as tester will do in an
environment where we all /WANT/ testing to be a top
priority and not just the phase at the end that suffers all the schedule
compression because - well - that's how it always
is with traditional waterfall planning. I would get so frustrated as a
testing in the environment. You want to do good work
but are never given the time to adequately do your job as a craftsman.
Hope to change that with the introduction of an
Agile model for this project. Guess I'll see how well it goes. Will let
you all know how things work out.

Thanks again for all your suggestions,
Mark

--- In agile-testing@..., Glenn Halstead <glenn@...> wrote:
>
> Hi Mark,
>
> I've answered some of your questions below.  I completely agree with
some of
> the other posters that what we do in our world (I hesitate to say
'what
> works for us' because we're still trying to get there) may not be
applicable
> to yours.
>
>     Thanks for the reply, Glenn.
>
>     I would like to hear what your role looks like through the course
of a
> typical sprint. With developers doing TDD, the until tests are pretty
much
> done by each individual developer.
>
>         * Do you spend time working to develop acceptance-level tests
and
> end-to-end tests?
> My focus is on testing soa services.  My tests incorporate the esb,
> (enterprise service mus, IBM MQ), and often multiple backend
applications,
> whereas the developers tests do not test through the esb and do not
interact
> with other backend apps.
>
>         * Do you develop the test scripts or help in their
development?
> I do develop the test scripts. Where I run into problems developing
the
> tests I interact with the developers to determine correct usage of the
> service operations or to confirm that the behaviour I'm seeing is
> incorrect.  I'll often drag one of our other testser in where they've
got
> more experience in a particular area or just to get 2 heads on a
problem.
>
>         * How do you interact with the developers as these are working
on
> completing stories?
> When development of a service operation is completed the devs release
it
> into our development integration environment and let me know it's
available
> to test.  Sometimes I need to wait for the esb guys to expose the
service
> before I can get at it.  These service operations have not yet been
released
> to our customer, the portal development team.  Its fairly easy to get
the
> developers attention at this stage as the dev work is only just been
> completed.  At this time they seem to be quite keen to answer
questions and
> look into unexpected behaviour.  (We've only been working this way
(testers
> with the services dev team) for a few weeks.  Previously we weren't
testing
> the services until after they'd formally released.  When working this
way I
> found it much more difficult to get the developers attention and
interest in
> my testing as they were busy developing the next iteration.)
>
>         * Are you part of all sprint planning meetings, reviews, and
stand
> ups?
> As yet I'm not in the sprint planning meetings.  I was invited to the
most
> recent one but didn't attend because we had some specific panics on
that
> day.  I am at the stand-ups and do a good bit of the talking; what
tests are
> failing that were previously passing (my pet focus), what's blocking
test
> development & execution, etc.
>
>     Guess I'm trying to determine to what extend the tester engaged
from a
> resource loading perspective. Adding a full time tester to the team
for a
> project that might run for 12 months will probably be met with
resistance by
> upper management when they would typically expect them to maybe spend
6-8
> weeks doing release testing at the end in the traditional process.
That's
> never really successful and is typically a bug finding exercise. I
expect
> they will want to see some proof of the ROI there. But, on the other
> extreme, I'm finding it hard to see having a full time tester for 12
months
> when developers should be doing a lot of the testing themselves. And,
at
> this time, there's no way I could even get a full time tester. Being
the
> first Agile project in the company that is a grass roots driven
project that
> I have instituted, you know how management is, they want to see the
proof
> before they commit. So, I've been working with our test lead to
discuss how
> I could use one of her people part time to at least start to create a
more
> cross-functional team. I'm just short on details regarding the
day-to-day
> activities that this person would be responsible for with the team.
>
> Tester resource: Where I use 'I' above, there are 4 of us full time
doing
> this.  There are 5 different backend services teams and an esb team
> producing services.  We're playing catchup at the moment.  As I
mentioned,
> we're only been working this way a few weeks.
>
> If there is a full time dev team why would there not be a full time
tester?
> As you say, the drive for this would be  dissatisfaction with how
things are
> currently working.  There's clearly a desire to improve you're current
dev
> process and putting a tester in there could help.  Who that tester is
is of
> major importance (in my opinion).  They need to have a vision of how
things
> should be / could be and the drive and tenacity to get there.  They
need to
> be able to change that vision as they go along, learning with the dev
team
> and they need to be part of the dev team, part of the creation of the
> software.
>
> There's a clear gap in my world between the testing I do and the
testing the
> devs do.  Integration... thats the big difference.  I test all the
> components (sub systems) together  The devs test their components in
> isolation.  I find things they don't and could not with theyre
testing.
>
>
>
> Regarding what a day for a dev tester might be like, I've sumarised my
day
> today  it's been a fairly typical day.  No doubt I've left out things
but
> thats not important.
>
>
> A brief summary of my day (today)...
>
> - Arrive @ work around 8am.  Look at the hourly smoke test run on the
> radiator display.  The screen shows the hudson junit results for my
smoke
> test pack (I use junit format to leverage hudsons built in reporting).
The
> test job is still running, it was kcicked off at 7am.  It should be
> finished.  I suspect theres a major issue in the environment causing
the
> test pack to take a long time because tests are waiting for the time
out
> when no response message is received from ESB.  I run a single test
from my
> pc that touches a couple of the main env components.  One of them is
not
> responding.  I email the dev lead for that component and the env
manager
> They won't be in till around 9am.  I leave the test pack running as I
should
> see a fail spike in my results graph in the radiator when the test run
is
> complete.
>
> - I take a look at the test of a new service operation I was trying to
get
> working on Friday.  The app is not responding as I expect.  I raised
this
> with the dev guy on Friday, he couldn't see a problem but it's an area
of
> the code that he reused so hes not 100% familiar with it.  I'd begun
to
> suspect that maybe some of the prior data prep in my test is not
right.  I
> work with one of the other testers on this and we figure out how we
should
> be prepping the data.  We've both learned a bit about how one of the
other
> service operations should be used.  I let the dev guy know there's
nothing
> wrong with the app in this area and I ask him about the two othere
area's
> that seem to be wrong that he's having a look at.  He's planning to
release
> a fix today, he'll shout when I can retry my test (he didn't shout by
the
> way... note for tomorrow).  I finish the current test and create one
for the
> the last operation of this service.  I commit the new tests and label
them
> to be included in our smoke test job.
>
> - We're using a fitnesse based service test framework based on service
> fixture, jaxb, automatically generated java code (generated based on
the
> wsdls) and lots of other javaery stuff I only partially understand.
>
> - I have a 'sit around our desks meeting' with the other 3 test devs
on the
> team.  I sit beside one of them in the esb dev team area, the other 2
sit
> across the corridor in the test area.  We have a brief chat about
major
> blockers / failure causers.  There are 4 main faults causing our 20 or
so
> test failures (out for th 100 or so tests in the smoke pack).  We
cover what
> we're gonna be doing today.  The purpose of this chat is to focus on
the
> info we want to provide and the questions we want to ask at the stand
up.
> We limit the meeting to 30 mins.
>
> - I pull out the per operation test results from our test run... by
the way
> the earlier env problem is resolved.  the test pack has run again and
the
> radiator shows a big red spike where all the tests (~30 out of 100)
affected
> by that component failed and now pass again.  I update our per service
> operation test status spreadsheet with the results from the lates test
run.
> A manual process but fairly trivial now, it's gradually become less
and less
> effort over the last 2 weeks as I've improved our test results parser
and
> summariser script.  This is all about providing information that
answers the
> questions people ask us.  "Do you have a test for this operation?",
"How
> many oerations pass / fail / aren't tested?", "Why are those not
tested?",
> etc.
>
> - There's no dev standup today.  This seems to be a Monday pattern
because
> some of the contract devs haven't arrived yet.  The dev manager and
one of
> the app dev leads stop by for a status update.  The dev guys want's to
know
> if there's anything we need his help with.  the dev guys are about to
embark
> on the next iteration and we still have failing tests and incomplete
tests.
> He's keen to get things in as good shape as possible before firing
into the
> next iteration.  I share a couple of issues and questions and get a
couple
> of pointers re. things I'm investigating.
>
> - Blimey it's lunch time already....
>
> _ The delivery manager stops to look at our radiator with one of the
other
> managers.  I pipe up about the big red spike and have a chat about the
> trends... number of tests increasing, number of failed tests
decreasing,
> this is good, we're making progress.  This is good news but remember
this is
> only smoke tests though, there's a lot to do.  We chat about the
broader
> coverage test packs and the gui tests that one of the other testers is
> heading up.  We chat about the Continuous Integration build that's
being
> worked on to build a test environment from scratch and what tests will
be
> included.  All of them is the conclusion, passes AND fails.
>
> - I meet with the build engineer / env guy who's doing the donkey work
of
> pulling together the environment build soluton with components from
all
> teams.  How are our tests going to plug into this.  We agree a few
first
> steps and there's some action on me to complete so we can move along
on
> this.
>
> - I need to build a new service model jar for the CI environment based
on
> the latest dev versions of the wsdls.  In future the jar will be
environment
> independant but this will get us up and running.  While this is
building I
> start work on the next of the new services that don't have tests yet.
>
> - Our dev integration environment is down as a deployment is running
I
> can't progress my test development  The new jar build is finished so I
try
> running a test in the CI env to check it.  It doesn't work either.  I
> suspect that env is not working, either that or I cocked it up.
>
> - Blimey its 5pm already  the env is still down, my tester buddy, desk
> neighour and care sharer suggests we call it a day.  We head off home.
I
> annoy hiim with chat about testing, ruby and my new android phone
during the
> journey.. more tomorrow, wahey.
>
>
> I hope sharing this is of some interest / help but again I emphasise
my
> agreement with others that this is very specific my my world and may
well be

> completely irrelevant to yours.
>
> I hope you're successful
>
> Glenn
>
>
>
>
>     Any thoughts here?
>
>     Mark
>
> 2009/10/4 markpetronic markpetronic@...
>
> >
> >
> > Thanks for the reply, Glenn.
> >
> > I would like to hear what your role looks like through the course of

a
> > typical sprint. With developers doing TDD, the until tests are
pretty much

> > done by each individual developer.
> >
>
>
>
> >
> >    - Do you spend time working to develop acceptance-level tests and
> >    end-to-end tests?
> >    - Do you develop the test scripts or help in their development?
> >    - How do you interact with the developers as these are working on
> >    completing stories?
> >    - Are you part of all sprint planning meetings, reviews, and

stand ups?
> >
> > Guess I'm trying to determine to what extend the tester engaged from
a
> > resource loading perspective. Adding a full time tester to the team
for a
> > project that might run for 12 months will probably be met with
resistance by
> > upper management when they would typically expect them to maybe
spend 6-8
> > weeks doing release testing at the end in the traditional process.
That's
> > never really successful and is typically a bug finding exercise. I
expect
> > they will want to see some proof of the ROI there. But, on the other
> > extreme, I'm finding it hard to see having a full time tester for 12
months
> > when developers should be doing a lot of the testing themselves.
And, at
> > this time, there's no way I could even get a full time tester. Being
the
> > first Agile project in the company that is a grass roots driven
project that
> > I have instituted, you know how management is, they want to see the
proof
> > before they commit. So, I've been working with our test lead to
discuss how
> > I could use one of her people part time to at least start to create
a more
> > cross-functional team. I'm just short on details regarding the
day-to-day

> > activities that this person would be responsible for with the team.
> >
> > Any thoughts here?
> >
> > Mark
> >
> > --- In agile-testing@..., Glenn Halstead glenn@ wrote:
> > >
> > > Hi Mark,
> > >
> > > I'm not a regular poster here (although I am a regular reader).
> > >
> > > I'm a test automation guy (historically) and I'm currently working

with
> > the
> > > dev teams on a project where we're trying to improve our early
testing.
> > >
> > > I think of my role as being there to help 'demonstrate, as soon as
> > possible
> > > after the software is created, that it does what it's intended to
do.'
> > >
> > > Making the tests automated and using continuous integration helps
us to
> > > demonstrate that the now existing software continues to do what
its
> > supposed
> > > to do whilst allowing me to focus on new code rather than on
manually
> > > re-testing existing functionality. It's a real challenge to keep
existing
> > > functionality working as new development continues. The continuous
> > > integration approach helps achieve this but the team has to 'care'
when
> > > passing tests start to fail (an area that we've found
challenging).
> > >
> > > This 'demonstrating that the software works' is in the first
instance
> > > demonstrating to myself and where the software doesn't work as
intended,
> > > demonstrating to the developers. I feel that the 'demonstrating'
mindset
> > > helps in providing confidence to anyone who's interested in the
status of
> > > the software being developed.
> > >
> > > I find that thinking and using the word 'demonstrate' rather than
'test'
> > > helps the collaboration between testing and developers in our more
> > > traditional organisation. It feels more like I'm 'helping our team
show
> > > that we've got working software' rather than 'showing the dev guys
that

> > > their software doesn't work'.
> > >
> > > Just a few thoughts from my own experience. I hope it helps.
> > >
> > > cheers
> > >
> > > Glenn
> > >
> > > 2009/10/3 markpetronic markpetronic@
> > >
> > > >
> > > >
> > > > I'm the SM for a new agile team in our company. This is the

first team
> > > > doing agile in our company that I am aware of. In keeping with
building
> > > > a cross-functional team, I am trying to now pull in someone from
> > testing
> > > > to contribute. We have really just started and are in our third
sprint
> > > > (about 2 months into the project). We already have a nightly
build
> > > > engine basically working, are using JUnit and Emma for the Java
part
> > for
> > > > unit testing and coverage, and CxxTest on the C++ client side
> > > > development. We want to do CI and are trying to really do things
right
> > > > from the onset because this project will be looked at from other
side
> > > > this group and I want us to succeed and inspire a cultural
change in
> > the
> > > > company. The team is 6 developers at this point. The product is
a
> > client
> > > > (embedded C++) and server (Java on Linux) application with no
real UI
> > to
> > > > speak of. Think of an HTTP proxy web acceleration kind of thing.
So, we
> > > > will need to have some significant end-to-end testing that I
hope to
> > > > automate for performance, stability, compliance, soak testing.
> > > >
> > > > Would like to hear from the community on ideas about how to
transition
> > a
> > > > tester who comes from the traditional process model with "big
bang"
> > > > integration and testing at the end into an agile team. The
tester would
> > > > probably not have many development skills but is a very good
> > exploritory
> > > > tester (however, could become proficient at developing testing
fixtures
> > > > in various scripting languages). I am already reading "Agile
Testing"

> > > > and it's a good source of information from this perspective.
> > > >
> > > > Thanks,
> > > > Mark
> > > >
> > > >
> > > >
> > >
> >
> >
>

[Beaton, Malcolm-2]

Sorry Prashant - That wasn't what I was saying

We are not the policemen - We merely uphold the teams definition of done

Mal

From: agile-testing@... [mailto:agile-testing@...] On Behalf Of Prashant Chavan
Sent: 05 October 2009 18:41
To: agile-testing@...
Subject: Re: [agile-testing] Re: Migrating traditional testers onto an agile team


I completely agree with your all statements!!!!!!!!!!

In fact Testing should happen in this way!

Testers are the POLICE MEN and they should be free to catch the bugs in all the process and NOT just at the END [cid:image001.gif@...]

--Prashant

From: Beaton, Malcolm<mailto:malcolm.beaton@...>
Sent: Monday, October 05, 2009 7:55 PM
To: agile-testing@...<mailto:agile-testing@...>
Subject: RE: [agile-testing] Re: Migrating traditional testers onto an agile team


Hi Mark
I actually did a presentation on this at Agile 2009 believe it or not. And I agree with Glenn - especially around the automation of tests - This will give your tester more time to explore the app and come up with crazy scenarios that the developers may or may not have thought about
There are a few things in your response that I'd like to discuss,
"when developers should be doing a lot of the testing themselves"
Assuming you are referring to the TDD practices they are following it might be worth reading some of Dan North's posts on BDD and about TDD itself, It is actually more of a design process than a testing process, It does give greater confidence in the code overall but it would be rare for a Unit test to pick up an error caused by a browser renderer or a fatal conflict with Outlook for example.
Following on from the other points (As a tester myself)

 *   Do you spend time working to develop acceptance-level tests and end-to-end tests?
Yes, A great deal of my time. I find helping the Product owner and the team define acceptance criteria before the sprint is estimated makes sprint planning quicker and easier and also gives the Dev team obvious delivery points to test as well as obvious automation points

 *   Do you develop the test scripts or help in their development?
I work with the clients acceptance tests that we have defined together, If you are referring to Automation I don't always work on these but I always have someone who is if it isn't me. I also work with the developers to help them come up with unit test scenarios for their unit tests, which also helps me in making sure boundary conditions and obvious common failure points are addressed

 *   How do you interact with the developers as these are working on completing stories?
We work together to get the story done - It is not a case of "They are completing stories" one of the most important roles a tester will have is the evaluation and re evaluation of your "Definition of done", If your definition of done is "Written and has some unit tests" would that be good enough to ship it or put it live? What if your product owner said "I don't want to see it - I trust you - If you met your definition of done then just go live!" would you be confident enough to that? Every single sprint? So for me it is a partnership - We work together to flush out the edge cases and the unobvious conflicts, I wouldn't expect them to catch every one any more than I would expect to catch every one but between us we catch more than either would

 *   Are you part of all sprint planning meetings, reviews, and stand ups?
I am (as I am sure glen is) a member of the team! Yes I am part of everything the team is
Which brings me back to one of the central points of the presentation we did - The tester doesn't work in a vacuum and the most agile tester will find it impossible to work effectively in an environment that wont enable them to, Forget the delineations between roles and push that your team as a whole needs a full skill set, How this is organised is up to you but any where you start doing things like (And I have seen all of these)

1)      A separate tester back log

2)      Testing a sprint behind the current sprint

3)      Saving all your bugs till the end
Your project will naturally de agaileise faster than you can say Prince 2.
Get a full time tester in to your project - Hire one if you need to and get them to help define the stories with acceptance criteria, Get them to challenge the developers on their definition of done, Get them to enforce the Shippable in "Potentially shippable and not the potentially, Get them to help the Product owner to think about the cross system impact of changes they ask for.
And if they do half of the things above I think you'll agree they will have been a valuable member of your team, no?
</rant>
Apologies - Is a subject very close to my heart!
From: agile-testing@... [mailto:agile-testing@...] On Behalf Of markpetronic
Sent: 04 October 2009 16:37
To: agile-testing@...
Subject: [agile-testing] Re: Migrating traditional testers onto an agile team


Thanks for the reply, Glenn.
I would like to hear what your role looks like through the course of a typical sprint. With developers doing TDD, the until tests are pretty much done by each individual developer.
Guess I'm trying to determine to what extend the tester engaged from a resource loading perspective. Adding a full time tester to the team for a project that might run for 12 months will probably be met with resistance by upper management when they would typically expect them to maybe spend 6-8 weeks doing release testing at the end in the traditional process. That's never really successful and is typically a bug finding exercise. I expect they will want to see some proof of the ROI there. But, on the other extreme, I'm finding it hard to see having a full time tester for 12 months when developers should be doing a lot of the testing themselves. And, at this time, there's no way I could even get a full time tester. Being the first Agile project in the company that is a grass roots driven project that I have instituted, you know how management is, they want to see the proof before they commit. So, I've been working with our test lead to discuss how I could use one of her people part time to at least start to create a more cross-functional team. I'm just short on details regarding the day-to-day activities that this person would be responsible for with the team.
Any thoughts here?
Mark
--- In agile-testing@..., Glenn Halstead <glenn@...> wrote:

>
> Hi Mark,
>
> I'm not a regular poster here (although I am a regular reader).
>
> I'm a test automation guy (historically) and I'm currently working with the
> dev teams on a project where we're trying to improve our early testing.
>
> I think of my role as being there to help 'demonstrate, as soon as possible
> after the software is created, that it does what it's intended to do.'
>
> Making the tests automated and using continuous integration helps us to
> demonstrate that the now existing software continues to do what its supposed
> to do whilst allowing me to focus on new code rather than on manually
> re-testing existing functionality. It's a real challenge to keep existing
> functionality working as new development continues. The continuous
> integration approach helps achieve this but the team has to 'care' when
> passing tests start to fail (an area that we've found challenging).
>
> This 'demonstrating that the software works' is in the first instance
> demonstrating to myself and where the software doesn't work as intended,
> demonstrating to the developers. I feel that the 'demonstrating' mindset
> helps in providing confidence to anyone who's interested in the status of
> the software being developed.
>
> I find that thinking and using the word 'demonstrate' rather than 'test'
> helps the collaboration between testing and developers in our more
> traditional organisation. It feels more like I'm 'helping our team show
> that we've got working software' rather than 'showing the dev guys that
> their software doesn't work'.
>
> Just a few thoughts from my own experience. I hope it helps.
>
> cheers
>
> Glenn
>
> 2009/10/3 markpetronic markpetronic@...
>
> >
> >
> > I'm the SM for a new agile team in our company. This is the first team
> > doing agile in our company that I am aware of. In keeping with building
> > a cross-functional team, I am trying to now pull in someone from testing
> > to contribute. We have really just started and are in our third sprint
> > (about 2 months into the project). We already have a nightly build
> > engine basically working, are using JUnit and Emma for the Java part for
> > unit testing and coverage, and CxxTest on the C++ client side
> > development. We want to do CI and are trying to really do things right
> > from the onset because this project will be looked at from other side
> > this group and I want us to succeed and inspire a cultural change in the
> > company. The team is 6 developers at this point. The product is a client
> > (embedded C++) and server (Java on Linux) application with no real UI to
> > speak of. Think of an HTTP proxy web acceleration kind of thing. So, we
> > will need to have some significant end-to-end testing that I hope to
> > automate for performance, stability, compliance, soak testing.
> >
> > Would like to hear from the community on ideas about how to transition a
> > tester who comes from the traditional process model with "big bang"
> > integration and testing at the end into an agile team. The tester would
> > probably not have many development skills but is a very good exploritory
> > tester (however, could become proficient at developing testing fixtures
> > in various scripting languages). I am already reading "Agile Testing"
> > and it's a good source of information from this perspective.
> >
> > Thanks,
> > Mark
> >
> >
> >
>

 

[Lisa Crispin-2]

For our Agile Testing book, we interviewed many teams around the world about
their experiences transitioning testers to agile, you might find it helpful
(I know, it seems so crass to sell my own book).

There are also some articles and presentations on my website that relate to
this.
http://lisacrispin.com/wordpress/articles/
http://lisacrispin.com/wordpress/presentations/

Please keep us posted on your experiences.

-- Lisa

On Mon, Oct 5, 2009 at 11:36 PM, markpetronic <markpetronic@...>wrote:

>
>
> Ok, Glenn, this is pretty intense - that you would go to all this detail
> to communicate a "day in the life". Pretty awesome! Thanks!!!
> You are obviously passionate about your job and I do appreciate that.
> This was very helpful to me and I will definitely
> turn on the guy I'm hoping will join our team to this thread and group.
> I'm really looking forward to just seeing how
> someone who really wants to be successful as tester will do in an
> environment where we all /WANT/ testing to be a top
> priority and not just the phase at the end that suffers all the schedule
> compression because - well - that's how it always
> is with traditional waterfall planning. I would get so frustrated as a
> testing in the environment. You want to do good work
> but are never given the time to adequately do your job as a craftsman.
> Hope to change that with the introduction of an
> Agile model for this project. Guess I'll see how well it goes. Will let
> you all know how things work out.
>
> Thanks again for all your suggestions,
>
> Mark
>
> --- In agile-testing@... <agile-testing%40yahoogroups.com>,
> Glenn Halstead <glenn@...> wrote:
> >
> > Hi Mark,
> >
> > I've answered some of your questions below. I completely agree with
> some of
> > the other posters that what we do in our world (I hesitate to say
> 'what
> > works for us' because we're still trying to get there) may not be
> applicable
> > to yours.
> >
> > Thanks for the reply, Glenn.
> >
> > I would like to hear what your role looks like through the course
> of a
> > typical sprint. With developers doing TDD, the until tests are pretty
> much
> > done by each individual developer.
> >
> > * Do you spend time working to develop acceptance-level tests
> and
> > end-to-end tests?
> > My focus is on testing soa services. My tests incorporate the esb,
> > (enterprise service mus, IBM MQ), and often multiple backend
> applications,
> > whereas the developers tests do not test through the esb and do not
> interact
> > with other backend apps.
> >
> > * Do you develop the test scripts or help in their
> development?
> > I do develop the test scripts. Where I run into problems developing
> the
> > tests I interact with the developers to determine correct usage of the
> > service operations or to confirm that the behaviour I'm seeing is
> > incorrect. I'll often drag one of our other testser in where they've
> got
> > more experience in a particular area or just to get 2 heads on a
> problem.
> >
> > * How do you interact with the developers as these are working
> on
> > completing stories?
> > When development of a service operation is completed the devs release
> it
> > into our development integration environment and let me know it's
> available
> > to test. Sometimes I need to wait for the esb guys to expose the
> service
> > before I can get at it. These service operations have not yet been
> released
> > to our customer, the portal development team. Its fairly easy to get
> the
> > developers attention at this stage as the dev work is only just been
> > completed. At this time they seem to be quite keen to answer
> questions and
> > look into unexpected behaviour. (We've only been working this way
> (testers
> > with the services dev team) for a few weeks. Previously we weren't
> testing
> > the services until after they'd formally released. When working this
> way I
> > found it much more difficult to get the developers attention and
> interest in
> > my testing as they were busy developing the next iteration.)
> >
> > * Are you part of all sprint planning meetings, reviews, and
> stand
> > ups?
> > As yet I'm not in the sprint planning meetings. I was invited to the
> most
> > recent one but didn't attend because we had some specific panics on
> that
> > day. I am at the stand-ups and do a good bit of the talking; what
> tests are
> > failing that were previously passing (my pet focus), what's blocking
> test
> > development & execution, etc.
> >
> > Guess I'm trying to determine to what extend the tester engaged
> from a
> > resource loading perspective. Adding a full time tester to the team
> for a
> > project that might run for 12 months will probably be met with
> resistance by
> > upper management when they would typically expect them to maybe spend
> 6-8
> > weeks doing release testing at the end in the traditional process.
> That's
> > never really successful and is typically a bug finding exercise. I
> expect
> > they will want to see some proof of the ROI there. But, on the other
> > extreme, I'm finding it hard to see having a full time tester for 12
> months
> > when developers should be doing a lot of the testing themselves. And,
> at
> > this time, there's no way I could even get a full time tester. Being
> the
> > first Agile project in the company that is a grass roots driven
> project that
> > I have instituted, you know how management is, they want to see the
> proof
> > before they commit. So, I've been working with our test lead to
> discuss how
> > I could use one of her people part time to at least start to create a
> more
> > cross-functional team. I'm just short on details regarding the
> day-to-day
> > activities that this person would be responsible for with the team.
> >
> > Tester resource: Where I use 'I' above, there are 4 of us full time
> doing
> > this. There are 5 different backend services teams and an esb team
> > producing services. We're playing catchup at the moment. As I
> mentioned,
> > we're only been working this way a few weeks.
> >
> > If there is a full time dev team why would there not be a full time
> tester?
> > As you say, the drive for this would be dissatisfaction with how
> things are
> > currently working. There's clearly a desire to improve you're current
> dev
> > process and putting a tester in there could help. Who that tester is
> is of
> > major importance (in my opinion). They need to have a vision of how
> things
> > should be / could be and the drive and tenacity to get there. They
> need to
> > be able to change that vision as they go along, learning with the dev
> team
> > and they need to be part of the dev team, part of the creation of the
> > software.
> >
> > There's a clear gap in my world between the testing I do and the
> testing the
> > devs do. Integration... thats the big difference. I test all the
> > components (sub systems) together The devs test their components in
> > isolation. I find things they don't and could not with theyre
> testing.
> >
> >
> >
> > Regarding what a day for a dev tester might be like, I've sumarised my
> day
> > today it's been a fairly typical day. No doubt I've left out things
> but
> > thats not important.
> >
> >
> > A brief summary of my day (today)...
> >
> > - Arrive @ work around 8am. Look at the hourly smoke test run on the
> > radiator display. The screen shows the hudson junit results for my
> smoke
> > test pack (I use junit format to leverage hudsons built in reporting).
> The
> > test job is still running, it was kcicked off at 7am. It should be
> > finished. I suspect theres a major issue in the environment causing
> the
> > test pack to take a long time because tests are waiting for the time
> out
> > when no response message is received from ESB. I run a single test
> from my
> > pc that touches a couple of the main env components. One of them is
> not
> > responding. I email the dev lead for that component and the env
> manager
> > They won't be in till around 9am. I leave the test pack running as I
> should
> > see a fail spike in my results graph in the radiator when the test run
> is
> > complete.
> >
> > - I take a look at the test of a new service operation I was trying to
> get
> > working on Friday. The app is not responding as I expect. I raised
> this
> > with the dev guy on Friday, he couldn't see a problem but it's an area
> of
> > the code that he reused so hes not 100% familiar with it. I'd begun
> to
> > suspect that maybe some of the prior data prep in my test is not
> right. I
> > work with one of the other testers on this and we figure out how we
> should
> > be prepping the data. We've both learned a bit about how one of the
> other
> > service operations should be used. I let the dev guy know there's
> nothing
> > wrong with the app in this area and I ask him about the two othere
> area's
> > that seem to be wrong that he's having a look at. He's planning to
> release
> > a fix today, he'll shout when I can retry my test (he didn't shout by
> the
> > way... note for tomorrow). I finish the current test and create one
> for the
> > the last operation of this service. I commit the new tests and label
> them
> > to be included in our smoke test job.
> >
> > - We're using a fitnesse based service test framework based on service
> > fixture, jaxb, automatically generated java code (generated based on
> the
> > wsdls) and lots of other javaery stuff I only partially understand.
> >
> > - I have a 'sit around our desks meeting' with the other 3 test devs
> on the
> > team. I sit beside one of them in the esb dev team area, the other 2
> sit
> > across the corridor in the test area. We have a brief chat about
> major
> > blockers / failure causers. There are 4 main faults causing our 20 or
> so
> > test failures (out for th 100 or so tests in the smoke pack). We
> cover what
> > we're gonna be doing today. The purpose of this chat is to focus on
> the
> > info we want to provide and the questions we want to ask at the stand
> up.
> > We limit the meeting to 30 mins.
> >
> > - I pull out the per operation test results from our test run... by
> the way
> > the earlier env problem is resolved. the test pack has run again and
> the
> > radiator shows a big red spike where all the tests (~30 out of 100)
> affected
> > by that component failed and now pass again. I update our per service
> > operation test status spreadsheet with the results from the lates test
> run.
> > A manual process but fairly trivial now, it's gradually become less
> and less
> > effort over the last 2 weeks as I've improved our test results parser
> and
> > summariser script. This is all about providing information that
> answers the
> > questions people ask us. "Do you have a test for this operation?",
> "How
> > many oerations pass / fail / aren't tested?", "Why are those not
> tested?",
> > etc.
> >
> > - There's no dev standup today. This seems to be a Monday pattern
> because
> > some of the contract devs haven't arrived yet. The dev manager and
> one of
> > the app dev leads stop by for a status update. The dev guys want's to
> know
> > if there's anything we need his help with. the dev guys are about to
> embark
> > on the next iteration and we still have failing tests and incomplete
> tests.
> > He's keen to get things in as good shape as possible before firing
> into the
> > next iteration. I share a couple of issues and questions and get a
> couple
> > of pointers re. things I'm investigating.
> >
> > - Blimey it's lunch time already....
> >
> > _ The delivery manager stops to look at our radiator with one of the
> other
> > managers. I pipe up about the big red spike and have a chat about the
> > trends... number of tests increasing, number of failed tests
> decreasing,
> > this is good, we're making progress. This is good news but remember
> this is
> > only smoke tests though, there's a lot to do. We chat about the
> broader
> > coverage test packs and the gui tests that one of the other testers is
> > heading up. We chat about the Continuous Integration build that's
> being
> > worked on to build a test environment from scratch and what tests will
> be
> > included. All of them is the conclusion, passes AND fails.
> >
> > - I meet with the build engineer / env guy who's doing the donkey work
> of
> > pulling together the environment build soluton with components from
> all
> > teams. How are our tests going to plug into this. We agree a few
> first
> > steps and there's some action on me to complete so we can move along
> on
> > this.
> >
> > - I need to build a new service model jar for the CI environment based
> on
> > the latest dev versions of the wsdls. In future the jar will be
> environment
> > independant but this will get us up and running. While this is
> building I
> > start work on the next of the new services that don't have tests yet.
> >
> > - Our dev integration environment is down as a deployment is running
> I
> > can't progress my test development The new jar build is finished so I
> try
> > running a test in the CI env to check it. It doesn't work either. I
> > suspect that env is not working, either that or I cocked it up.
> >
> > - Blimey its 5pm already the env is still down, my tester buddy, desk
> > neighour and care sharer suggests we call it a day. We head off home.
> I
> > annoy hiim with chat about testing, ruby and my new android phone
> during the
> > journey.. more tomorrow, wahey.
> >
> >
> > I hope sharing this is of some interest / help but again I emphasise
> my
> > agreement with others that this is very specific my my world and may
> well be
> > completely irrelevant to yours.
> >
> > I hope you're successful
> >
> > Glenn
> >
> >
> >
> >
> > Any thoughts here?
> >
> > Mark
> >
> > 2009/10/4 markpetronic markpetronic@...
>
> >
> > >
> > >
> > > Thanks for the reply, Glenn.
> > >
> > > I would like to hear what your role looks like through the course of
> a
> > > typical sprint. With developers doing TDD, the until tests are
> pretty much
> > > done by each individual developer.
> > >
> >
> >
> >
> > >
> > > - Do you spend time working to develop acceptance-level tests and
> > > end-to-end tests?
> > > - Do you develop the test scripts or help in their development?
> > > - How do you interact with the developers as these are working on
> > > completing stories?
> > > - Are you part of all sprint planning meetings, reviews, and
> stand ups?
> > >
> > > Guess I'm trying to determine to what extend the tester engaged from
> a
> > > resource loading perspective. Adding a full time tester to the team
> for a
> > > project that might run for 12 months will probably be met with
> resistance by
> > > upper management when they would typically expect them to maybe
> spend 6-8
> > > weeks doing release testing at the end in the traditional process.
> That's
> > > never really successful and is typically a bug finding exercise. I
> expect
> > > they will want to see some proof of the ROI there. But, on the other
> > > extreme, I'm finding it hard to see having a full time tester for 12
> months
> > > when developers should be doing a lot of the testing themselves.
> And, at
> > > this time, there's no way I could even get a full time tester. Being
> the
> > > first Agile project in the company that is a grass roots driven
> project that
> > > I have instituted, you know how management is, they want to see the
> proof
> > > before they commit. So, I've been working with our test lead to
> discuss how
> > > I could use one of her people part time to at least start to create
> a more
> > > cross-functional team. I'm just short on details regarding the
> day-to-day
> > > activities that this person would be responsible for with the team.
> > >
> > > Any thoughts here?
> > >
> > > Mark
> > >
> > > --- In agile-testing@... <agile-testing%40yahoogroups.com>,
> Glenn Halstead glenn@ wrote:
> > > >
> > > > Hi Mark,
> > > >
> > > > I'm not a regular poster here (although I am a regular reader).
> > > >
> > > > I'm a test automation guy (historically) and I'm currently working
> with
> > > the
> > > > dev teams on a project where we're trying to improve our early
> testing.
> > > >
> > > > I think of my role as being there to help 'demonstrate, as soon as
> > > possible
> > > > after the software is created, that it does what it's intended to
> do.'
> > > >
> > > > Making the tests automated and using continuous integration helps
> us to
> > > > demonstrate that the now existing software continues to do what
> its
> > > supposed
> > > > to do whilst allowing me to focus on new code rather than on
> manually
> > > > re-testing existing functionality. It's a real challenge to keep
> existing
> > > > functionality working as new development continues. The continuous
> > > > integration approach helps achieve this but the team has to 'care'
> when
> > > > passing tests start to fail (an area that we've found
> challenging).
> > > >
> > > > This 'demonstrating that the software works' is in the first
> instance
> > > > demonstrating to myself and where the software doesn't work as
> intended,
> > > > demonstrating to the developers. I feel that the 'demonstrating'
> mindset
> > > > helps in providing confidence to anyone who's interested in the
> status of
> > > > the software being developed.
> > > >
> > > > I find that thinking and using the word 'demonstrate' rather than
> 'test'
> > > > helps the collaboration between testing and developers in our more
> > > > traditional organisation. It feels more like I'm 'helping our team
> show
> > > > that we've got working software' rather than 'showing the dev guys
> that
> > > > their software doesn't work'.
> > > >
> > > > Just a few thoughts from my own experience. I hope it helps.
> > > >
> > > > cheers
> > > >
> > > > Glenn
> > > >
> > > > 2009/10/3 markpetronic markpetronic@
> > > >
> > > > >
> > > > >
> > > > > I'm the SM for a new agile team in our company. This is the
> first team
> > > > > doing agile in our company that I am aware of. In keeping with
> building
> > > > > a cross-functional team, I am trying to now pull in someone from
> > > testing
> > > > > to contribute. We have really just started and are in our third
> sprint
> > > > > (about 2 months into the project). We already have a nightly
> build
> > > > > engine basically working, are using JUnit and Emma for the Java
> part
> > > for
> > > > > unit testing and coverage, and CxxTest on the C++ client side
> > > > > development. We want to do CI and are trying to really do things
> right
> > > > > from the onset because this project will be looked at from other
> side
> > > > > this group and I want us to succeed and inspire a cultural
> change in
> > > the
> > > > > company. The team is 6 developers at this point. The product is
> a
> > > client
> > > > > (embedded C++) and server (Java on Linux) application with no
> real UI
> > > to
> > > > > speak of. Think of an HTTP proxy web acceleration kind of thing.
> So, we
> > > > > will need to have some significant end-to-end testing that I
> hope to
> > > > > automate for performance, stability, compliance, soak testing.
> > > > >
> > > > > Would like to hear from the community on ideas about how to
> transition
> > > a
> > > > > tester who comes from the traditional process model with "big
> bang"
> > > > > integration and testing at the end into an agile team. The
> tester would
> > > > > probably not have many development skills but is a very good
> > > exploritory
> > > > > tester (however, could become proficient at developing testing
> fixtures
> > > > > in various scripting languages). I am already reading "Agile
> Testing"
> > > > > and it's a good source of information from this perspective.
> > > > >
> > > > > Thanks,
> > > > > Mark
> > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
>
>  
>

--
Lisa Crispin
Co-author with Janet Gregory, _Agile Testing: A Practical Guide for Testers
and Agile Teams_ (Addison-Wesley 2009)
http://lisacrispin.com

[markpetronic]

I bought your book two weeks ago. LOL. It's good information. I read through the first 400 pages in about two days as a quick overview. I think I'll go back and dig a little deeper now and finish the book. My first assignment to the tester that comes on board will be to read it as well. :)

Mark

--- In agile-testing@..., Lisa Crispin <lisa.crispin@...> wrote:

>
> For our Agile Testing book, we interviewed many teams around the world about
> their experiences transitioning testers to agile, you might find it helpful
> (I know, it seems so crass to sell my own book).
>
> There are also some articles and presentations on my website that relate to
> this.
> http://lisacrispin.com/wordpress/articles/
> http://lisacrispin.com/wordpress/presentations/
>
> Please keep us posted on your experiences.
>
> -- Lisa
>
> On Mon, Oct 5, 2009 at 11:36 PM, markpetronic <markpetronic@...>wrote:
>
> >
> >
> > Ok, Glenn, this is pretty intense - that you would go to all this detail
> > to communicate a "day in the life". Pretty awesome! Thanks!!!
> > You are obviously passionate about your job and I do appreciate that.
> > This was very helpful to me and I will definitely
> > turn on the guy I'm hoping will join our team to this thread and group.
> > I'm really looking forward to just seeing how
> > someone who really wants to be successful as tester will do in an
> > environment where we all /WANT/ testing to be a top
> > priority and not just the phase at the end that suffers all the schedule
> > compression because - well - that's how it always
> > is with traditional waterfall planning. I would get so frustrated as a
> > testing in the environment. You want to do good work
> > but are never given the time to adequately do your job as a craftsman.
> > Hope to change that with the introduction of an
> > Agile model for this project. Guess I'll see how well it goes. Will let
> > you all know how things work out.
> >
> > Thanks again for all your suggestions,
> >
> > Mark
> >
> > --- In agile-testing@... <agile-testing%40yahoogroups.com>,
> > Glenn Halstead <glenn@> wrote:
> > >
> > > Hi Mark,
> > >
> > > I've answered some of your questions below. I completely agree with
> > some of
> > > the other posters that what we do in our world (I hesitate to say
> > 'what
> > > works for us' because we're still trying to get there) may not be
> > applicable
> > > to yours.
> > >
> > > Thanks for the reply, Glenn.
> > >
> > > I would like to hear what your role looks like through the course
> > of a
> > > typical sprint. With developers doing TDD, the until tests are pretty
> > much
> > > done by each individual developer.
> > >
> > > * Do you spend time working to develop acceptance-level tests
> > and
> > > end-to-end tests?
> > > My focus is on testing soa services. My tests incorporate the esb,
> > > (enterprise service mus, IBM MQ), and often multiple backend
> > applications,
> > > whereas the developers tests do not test through the esb and do not
> > interact
> > > with other backend apps.
> > >
> > > * Do you develop the test scripts or help in their
> > development?
> > > I do develop the test scripts. Where I run into problems developing
> > the
> > > tests I interact with the developers to determine correct usage of the
> > > service operations or to confirm that the behaviour I'm seeing is
> > > incorrect. I'll often drag one of our other testser in where they've
> > got
> > > more experience in a particular area or just to get 2 heads on a
> > problem.
> > >
> > > * How do you interact with the developers as these are working
> > on
> > > completing stories?
> > > When development of a service operation is completed the devs release
> > it
> > > into our development integration environment and let me know it's
> > available
> > > to test. Sometimes I need to wait for the esb guys to expose the
> > service
> > > before I can get at it. These service operations have not yet been
> > released
> > > to our customer, the portal development team. Its fairly easy to get
> > the
> > > developers attention at this stage as the dev work is only just been
> > > completed. At this time they seem to be quite keen to answer
> > questions and
> > > look into unexpected behaviour. (We've only been working this way
> > (testers
> > > with the services dev team) for a few weeks. Previously we weren't
> > testing
> > > the services until after they'd formally released. When working this
> > way I
> > > found it much more difficult to get the developers attention and
> > interest in
> > > my testing as they were busy developing the next iteration.)
> > >
> > > * Are you part of all sprint planning meetings, reviews, and
> > stand
> > > ups?
> > > As yet I'm not in the sprint planning meetings. I was invited to the
> > most
> > > recent one but didn't attend because we had some specific panics on
> > that
> > > day. I am at the stand-ups and do a good bit of the talking; what
> > tests are
> > > failing that were previously passing (my pet focus), what's blocking
> > test
> > > development & execution, etc.
> > >
> > > Guess I'm trying to determine to what extend the tester engaged
> > from a
> > > resource loading perspective. Adding a full time tester to the team
> > for a
> > > project that might run for 12 months will probably be met with
> > resistance by
> > > upper management when they would typically expect them to maybe spend
> > 6-8
> > > weeks doing release testing at the end in the traditional process.
> > That's
> > > never really successful and is typically a bug finding exercise. I
> > expect
> > > they will want to see some proof of the ROI there. But, on the other
> > > extreme, I'm finding it hard to see having a full time tester for 12
> > months
> > > when developers should be doing a lot of the testing themselves. And,
> > at
> > > this time, there's no way I could even get a full time tester. Being
> > the
> > > first Agile project in the company that is a grass roots driven
> > project that
> > > I have instituted, you know how management is, they want to see the
> > proof
> > > before they commit. So, I've been working with our test lead to
> > discuss how
> > > I could use one of her people part time to at least start to create a
> > more
> > > cross-functional team. I'm just short on details regarding the
> > day-to-day
> > > activities that this person would be responsible for with the team.
> > >
> > > Tester resource: Where I use 'I' above, there are 4 of us full time
> > doing
> > > this. There are 5 different backend services teams and an esb team
> > > producing services. We're playing catchup at the moment. As I
> > mentioned,
> > > we're only been working this way a few weeks.
> > >
> > > If there is a full time dev team why would there not be a full time
> > tester?
> > > As you say, the drive for this would be dissatisfaction with how
> > things are
> > > currently working. There's clearly a desire to improve you're current
> > dev
> > > process and putting a tester in there could help. Who that tester is
> > is of
> > > major importance (in my opinion). They need to have a vision of how
> > things
> > > should be / could be and the drive and tenacity to get there. They
> > need to
> > > be able to change that vision as they go along, learning with the dev
> > team
> > > and they need to be part of the dev team, part of the creation of the
> > > software.
> > >
> > > There's a clear gap in my world between the testing I do and the
> > testing the
> > > devs do. Integration... thats the big difference. I test all the
> > > components (sub systems) together The devs test their components in
> > > isolation. I find things they don't and could not with theyre
> > testing.
> > >
> > >
> > >
> > > Regarding what a day for a dev tester might be like, I've sumarised my
> > day
> > > today it's been a fairly typical day. No doubt I've left out things
> > but
> > > thats not important.
> > >
> > >
> > > A brief summary of my day (today)...
> > >
> > > - Arrive @ work around 8am. Look at the hourly smoke test run on the
> > > radiator display. The screen shows the hudson junit results for my
> > smoke
> > > test pack (I use junit format to leverage hudsons built in reporting).
> > The
> > > test job is still running, it was kcicked off at 7am. It should be
> > > finished. I suspect theres a major issue in the environment causing
> > the
> > > test pack to take a long time because tests are waiting for the time
> > out
> > > when no response message is received from ESB. I run a single test
> > from my
> > > pc that touches a couple of the main env components. One of them is
> > not
> > > responding. I email the dev lead for that component and the env
> > manager
> > > They won't be in till around 9am. I leave the test pack running as I
> > should
> > > see a fail spike in my results graph in the radiator when the test run
> > is
> > > complete.
> > >
> > > - I take a look at the test of a new service operation I was trying to
> > get
> > > working on Friday. The app is not responding as I expect. I raised
> > this
> > > with the dev guy on Friday, he couldn't see a problem but it's an area
> > of
> > > the code that he reused so hes not 100% familiar with it. I'd begun
> > to
> > > suspect that maybe some of the prior data prep in my test is not
> > right. I
> > > work with one of the other testers on this and we figure out how we
> > should
> > > be prepping the data. We've both learned a bit about how one of the
> > other
> > > service operations should be used. I let the dev guy know there's
> > nothing
> > > wrong with the app in this area and I ask him about the two othere
> > area's
> > > that seem to be wrong that he's having a look at. He's planning to
> > release
> > > a fix today, he'll shout when I can retry my test (he didn't shout by
> > the
> > > way... note for tomorrow). I finish the current test and create one
> > for the
> > > the last operation of this service. I commit the new tests and label
> > them
> > > to be included in our smoke test job.
> > >
> > > - We're using a fitnesse based service test framework based on service
> > > fixture, jaxb, automatically generated java code (generated based on
> > the
> > > wsdls) and lots of other javaery stuff I only partially understand.
> > >
> > > - I have a 'sit around our desks meeting' with the other 3 test devs
> > on the
> > > team. I sit beside one of them in the esb dev team area, the other 2
> > sit
> > > across the corridor in the test area. We have a brief chat about
> > major
> > > blockers / failure causers. There are 4 main faults causing our 20 or
> > so
> > > test failures (out for th 100 or so tests in the smoke pack). We
> > cover what
> > > we're gonna be doing today. The purpose of this chat is to focus on
> > the
> > > info we want to provide and the questions we want to ask at the stand
> > up.
> > > We limit the meeting to 30 mins.
> > >
> > > - I pull out the per operation test results from our test run... by
> > the way
> > > the earlier env problem is resolved. the test pack has run again and
> > the
> > > radiator shows a big red spike where all the tests (~30 out of 100)
> > affected
> > > by that component failed and now pass again. I update our per service
> > > operation test status spreadsheet with the results from the lates test
> > run.
> > > A manual process but fairly trivial now, it's gradually become less
> > and less
> > > effort over the last 2 weeks as I've improved our test results parser
> > and
> > > summariser script. This is all about providing information that
> > answers the
> > > questions people ask us. "Do you have a test for this operation?",
> > "How
> > > many oerations pass / fail / aren't tested?", "Why are those not
> > tested?",
> > > etc.
> > >
> > > - There's no dev standup today. This seems to be a Monday pattern
> > because
> > > some of the contract devs haven't arrived yet. The dev manager and
> > one of
> > > the app dev leads stop by for a status update. The dev guys want's to
> > know
> > > if there's anything we need his help with. the dev guys are about to
> > embark
> > > on the next iteration and we still have failing tests and incomplete
> > tests.
> > > He's keen to get things in as good shape as possible before firing
> > into the
> > > next iteration. I share a couple of issues and questions and get a
> > couple
> > > of pointers re. things I'm investigating.
> > >
> > > - Blimey it's lunch time already....
> > >
> > > _ The delivery manager stops to look at our radiator with one of the
> > other
> > > managers. I pipe up about the big red spike and have a chat about the
> > > trends... number of tests increasing, number of failed tests
> > decreasing,
> > > this is good, we're making progress. This is good news but remember
> > this is
> > > only smoke tests though, there's a lot to do. We chat about the
> > broader
> > > coverage test packs and the gui tests that one of the other testers is
> > > heading up. We chat about the Continuous Integration build that's
> > being
> > > worked on to build a test environment from scratch and what tests will
> > be
> > > included. All of them is the conclusion, passes AND fails.
> > >
> > > - I meet with the build engineer / env guy who's doing the donkey work
> > of
> > > pulling together the environment build soluton with components from
> > all
> > > teams. How are our tests going to plug into this. We agree a few
> > first
> > > steps and there's some action on me to complete so we can move along
> > on
> > > this.
> > >
> > > - I need to build a new service model jar for the CI environment based
> > on
> > > the latest dev versions of the wsdls. In future the jar will be
> > environment
> > > independant but this will get us up and running. While this is
> > building I
> > > start work on the next of the new services that don't have tests yet.
> > >
> > > - Our dev integration environment is down as a deployment is running
> > I
> > > can't progress my test development The new jar build is finished so I
> > try
> > > running a test in the CI env to check it. It doesn't work either. I
> > > suspect that env is not working, either that or I cocked it up.
> > >
> > > - Blimey its 5pm already the env is still down, my tester buddy, desk
> > > neighour and care sharer suggests we call it a day. We head off home.
> > I
> > > annoy hiim with chat about testing, ruby and my new android phone
> > during the
> > > journey.. more tomorrow, wahey.
> > >
> > >
> > > I hope sharing this is of some interest / help but again I emphasise
> > my
> > > agreement with others that this is very specific my my world and may
> > well be
> > > completely irrelevant to yours.
> > >
> > > I hope you're successful
> > >
> > > Glenn
> > >
> > >
> > >
> > >
> > > Any thoughts here?
> > >
> > > Mark
> > >
> > > 2009/10/4 markpetronic markpetronic@
> >
> > >
> > > >
> > > >
> > > > Thanks for the reply, Glenn.
> > > >
> > > > I would like to hear what your role looks like through the course of
> > a
> > > > typical sprint. With developers doing TDD, the until tests are
> > pretty much
> > > > done by each individual developer.
> > > >
> > >
> > >
> > >
> > > >
> > > > - Do you spend time working to develop acceptance-level tests and
> > > > end-to-end tests?
> > > > - Do you develop the test scripts or help in their development?
> > > > - How do you interact with the developers as these are working on
> > > > completing stories?
> > > > - Are you part of all sprint planning meetings, reviews, and
> > stand ups?
> > > >
> > > > Guess I'm trying to determine to what extend the tester engaged from
> > a
> > > > resource loading perspective. Adding a full time tester to the team
> > for a
> > > > project that might run for 12 months will probably be met with
> > resistance by
> > > > upper management when they would typically expect them to maybe
> > spend 6-8
> > > > weeks doing release testing at the end in the traditional process.
> > That's
> > > > never really successful and is typically a bug finding exercise. I
> > expect
> > > > they will want to see some proof of the ROI there. But, on the other
> > > > extreme, I'm finding it hard to see having a full time tester for 12
> > months
> > > > when developers should be doing a lot of the testing themselves.
> > And, at
> > > > this time, there's no way I could even get a full time tester. Being
> > the
> > > > first Agile project in the company that is a grass roots driven
> > project that
> > > > I have instituted, you know how management is, they want to see the
> > proof
> > > > before they commit. So, I've been working with our test lead to
> > discuss how
> > > > I could use one of her people part time to at least start to create
> > a more
> > > > cross-functional team. I'm just short on details regarding the
> > day-to-day
> > > > activities that this person would be responsible for with the team.
> > > >
> > > > Any thoughts here?
> > > >
> > > > Mark
> > > >
> > > > --- In agile-testing@... <agile-testing%40yahoogroups.com>,
> > Glenn Halstead glenn@ wrote:
> > > > >
> > > > > Hi Mark,
> > > > >
> > > > > I'm not a regular poster here (although I am a regular reader).
> > > > >
> > > > > I'm a test automation guy (historically) and I'm currently working
> > with
> > > > the
> > > > > dev teams on a project where we're trying to improve our early
> > testing.
> > > > >
> > > > > I think of my role as being there to help 'demonstrate, as soon as
> > > > possible
> > > > > after the software is created, that it does what it's intended to
> > do.'
> > > > >
> > > > > Making the tests automated and using continuous integration helps
> > us to
> > > > > demonstrate that the now existing software continues to do what
> > its
> > > > supposed
> > > > > to do whilst allowing me to focus on new code rather than on
> > manually
> > > > > re-testing existing functionality. It's a real challenge to keep
> > existing
> > > > > functionality working as new development continues. The continuous
> > > > > integration approach helps achieve this but the team has to 'care'
> > when
> > > > > passing tests start to fail (an area that we've found
> > challenging).
> > > > >
> > > > > This 'demonstrating that the software works' is in the first
> > instance
> > > > > demonstrating to myself and where the software doesn't work as
> > intended,
> > > > > demonstrating to the developers. I feel that the 'demonstrating'
> > mindset
> > > > > helps in providing confidence to anyone who's interested in the
> > status of
> > > > > the software being developed.
> > > > >
> > > > > I find that thinking and using the word 'demonstrate' rather than
> > 'test'
> > > > > helps the collaboration between testing and developers in our more
> > > > > traditional organisation. It feels more like I'm 'helping our team
> > show
> > > > > that we've got working software' rather than 'showing the dev guys
> > that
> > > > > their software doesn't work'.
> > > > >
> > > > > Just a few thoughts from my own experience. I hope it helps.
> > > > >
> > > > > cheers
> > > > >
> > > > > Glenn
> > > > >
> > > > > 2009/10/3 markpetronic markpetronic@
> > > > >
> > > > > >
> > > > > >
> > > > > > I'm the SM for a new agile team in our company. This is the
> > first team
> > > > > > doing agile in our company that I am aware of. In keeping with
> > building
> > > > > > a cross-functional team, I am trying to now pull in someone from
> > > > testing
> > > > > > to contribute. We have really just started and are in our third
> > sprint
> > > > > > (about 2 months into the project). We already have a nightly
> > build
> > > > > > engine basically working, are using JUnit and Emma for the Java
> > part
> > > > for
> > > > > > unit testing and coverage, and CxxTest on the C++ client side
> > > > > > development. We want to do CI and are trying to really do things
> > right
> > > > > > from the onset because this project will be looked at from other
> > side
> > > > > > this group and I want us to succeed and inspire a cultural
> > change in
> > > > the
> > > > > > company. The team is 6 developers at this point. The product is
> > a
> > > > client
> > > > > > (embedded C++) and server (Java on Linux) application with no
> > real UI
> > > > to
> > > > > > speak of. Think of an HTTP proxy web acceleration kind of thing.
> > So, we
> > > > > > will need to have some significant end-to-end testing that I
> > hope to
> > > > > > automate for performance, stability, compliance, soak testing.
> > > > > >
> > > > > > Would like to hear from the community on ideas about how to
> > transition
> > > > a
> > > > > > tester who comes from the traditional process model with "big
> > bang"
> > > > > > integration and testing at the end into an agile team. The
> > tester would
> > > > > > probably not have many development skills but is a very good
> > > > exploritory
> > > > > > tester (however, could become proficient at developing testing
> > fixtures
> > > > > > in various scripting languages). I am already reading "Agile
> > Testing"
> > > > > > and it's a good source of information from this perspective.
> > > > > >
> > > > > > Thanks,
> > > > > > Mark
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> >
> >  
> >
>
>
>
> --
> Lisa Crispin
> Co-author with Janet Gregory, _Agile Testing: A Practical Guide for Testers
> and Agile Teams_ (Addison-Wesley 2009)
> http://lisacrispin.com
>