Steven Wilssens http://steven.wilssens.net/ Imagination is more importand then knowledge Steven Wilssens Wed, 15 Mar 2006 10:31:09 GMT newtelligence dasBlog 1.7.5016.2 Steven.Wilssens@telenet.be Steven.Wilssens@telenet.be http://steven.wilssens.net/Trackback.aspx?guid=3c2e75c9-3688-4dd2-ac76-914fda0f100e http://steven.wilssens.net/pingback.aspx http://steven.wilssens.net/PermaLink.aspx?guid=3c2e75c9-3688-4dd2-ac76-914fda0f100e http://steven.wilssens.net/CommentView.aspx?guid=3c2e75c9-3688-4dd2-ac76-914fda0f100e http://steven.wilssens.net/SyndicationService.asmx/GetEntryCommentsRss?guid=3c2e75c9-3688-4dd2-ac76-914fda0f100e 0 These are the presentations and the code demo's Jelle Druyts and I used during the Microsoft Developer & IT Pro Days 2006 in Belgium on 8th of March.
The Best Practices for Application Development (Jelle Druyts and Steven Wilssens):
Best Practices For Application Development.zip
Demo 01 - Enterprise Library.zip
Demo 02 - Enterprise Library and Command Pattern.zip
Demo 03 - Test Driven Development.zip
Best Practices for Advanced Source Control: Beyond CheckOut and CheckIn (Steven Wilssens):
Advanced Source Control - PART I.zip
Advanced Source Control - PART II.zip
Advanced Source Control - PART III.zip
Final version of Slides and Demo's Developer and IT Pro Days 2006 http://steven.wilssens.net/PermaLink.aspx?guid=3c2e75c9-3688-4dd2-ac76-914fda0f100e http://steven.wilssens.net/FinalVersionOfSlidesAndDemosDeveloperAndITProDays2006.aspx Wed, 15 Mar 2006 10:31:09 GMT <font color=#000000>These are the presentations and the code demo's</font> <a href="#topofpage"><font color=#0000ff size=2>Jelle Druyts</font></a> <font color=#000000>and </font><a href="#topofpage"><font color=#0000ff size=2>I</font></a> <font color=#000000>used during the </font><a href="#topofpage"><font color=#0000ff size=2>Microsoft Developer &amp; IT Pro Days 2006 in Belgium on 8th of March.</font></a> <br> <table style="WIDTH: 100%" cellspacing=0 cellpadding=0 border=0> <tbody> <tr> <td style="WIDTH: 30px" valign=top align=left> <span style="FONT-SIZE: 10pt"><font color=#000000>•</font></span></td> <td valign=top align=left> <a href="#topofpage"><font color=#0000ff size=2>The Best Practices for Application Development (Jelle Druyts and Steven Wilssens):</font></a> <br> <a href="/content/binary/Best20Practices20For20Application20Development.zip"><font color=#0000ff size=2>Best Practices For Application Development.zip</font></a> <br> <a href="/content/binary/Demo200120_20Enterprise20Library.zip"><font color=#0000ff size=2>Demo 01 - Enterprise Library.zip</font></a> <br> <a href="/content/binary/Demo200220_20Enterprise20Library20and20Command20Pattern.zip"><font color=#0000ff size=2>Demo 02 - Enterprise Library and Command Pattern.zip</font></a> <br> <a href="/content/binary/Demo200320_20Test20Driven20Development.zip"><font color=#0000ff size=2>Demo 03 - Test Driven Development.zip</font></a> <br> </td> </tr> <tr> <td style="WIDTH: 30px" valign=top align=left> <span style="FONT-SIZE: 10pt"><font color=#000000>•</font></span></td> <td valign=top align=left> <a href="#topofpage"><font color=#0000ff size=2>Best Practices for Advanced Source Control: Beyond CheckOut and CheckIn (Steven Wilssens):</font></a> <br> <a href="/content/binary/Advanced20Source20Control20_20PART20I.zip"><font color=#0000ff size=2>Advanced Source Control - PART I.zip</font></a> <br> <a href="/content/binary/Advanced20Source20Control20_20PART20II.zip"><font color=#0000ff size=2>Advanced Source Control - PART II.zip</font></a> <br> <a href="/content/binary/Advanced20Source20Control20_20PART20III.zip"><font color=#0000ff size=2>Advanced Source Control - PART III.zip</font></a> <br> </td> </tr> </tbody> </table> <img width="0" height="0" src="/aggbug_id_3c2e75c9_3688_4dd2_ac76_914fda0f100e.ashx"> http://steven.wilssens.net/CommentView.aspx?guid=3c2e75c9-3688-4dd2-ac76-914fda0f100e .NET 2.0
http://steven.wilssens.net/Trackback.aspx?guid=b3769592-d2c2-4287-9f55-76989eaed47b http://steven.wilssens.net/pingback.aspx http://steven.wilssens.net/PermaLink.aspx?guid=b3769592-d2c2-4287-9f55-76989eaed47b http://steven.wilssens.net/CommentView.aspx?guid=b3769592-d2c2-4287-9f55-76989eaed47b http://steven.wilssens.net/SyndicationService.asmx/GetEntryCommentsRss?guid=b3769592-d2c2-4287-9f55-76989eaed47b 1

In previous versions of Visual Studio, a tester had to resort to many different tool vendors for his testing equipment. The release of Microsoft Visual Studio 2005 Team System will mark an important milestone in testing land since it marks the recognition of the tester as a first class citizen in Visual Studio. It will provide testers with tools that support testing throughout the entire software development and maintenance lifecycles. Does this mean that every tool a tester ever dreamt of or even really needs is in Team System? No, but it’s a great start. In this post I’ll focus on the test levels that are defined in the “V” model and the Visual Studio 2005 and Team System features that support them. The “V” model has become an industry wide standard for visualizing the levels of tests. Figure 1 is an illustration of the “V” model.



I regularly notice that there is a lot of confusion on the what, how and when wile discussing these levels. Before we can start to define the different testing levels it’s probably wise to define what a unit and a component is:

Unit:
A unit is the smallest compilable component. It does not include any communicating components and it’s generally created by one programmer.
Component:
A unit is a component. The integration of one or more components is a component. The reason for "one or more" as contrasted to "Two or more" is to allow for components that call themselves recursively.

On the right-leg of the “V” model you’ll find these levels:
Unit Testing:
During unit-testing the developer should always make sure the unit is tested in isolation, and that it is the only possible point of failure. In unit testing communicating components and called components should be replaced with stubs, simulators, or trusted components. Calling components should be replaced with drivers or trusted super-components.
Component Testing:
During component testing the same scenarios are tested as during unit testing but all stubs and simulators are replaced with the real thing.
Integration Testing:
Integration testing identifies problems that occur when components are combined. Component A and B are two components for which A calls B. Figure 2 illustrates integration testing for Components A and B:
Test Suite A contains the component level tests of component A.
Test Suite B consits the component level tests of component B.
Tab are the tests in A’s suite that cause A to call B.
Tsab are the tests in B's suite for which it would be possible to replace the code that is written to test component B by a call from Component A as input for the tests.
When you combine the test suites Tsab and Tab you will have a set of component tests that you can use after you modify Component B. When you modify Component B or A, you will be able to verify that will still function correctly together.


System Testing:
In system testing the tester will verify if the developed system or subsystems still meet the requirements that were set in the functional and quality specifications.
Acceptance Testing:
In acceptance testing the user and system manager will verify if the developed system still meets the requirements that were set in the functional and quality specifications. This level of testing is done in an environment that simulates the operational environment in the greatest possible extent.
Release Testing:
Prior to a public release of a program you must ensure that all bugs that were intended to be fixed were actually fixed. In release testing following aspects will be verified:

A mixture of previously failed-and-fixed tests and tests that have always passed;

Virus checking of the final installation package. Too many cases of distribution of viruses have been reported to not take this additional precaution.
A comparison of all features actually working reliably with prepared documentation. It is crucial that the documentation reflects all design decisions made during development and testing.

There are many variations on these definitions and the “V” model, but the key point is that the abovementioned testing levels are formally defined. A wise man once said: “Even when laws have been written down, they ought not always to remain unaltered.” Despite the fact that we are not talking about laws here, you can always leave a comment when you have another understanding of these definitions.
Testing Levels http://steven.wilssens.net/PermaLink.aspx?guid=b3769592-d2c2-4287-9f55-76989eaed47b http://steven.wilssens.net/TestingLevels.aspx Sun, 07 Aug 2005 15:43:44 GMT <p> <table id=Table1 cellspacing=0 cellpadding=0 width="100%" border=0> <tbody> <tr> <td height=113> <p> <font face=Tahoma color=#000000>In previous versions of Visual Studio, a tester had to resort to many different tool vendors for his testing equipment. The release of Microsoft Visual Studio 2005 Team System will mark an important milestone in testing land since it marks the recognition of the tester as a first class citizen in Visual Studio. It will provide testers with tools that support testing throughout the entire software development and maintenance lifecycles. Does this mean that every tool a tester ever dreamt of or even really needs is in Team System? No, but it’s a great start. In this post I’ll focus on the test levels that are defined in the “V” model and the Visual Studio 2005 and Team System features that support them. The “V” model has become an industry wide standard for visualizing the levels of tests. Figure 1 is an illustration of the “V” model. </font> </p> </td> </tr> <tr> <td align=middle> <p> <br> <font face=Tahoma color=#000000><img src="/content/binary/V_Model.gif" border=0> <br> </font> </p> </td> </tr> <tr> <td> <p> <font face=Tahoma color=#000000>I regularly notice that there is a lot of confusion on the what, how and when wile discussing these levels. Before we can start to define the different testing levels it’s probably wise to define what a unit and a component is:<br> </font> <table id=Table2 cellspacing=0 cellpadding=0 width="100%" border=0> <tbody> <tr> <td valign=top width=17> <font face=Tahoma color=#000000>• </font></td> <td> <font face=Tahoma><font color=#000000><strong>Unit:</strong> <br> A unit is the smallest compilable component. It does not include any communicating components and it’s generally created by one programmer. </font></font></td> </tr> <tr> <td valign=top width=17> <font face=Tahoma color=#000000>• </font></td> <td> <font face=Tahoma><font color=#000000><strong>Component:<br> </strong>A unit is a component. The integration of one or more components is a component. The reason for "one or more" as contrasted to "Two or more" is to allow for components that call themselves recursively.<br> </font></font></td> </tr> </tbody> </table> <br> <font face=Tahoma color=#000000>On the right-leg of the “V” model you’ll find these levels:<br> </font> <table cellspacing=0 cellpadding=0 width="100%" border=0> <tbody> <tr> <td valign=top width=19> <font face=Tahoma color=#000000>• </font></td> <td> <font face=Tahoma><font color=#000000><strong>Unit Testing:<br> </strong>During unit-testing the developer should always make sure the unit is tested in isolation, and that it is the only possible point of failure. In unit testing communicating components and called components should be replaced with stubs, simulators, or trusted components. Calling components should be replaced with drivers or trusted super-components.</font></font></td> </tr> <tr> <td valign=top width=19> <font face=Tahoma color=#000000>• </font></td> <td> <font face=Tahoma><font color=#000000><strong>Component Testing:<br> </strong>During component testing the same scenarios are tested as during unit testing but all stubs and simulators are replaced with the real thing.</font></font></td> </tr> <tr> <td valign=top width=19> <font face=Tahoma color=#000000>• </font></td> <td> <table id=Table3 cellspacing=0 cellpadding=0 width="100%" border=0> <tbody> <tr> <td> <font face=Tahoma><font color=#000000><strong>Integration Testing:</strong> <br> Integration testing identifies problems that occur when components are combined. Component A&nbsp;and B are two components for which A calls B.&nbsp;Figure 2&nbsp;illustrates integration testing for Components A and B: </font></font></td> </tr> <tr> <td> <table id=Table4 cellspacing=0 cellpadding=0 width="100%" border=0> <tbody> <tr> <td valign=top width=26> <font face=Tahoma color=#000000>• </font></td> <td> <font face=Tahoma color=#000000>Test Suite A contains the component level tests of component A.</font></td> </tr> <tr> <td valign=top width=26> <font face=Tahoma color=#000000>• </font></td> <td> <font face=Tahoma color=#000000>Test Suite B consits the component level tests of component B. </font></td> </tr> <tr> <td valign=top width=26> <font face=Tahoma color=#000000>• </font></td> <td> <font face=Tahoma color=#000000>Tab are the tests in A’s suite that cause A to call B. </font></td> </tr> <tr> <td valign=top width=26> <font face=Tahoma color=#000000>• </font></td> <td> <font face=Tahoma color=#000000>Tsab are the tests in B's suite for which it would be possible to replace the code that is written to test component B by a call from Component A as input for the tests.</font></td> </tr> </tbody> </table> <font face=Tahoma color=#000000>When you combine the test suites Tsab and Tab you will have a set of component tests that you can use after you modify Component B. When you modify Component B or A, you will be able to verify that will still function correctly together. </font></td> </tr> <tr> <td align=middle> <br> <font face=Tahoma color=#000000><img src="/content/binary/Integration_Testing.gif" border=0> <br> </font></td> </tr> </tbody> </table> </td> </tr> <tr> <td valign=top width=21> <font face=Tahoma color=#000000>• </font></td> <td> <font face=Tahoma><font color=#000000><strong>System Testing:</strong> <br> In system testing the tester will verify if the developed system or subsystems still meet the requirements that were set in the functional and quality specifications. </font></font></td> </tr> <tr> <td valign=top width=21> <font face=Tahoma color=#000000>•</font></td> <td> <font face=Tahoma><font color=#000000><strong>Acceptance Testing:</strong> <br> In acceptance testing the user and system manager will verify if the developed system still meets the requirements that were set in the functional and quality specifications. This level of testing is done in an environment that simulates the operational environment in the greatest possible extent. </font></font></td> </tr> <tr> <td valign=top width=21> <font face=Tahoma color=#000000>•</font></td> <td> <font face=Tahoma><font color=#000000><strong>Release Testing:<br> </strong>Prior to a public release of a program you must ensure that all bugs that were intended to be fixed were actually fixed. In release testing following&nbsp;aspects will be verified: <br> </font></font> <table cellspacing=0 cellpadding=0 width="100%" border=0> <tbody> <tr> <td valign=top width=20> <font face=Tahoma color=#000000>• </font></td> <td> <p> <font face=Tahoma color=#000000>A mixture of previously failed-and-fixed tests and tests that have always passed;</font> </p> </td> </tr> <tr> <td valign=top width=20> <font face=Tahoma color=#000000>• </font></td> <td> <font face=Tahoma color=#000000>Virus checking of the final installation package. Too many cases of distribution of viruses have been reported to not take this additional precaution.</font></td> </tr> <tr> <td valign=top width=20> <font face=Tahoma color=#000000>• </font></td> <td> <font face=Tahoma color=#000000>A comparison of all features actually working reliably with prepared documentation. It is crucial that the documentation reflects all design decisions made during development and testing.</font></td> </tr> </tbody> </table> </td> </tr> </tbody> </table> </p> </td> </tr> <tr> <td> <br> <font face=Tahoma color=#000000>There are many variations on these definitions and the “V” model, but the key point is that the abovementioned testing levels are formally defined. A wise man once said: “Even when laws have been written down, they ought not always to remain unaltered.” Despite the fact that we are not talking about laws here, you can always leave a comment when you have another understanding of these definitions.</font></td> </tr> <tr> <td> <font face=Tahoma color=#000000></font></td> </tr> </tbody> </table> </p> <img width="0" height="0" src="/aggbug_id_b3769592_d2c2_4287_9f55_76989eaed47b.ashx"> http://steven.wilssens.net/CommentView.aspx?guid=b3769592-d2c2-4287-9f55-76989eaed47b Team System