Archive for December, 2008

Testing Talks

Thursday, December 4th, 2008

Myself and a colleague visited the University of Southampton‘s School of Electronics and Computer Science today. We were invited as guest lecturers to deliver a presentation on Enterprise Software Testing to a group of Software Engineering MSc Students. I was really impressed with the questions and discussion points from the students. There was a great deal of interest in the testing discipline with real enthusiasm for Agile practices, as a strategy to deliver capability, and not just code.

Maybe testing really is the new development!

println “Hello World”

Thursday, December 4th, 2008

Having spent most of my time testing on the mainframe, I’ve spent little of that time actually writing command lines scripts for tests (other than some Unix System Services work). Now that’s not to say I’m not completely familiar with scripting since my primary work station has been running Linux for a considerable time.

However, recently I needed to a little more advanced scripting on my Linux machine. So it was at this point I thought “which scripting language should I pick up and use?”. Obviously there’s a decent selection to choose from: Perl, Python, Ruby, Groovy, others (including Rexx).

In the end I settled on Groovy due to my years of experience in writing Java applications, plus Project Zero provides Groovy support.

With my first script in mind I set down to write and learn on the fly. After getting my head around the new syntax I found myself making progress. Also it’s quite nice being able to drop down to the Java syntax and use utility classes that you know to exist and are already familiar with. I know I’m not writing the prettiest Groovy code at the moment, but the way I see it is scripting languages are there for getting things done. And in one afternoon I picked up Groovy, installed the Eclipse plugin for it, and created a working script to do exactly what I needed. I was happy.

I have this niggling thought though… if I get in to Groovy, will it confuse the hell out of me when I go back to pure Java?

What is a Test Bucket?

Tuesday, December 2nd, 2008

Test bucket x, the Regression Test bucket – sound familiar?

Seriously, I’ve always wondered where the term comes from. Is it just a collective noun for tests, or was there really a time when the software industry quantified tests by the bucket-load?

In true Balderdash & Piffle style: Does anyone have a reference for its first usage?

New Agile testing model – inspired!

Tuesday, December 2nd, 2008

I have just been sent a link to a company called UTest who are building a software testing community.

Their basic model is to build a community of networked testers, invite development projects to submit their projects and then match testers with projects. Simple.

I can see this working very effectively for small scale, web based projects as it brings incredible diversity to the testing. I wonder how we could benefit from it in Enterprise testing?

More Agile SVT thoughts

Tuesday, December 2nd, 2008

Back in May I posted these thoughts on Agile SVT and I’m please to find I wasn’t too far of the mark all those months ago.
I was going through a presentation on ‘User Stories’ and one of the slides (page 73 out of 89) was dedicated to ‘Writing Stories for SVT scenarios’. Here’s the gist of it:

  • §Write stories to test different System Verification Tests
  • OS testing, reliability, load, stress, security, serviceability, consumability, integration, usability, accessibility, scalability, migratability, availability, …
  • §Work will often require more ‘tester’ effort, than ‘developer’ effort
§Examples:
  • As a system administrator, I want the system to support 500 concurrent users with sub-second response time with less than 50% CPU utilization.
  • As a solution deployer, I want to migrate from version 3 inside 1 hour.
  • As a principal, I want the system to be able to support 40,000 users and to be able to run on my existing servers.
  • §Some system requirements will be tested across user stories
  • Ex: Test on IE and Firefox.
Good to see this is the recognized way to go. To me, the important thing here is to have the whole team understanding what user stories are going to be delivered by SVT (and perhaps even more importantly what user stories are NOT being delivered). Hopefully this will force teams into really thinking about what a deliverable is supposed to do. I remember some years ago working on a product that was capable of passing large amounts of data around a network. I was reliably informed that there were no architectural limits on the amount of data that could be passed around, so could I do some testing with really big amounts of data. In hind site this was a pointless test and I should have pushed back on it. All I eventually demonstrated was that the hardware became constrained before the software.
What would have been really helpful would have been a user story along the lines of:
Application programmer wants to send  a 100mbs of data around the network every minute (and some business reason/value). This would have been much easier to understand and demonstrate rather than the open ended statement I had to work with.
Hopefully this is the way we are moving.