Agile Software Testing 101: Stress Testing

So your a software tester and you have received a new build with a new feature to test. How do you stress test it? Not difficult, you just need to know the pattern of "Stress Testing" to find those weak points. Here is a simple agile "how to".

Agile principles can be applied to testing. When done they leverage the tester's skills with the developer's skills.

Steps:

1. Being agile (as we all are) you let the developer responsible know that you are about to test the new feature.
2. As agile means collocated, you make sure you are near the developer and he/she can see your screen. Think of this as limited-pair testing perhaps, an agile balance of full pairing and letting the developer get on with his job.
   
3. To enhance your pairing make sure you have a mirror so you can see the developer. Collaboration is critical to stress testing.
   
4. Now go to the UI page that uses the feature and sweep your mouse pointer over the page watching the developers. When you see signs of stress ... click.

Stress testing saves time and leverages agile principles of, well, whatever your company says is agile today.

Oath of Non-Allegiance

Alistair Cockburn again challenges us. Check out the "Oath of Non-Allegiance" here.

I'm sick of hearing 'they are not agile because they use UML' or 'In agile we stand up and spin clockwise every 42 minutes".

Now I will go back to making my agile coffee on my agile PC and writing lots and lots of agile modelling diagrams. I wonder if my agile undies have arrived?

The term 'Agile' has joined the livings dead, its meaning and purpose of the manefesto is long gone. It is now used to mean whatever you want like Scrum, eXtreme Programming, or just anything.

May tolerance, an understanding that all processes are broken, and the bravery to find 'what works', replace it.

Using Visual Studio 2010 over RDP With Dual Screens

I often work from home and want to use my work box with dual screens but my home monitors have different resolutions. Normally, with a VPN/RDP connection, the windows RDP software cannot handle dual screens nicely and not at all when they have different resolutions. I like SplitView, it allows me to do this.

At home I have laptop and an external monitor. The laptop has a 1680 pixels across and the monitor has 1920 across. Needless to say I want to use both with Visual Studio's main editor on the larger monitor and the debug, output, unit tests windows on the smaller laptop monitor. With SplitView I can connect to my work computer and use both. The nice thing is that I can maximise an application within a monitor without it filling both monitors.

It is a little tricky (you do need to read the doco) to setup as it does layer over RDP. With a little fiddling about with the screen sizes it works nicely.

But the screens are not exactly the same and when I return to the office after working from home I find that the screen layouts have changed. A bit annoying. Move the VS2010 properties window here, output window here, etc. So I saves my "in office" and "rdp" layouts using VS's "Import and Export Settings". First get the layout you want and the export it by selecting "General Settings | Windows Layout" only. Then from home, or in the morning, you can quickly restore world order to your windows. Nice.

Continuous Integration can build time dependency

It seems to me that there is a dependency between Continuous Integration (CI) and build time. Each time I hit a slow build it puts pressure on 'fast' CI. It seems that if the build is slow then CI may be more destructive that beneficial. I'm thinking it is all a question of ratio.

CI does not define an integration rate. Some teams see CI as once a week, others see it as every 15 minutes. It is a relative concept.

If a build box can build and run all tests in, say, 1 second then a team's commit rate of once every 5 minutes would seem achievable. Each developer would have instant feedback and be able to fix, or revert, any problem within a couple of minutes, after a commit, with minimal effect (without considering a pre-commit test system). But if the build takes, say, 30 minutes and the team's commit rate was once every 15 minutes then by the time a build failure is detected the whole team is affected.

So it seems to me that there is a relationship between CI's rate and build time. Just do not know hat it is yet.

Visual Studio 2010 build speed - kinda Windows 7 really

When I moved to a new project using Visual Studio 2010 the build time seemed very very slow. But it would seem the problem is more to do with Windows 7. We are using Subversion, VisualSVN, TortoiseSVN for RCS. I have been perplexed as to why we no longer get icons in Explorer and today I found the solution here.

Once I ran the spell:

netsh interface tcp set global autotuninglevel=disabled.

The world order was restored. VS2010 compiled 2 times faster, Explorer icons came out from hiding, and Explorer was happy (much much faster).