Let’s start from the basic concepts that are never fully known from the get go.
What is a software or material product quality control flow?
People ask themselves this each time they receive a product that does not fulfill the conditions and promises that the product claims to achieve during the sale.
For example you can find that the product’s useful life period is shorter than expected, the material quality which was built is poor and it does not resist what it was supposed to.
The same example applies to a tailored software development when it’s implemented and running in production and the final users finds that certain software features are unusable due to a coding error or a misunderstanding of the software business rules.
So what does the final user think about this situation?
Clearly, something like: “This is not what I expected. I want my money back”
This concept applies to all the companies that produce assets. A product without quality is a product that will be failing quickly, risking client’s satisfaction or even breaking legal agreements that could end eventually in a monetary loss or legal prosecution.
In order to implement a correct quality process, the company has to:
● Closely follow the ISO/DIS/etc. standards for measuring the produced product’s quality
● Have a quality accomplishment dedicated area which performs the quality control processes
● Elaborate quality indexes and ratios to know precisely where the company is and where the company wants to be regarding the quality assurance.
The end user’s satisfaction is the company’s objective to conquer, so what is better than offering a good product that makes the client choose the company again among all the options that the market has.
Another fact is that when the customer decides to buy a certain product, a lot of factors are taken in account, but there is one that is always present:
“Acquire the best at the lowest cost”
This fact makes the customer evaluate the product's quality and here is where a company which has a correctly quality control policy implemented makes all the difference.
At companies that have correct QA policies, QA areas are composed by a set of professionals called in several ways as: QA Engineer, Tester, QA Analyst, SDET, etc. but the objective is the same for all: to provide the highest quality levels within what is being evaluated.
This gives place to the following question:
How can the QA team be sure about what is being tested and if it accomplishes the standards?
Here is where the distinct QA roles come into play.
Here we can take a look at the QA roots, the ISTQB syllabus.
The ISTQB syllabus says:
- The tester needs experience in using the system or product that he/she is going to test
- Clear product documentation and/or product specification elaborated by the functional analysts have to be available for the testers
- A test cases suite that covers the complete product’s functionality to be tested has to be available as well
- Testers need to do a role exchange with the final user to find the possible errors that the end user could face
Nowadays modern software companies are including quality control areas with the purpose of getting the best of what they are producing.
QA engineers work side by side with developers, helping them to verify that the code developers write works as it was expected to, and also that the whole system behaves correctly elaborating, in this way, what the user needs.
Working as a QA engineer you have to face the fact that sometimes developers do not understand precisely the idea of what the software has to do or how it has to work.
This situation derives in an immediate rejection from QA of the newly developed software piece.
This situation also provokes the developer to take the rejected software piece again to be fixed or modified and then after correcting it, submit it again to QA.
This flow can take a cycle or loop shape that moves the delivery date far away.
So what’s wrong with this if the company has a QA area that works together with the developers?
The answer is really simple. It’s true that there is a gap between what developers do and what QA considers to evaluate or verify about the way the software works.
One thing that is true is that these cases are not related to the developer’s abilities or knowledge or the QA’s perspectives.
So, again, we can ask the question: Where is the problem? Or what is provoking that gap?
As it is quickly evident, having expert developers and expert QAs is sometimes not enough. The true problem is that the whole company needs to extend the QA activity not only to software development but to the complete documentation and requirement specification that the development process manages.
The earlier QA starts participating in the process the lower the bug fixing cost will be and also the faster better solutions can be implemented bringing the delivery dates much closer to the expected date.
So to not die trying to implement QA, the company should give more participation to the QA areas within all the development life cycle stages. If that happens, the final product’s quality will be improved, making the product not only fulfill user’s expectations but also to overcome them.
If you are looking for software testing services & QA,Devlane is ready to take care of your project. Our team of engineers is ready to start working on your product. We can carry on your entire project from scratch, or we can lend you some IT resources to augment your in-house team.
If you wish to learn more about this, please visit our full website here. Or you can contact us directly here.
Thank you for reading!
