Here is another great video. This time, the topic is Agile Testing. I met the speaker, Elisabeth Hendrickson, a few months ago at Agile Open Northwest here in Portland. She led a couple of sessions, and they were some of the best attended and interesting ones of the bunch. This lady has ENERGY and a PASSION (BIG CAPS HERE) about testing. Before meeting her, I didn't know somebody could care so much about testing software. This video is from December 2006, but is still very relevant. If you are transitioning to Agile and have been used to having a separate testing group, this video is for you. If you are still struggling with how testing should be done on an Agile project, you will get something of value. Elisabeth does a great job helping understand the shift that needs to take place to do testing differently within the context of Agile. Here is the video:
Subscribe to:
Post Comments (Atom)
3 comments:
Skip, when you get a chance, will you please summarize a few of the key points for us readers who don't have an hour to spare? Or were there any points in particular that you feel are critical to understand? :-)
Sure I will, but I still encourage everyone to watch the video.
In summary, traditional testing was done too late in the process. Testing teams didn't understand the software changes very well, documentation that was produced was outdated, the amount of testing was overwhelming and the cost to fix anything broken was too great. Worst of all, by the time testing was underway the project was usually behind schedule and there was great pressure to get things done. Therefore, some defects were "logged" into repositories to deal with later and some defects weren't even discovered given limited time for testing.
In the Agile world, a different mentality needs to take place. Testing should be done early, often and not wait until the end. The entire team is responsible for testing the product, not just a separate testing group. Tests needs to accomodate change, so automation is key. Best of all, tests need to become the documentation of the system defining what "done" means, verifying business rules and requirements, and driving design of the product through practices such as Test Driven Development.
I completely agree that the earlier the better. In fact, at my new gig we started talking about testing after only a week of coding. I had put together a basic reporting framework for Jasper Reports, checked in the code, and sent a link to QA for a preview. The QA lead discovered an issue right off the bat that I had not even considered at all, and it shaped the direction of the project immediately.
I could have gone on for weeks or longer under a wrong assumption, but having QA eyes on my work early on ensured that I stayed on the right track.
Post a Comment