Is Agile Testing for a non-Agile Team?

[Mike Farnham]

What if we are more traditional than Agile?

Would we still benefit from reading "Agile Testing"?

[Tina Ma]

I feel:
If you have access to in-construction software to test, then you can follow agile methodology to test it.
But if the whole team follows a traditional SDLC, then you will not have the software to test before the end of development of a stable version, then ofcourse you cannot take an agile-approach to your testing work.

[Mike Farnham]

We do develop code in packages (.jar and .war)
so it is possible to add Unit Tests to the code.

Unfortunately, we do not have direct contact with our customers,
so we are not interacting on a daily or weekly basis with our customers.

But, I will ask again in a slightly different way,
is there anything in the book "Agile Testing" that would benefit people who do testing
even if they don't do development, in an agile way?

Surely there are some "Best Practices" presented?

[Janet Gregory]

Hi Mike,

I think there are lots of ideas that can be borrowed from agile and used on traditional teams. Of course, it is easier if you have a customer on site, short iterations, etc., but don't let that stop you.

We talk about the agile testing quadrants as a way to think about the purpose of testing. I think that alone is worth while.

Lisa an I also just wrote an article which borrows ideas we have learned from agile teams.
http://www.informit.com/articles/article.aspx?p=1322400

Janet

[Mike Farnham]

Thanks Janet (and Lisa) for your replies and insight.

I did find the article on InformIT.

I wonder if there is an anti-pattern or syndrome. "Too busy to test",
or "Too busy to write tests"?

[Lisa Crispin]

Mike Farnham wrote:Thanks Janet (and Lisa) for your replies and insight.

I did find the article on InformIT.

I wonder if there is an anti-pattern or syndrome. "Too busy to test",
or "Too busy to write tests"?

That does sound like a valid pattern!

Mike, at my last job, the development organization said it wanted to "go agile", but never adopted any practices except for one small (and successful!) project. The programmers wouldn't automate unit tests. We released every two weeks, but that didn't make it agile.

While I tried my best (using patterns from Rising and Manns' Fearless Change) to motivate the organization to change, I focused mainly on making my own QA team successful, and working with the developers and customers as best I could. Within our QA team, we used agile practices such as using good design techniques and refactoring on our automated test scripts, pairing, working in small increments, and collaborating closely with other teams. I got more help from programmers on functional test automation when I started writing test scripts in the same language they used for the app. I went to the dev managers to ask them their greatest areas of pain, and borrowed what I could from Agile to address those. For example, they complained most about not getting useful requirements. I suggested writing customer-facing tests ahead of time in place of requirements documents. They agreed to this practice, and it solved the problem.

That's just one example. The agile approach to testing is mainly about applying certain values and principles. You can try to get more involved with other parts of the organization, even when testers are on a separate team. You can also try to work more closely with business experts, learn more about the business so you can help deliver value, and step out of your comfort zone to find more ways to contribute.
-- Lisa