This is an open question to all that have ideas or have implemented the Extreme Testing methodology in their environment.
I am evaluating this methodology for it's fit into our development structure, as my company is a very customer driven environment with requirements changing sometimes up to the very hour before testing, and times, even after testing has started. This is not a failure in how the development group is defining the requirements, it is a given choice to work with the users/customers in a hands on up to the release minute environment as what we supply is definitely one of those tailoring out product to the customer needs. We have a release every other week, and try to ensure that if a customer has requested something to go out, that it usually does, and any changes that they see they would like to the site prior to it being turned on for the masses.
With this said, getting the requirements completely documented, then designing the required test cases, and then executing those test cases from end to end at least once is a job that doesn't get done.
Having read the information that I could find on Extreme Testing, it seems that this would be a better fit for the development scheme that my company has chosen. The only hurdle that I have at the moment is we are also a company that is audited by the companies that we sell to, and by 3rd party auditors at their request. I am looking for input on how this method of testing is adequate (or how I can make sure that it is adequate enough) when it comes to sitting down across the table from a group of auditors and demonstrating that you are producing a quality product to the best of your abilities?
Thanks kn advance for any input.
[This message has been edited by awdavis (edited 01-27-2003).]
Well, read you topic. the same situation is here in our company. even our company is ready to change the logic at last day of delivery project. which is very diffcult for testers to test. so would any body please help us. how to handle this situation.
I'm not an XP practitioner but I've been looking at some of the literature lately so I'll offer a few observations that may help until someone more experienced finds you.
A methodology like XP tries to limit documenting to only what is absolutly necessary. But if you are being audited, what is "necessary" grows a lot, doesn't it? So how do you keep your documenting activities efficient? I suggest you look at keeping the documenting activities tightly integrated in the basic XP activities. Make your code rigorously self-documenting. Embed low level design documentation right in the source code so it is updated with each code change. Test sets tell a lot about how a system really works. In XP you are writing and running tests all the time. Structure & document those automated tests so they can serve as your v&v documentation.