SOFTware is HARD

Application support teams who are maintaining pre-written applications may be disappointed to find that test cases have not been written prior. The recommendation is not to stop work and start writing test cases. Instead, test cases should be written incrementally . Every time you need to “touch” the application code, you should write the test cases directed at that aspect. For example: Every enhancement to the system should be supplemented with newly created test cases Every bug you attempt to fix should be supplemented with pre-fix and post-fix test cases In so doing, the risky and unstable portions of the system will be covered by test cases. At the same time, if test cases are regressed, a previously fixed bug will not resurface! See a related article

There are 3 main concerns that performance testing seeks to address. These concerns form the acceptance criteria or metrices for the tests. They are: User concern – Response Time Business concern - Throughput. E.g. requests/ sec; calls/ day System concern - Resource Utilisation (often overlooked). E.g. processor & memory utilisation; disk I/O; network I/O Purpose of Performance Testing Depending on what has been done, performance testing helps in assessing: release readiness infrastructure adequacy software performance performance tuning efficiency Some Definitions Performance Target = Performance Goals Performance Requirements = contractual obligation, SLAs that cannot be compromised. = Performance Thresholds Workload = Stimulus applied. E.g. number of users, concurrent users, data volume, transaction volume. Types of Performance Testing Load Testing - testing within anticipated production load/ volume Stress Testing - testing beyond expected production load/ v...

These are some tools recommended by a book for .NET CI: White ( http://white.codeplex.com/ ) for automated testing of Windows Forms Selenium ( http://seleniumhq.org/ ) for automated testing of Web Applications Non-Sucking Service Manager ( http://iain.cx/src/nssm ) for running applications as Windows Services FitNesse ( http://www.fitnesse.org/ ) for automating Acceptance Testing FitSharp ( http://www.syterra.com/FitSharp.html ) for .NET FxCop ( http://www.microsoft.com/downloads/en/details.aspx?FamilyID=917023f6-d5b7-41bb-bbc0-411a7d66cf3c ) for analysing .NET code SandCastle ( http://sandcastle.codeplex.com/ ) for compiling documentation HelpFile Builder ( http://shfb.codeplex.com/ ) WiX ( http://wix.sourceforge.net/ ) for building Windows installation packages Publishing of: ClickOnce using Mage ( http://msdn.microsoft.com/en-us/library/acz3y3te.aspx  and http://msdn.microsoft.com/en-us/library/xhctdw55.aspx ) or MsBuild Web Application using MsDeplo...

I've been using Fiddler ( http://www.fiddler2.com/ ) for sometime now. It attaches to the web browser and intercepts browser requests and reponses. Fiddler is very useful for inspecting and debugging HTTP roundtrips. Recently, I found something to supplement Fiddler. Stresstimlus (( http://stresstimulus.stimulustechnology.com/ ) is useful for HTTP load testing together with Fiddler.

What is legacy code? Some define legacy code as code without proper unit tests . Consider these: Did you just write some legacy code yesterday? What happens when you are tasked to take over the maintenance of someone else's code; someone's legacy code? What happens when you need to modify someone's legacy code? Some steps to take when planning to unit test legacy code: identify the area of change build safety net over the area before touching/ changing it refactor the code to ease adding new code write unit test for issue write code for fix/ enhancements Some links to refer to: http://members.pingnet.ch/gamma/junit.htm http://c2.com/cgi/wiki?UnitTestingLegacyCode http://spin.atomicobject.com/2008/12/29/testing-and-legacy-code-a-primer http://www.ibm.com/developerworks/java/library/j-testng/