So, what do you think of the previous part? I am pretty sure all the readers got a generalized knowledge about how hard QA can be and how easy the myths make it look. Let's look at more myths circulating around the SQA field.
Testing Takes Equal Time Always
SQA myth arises due to the disparity in time commitments between the developer and SQA Engineer sides. The developer can quickly change a few lines of code, but the testing strategy and time will differ for each SQA engineer and rely on the project's stage. This is why testing could take more time than expected.
Let us look into the most common three phases of the project.
1. Development Phase
Suppose, a project is in the development phase and has more than six months to deploy to the user base. There will still be a lot of features and functions to be developed. Minor changes during this stage can be tested comparatively quicker depending upon the functionality hidden behind that change.
2. Pre-release Phase
In this phase, all the functionalities will have been deployed, and the client might demand changes inside the product. The developer makes the changes and passes the made changes to the QAE for testing. To prevent regression issues, the QAE examines the change and its operation in this instance. Any prospective alterations that could arise from the change to the associated functionality or modules are also examined. A small change testing during this phase will surely take time.
3. Production Phase
The production phase implies that the users are using it. During this phase, the product owner might expand it and make a few changes to the product. Testing only the change does not make any sense in this scenario. We should carry out tests, remembering that the consumers should be able to use all the features to carry out the crucial operations in the software.
Every time rather a new feature is introduced, the entire product will be released. It is important to verify that consumers continue to utilize it as previously without experiencing any new issues. While all these factors are considered, even the smallest change may require high time to test the product in the production phase.
QA is Expensive
Is it really expensive? It can be easy to cut corners regarding quality control, especially when deadlines start to shrink. However, this approach to cutting corners with quality assurance comes with inexperience. Also, somehow it seems weird saying that adding an extra human resource saves money in a project, isn't it?
Think of a water tank with very small holes in it. You keep pouring water into it to eliminate the water shortage problem. Had you known the holes were present at the early stage, you would have fixed them beforehand.
The same applies to software development. At the later stages of the product, you keep adding resources to eliminate problems that could have been found and fixed at the very early stage of development. Later, you will understand that saving money on QA will cost you more with the loss of customers and overall revenue. Such company and their projects will sooner or later collapse. Many examples of such projects get stuck in a never-ending loop of finding bugs and fixing them without any growth.
I hit two targets with an arrow. "QA is to be done only at the end" is another common myth I unknowingly covered while explaining this topic. Hope you caught both points in one read.
QA Adds No Value
Every product owner wants to add more value to their products and businesses, and the product is valuable only when it is of quality. However, there is a cost that comes with quality. It is a long-standing myth that QA adds no value to a business.
QA jobs are so diverse that it depends on the product they are working on. QA does not only assure the quality of a product. QA engineers are also responsible for providing feedback and suggestions on making the product more qualitative and productive. A small feedback from a QA engineer might help a product stand out from the others.
Thanks to the rise of app stores on different platforms, a product's success or failure is determined by the continuous change of user ratings. It could change at any minute or in every app update. A product's quality assurance has never been more important or worthy of investment. So, the idea that quality assurance does not add value is already a failure. It will result in a significant loss of business revenue if quality assurance is taken lightly.
SQA is Only for Bugs and Errors
This is the most unwanted myth out of all. If you are an SQA, you will not agree with this in any way. If it is all about finding bugs and errors, you do not need an SQA. Anybody, even a layman, can do exploratory testing or ad-hoc to find the errors. Finding bugs and errors is still a small part of software testing.
The investment in SQA is more towards preventing bugs rather than finding bugs. The SQA is involved from the initial phase of a product, i.e., from the time of user stories collection. Their presence is needed from the early stages to prevent the bugs that could be encountered in later phases of product development.
Suppose a product did not involve an SQA during UI/UX design. Designers could provide the best designs with their creativity, but the SQA is responsible for looking into that design from the end user's perspective. The design is then passed to the developers, who will develop a product module. After that, it goes on for a round of quality tests. During the test, SQA will find a blunder in the design and send it back to the design team with feedback to improve it differently. After that, the developers need to develop again according to the new design provided by the design team, which is time-consuming and expensive. This could have been prevented by simply including someone from the SQA department.
So, SQA prevents bugs and errors beforehand and saves time, which is one of the main reasons to invest in SQA.
SQA Engineers are Not Needed After The Unit Test
Do you think only unit tests are enough for a product to meet its quality? If yes, you will deliver software with interface flaws and faults brought on by various parts of the product that does not function well together.
Unit test, by the name, only suggests unit testing. Different units, after integration, may not function properly and cause issues in every corner. Besides, anyone who tests after the unit test is not always good at reviewing a product's responsiveness or UI/UX, whether it's friendly or instinctive.
The biggest benefit of a dedicated and knowledgeable QA is their ability to identify holes in potential assumptions made by anyone. It is not only the skills the QA carry. Their trained mindset to find unexpected loopholes in a product is exceptional. So, not everyone can provide the quality that your business needs.
Closing Out
An SQA requires knowledge about the developing software, programming languages, specific tools and methodologies, source code repositories and automated test coding.
Additionally, SQAs must be proficient in technology, arithmetic, and verbal and written communication. They need engineering skills to establish test plans, comprehend QA testing environments, and follow the agile development process. SQAs must be adept problem-solvers with solid logical and reasoning abilities and practical skills like excellent documentation, time management, and many more.
Never underestimate the importance of QAs; there are no ifs and buts about it.
Thank you for reading, consider subscribing!