I just read an article by Dave McMunn at the Agile Journal that talks
about how agile will change the roll of project managers and testers.
This article discusses how the roles of PM, BA, and QA change with
agile development, and the implications that shift has for people and
organizations.

http://www.agilejournal.com/content/view/109/43/

Dave says "On a recent engagement, my company walked into an
organization that was struggling to adopt agile software development
practices. There was clearly energy and willingness on the part of the
development team to try new practices. However, the confusion around
new responsibilities of the project manager (PM), business analyst
(BA), and quality assurance tester (QA) was preventing progress. While
the developers and architects were being challenged to adopt some
different practices, the main responsibilities of their "roles"
remained the same - to design, code, and unit test. In contrast, the
responsibilities of the PM, BA, and QA were undergoing change that was
in conflict with the organization's traditional expectations. The
training, skill development, and management structure were not aligned
to the new demands of supporting an agile development process."

mthompson quoted:


They lead the project, and the programmers are their bitches.

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!

> However, the confusion around

Let me guess... they were not said what to do.

----
Best Wishes,
Vladimir

mthompson wrote:

I think this topic is relevant to Ad-hoc testing posted a little
earlier. I dare suppose the word agile here means that documentation is
not in favor and taken as unnecessary. In this case the role of QA, or
that of a tester (which is the right word in this case), will be way
not enviable.

See topic:
http://groups.google.com/group/comp...690c3a994bc5f49

----
Best Wishes,
Vladimir

Vladimir Trushkin wrote:


Then you would be wrong. The most important form of documentation is the
test corpus, and this should be literate and presentable. Anything you want
documented you should seek to write up as a test, and if you can't test
something then maybe you shouldn't code it!

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!

Hello,

"They lead the project, and the programmers are their bitches."
lets stick to some neutral facts, I mean what happens if they have only
male programmers? :-)


when considering XP as one of the agile models, where there is in the
worst case not so much documentation
(but hopefully good documentation in form of test cases
BTW: I agree, to this fully:
"Anything you want
documented you should seek to write up as a test, and if you can't test
something then maybe you shouldn't code it! " ) :

you can read here, there are some comments on the role of a tester in
XP:
http://www.stickyminds.com/sitewide...OK&ObjectId=562


as Crispin tells:
the role of the tester is the tie between developers and customer
e.g.
the customer might not understand the unit tests, because they are too
technical
so the tester creates and demonstrates the high-level tests for the
customer
the tester explains also everything to the customer


when we stick to the test levels from sequential models, Spillner says:
the focus in development is on unit tests (component testing)
for system- and acceptancetest the customer has responsibility
and integration tests are also not present really,
because only the unit tests are repeated in the continuous
integration
e.g. no new test cases are written for "hunting" interface-problems

so Crispins new role for the tester makes quite much sense.

(ok, the question here is, how far Spillner describes a real life-XP,
since XP is adapted everywhere to the conditions in a
company/project/...)


another thing is (the quotes are taken from the article "How Agile
Development Is Changing The Role Of Project Managers, Business
Analysts, And Testers"):

"On a recent engagement, my company walked into an organization that
was struggling to adopt agile software development practices."

-> if the company does this, then it should provide guidance/help
like the author says: "The training, skill development, and management
structure were not aligned to the new demands of supporting an agile
development process."

When the conditions are correct, I believe the other things work also
well. Because I think if everybody wants XP, then problems will be
solved faster:
"As a customer team, its focus shifts from individuals and individual
task completion by role to how well everyone can work together to
translate business needs into a testable/verifiable working piece of
software."
"The more flexibility the team members have in adapting to this kind of
shifting demand, the more efficient the team will be."
"BAs must get better at learning how to think of tests for
requirements, and QA testers must learn how to work with business
owners who may not clearly understand exactly what they want."


CU, Erkan
http://www.skilledtesting.com/



reference for Spillner:
Andreas Spillner, Thomas Roßner, Mario Winter: Praxiswissen
Softwaretest - Testmanagement, ISBN: 3898642755, page 36

Phlip wrote:

Ok. When do you get the test corpus? Who (what) is there to teach you
the way application should work?

Just read the original post and you will get the context that made me
think that no one told testerd how application should work and they are
to rely on themselves in fidning this out. We call it ad-hoc testing.

When you are talking about tests to be documentation then, I dare say,
testers will be doing exactly the same as developers do in their
testing -- test first. What is the difference? Another perspective?
Unbiased view? Independent quality control? I would argue with that, as
testers will not be able to validate the concept if their test design
will be led by code design. There is no way they will be able to
abstract from it sufficiently if they will be thinking how to build
their high level user-oriented (system level) tests based on code
design.

Having a description of what a module is supposed to do (which is not
too costly to create btw) helps people to build their test design based
on how system should work not on how it is designed or built to work,
thus providing confidence we created what is supposed to be done, not
what we managed to do.

Anyway, arguing here we need to put limitations to our discussion. I am
speaking about Medium to Large pojects, when documentation is vital and
saved A LOT of rework. In Small business the simple concepts that I
learned will also be of help, though Small projects are much easier to
control and manage, so OTHER WAYS would work too.

----
Best Wishes,
Vladimir

Vladimir Trushkin wrote:


Remember when I said the domain analysts, customer liaisons, and test
engineers make the programmers their b-words? That's how; by writing
literate acceptance tests.


Sorry; thought this was the original post. That organization gets what they
deserve.


High-level tests are not GUI-driving.


And the best such description is an executable test. Also not too costly to
create.


Agreed. I am indeed describing systems based on reading others' reports
actually doing this stuff; not from personal experience.

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!