Tuesday, 30 June 2009

Does software testing suck ?

I have recently read a blog article titled, “testing sucks” by the charismatic industry guru, James Whittaker. The article gives an interesting and unique insight into the life of a testing professional. I am keen to see whether other testing professionals agree that this is a reasonable explanation for miserable testers.

If you have read the article, (if you haven’t you can find it here) what is your opinion? Has James Whittaker’s article struck a chord with you? Do you agree or disagree? I welcome your comments below...

6 comments:

theTestingExpert said...

Well that all sounds very nice in an ideal world or a cash rich company like Microsoft was !
But the reality is that test automation is difficult and expensive, which means that most companies still have to do the "Boring" stuff.

Anonymous said...

Yeah I agree with the last comment, we don’t have the budget to automate, and even if we did, with our current skill-set, we would be unlikely to get the ROI to make implementing worthwhile.

Ryan_James said...

Yes...however, if you choose to outsource the automated testing (particularly regression testing) to an organisation that specialises in automated testing, then you can still get all of the advantages of automated testing without facing the challenges. Take a look at nFocus' virtual test service:

http://www.nfocus.co.uk/Services/ManagedServices/VirtualTestService.aspx

Steve Watson said...

A few points come to mind, having read the article and the comments....

Testing is seen as a negative task - developers build things and we as testers are seens as trying to break things, so I can see that a developer may agree that testers and testing 'sucks'.

Also, those stuck in a neverending round of repetitive mind numbing manual tests will also feel it sucks, or as in one place I worked, if you were not in the Test Creation team but were in the Test Execution team - only running tests that other people had written. Never ever do this to your testers, they'll hate you for it!

Writing automated scripts doesn't suit everyone either - after all if we wanted to write code, we'd be developers right? Plus tools are expensive (dont buy cheap - been there, done it, seen the shelfware). Automation certainly has its place but dont rely on it just to make the testers happy.

The answer is to get testers embedded in the process much more - with Agile you do this by writing user stories, and actually shaping the product. It's not so easy with a Waterfall methodology, however thats not to say that testers cannot be involved in writing the specifications, talking to users up-front about the solution, and then being recognised by the developers as the person/people that know what should happen. All of a sudden a tester is not seen as an annoying individual forever moaning that the code doesnt work, but is instead seen as a Subject Matter Expert (SME).

That works for me!

Dandino said...

I quite agree Steve, sometimes (perhaps more often that it should) there is the perception that testers suck and that we break things. The perception needs to be moved round to testers help make things work!
Automation (if it is not a core skill or competancy) can be time consuming and may not provide the return on investment in all cases.
Even if you get the testers involved in Agile say by writing user stories, tests still need to be executed and over a number of sprints, the regression testing effort will become onerous. Automation of regression tests definitely has its place in Agile and can reduce down the testing effort to allow primary and regression testing to occur within a sprint. We have worked on a number of Agile projects and found the way to tackle this is by actually splitting the test team into onsite test analysts and offsite test automaters. This way, the testers and the rest of the team think testing Rocks!

Inder P Singh said...

Well, it depends a LOT on an individual tester's attitude. Smart people find ways to make even boring tasks challenging. See my blog post at the link below where two testers face identical task assignments but one is able to provide more value than the other and ends up stretching her competencies as a nice side effect.

http://inderpsingh.blogspot.com/2009/12/story-of-rich-tester-and-poor-tester.html