Comments on: Agile Principle 9: Agile Testing Is Not For Dummies!

By: Kelly Waters

Kelly Waters — Sat, 02 Jun 2012 06:20:27 +0000

Hi Steve,

I would advocate that UAT is something that’s completed for each and every piece of work (ideally user stories) as they are delivered throughout each iteration. I would also advocate one final UAT check before releasing the software into production, but the nature of that would be more generalised than the individual story UAT’s and would also be a lot shorter than a full UAT in one big block.

Kelly.

By: Steve Shields

Steve Shields — Fri, 01 Jun 2012 08:43:23 +0000

If we are incorporating Agile into Project/Programme IT delivery would you still advocate UAT as a necessary and very important final piece of the delivery jigsaw?

By: Agile Software

Agile Software — Fri, 20 Jan 2012 07:37:12 +0000

In Agile, I prefer the tester takes two roles, Tester and Business Analyst. The tester communicates with a product owner to get requirements, write the test cases, and present requirements to coders. The test cases should be finished before the coder implements, the coder can review and also use the test cases during the implementation time. The tester still report bugs and inform coders to fix them. The product owner will do UAT after the tester complete testing.
How do you think?

By: Cheap Domain Names

Cheap Domain Names — Thu, 16 Dec 2010 05:00:13 +0000

Brilliant stuff, man! What you have to say is really important and I am glad you took the time to share it. I hope that I can learn more about testing. According to me Software testing is provides an objective, self-sufficient view of the software to allow the business to value and understand the risks of software implementation. Thanks for sharing your opinion. I am yet to find anything as enlightening as this on the web.

By: Anonymous

Anonymous — Mon, 12 Jan 2009 20:39:00 +0000

I think the QA/risk mitigation aspect of testing becomes overstated as you use richer web frameworks with less custom code. For example, CI is clearly a necessity for developing reliable and secure banking systems in Java/C++, but for lightweight modular web development (e.g. customisation of typical web publishing apps) mandatory CI is a victory of process over end product. This is a clear case of the tail wagging the dog and violates the first principle of the agile manifesto. Over-adherence to process in the name of 'agile' can easily become a kind of techno-beaurocracy that should be seen to fly against the spirit of agile/lean.

That's not to say that developers shouldn't use tests or automate them where convenient. The big value is in TDD _as a coding technique_ to keep developers focused on features (also helping achieve the 80/20), and dev assurance that encourages refactoring.

By: pkr

pkr — Tue, 08 Jan 2008 05:56:00 +0000

I'd recommend reading Conventional Software Testing on an Extreme Programming Team

By: Steve Watson

Steve Watson — Thu, 19 Jul 2007 08:58:00 +0000

I must admit that after 18 years in a waterfall approach, it would be astruggle to change to an Agile approach. However I can see the benefits of throwing off the shackles that bind us as testers and starting to have more impact on what is produced.
We have come a long way from throwing code at testers at the end of the dev cycle, and testers only being used to match results versus spec. I enjoy being involved in decision making, helping to shape how a product looks and works, and it makes it more of a collaborative effort, encouraging team building.
You can use bits of Agile even in a waterfall project, by being proactive as a tester, challenging the spec (nicely!), making comments on design and usability etc.
In some ways the thought of changing my whole approach to Agile scares me but in another way I'd love to give it a go!

By: Paul Littlebury

Paul Littlebury — Sat, 30 Jun 2007 13:00:00 +0000

Agile a good methodology, but hardly re-invents any testing rules. Testing should always be involved from the outset, any software development manual from 1980's onwards will say that. Developers seem to have forgotten their own training.

Modern software development happens in tighter more rapid cycles - its that simple. What is generally missed out from Agile, which is the the whole point - is involvement by the client, or the end-user is no such client exists. Making software quickly is not the focus of Agile, it's retaining control and ensuring that what a client wants is what they get, and that changes can be made mid-stream with minimal impact.

Have a look at usabilitymustdie.com, as it contains some good reality-checks for developers. Not Agile specific, but succinctly summarises to crisis in modern development. Development has become far too smug and self-congratulatory to the point of dictating to users what they want, instead of LISTENING.

By: Piersj

Piersj — Fri, 27 Apr 2007 10:59:00 +0000

I came across this netcase on agile testing which might be of interest?

http://parlezuml.com/blog/?postid=394