Browsing through the SQA blogs I found an interesting entry that mentioned a book ( I'm always on the lookout for more books to read ! ) and after an exchange of messages where it was recommended I went ahead and ordered it.
The book was
"Surviving the Top Ten Challenges of Software Testing: A People-Oriented Approach"
by Perry and Rice.
It was a small book ( 190 pages ) so was easily read over a weekend - even easier as I found it to be an interesting read.
The 10 challenges were:-
Challenge #10: Getting Trained in Testing
Doesn't happen here, the attitude is that anyone can do testing and support staff are usually made to do testing when they have any spare time. The one supposed official tester has never shown any interest in getting training and doesn't even possess a testing book.
I've educated myself, have amassed a large library of books, subscribe to Better Software, lurk on QA forums and Sticky Minds and try to read as many blogs as I can.
Next step will be to see if the company will pay for me to attend some conferences...
Challenge #9: Building Relationships with Developers
As most of our products were tested by random people or live on-site there was never any relationship building. The one official tester had great credibility problems as the main content of bugs he found were tabbing order and keyboard shortcut failings. It was so bad that we named these sort of tests after him...
Being a developer moving to testing I should have more credibility with the programmers and I want to convince them as soon as I can that I don't have to have a UI to test their programs. If they do provide one then understand that they are providing it to make my testing life easier and I wont spend my time finding fault with it
Challenge #8: Testing Without Tools
Up til now our only tools were an Excel spreadsheet for bugs ( occsionally used ) and very occasional use of a capture-replay tool
Now we have Mantis ready to be unleashed, Perl scripts all set to be written, Ruby and Watir for possible automation testing and a whole heap of network tools to capture and packets and cookies etc etc
Challenge #7: Explaining Testing to Managers
I will give credit where it's due and I got my interest in testing after a gentle nudge from my manager who noticed I seemed to be much better at the end of projects when it was down to getting the program finished off and working and all the bugs tracked down and squashed
Challenge #6: Communicating with Customers -- And Users
I've worked here for over 15 years and had about 5 site visits despite that being my number one complaint at every annual review
Nuff said
Our customers do seem to have teams that test our programs before they get rolled out - wouldn't I just love to be liasing with them to find out how THEY do their testing ? And wouldn't I just absolutely LOVE it if they found nothing major whenever we sent them stuff ?
Challenge #5: Making Time for Testing
Stick a finger in the air, think of a number, double it, take off 1 and there's how much time to allocate. Well I don't know how else they come up with their numbers as we never measure how long the testing effort takes
Next steps - find out from the managers just how they do come up with their magic numbers. And get our 'tester' to start measuring how long it takes him - not just to test but to write the test plan and test cases. Yes, shock, horror, we are also going to be doing that
Challenge #4: Testing What's Thrown Over the Wall
Well I just got hit on the head with that one. At the end of the first Sprint I casually asked the programmers what they wanted testing. Just the security aspects ? How about the user interface, was that up for grabs ? Yup. And the consistency of the data, can we test that and see if we can find inconsistencies ? Yup. There seems to be a load balancer, want us to stress that out and see what happens ? Yup. Shall we see how it performs ? Yup. How about some load testing, after all the earlier the better. Yup, why not
Challenge #3: Hitting a Moving Target
This actually hasn't been that much of a problem as our core products haven't changed much the last few years. Those products that have changed a lot haven't been tested.
We're now trying an Agile approach which can mean a lot of change - but it also calls for test involvement all the time as well and also emphasises the importance of communication between developers and testers
Challenge #2: Fighting a Lose-Lose Situation
This is when testers lose if they find bugs and delay shipping and they lose if bugs are found in a shipped product. Not really been a challenge here and in fact the move to start off proper QA and test came from the fact that customers were finding simple bugs that should never have made it out of the door.
Challenge #1: Having to Say No
When testing has been done and problems found then management has listened. The problem has been doing any testing in the first place - and the second problem has been the poor quality of testing. Both problems are now starting to be addressed
So I found it to be a very good read, invaluable for someone in my situation at a company with little or no QA or testing in place.
I had looked at the book before but had been slightly put off by this review on Amazon
Not worth my time, October 29, 1999
The industry has long since passed Perry by. I found this book simplistic in its approach, mired in problems that most software development houses solved long ago, and dependent on overblown methods no longer appropriate in the internet age
I wish I worked where that reviewer worked
However there were other favourable reviews, one which said
This book gives excellent insight for the beginning QA professional
I agree - and would like to thank jpweston for the blog entry and the recommendation
| 