Golden Rules of Testing

This content is syndicated from Agile Testing | Tester Troubles by Ray Claridge. To view the original post in full, click here.

In a previous post I've blogged about switching from waterfall to agile and how this impacts us testers.

It's true, the change can be difficult for some of us. However, fear not, somethings never change regardless of the development approach.

I've put together, what I think are the golden rules of testing that still apply. So when someone says "that's not how we do it in agile" (and believe me - they will) don't take none of it and stick with the basics.


Read these simple golden rules for software testing based on my own experiences.

Its all about finding the bug as early as possible:
  • Start the software testing process by analysing requirements long before development.
Make sure you have these 3 software testing levels
  • Integration testing (performed by IT)
  • System testing (performed by professional testers)
  • Acceptance testing (performed by business users)
Don’t expect too much of automated testing:
  • First let me state this : automated testing can be extremely useful and can be a real time saver. But it can also turn out to be a very expensive and invalid solution.
Deal with resistance:
  • If you like to be instant popular, don’t become a software tester ! You 'll find out that you are going to meet a great deal of resistance... It is very likely that you will end up being the sole defender of quality at a certain point. Other participants in the project will be tempted to go for the deadline, whatever the quality of the application is.
  • You should deal with this by reporting facts and figures in stead of opinions. It might take a while before your work colleagues appreciate the great job you're doing !
Do regression testing every new release
  • Okay, you've tested your new development successfully. Great. But do the features of the application that you didn't change still work ? You really should test this before going live.
Let real users test with real data
  • This one is obvious but who does it ?
  • You cannot beat real data.
Give defects a test severity status :
  • Critical (must have, no work around)
  • High (must have, work around possible)
  • Medium (not business critical, but wanted)
  • Low (nice to have)
Let product owners deceide if a defect is to be fixed based on business priority:
  • A bit obvious, but I've seen testers make this decision and assign business statuses
  • Actively use these statuses for reporting and follow up !
This might be the most difficult goal to achieve:
  • You should talk about exit and entry criteria with IT. When is software good enough to deliver to a test team ? Think about server errors, certain level of IT testing achieved, when and how to build...
  • Same goes for business. What quality do they expect ? Who is going to make decisions on when to go live ? Make sure it is not you. Your role should be advisory.
Focus on the software testing process, not on the tools:
  • There 's a lot of talking about test management software. Sure, they can be very helpful indeed. These tools probably will take a lot of work out of your hands... But don't forget : it 's you who has to define the testing process. No tool is going to do that for you ! Think thoroughly about how you 're going to organise your testing. You can be very successful by using basic tools like MS Excel.
Good luck

Ray

Leave a Reply

What is 8 + 3 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)

There are 101 ways to approach anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”

DAN PULHAM, DIGITAL DIRECTOR
TELSTRA