For Programmers: Free Programming Magazines  


Home > Archive > Software Testing > November 2006 > Driving Agile









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author Driving Agile
JTC ^..^

2006-11-18, 8:02 am

I would like the opinion of the group as to what it's like to be the
tester driving the enthusiasm of adopting Agile Methodology. Opinions
from either persons who have done this or has an informed opinion.

I've been inspire by Agile Testing talk given by Elisabeth Hendrickson.
(http://video.google.co.uk/videoplay...6235846&q=agile)
from a testers point of view. It has given me some fuel to do more
reading and research into the concept of Agile Methodology and I feel it
is appropriate to improve the "ad hoc" methodology adopted by the
in-house development team I work in. But am I in danger of being the
only one driving this enthusiasm. The methodology will undoubtedly
require discipline from everyone to follow it.

Opinions please! Thanks in advance.

--
Regards
JTC ^..^
Vladimir Trushkin

2006-11-20, 8:04 am


JTC ^..^ wrote:
> I would like the opinion of the group as to what it's like to be the
> tester driving the enthusiasm of adopting Agile Methodology. Opinions
> from either persons who have done this or has an informed opinion.
>
> I've been inspire by Agile Testing talk given by Elisabeth Hendrickson.
> (http://video.google.co.uk/videoplay...6235846&q=agile)
> from a testers point of view. It has given me some fuel to do more
> reading and research into the concept of Agile Methodology and I feel it
> is appropriate to improve the "ad hoc" methodology adopted by the
> in-house development team I work in. But am I in danger of being the
> only one driving this enthusiasm. The methodology will undoubtedly
> require discipline from everyone to follow it.


Amen! As any other methodology ;)

> Opinions please! Thanks in advance.
>


Yeah... This is funny! :)

As for comments, well... I did not like the idea that traditional
process is always a chaos. The mere starting postulate of this speech
is wrong. I agree that in most cases there is not enough initiative,
enthusiasm and management power put in fighting chaos. But as the
lecturer said this is not an ideal world and some practices may not
work as well in agile processes. This is all about human wits and
responsibility.

There is also a thing that I liked very much: Traditional approaches to
controlling quality are anti-agile. And, I say, so are others :) Just
imagine a 100% quality thing. Does it need testing? No! Then this is
always an addendum, an extra, to what we are doing. Even in agile
world, we are testing because we are not sure the result is good.

Further in the speech... Oh, I am disappointed... Big-bang thing is an
old argument that shall be buried forever. Burn it out! This is not an
argument any more. I know no one who uses it and the divantages are
well known to even those who just started to work in the industry.
Please stop referring to Waterfall as an argument!

The part about "deliver often"... Yeah this is always useful. What for?
I think that the reason is that we need to make sure we are going right
direction until we got too far (the main problem with waterfall). So,
thanks to the lecturer for opening our eyes, but we already know how to
fight the main waterfall divantage. It was invented long before
agile era.

BTW, all this stuff about "deliver/release often" reminds me about
chaos controlling theory. Is not it what was referenced in the
beginning of the speech? Why do you need it in agile? The answer is
simple: because it is the same old chaos and it should be controlled.
But the reason in agile is thought to be different. They think that
chaos is in head of people who do not realize what they need of a
product. As I already said here this might be a case (especially in
outsourcing world where agile fits best IMO), but the difficulty of
doping something is not an excuse for not trying. I have a good
experience at it and yes, it takes efforts, bit it's extremely
rewarding at the same time.

Another thing that strikes me is comparing traditional testers to last
defenders. This is not correct, at least in our organization. And it
never was so. Even in dark ages, when there was a complete chaos we
thought of ourselves as being part of development team, as the second
wing of an organization, completing development. Yes sometimes we are
last defense but not always. Most of the time, we are supporting the
development efforts by providing timely feedback on quality by
revealing issues with organization earlier making the cost of quality
tend to zero.

The purpose of documentation was also distorted. It's been said that
documentation is needed to "cover our ass" in case something goes
wrong. No. This idea is bad. I was almost fired once for being too
resistive to a manager who thought that the first thing QA manager must
do is covering his ass. He thought this is due to being in the first
row to take blame about quality issues. Well, we are and I learned that
this dark side of our profession is for those who dare. Being able to
take a blow and arguable defend your position is one of important
qualities that we all should have. But covering your ass and putting
efforts into it... nahh... this is for the weak.

The rest was not of much interest to me, so I skipped it. (Sorry guys I
have no more time. If you think that's important for me to complete
listening just let me know. Now I see no reason in having more of it)

Sorry if I am being too harsh. I didn't want to obuse anyone's
feelings. But the arguments I have found in this presentation are weak.
This is a strawman IMO.

BTW, I noted people going to and fro. Was the auditory really
interested in hearing that? And the lecturer is too aggressive IMHO. It
burdens me a little bit.

----
Best Wishes,
Vladimir

"Sell me the infection
It is only for the weak..."

Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2008 codecomments.com