Testing for success – the 7 principles of software testing

    Post 5 of 46
    // Changing the CSS styles to the blog posts page to remove a search bar // and recentre the navigation bar Testing for success – the 7 principles of software testing

    We thought we would revisit the 7 principles of software testing as a reminder to keep them at the forefront when testing for success!

    1. Testing shows presence of bugs – design tests to find bugs, not tests that pass!

    When you hear the term software testing it creates visions of a bug free system and that a green light means success. But it in actual fact, as a process, software testing is focussed on finding defects. Our own software tester is renowned for saying ‘it’s been a good day’ when she has a list of bugs registered in bugzilla!

    It is also important to remember that even after testing, it doesn’t mean that an application is bug free, there will always be others to find so continuous testing is a must.

    2. Exhaustive testing is impossible – it is not possible to test all combinations of data, so prioritising according to risk is essential.

    Often testing cannot capture every single bug or defect that exists. The data variations that can be used within some applications are so vast that in order to carry out all the different types of testing required it would need extensive time and an endless pot of resource and money.

    Prioritisation and risk analysis is key, as is keeping a focus of the value and purpose of the application. Why has the application been developed? What are the risks to the organisation or business if it or a key element within it fails? Answering these questions when mapping out requirements and planning the testing project allows critical elements at risk from bugs, and key test cases, to be identified and become the focus for the testing team.

    3. Early testing is essential – do not leave testing until end of life cycle.

    Bugs found early on will reduce defects at later stages and therefore will be less time consuming and less expensive to fix. If the testing team is involved early in the software development lifecycle then defects in areas such as UX can be identified and addressed before the development gets too far. Fixing a small change in early development is easier than having to change the full functionality in a much larger system down the line.

    Remember testers are experienced defect spotters and so can often see them long before anyone else!

    4. Defect clustering – The Pareto Principle

    The 80/20 rule! It is followed in many situations and software testing is no different. Working on the principle that 80% of bugs can be found in 20% of an application, experienced testers can identify those modules that are risky. However testers need to be careful to vary the test cases as if the same ones are tested over and over, eventually they will not find any bugs, and as we know from testing principle number 1 this does not mean success.

    5. Pesticide paradox

    The pesticide paradox is related to the repetitive use of the same pesticide mix to eradicate insects during farming and where over time the insects develop a resistance to the pesticides.

    The same approach applies to software bugs. New bugs can lie undetected if the same set of repetitive test cases are conducted over and over. As with the case of the Pareto Principle test cases need to be reviewed and revised regularly to make sure they can find all the defects. Using new test techniques can also help to make discovering new bugs easier.

    6. Testing is context dependent

    The type of testing carried out is dependent on the purpose of the application and the nature of the business or organisation in which it has to perform. For example testing popular websites to check they can cope with traffic demands or testing the functionality of a gaming application to ensure UX may need different approaches and techniques.

    7. Absence of errors fallacy

    A software may be bug free but still not meet user requirements. Just because in its current format all (or nearly all) the bugs have been resolved, it doesn’t mean that it meets the need of the user. The purpose of the application needs to be kept at the forefront throughout the full testing cycle. Just testing something to make sure it works isn’t the same as testing something to make sure it meets user requirements. All you just end up with is a bug free application that no one will use. User expectation must always be kept front of mind.

    Find out more about load and functionality testing your application Here

    Social share:

    This article was written by Jar Technologies