AgileAttitudes Article
 
 
 

Vol 01 Issue 11- Tear Down The Wall- Do SQA First

  
 
Back to the list of articles Agile Attitudes Volume 1, Issue 11 Nov. 4, 2004 A free bi-weekly email newsletter Brought to you by Agile Rules consulting www.agilerules.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Welcome to Agile Attitudes, a newsletter of ideas, insights and technical tips that help people find better ways to develop software. Feel free to share this with anyone - just be sure you send or print the whole thing, including the copyright notice. Directions for managing your subscription are below. O><O><O><O><O><O Ron Morsicato will be discussing agile software development at the next meeting of the New England M User's Group. Damon Carr of Agile Factor will be the main speaker. The meeting is Tuesday, November 9 at 6:00 PM. For more information and directions see http://www.nemug.org/nov04mtg.html O><O><O><O><O><O Tear Down the Wall -- Do SQA First by Ron Morsicato A few years ago I was audited for conformance to a particular industry standard. The first question the auditor asked me was whether or not development and SQA were separate organizations within the company. Having several military contracts, I was able to answer to the affirmative on the behalf of the company. This was a very telling question. It supposed that in order to do business with my company, the auditor had to make sure that SQA could in the future become his proxy, conducting audits. The result would certainly lead to an authoritarian relationship between SQA and development. It seemed like the premise of the question was that some structure has to be in place to make sure developers do the right thing (whatever that is!) not because of their beliefs, but because they would have to answer to their company's "process police." This kind of relationship produces conflict, whereas agile practitioners try to foster collaboration. We at Agile Rules have often pointed out that the development pattern for testing one's code is in the exact reverse of typical industry practice - we write unit testing code first, and then go on to write production code that passes the test. Similarly, the agile outlook on the role of SQA involves doing things in reverse of the conventional wisdom. Rather than tossing the code "over the wall" for SQA to test after it's written, SQA develops the acceptance test for the code prior to it being written. Good things happen when you do this. First of all, how often have you seen a "throwback" of the code by SQA because of disagreements on the interpretation of requirements? If you've been around as long as I have I wouldn't be surprised if your answer is "All too often!" When SQA writes acceptance tests first, a development team is charged with "Write code that passes this test" rather than "Write code that meets this requirement." The task is clearer and a potential major stumbling block is avoided. Everyone benefits when success can be objectively determined. Another good thing is involvement. A common complaint among SQA personnel is that they have difficulty seeing whether the software behaves as advertised internally when there is no visibility into its internal workings. When SQA and development collaborate from the start, development can provide a "tester's view" into the software. Without such a view, it is more likely that software with an internal bug will be released into production. So next time you're confronting that "release engineering" process, anticipating it as where the trouble begins, remember that there's an alternative that just might help you get better working code out the door sooner. O><O><O><O><O><O More articles on Agile software topics at http://www.agilerules.com Within our company we have a sub-specialty in embedded systems. Our site has articles on embedded XP and we support a discussion list focused on the use of agile methods for building embedded software. The list signup info is at http://www.agilerules.com/mailinglists.phtml O><O><O><O><O><O To help you get started with in-depth research into Agile Attitudes topics, we have added a Library section to our web site at http://www.agilerules.com/library.phtml Order using our links and receive discounts up to 30%! O><O><O><O><O><O If you enjoyed this issue or found it useful, forward it to a friend! Help spread the word about better ways to build software. Invite your friends and colleagues to join our growing reader community at http://www.agilerules.com/mailinglists.phtml O><O><O><O><O><O Looking for a speaker for your next corporate or society meeting? We present dynamic, informative programs on topics of interest to managers and technical staff in their transition to more flexible, robust ways to create software. O><O><O><O><O><O Want to reprint this issue in your company or society newsletter? For permission to reprint any of the articles, contact us at info@agilerules.com. O><O><O><O><O><O Your feedback is welcome! Send feedback to info@agilerules.com To manage your subscription: http://www.agilerules.com/mailman/listinfo/agileattitudes O><O><O><O><O><O Brought to you by Agile Rules consulting 162 Marrett Road, Lexington MA 02421 Copyright (c) 2004 Agile Rules info@agilerules.com O><O><O><O><O><O Privacy notice: We will not release a subscriber's address to any third party for any reason. This is a strictly opt-in newsletter. No one is ever subscribed without their explicit request. </plaintext> </td id="bodytable_r1_c3_body"> </tr id="bodytable_r1"> </table id="bodytable">