What is it about Agile methodologies causes them to be "Old Boys Clubs". I can dig around the internet and find all the information I want on Scrum, Agile or TDD, but all of it is from the developer perspective. What part of this is only concerned about one or two portion of the SDLC? Yah it covers off the Coding / Debugging and, in some cases, the Requirements Gathering portions just fine, but those are only 2 of the 5 tenants of the SDLC. What about Architectural Design and System Testing? I have not seen a single post, article or explanation of what the steps are for taking an iteration based approach to software development and turning it over to team or business testers with cohesion and continuity. Why is that?
Is it because the Agile community is focused solely on the process of creating the software, or is it because the process of business acceptance testing is so clearly defined? My experience makes me believe that this community is focused on one thing and one thing only. They have gotten so wrapped up in the process of writing the software (which I tend to thing is a good process) that they've started to wear blinders. They can't see that there is more to the process than, in the case of TDD, write test, make test fail, make test succeed, and refactor. Well, I tend to believe that most of us creating business software have to answer to the....hold on....brace yourself....yes, the business. Now to do that we must turn software over to them that can be tested or used either through the development process or at the tail end of it. Yes, I know...that sounds very waterfall.
So what I'm trying to figure out right now, as I approach the first project I've worked on that dictates an agile approach, is how do you turn your iterations over to the different test teams. In my case I'm thinking of having 2 week long iterations and, after the iteration is complete, we provide a build to the team testers. This I have no problem with. The problem arises when I begin to think about how this process works when I add in the need to release the iteration to User Acceptance Testing for the business to play with, verify and generally check over. Traditionally I've released to the internal test team, started a loop of test and release with that team and finally provided a tested build to the UAT team.
So what do I do once I've released to the internal test team? My instinct says wait, fix and retest. The problem I see is that if I follow this process I will be ready to release to the UAT team once the code from any subsequent iteration is started or worse yet completed. The only thing that I can think of doing is releasing the code to UAT less often than I release it to the internal test team. What is the problem with this? Well, in my mind it's less agile. Maybe I'm wrong though.
At any rate, I'm open to suggestion, opinion or, if it's your style, ridicule.
I'm the Igloo Coder and I'm thinking that I should be building my igloo one tested block of snow at a time.
posted @ Monday, May 15, 2006 9:18 PM