Is Testing Last in Line?

A post on the Software Testing Club, Is Testing Last in Line? seems oh so familiar to complaints (if that that is they are) heard for as long as I've been in software (and I'm in my 29th year).

I think all of the responses to the blog are reasonable - but the underlying assumption in all (most) of them is that the tester is responsible for getting:

a) involved early
b) involved heavily

Is anyone researching HOW to choose a test model?

The Project Euler site presents a collection of 'maths-related' problems to be solved by computer - 250+ of them and the site allows you to check your answers etc. You don't need to be a mathematician for all of them really, but you do need to be a good algorithm designer/programmer.

But it also reminded me of a recurring thought about something else. Could the problems be used as 'testing' problems too? The neat thing about some of them is that testing them isn't easy. Some problems have only one answer – they aren't very useful for testers - there is only one test case (or you need simply to write/reuse a parallel program to act as oracle). But others like problem 22 for example provide input files to process http://projecteuler.net/index.php?section=problems&id=22

What is the best ratio of testers to developers in an agile team?

You may or may not find this response useful. :-)

"It depends".

The "it depends" response is an old joke. I think I was advised by David Gelperin in the early 90s that if someone says "it depends" your response should be "ahh, you must be a consultant!"

But it does depend. It always has and will do. The context-driven guys provide a little more information - "it depends on context". But this doesn't answer the question of course – we still get asked by people who really do need an answer – i.e. project managers who need to plan and to resource teams.

The new website

Welcome to the new site!

We're using Drupal, a very popular Content Management system, MySQL and PHP to manage the new site. This is a complete change of direction from the old technology which was based around Microsoft Active Server Pages, VBScript and an Access database.

Gerrard Consulting Bulletin June 2010

First attempt - testing only.

Header level 1

strong

Test Axioms as Thinking Tools

Is it possible to define a set of axioms that provide a framework for software testing that all the variations of test approach currently being advocated align with or obey? In this respect, an axiom would be an uncontested principle; something self-evidently and so obviously true and not requiring proof. What would such test axioms look like?

The Tester's Pocketbook - Published at last

I'm relieved, excited and delighted to tell you that The Tester's Pocketbook has been published and is available. (It is a pocketbook, with 104 pages and c. 19k words).

The book summarises the thinking on Test Axioms and the axiom definitions are hosted (and will be maintained in future) on the Test Axioms website.

Thanks to all my reviewers and people who supported me.

School's Out!

Teacher: Paul, make a sentence starting with the letter I.

Paul: I is...

Teacher: No, no, no, don't say "I is", you say "I am".

Paul: OK, I am the ninth letter of the alphabet.

If...

With most humble apologies to Rudyard Kipling...

If you can test when tests are always failing,
When failing tests are sometimes blamed on you,
If you can trace a path when dev teams doubt that,
Defend your test and reason with them too.

If you can test and not be tired by testing,
Be reviewed, and give reviewers what they seek,
Or, being challenged, take their comments kindly,
And don't resist, just make the changes that you need.

If you find bugs then make them not your master;
If you use tools - but not make tools your aim;
If you can meet with marketing and salesmen

Syndicate content