10 Common Software Testing Myths

There are a a lot of myths about software testing out there, whether you’re getting your information from forums, books or the Internet, and they can be damaging both to testers and to the industry.

Some myths stick around and gain a false credibility, meaning that they seem true enough, but prove to be false under closer scrutiny.

Check out our top 10 myths about software testing below so that you can avoid them!

If you’re new to  software testing, you might also benefit from these 5 Software Testing Tips.

Myth 1: Complete Software Testing is Possible

This myth becomes a problem when managers believe it, and so expect their software to be defect free. It is, technically, possible to completely test a piece of software, but the occurrence of complete testing actually happening is rare. Managers need to be discouraged from trying to force software testing teams to search for all the defects in a product under all conditions, since it is far more productive to search for defects when the product is used under the conditions that clients are most likely to create for it.  This will not only prevent numerous hours being wasted, but will also prevent all responsibility for defects being placed upon software testers’ heads. This will create a less stressful environment, which is beneficial for all.

Myth 2: If the product’s been tested, it must be defect free

Now you know about Myth no.1, it should be obvious that this myth is also false. However, you should bear in mind that it can be believed by clients. To begin with, the job of a tester is to find the defects in a product. Since you can never be 100% sure that your product has no defects, you cannot reliably say that your product is defect free, no matter how long you spend testing it and in how many different conditions. All you can do is guarantee that the product is defect-free for the tests you carried out.

Myth 3: Missed defects are due to limited time and resources

Although time and resources are often limited, this is definitely not the main reason for missing defects. No matter how much time and how many resources you have, if your test strategy is flawed there will be defects in the software. Rather than blame the presence of defects on a lack of time and resources, it is far more important to use what time and resources you have to your advantage by preparing a strategy specifically for testing the product you’re working on. Starting off a project with a detailed plan will greatly decrease the risk of unnoticed defects.

Myth 4: The requirements for any project must never change

Before the development of Agile techniques, there was a tendency among software testers to reject the idea of any changes, whether in their requirements or in the documentation. There was also a tendency for the testing team and the development team to work completely separately, which meant that communication was limited and the two teams would accuse each other of the project’s failings – as you can imagine, this didn’t create a happy working environment! Since Agile, the teams have begun working together to create better quality products, and changes in requirements or documentation have become far less of an issue.

Myth 5: Testers should be responsible for release of a product

This myth is based on a common misinterpretation of what a software tester’s job is. It suggests that software testers should be responsible for the quality of a product. This is not the case at all, as it should be the testers’ job to inform stakeholders about the defects or potential defects in the product, after which it should be the stakeholders’ decision whether or not the product is released. By making such decisions the business of the testers, a company puts extreme pressure on their testers as they will automatically be blamed for any flaws in the product. In some cases, this can lead to a product being held back by the testers’ concerns that there may be a single defect left.

Myth 6: Test Automation should be used wherever possible

Although automation can be an extremely useful tool, saving time and money on testing, it should not be the first thing to consider when testing. It is much more important to design the method for testing a product and then use the design to decide whether automation is necessary. If this is not done, many hours can be wasted on creating the automation which will then prove useless. Furthermore, although automation can save money, a thing which attracts management to it, it cannot always ensure a good quality product.  Remember that a good test design at the beginning of a project will improve the quality of the product at the end.

Myth 7: Testing is not a creative or skilled job

If you’re a software tester, you will already know that this is a complete myth! However, people outside the industry can imagine the job to be repetitive and uncreative, just following instructions. However, aside from manual scripted training which requires little training and skill, software testing requires a great deal of creativity to set up as well as the skills to complete a project. Luckily since Agile and other developments in the world of business and IT, non-software testers are gradually coming to recognise software testing as a skilled craft.

Myth 8: Follow the best practices

Following the best practises can work – but only if your project runs on similar lines to the project the best practise was formulated for. In other words, if you apply a process which worked brilliantly for one project to a different project, there is no guarantee that it will work. This is one of the reasons software testing is a skilled and creative job – there is no one way of doing things. Instead, a project has to be considered and planned before you decide how best to go about it. If the industry’s best practise would work for the project, all well and good. If not, you will have to find or create a different way of doing things. Just remember to plan properly to get the results you expect from your work.

Myth 9: All measurements are important

If a team carries out a project making reports on things such as the number of test cases written, how many defects were found, how many were automated and so on, they must bear in mind that the numbers must be reported with additional information to give the numbers meaning. If there is no meaning to the reports your team is sending to management, management’s view of what is happening may become skewed, and they may start to focus on the numbers, such as the number of defects, rather than what these defects entail. For example, a report could say that 10 defects were found at a certain time. However, this number would be useless to management since it does not suggest the scales of the defects – some may be extremely important, others minimal. Remember when sending a report to ensure the reader will be able to understand exactly what it means.

Myth 10: Certifications are all you need to be a great software tester

Certifications are always considered a good thing, especially by clients who will see certifications as a sign that they can have confidence in you. Our Software Testing Training Courses provide a range of ISEB Certifications and ISTQB Certifications for software testers. These qualifications provide you with extra knowledge in your field and provide you with proof that you can apply proven Software testing methodologies. However – to become a ‘great’ software tester also requires experience, which you can only gain through real-world testing.

To find out more about Software Testing Certifications and qualifications, call us on 01273 622272