contracting in great depression II

[Mich the Tester]

Same old tulipe bing peddled this time round I see.

I'd like to see the end of the gobtulipe BAs and the barra boyz of IT - testers!

(sorry mitch)

You guys have one means of putting me out of work for good. Write perfect code and run it through a perfect compiler to work on a perfect OS. Easier said than done, I think.

Anyway, I certainly don't think of myself as your average run-of-the-mill
tester; I like to work in agile and RAD environments close to the code; I was DBA and a PL/SQL and Oracle forms developer (admittedly not a very good one) and did some C and VB work before I became a tester, so if I get a chance I often help to solve the problems instead of just doing that bloody irritating tester thing of reporting a bug without first investigating my own work. I actually think(maybe just false hope) that testing's future will be more like that than the current bureaucratic bulltulip.

[rootsnall]

I think those of us who are good at patching holes in creaky old C++ apps will be in demand as plans to rewrite projects in the latest trendy language/platform/paradigm are put on hold. Boomed!

WHS

C++ has got to be the most tulip language of all time and the amount of very tulip systems needing constant patching is never ending. It nearly killed me last time I went back to C++ but I'll do it again if things get really dire.

[Shimano105]

Ok mate, you're off the hook.

It does seem that nowadays there are hoardes of wannabe ITers in the guise of tester clumps, pumping loads of illegible messages into Test Director and the like.

[Mich the Tester]

Ok mate, you're off the hook.

It does seem that nowadays there are hoardes of wannabe ITers in the guise of tester clumps, pumping loads of illegible messages into Test Director and the like.

These are the guys from consultancies who’ve spent two weeks on an ISEB or T-Map course and think that makes them professional testers; they’ve been conned into believing that their certificates make them into really good testers, but when the market goes down they’ll need a lot more than their pieces of paper to show they can be valuable. They also proudly put the name of some findings tool like test director or Quality Center on their CVs as if that makes them gurus, when anyone with any knowledge of testing should be able to figure out how to use these things in 2 minutes; if you can't, either you're an idiot or the tool is too complex for the job in hand. I’ve got the certificates for purely commercial reasons; purchasers move your CV to the top of the pile.


If you want an alternative view of testing, I’d take a look at James Bach’s website; www.satisfice.com

I find myself agreeing with about 75% what he says and I’m convinced that he’s latched on to a really good approach to testing that could be the future for saving companies money and time while helping to innovate; part of my plan B is to give training in the type of testing skills he talks about as an antidote to the bureaucratic BS of the consultancies.

Take a look at the principles of the context-driven school of testing. you'd think this is stating the bleeding obvious, but it's a sign of how bureaucratic and bulltulippy things have become that what's being said appears radical in the tsting world;

The value of any practice depends on its context.

There are good practices in context, but there are no best practices.

People, working together, are the most important part of any project's context.

Projects unfold over time in ways that are often not predictable.

The product is a solution. If the problem isn't solved, the product doesn't work.

Good software testing is a challenging intellectual process.

Only through judgment and skill, exercised cooperatively throughout the entire project, are we able to do the right things at the right times to effectively test our products

[bobhope]

Ahh Quality Center, now there's a product. If only it could go more than a couple of hours without crashing the browser.

[Purple Dalek]

Ahh Quality Center, now there's a product. If only it could go more than a couple of hours without crashing the browser.

There's a liverpudlian lass, here, ok she's from St Helens, very entertaining when that browser crashes and takes with it the last half hours worth of input.

It really is an over-priced idiotically interfaced pile of steaming poo.

Glad I don't have to go too near it too often.

[Mich the Tester]

Ahh Quality Center, now there's a product. If only it could go more than a couple of hours without crashing the browser.

Yeah, and you know what a big part of the problem is? It gets so damn busy because of people entering bulltulip findings accompanied by miles of screen dumps. Testers do this, either because they lack the self investigation skills to check their own finding and investigate possible causes, or because they're not allowed to talk with the developers who are hidden somewhere in India behind a legion of managers. The way I like to work is to show the developer what I've found and how I've found it, then ask him what he thinks about it, reserving judgement as to whether it's a bug; after all, he might have got it right and I might have got it wrong; we might both have got it wrong, in which case we both learn something valuable from the finding. Ideally nothing should be entered into the findings tool until it's been discussed by the tester and the developer so that both understand what the problem is.

Amazingly, in all the testing courses, we're told that testers should have good communication skills to avoid making a developer feel personally attacked by a finding, but the methodologies and tools used by large organisations seem designed to prevent that kind of cooperative working.

In short; let me talk with the developer and show him what's going on, and that way we can work together for a better product. When we've agreed that there's an issue we can put it in QC so that the managers can have their meaningless reports.

Sorry guys, I could go on about this for months, but I'll save you it. Just wait until my first testing courses go on the market. Alternatively, hire me and I'll tell you how tsting really should be done. I'm not cheap, but as Red Adair says, 'if you think hiring a professional is expensive, see what it costs when you hire an amateur'.

[Doggy Styles]

You guys have one means of putting me out of work for good. Write perfect code and run it through a perfect compiler to work on a perfect OS.

That perfect code would be written to a perfect spec, written to a perfect analysis of a perfect requirement.

[Mich the Tester]

That perfect code would be written to a perfect spec, written to a perfect analysis of a perfect requirement.

Of course. Until then, I'll keep on invoicing.

[TimberWolf]

Of course. Until then, I'll keep on invoicing.

There's a lot of science in testing and unfortunately a lot of it is carp and I've forgotten much of it. At what stage do you stop testing? e.g. when you don't find a bug at all for x amount of time, or when you only find x number of bugs in a certain amount of time? With huge software products I expect the latter approach is more common, and a certain amount of bugs are assumed and almost mathematically certain to exist.