[6] Software Quality Assurance Myths are Dispelled

Many companies that plan to develop their software product misunderstand some conceptions about quality assurance, while the same concepts look evident for software development providers. As a software development company, SumatoSoft sees some lack of understanding of the role of quality assurance (or simply QA)  in development from our potential clients. We see that confusion while working on Quality Assurance planning and QA estimation on different types of projects.

This article summarizes the common myths and customers’ misconceptions about quality assurance in software testing.

Myth 1 – We do not need testers, the development team should write without bugs.

Quite often, especially if the client is a business person and not from the IT sphere, they try to optimize the expenses and try to reject “ineffective and additional” activities in the project’s lifecycle.

The development part cannot be canceled in any case. However, basically, they think, we can release the project without QA in software testing. It happens because testers don’t develop the product that will be used and seen by customers (as the developers do). Moreover, Quality Assurance specialists are the people who may delay the release. Who wants to wait for someone to finish their tests when the development has been completed already?

However, without a dedicated tester, there is someone from the team who executes the QA testing tasks and responsibilities in the product teams. It can be a project manager or product owner, setting aside their direct responsibilities, developers (with a higher hourly rate than QA specialists typically have), or a business analyst (without specific tester’s skills or knowledge). All these people are not motivated to perform quality assurance because it’s not their role. Moreover, they have a lack knowledge of best practices and quality assurance guidelines. As a result, somebody from the team takes care of the testing part, but this activity will not be explicit for the client.

Or, the testing process will be skipped altogether due to a lack of resources. In any case, the quality of that kind of QA in software testing will be lower, because it will be provided by somebody who is not a specialist in these activities, and the cost will be higher.

Why developers can make a mistake when developing software:

• The human factor – fatigue, blurring the eyes.
• Missing requirements errors. Requirements testing is additional specific activity and it is needed to know rules on how to perform it effectively. 
• They do not look at the product as a completed system as END user/tester does. 
• They may not know the specific integrations of modules and functions, but only those parts that they develop themselves.
• Delivery deadlines – people can work worse due to the need to quickly complete a project.
• System and integration complexity may not be taken into account during testing and End to End cases are not carried out.
• Defects accumulate with the growth of the product and the scope of necessary regression testing increases. Developers have their direct responsibilities to develop features, and the goal to meet the deadlines will lead to skipping important regression testing.
• They may miss changes in requirements.

Myth 2 – Why will testing take so much time? We just add one button.

This myth on QA in software testing appears due to the difference in the working investments from the developer and tester sides. The developer can change a few lines of code and this is relatively fast. For the tester, the strategy will have differences and it also depends on the stage of the project.

Let’s analyze 3 situations:

1. The product is being actively developed, but it is not yet available to users, and will not be available for several months. In this case, QA in software testing can take a small amount of time, depending on the functionality hidden behind the button.
2. The product is in the pre-release phase. All functionalities have been developed and the client wants to change something. In this case, the tester will check not only the button and its functionality, but will also look for potential disruptions that may happen as a result of these changes, connected functionality, or modules to avoid regression issues (issues in previously developed and working functionalities) appearing. Nothing should be broken by the changes the developer has made.
3. The product is in production (users are working with it) and we are expanding it. Here, the tester’s focus is not only on the button (functionality) but also on the fact that users can perform ALL operations that are important to them. We will not release a separate feature – every time we will release the WHOLE PRODUCT (specifics of the development process). It is important to check that users can still work with it as before and without any new problems.

Myth 3 – Testing should be 30% of development estimation

This is also a fairly common idea about the direct connection between development estimations and testing estimations.

At different stages of the project, the scope of software testing should be different. At the start of the development phase, there is a small amount of testing that should be provided, which involves such activities as: 

• deep-diving into a product idea and domain;
• reading and reviewing specifications and requirements;
• preparing test documentation;
• planning needed testing activities;
• preparing needed test data.

At different stages during custom software development, the scope of software testing should be different. At the start of the development phase, there is a small amount of testing that should be provided, which involves such activities as: 

The assessment also depends on the number of environments you want to support/check. For example, if 1 run takes 20 hours, then for one environment it takes 20 hours. But if we need to check for 3-4 – this is already 60-80 hours of work – but the scope of functionality has not changed.  Testers naturally apply techniques to reduce this time, but, for example, it cannot take less than 20 hours, only more. For instance, this is true with mobile applications.

Myth 4- You said that testing will take 4 hours – why don’t I have a finished product even after a week? Or why don’t you fit that into your testing estimation?

In this case, often the question “How long will the testing take?” hides the question “When will I have a product of proper quality ready?”

But the challenge there for Quality Assurance in software testing is that we can predict how much we will spend on testing the product or feature in this round, but we cannot predict what results from quality assurance services and how many issues we will find. 

For example, we said testing will take 40 hours – this means that after 40 hours we will be able to provide you with information about the product quality (issues that we found, list of improvements). This information can help to make a business decision if we can release the product or not. If all has been good and the bugs found are not significant, then the product will be ready in 40 hours and the product will be released as-is.

If there are serious bugs and problems that QA found, then a stabilization period is required (correction of defects by development and their double-checking, in order to be sure that something additional has not broken and the quality reaches the desired level). And unfortunately, it will be 40 hours for testing in the 1st Round + time for stabilization from the development team + time for Quality Assurance of rechecking fixes + time for regression testing to be sure that nothing was broken by changes in code. It definitely will take more than 40 hours.

Myth 5 – Automation is an unjustified investment – is it better to add one more tester to the team?

This can be either true or not. Automation is a great tool but should be applied correctly. Automation can save time for repeated regression testing or repeated actions, but there are also cases when it may be more efficient to hire a second tester as part of your project.

Where I would advise thinking about automation for QA in software testing in the following cases:

1. Frequent and stable deliveries are important.
2. The product will be developed for more than six months
3. Many environments/browsers/platforms to maintain and test.
4. There are many routine operations in testing product functionality, test data preparation, test environment setup.

Myth 6 – Why should I increase the size of the testing team if my development team does not grow and we have been working like this for half a year?

This myth is similar to myth 3. The amount of regression testing grows each time a new feature is added. 

For example, we have already released features A and B in our product. In the current release, we will add C and D. Testing will include the new feature testing activity for C and D and regression testing for A and B. In the next release, we will add feature F. In this case, the tester should check the new feature F and recheck A, B, C, and D features (to confirm that they are still working as expected).

Can you just imagine how fast this scope of regression testing will grow in half a year with several developers working in a team? Testers will try to optimize coverage but this can lead to skipping some regression checks and then to the unpredictable appearance of regression defects in untested areas. In some cases, only the growth of the QA team can help (but automation is sometimes much more preferable, of course).

What exactly can be included in the Quality Assurance estimation

1. Requirements review and testing, as well as deep-diving into the project idea. Quality Assurance in software testing can find issues in requirements that can save a lot of money before release.
2. Communication – QA tester is a full-fledged team member, who should know what is going on or what will be changed in the project to get ready for testing or to prepare questions for the team that will avoid issues in the future.
3. Functional testing – reviewing that implementation is being performed according to the functional specifications.
4. Test-data preparation, planning of testing activities, test-documentation preparation.
5. Describing identified issues in the issue-tracking system for all team members. This action is necessary for QA in software testing since it allows having a review of the actual product quality and making correct business decisions about the upcoming release.
6. Cross-browser and cross-platform testing for the product being reviewed on different devices and in different environments.
7. Defects validation to review fixed defects in the code and regression testing to check that code changes did not add new issues in the already tested parts.
8. Reporting.
9. Non-functional types of testing – security, performance, automation testing.

Final words from SumatoSoft

To summarize, Quality Assurance in software testing nowadays is not a nice-to-have activity but a must-have one to get a stable product of predictable quality and released by the deadline. 

In SumatoSoft we will help you with quality testing and the development of reliable software. We have well-established processes that are built to bring value to our clients. We believe that different solutions need different quality assurance services and optimize the volume of QA services just for your project. Contact us and get a free testing estimation!