Welcome to MSDN Blogs Sign in | Join | Help

Architecture Testing

I often wonder how many IT professionals say “we could have caught these bugs up front had we been involved in the planning and design phase at project proposal”. How true can it be and what does it take to convince the business leaders, architects and other stakeholders that testing should occur at design time? A time where value propositions are discussed to increase the company’s ROI based on customer requirements and business trends.

Another way of saying this is how much money can be added to the ROI if testing begins at design time? I have seen numbers that state for every 100,000 lines of code released to production a company can spend up to $300,000 dollars in maintenance and support cost over the lifecycle of the product. Some would say this is too high while others would argue it’s too low. What are your thoughts?

·         Can the cost be attributed to not having a comprehensive quality control system in place at design time?

·         Can you agree that implementing an architecture testing process at design time can?

§         Reduce rework and maintenance cost

§         Provide better fault detection and test coverage at development and implementation time? (increased productivity)

§         Provide a more proven deployment and operations plan (faster time to market)

§         Provide better traceability through the product life cycle (predictability)

If you answered yes to all or some of these questions, then you either have a quality control process in place to cover architecture testing or you are in need of implementing one.

The patterns and practices test team is in the process of developing guidance that addresses architecture testing. Our years of experience have proven the earlier you identify issues in the product life cycle, the more you will save in the rears. It’s not just saving money; architecture testing is saving and expanding the business with collaborative partnerships and customer satisfaction.

One high severity bug or a missed opportunity can cost you dearly in your enterprise application space. Your business domain should be validated against each solution (application) as well as the application itself. So if you were to assemble an architecture test team, what skill sets would require? Better yet:

·         How would you define architecture testing?

·         Are you faced with this challenge in your business today?

·         Do you test at Design Time?

§         If not, why not?

§         If so what’s the approach and benefits?

You can also visit patterns & practices: Test & QA: CodeGallery Project and click downloads at:

·        http://www.gotdotnet.com/codegallery/codegallery.aspx?id=4713168a-9073-40e2-854a-a4b9ca217de9  and .net application block testing at:

·        http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/mtf.asp

 

Ed

Published Friday, March 18, 2005 1:09 PM by PAGTest

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

# re: Architecture Testing

Friday, March 18, 2005 2:07 PM by Darrell
1. Some of it can, if it is attributable to errors. If maint/support means &quot;enhancements&quot;, then no. <br>2. Yes except for the last one. Traceability sounds nice but in reality is difficult, time-consuming, and has never been justified in my opinion (maybe for different types of apps?). <br> <br>Architecture testing is making sure that a given architecture allows the developers to implement ALL (or as many as possible) of the business requirements in the easiest manner for the given load conditions and can scale for growth according to an initial estimated compound growth rate. <br> <br>Yep, some people I know rolled out something and didn't check to make sure it would scale to an order of magnitude greater than they tested it at. <br> <br>If you mean I test continually as I refine the design, then yes. It's impossible to test bubbles and arrows, but I test the heck out of my code. I prototype to make sure something will scale as much as it needs to (if I don't know it will scale that much already).

# re: Architecture Testing

Friday, March 18, 2005 4:27 PM by Jeff Parker
&gt;&gt; Some would say this is too high while others would argue it’s too low. What are your thoughts? <br>I would say it depends on the coders you have in place as well as far as the numbers go. I would say that number is lower for coders that do things like Unit testing and research planning to the best of their ability this number will be much lower, kind of like the Mort to Einstein comparison. Mort will cost you more in the long run. <br> <br>I won't say anything about the quality practices in place. Any quality is better than no quality. But the more you have the more you can test the better you are in the long run <br> <br>I strongly recomend for further reading besides the patterns and practices Code Complete 2nd edition by Steve McConnell this really covers the cost of doing things right <a target="_new" href="http://www.microsoft.com/MSPress/books/6822.asp">http://www.microsoft.com/MSPress/books/6822.asp</a>

# re: Architecture Testing

Tuesday, August 01, 2006 2:16 PM by Lizet Pena
Is there any way i could contact the Data Access Block team? I Have problem binding Output parameter through the DBCommandWrapper class for Oracle Providers, whenever we ExecuteNonQuery the parameters with an output direction return absolutely no results.
email lizet.pena at cit dot com

# re: Architecture Testing

Wednesday, August 02, 2006 10:08 AM by Lizet Pena
Is there any way i could contact the Data Access Block team? I also have problems binding Integers to  Oracle Number types.
Oracle version 9i, Enterprise Library version 1.1
email lizet.pena at cit dot com

Leave a Comment

(required) 
required 
(required) 

  
Enter Code Here: Required
 
Page view tracker