Testing is Rocket Science Not Brain Surgery

Away from the city lights and from the smoggy haze of the freeways there is a sky full of millions of stars visible by the naked eye.  These stars that fill the sky have the distinction of being brighter than their millions of other brother and sister stars they share the sky with.  Among these over-achievers are a few that shine even brighter, usually found in our constellations because of their brilliance.  This is analogous to all of the possibilities in a newly minted system you are being asked to test.  Like those stars in the sky some of those possibilities will show themselves as being more brilliant or more critical to the success of the application.  For me these mission critical business functions kind of pop out, things that involve integration touch points to external systems, queries that work against large quantities of data or what will become large data sets over time, queries involving extensive filtering, areas that require a lot of logical branching to create or process requests and responses, etc..  Then compound this with the needs of the presentation layer with streaming, AJAX, dynamic content presentation where what you see is contingent on business rule processing, and data grids.

But if these types of things aren’t obvious to you then lets try to tackle this issue one at a time through a little divide and conquer exercise.  We’ll begin with a friendly reminder of my “Take absolutely nothing for granted” mantra.  If one line of code was written to support a business function there is the potential for that code to wreck your system’s performance.  That doesn’t help but I’ve covered my bases for whatever you do with this advice.  First on the list is the database, since it more often than not is your application’s Achilles Heel.  When Microsoft has four or five available data access methods you know you’re in trouble.  Getting at data is a perilous task, wrought with the potential to take missteps architecturally.  There is enough published on the various methods from not only Microsoft, but all of the various flavors of access methods and database providers.  In the context of this discussion I want us to think in terms of the means that we get to our end and that’s SQL.  I have to wonder if it’s as ubiquitous as COBOL; it makes the world go round gluing application data stores together.  All things considered equal SQL is the target language and it can be a complicated one to speak for any developer.  To understand how well that language is being spoken you have to make use of what are called profilers.  Usually provided by the database provider, this tool can gauge execution time of the actual query and the query’s prep time.  This allows you to see what the cost of your SQL is; you will be able to identify SQL statements that are more resource intensive. When you couple execution against a DB with multiple data sets of varying sizes and the measurements from the hardware and DB platform-specific utilization stats, you can paint a 360-degree view of your database performance based on your application’s needs.

Here is a primer for using Microsoft’s SQL profiler:
http://www.developer.com/db/article.php/3482216

I would suggest the use of an orthogonal array going forward through this series to start keeping track of what will become a load profile.
An excellent article was published in the June issue of Software Test&Performance magazine by Yogananda Jeppu “Trusting Instincts
Is Not a Sin Experimental Design Can Help” http://www.stpmag.com/issues/stp-2007-06.pdf

Basically your factors become the size of the data set you are working against, and the various queries themselves, not forgetting to make variants of that SQL based on the various filters that can be applied to each query.