Iterative Development
What are people's experiences with iterative development? A large project I'm working on is working to an interative process, albeit not how I'd have done it. Essentially we have a weekly or 2-weekly build which is used as a project milestone and where we aim (as the test team) to test what functionality is available.
As it stands we've been having interim builds since January and are yet to see any real end-to-end functionality. Hugely frustrating for everyone concerned and we're only now getting close to having something worthwhile to test.
Were I to be involved in such a process again I'd almost certainly suggest forming interim builds around a guaranteed area of working functionality and I'd most certainly ensure our development team had ticked off a number of use cases as "tested" before commiting my team to do any testing.
We had intended to use our early involvement to get the testers familiar with the product, find defects early etc etc. In the end we've not had the functionality to add any kind of value via early testing. Very annoying.
Anyone else had similar experiences?
Hi,
I tend prefer the approach of Scrum style sprints with interation forming each Sprint. Within each sprint you can forumulate which cards\stories (use cases) apply to each sprint. If you keep the sprints short, knowing which cards will pass into the next sprint you can delivery early and often to your stake holders. The bug run sprints are also good as these can be shorter sprints that allow you to focus on testing and creating any new cards\taking on bug realted cards from previous sprints in the iteration.
Andy
I am in a similar boat as Andrew, we use 4 week sprints and daily scrums. Development work is divided up in to blocks of time as small as a quarter of a day to a maximum of 3 days. Each check-in of code, is to be considered a single unit of change. Each time code is checked in, QA gets a testing ticket which describes the change, and what areas to investigate. To avoid one group waiting on another group, for example QA waiting on a code change from dev, everyone is able to download the source and build it. This way, no group is ever waiting for a build from someone. Best of luck.
When I work with test teams using any of the iterative development flavors (usually scrum), this is the number 1 complaint. The advice I give them, and (IMO) the underlying problem is a lack of definitions of "done".
Work in an iteration is supposed to reach "done" status. However, if everyone involved isn't part of creating the "done" definition, what usually ends up happening is that for developers, "done" may mean "it compiles", whereas for testing, "done" means "it does something that I can test and use the same way our customers will".
It's as though we were working on the same project!
I had very similar experience at a previous place of employment.
It was very annoying. I would do things differently next time, as I think I learned a lot from the very fact that the iterative nature of the project did not work that well.
I've got similar frustrations with my project (3 week iterations). I waste a ton of time trying to determine what is testable. The devs break up features into dev tasks and track them in Visual Studio Team Server. So every three weeks I get a new build and I query the completed dev tasks for said build. The problem is, I don't always know the dependencies. So when I log a bug against Feature A, the devs typically reject it because Feature A is dependent on Feature B and Feature C, in which case I've just wasted everyone's time.
We do our best to test single web services and even write our own QA unit tests for these sometimes. The problem is, you still have to do the functional testing and that's the stuff that counts. So as the iterations pass you by and you keep saying "I'll test Feature A in the next build because maybe Feature B and C will be done", you begin wasting more time on administrative tasks like managing your test cases. And then before you know it, stuff becomes testable...too much stuff!
We're on iteration 32 now and there is an overwhelming amount of stuff to test. The devs are like 60% code complete and QA is like 20% test execution complete. Everyone wonders why QA is so far behind and how they're going to catch up.
So yeah, I agree. If the features are not released logically to provide working functionality, it's a real nightmare for QA and probably misses out big time on many of the advantages of Iterative development.
