I seem to notice that I like posing questions in the title of my entries... Anyway, I am currently trying to unravel what exactly Agile testing is. In fact the question could be: how do testers fit into an Agile project? A short Google search tells me that this is still a hot topic, and that there is division over it (an essay from testing.com, Agile Testing, what is it?). I can't help feeling that there is still a silo mentality where each group (development and testing) is going away on their own and deciding what their roles in an Agile project is - which kind of goes against the manifesto.
I have recently witnessed three Agile projects where the testers sat in the same room as the developers but yet both groups built their own set of automated functional tests. This seems crazy to me, but I am willing to accept that I am the odd one out here.
What are people doing elsewhere on projects? Have people been successful in integrating teams as Brian Marick describes, or have you just assumed that the twain shall never meet and focused on getting the developers to produce better code (and functional tests) on their own?
In closing, I do like Brian's categorisation of testing.
Subscribe to:
Post Comments (Atom)
3 comments:
I agree, viewing testers and developers independently poses a significant opportunity lost for any project. In line with Lean theory, processes with this ol' school approach inevitably produce waste.
Perhaps the industries lack of action is this area is a reflection of the weight of 'correctness'?
Surely key to eliminating the waste is:
- Both groups coming together (an interesting approach is mentioned Agile Organizational Patterns; splitting a team into small focused teams of 5 or so with devs, analysts and testers)
- The entire team understanding test artifacts produced and exploring their complementary nature (or lack of)
Further to that, I'll write an entry soon about how I attempted to blend a team and the outcomes that followed.
One would hope that the testers are recording (and refactoring) exploratory tests that hadn't (yet) been incorporated into the functional test suite being driven by the developers (which should parrot the story's acceptance criteria).
Duplicate acceptance tests are bad juju - they magnify brittleness, increase maintenance workload, and confuse everyone (which one is authoritative?)
Post a Comment