Golden Rules for Software Testing

  

 

  • Introduction

 

Read these simple golden rules for software testing.  They are based on years of practical testing experience and solid theory.

 

  • Its all about finding the bug as early as possible

 

Start the software testing process long before you start development.  Make sure testing is started at the beginning of the software project.  The moment you start analysing the application you should start testing by making software testing part of the reviewing process. 

 

Learn more...

 

    • Make sure you have these 3 software testing levels

     

      1. Integration testing (performed by IT)

      2. System testing (performed by professional testers)

      3. Acceptance testing (performed by end users)

     

    Learn more ...

     

      • Don’t expect too much of automated testing

       

      First let me state this : automated testing can be extremely usefull and can be a real time saver. But it can also turn out to be a very expensive and invalid solution. 

       

      Learn more on the testing tools page... 

       

        • Deal with resistance

         

        If you like to be instant popular, don’t become a software testing manager !  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 project partners will appreciate the great job you're doing !

         

        Learn more on Practical Test Reporting... 

         

          • Do regression testing every new release

           

          Okay, you 've tested your new development succesfully.  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‘ll be lost without change request management

               

              Keep track of your change requests before they make your life miserable.  You should consider these change request statuses :

               

              • Reported

              • Analysed

              • Busy programming

              • Ready for test IT

              • Ready for user test

              • Accepted

              • Rejected

                

              Give the requests a priority status :

              • Show stopper (must have, no work around)

              • Major (must have, work around possible)

              • Minor (not business critical, but wanted)

              • Nice to have

               

              Actively use these statuses for reporting and follow up !

               

              Learn more on bug reporting...

               

                • Make good arrangements with development and business  

                 

                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 decisons 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 very helpfull 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 toroughly about how you 're going to organise your testing.   You can be very succesfull by using basic tools like MS Excel.

                   

                    • 'Impact' and 'Chance' are the keys to decide on risk and priority

                     

                    You should keep a helicopter view on your project.  For each part of your application you have to define the 'impact' and the 'chance' of anything going wrong.

                     

                    'Impact' being what happens if a certain situation occurs.  

                    --> What 's the impact of an airplane crashing ?

                     

                    'Chance' is the likelihood that something happens.

                    --> What 's the chance to an airplane crash ?

                     

                    If both are high, you 'd better put in a big effort in testing it. If both are low, some agile testing will do.

                     

                     

                     

                     

                     

                    If you like what we're doing, link to us !

                                                  Home

                     

                    Mastertesting.Net © 2008  
                    Ma