Inspecting Software Testing Myths

by TestFortExpert on 02/20/2012

Software testing services are rather new and rapidly growing area in information technology. Not every university offers a course in testing, that’s why a lot of developers move from developing to testing. And here they encounter with lots of theories and myths concerning testing which are not always true.

Unfortunately some of them are deep routed. And it feels that they have brought more harm than good to this area. So what are these software testing myths? What harm do they bring to the profession of testers?

Let’s face them.

Myth 1: Testers are guards of quality – release nothing before testers approve.

It often happens that in many companies testers/test team really fight for the right “my word – last word”. However it is not the right way to think. In reality such attitude can be extremely dangerous both for the team and for the product/ can influence badly either on the team or a product. Testers give information to stakeholders. When they perform the role of guards, they feel empowered and therefore fully responsible for the product. So they are concerned that only they are fully responsible for the quality. As a result it raises pressure and provokes situations when testers have doubts about project releasing, worrying about the last remaining unfixed defect.

Myth 2: Thorough testing is possible. Proper planning and you’ve got complete testing with all fixed defects.

A lot of companies are convinced that full testing of the software in not impossible and it’s possible to repair all defects. But it’s completely untrue. No matter how thorough tests you do, it is just a big delusion that makes you think, you can succeed. With every single day applications become more and more complex and therefore there is a small chance to test all the features. If a management team sticks to such a policy, then a test team will bear all the responsibility. From the other side, if testers decide to make the full testing, they will get a choke point. In fact, nearly every project has defects. The only difference constitutes the kind of defects that they have and frequency of their occurring. You can find defects almost in everything that you use. So complete testing is not the best way to get out.

Myth 3: To improve quality is easy and simple; adhere to the professionals with their best practices.

Best practices, standards and processes all make up a big fantasy because they don’t work all the time. Sometimes they just let you down. There is nothing wrong in practice, the problem lies in not being able to identify the context correctly before applying any practices. Practices can benefit only when they are applied after considering the context. If not then they are of no good. Every situation requires individual unique approach. The same concerns test teams when they start to apply the best practices without taking into consideration their own projects, timeline, skills, technology, environment, etc., as a result they can’t provide their work to be done quality and therefore don’t get expected results.

Myth 4: Certificates – CSETE, ISTQB – make you a better tester.

Well, some areas do really need certificates and they are considered good. There is a reason for this. Certificates attract a lot of clients, because they are inspired with the confidence that certificates grant. However the certification exams are not profound enough and can’t entirely reflect if a person is a good professional or not. Everyone who is eager to spend a couple of weeks studying can get a certificate. But will he really become a good tester in these two weeks? Certificates have become just a piece of quality paper, rather than a benchmark of knowledge.

Myth 5: Test automation – automate everything!

Automation is surely of a great support, but only in cases when it adds value. It sometimes happens that a lot of time is spent on developing automation or frameworks for it, and then it is barely used. So, isn’t automation, not taking into account its ROI and effectiveness, just a waste of time? In his recent post Dr. James has emphasized that it only makes sense to use manual/automated testing after a good test design. The perception of assuming automation as a silver bullet is an extremely dangerous myth for the people who are involved in this profession. Sometimes management forgets about improving quality, concentrating only on the process of automation. Overflowing with automation will not bring any good. However, the right level of automation plus a required exploratory testing and a good test design will definitely raise the quality of work and it will become more useful.

Myth 6: Testing gives you zero-defect quality. When testing is done and test team releases the product, it can be considered defectless.

Whoever said this is certainly wrong. It’s unreasonable to state that any product is defectless. No matter how many sleepless nights you have spend testing the product, there will definitely be one combination which wasn’t considered, one condition that was missed and it will surely be revealed in product environment. Being a tester or a manager and believing that zero defect is true, will make you feel responsible every time for any revealed defect in a product. But try to specify your task and say that for the combination you’ve tried, environment and data you’ve used and scenarios you’ve tested, no defects have been revealed. The main aim of testing is to find defects, so as a tester you should do your best to find them and it is highly unreasonably from your side to claim that the product is free from defects.

Myth 7: Make measurements – keep track of everything you can think of.

Writing thousands of reports, recording everything, including how many test cases were revealed, how many of them were accomplished, how many of them were automate, how many defects were found out, etc. and then sending them to developers and management just takes time. But without additional information these numbers do not have any significance. If management concentrates on these numbers in a result suffers the quality. For instance, if number of defects is a priority, then test team will begin filing each and every issue, if number of rejected/duplicate defects is a prior issue test team will start spending time of defects filing them. Anyway any measurement program should be used carefully, always emphasizing on the meaning for all the numbers.

Myth 8: Fixed requirements and documentation are important for any project.

With today’s rapid development this myth is beginning to dissolve. Changes are necessary. Instead of fighting with changes we now accept them. There are still some difficulties left in many organizations, changes are unwelcomed, requirements are the same, and the first thing test team asks for is documentation. Developers and testers work in their own stride and thus communication between them is very limited. In such an environment it’s impossible to produce quality software. Developers and testers should work together to receive quality results.

Myth 9: Time and resource limitation are the main reasons for missed defects. Test team is constantly limited in time and hardly has any resources. If we had more time/resource, we could have done this better.

A lot of testers have encountered with this issue. It’s true that time and resources are limited. But it often happens that defects are missed because some resources are unavailable or because the resources were not properly utilized, that has lead to false strategy and design. People spend great amount of time on useless work that doesn’t add value at all. For example, they write detailed test plans, test cases, writing automation suit which as a consequence become absolutely useless. Time and recourses availability are important, but it’s better to have strong test strategy and design, which is ready to be used, in mind.

Myth 10: To become a tester is easy, you should just be able to read and follow the instruction. Testing is not creative and thus requires none of special trainings or skills. That is why there are only a few professional testers.

This myth is the most ridiculous and damaging myth of all. It has brought a lot of harm to the testing community. Yes, manual scripted testing is easy and requires not that many skills and can be performed with a basic training. Everything else starting from test design and ending in test execution is highly skilled and creative job. It can be performed effectively only when one possesses good skills. But with the recognition of testing as a separate skill, exploratory testing practices, sensible test automaton this myth has begun to evaporate, but time should pass so that testers become recognized and praised.

We Work With

Having one outside team deal with every aspect of quality assurance on your software project saves you time and money on creating an in-house QA department. We have dedicated testing engineers with years of experience, and here is what they can help you with.

Software is everywhere around us, and it’s essential for your testing team to be familiar with all the various types and platforms software can come with. In 21+ years, our QA team has tested every type of software there is, and here are some of their specialties.

There are dozens of different types of testing, but it takes a team of experts to know which ones are relevant to your software project and how to include them in the testing strategy the right way. These are just some of the testing types our QA engineers excel in.

The success of a software project depends, among other things, on whether it’s the right fit for the industry it’s in. And that is true not just for the development stage, but also for QA. Different industry have different software requirements, and our team knows all about them.

Full-Cycle Services

By Platform

By Type

Industries