Golden rules for software testing

By Ray Claridge
Pin It

Read these simple golden rules for software testing. They are based on my testing 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.


  • Mark Crowther said:  

    I really like the message you make in this post as it touches on the topic of a talk I recently gave at BCS SIGiST.

    What I said there was 'agile', 'traditional', etc. can be thought of as metaphors for ways to approach testing that at their core were really about addressing the type of things you've written above.


  • Viet Dung said:  

    It's helpful. Thanks for sharing

  • -e said:  

    You cannot develop a system of any size without using automated testing - otherwise, you'll find you are perpetually short of testing capacity. I agree it cannot substitute for "manual" testing, but it is necessary to have it, otherwise, you will waste time, and probably have very unhappy testers when they are always retesting things.

  • Anonymous said:  

    Very Informative. Thanks!