The first person to link the quality of the product to profits and who identified and described the cause-effect linkage, was Edwards Deming, a doctor in physics, a statistician, and a pioneer of quality in production. The success of his work at Toyota’s plants in the 80's was called the Japanese miracle.
The central ideas of Deming’s philosophy concern the satisfaction of the consumer and continuous changes at all stages of product development. This serves to improve consumer properties, guarantees competitiveness and, as a result, encourages profitability.
In answering this question, you should always keep in mind that such criterion is somewhat subjective and can’t be looked at from only one perspective. In fact, there are four perspectives that developers, managers, clients, and QA engineers to assess a software product.
The aforementioned professionals define the product quality according to their personal standards. For instance, according to the client’s opinion, “quality” is the complete absence of errors and the solution to the problem for which it was created.
For the developer and manager, the quality is apparent in a clear solution to the business issue and the absence of errors in the software that blocks the possibility of using it efficiently.
For the tester (or Quality Assurance Engineer), the quality level has to be well above average. At this stage, developers have to provide the product without the errors that significantly affect the experience of using the software.
The quality is measured according to the international quality standard ISO/IEC 9126.
This international quality standard determines:
-The extent to which functionality meets needs;
-Whether it is attractive, intuitive, and easy to use;
-How stable the system is;
-Whether physical resources are used efficiently;
-How consistent it will be in bringing benefits across different environments, conditions, and configurations;
-The effort the project team will need to plan the scaling, make changes, test and diagnose the system's performance.
Frequently, developers try to justify a software product of dubious quality through the client’s eyes with reference to the line from the Agile Manifesto- “working software over comprehensive documentation”. Although such an approach leads to the product being ready for the launch, this can also result in additional costs. Even a single bug can result in substantial efforts and costs in order to correct it. Let’s calculate!
There are usually five stages:
Just imagine, at almost every step, you bear the costs (time and money!) in the form of additional work done by:
*You should also consider costs due to a possible loss of reputation and revenue.
A quite reasonable question here is how to reduce at least the number of such mistakes. As coding is a creative process, it’s unreasonable to demand from developers that they write bugless code every time. Instead, it’s better to think how you, as well as each team member, can improve the process at every stage.
Quality is a shared responsibility of the team.
Here, at K&C, we put out customer satisfaction at the forefront. For this reason, when it comes to the quality assurance process, we act according to a carefully thought-through plan with particular rules.
Rule #1. Specify expectations
The answer “well, we want a good product without any issues” is insufficient. We always try to find out and define the exact expectations of our client regarding the final product, especially if they don’t have a technical background.
Rule #2. Define “must-have” activities before testing
For example, they can be:
-Preparing a test plan. Here we define the scope of work for the project and a test focus. Without it, we will not be able to estimate any test coverage, features to be not/tested, estimation, scheduling, and resource management.
-Preparing a test strategy. The test strategy consists of guidelines, analyzes risks, and answers questions regarding how exactly to achieve test objectives.
Rule #3. Discuss project coverage
The project coverage is included in the test plan. Firstly, we discuss it with a client and then prepare particular checklists and test case documents. We always tell our clients that there are no “ideal” test cases or a 100% QA guarantee when covering the project (because of time limitations, project difficulty, or lack of people). Sometimes, this is just not needed.
The project coverage depends on the customer’s expectations and specifications regarding the application’s future use.
For example, in typical applications, a login form can be described in test cases with 2 variants:
“Do valid login, do invalid login”
While the more complicated application will already need six variants:
“Valid login, invalid login, ability to login with restricted accounts, check visual appearance, check texts, check localizations, etc.”
Rule #4. Explain a testing approach
Quality Assurance is a process that is mostly facilitated by motivation, attention, and the skills of those who perform the tests. What’s more, a testing process often depends on personal preferences. Two different QA engineers will never provide the same testing strategy. Furthermore, there is not a unified testing approach. Thus, we always tell our client what will be tested and how it will be done.
Rule #5. Set the right questions
An iterative approach, which we often use, raises questions: “What can I adjust in the process? How can I do testing better? Which tests should I do now?” And other questions. But the process of testing doesn’t only involve the QA engineer. He or she should work in cooperation with a customer and a team lead, as well as other testers. They, in turn, can raise such important questions as: “What are your expectations for this iteration of the process? More deep testing? Should we focus on performance testing? Or should we spend more time on regression?”
Rule #6. Juggle priorities
Correct prioritization is essential for every project, especially for small teams.
-What should be tested first?
-How much time do we have?
-What is our priority: to test system stability or to test new functionality?
-Shall we try to develop new scenarios or concentrate on existing ones?
-Should we try to investigate and implement new techniques in testing or focus on usual checklists creation?
All of these questions are crucial and should be discussed before each iteration of testing. It is not possible to tell the QA engineer: “You have just one day to test everything across multiple devices, and there should not be any issues after sprint”. For example, for one of our clients, we prepared a Master Test Plan document, and we became sure that if some issues are found by a customer in the old code, old features, or non-default devices, it will not be the QA’s fault as we have discussed the top priority for testing and focused our attention on it.
A high-quality product is a result of the blood, sweat, and tears of the whole team, not only the QA engineer. A clear understanding of the final result by the customer, an elaborated test strategy, and an appropriate approach are the keys to a product’s success.
Talk to the K&C team to develop the right testing strategy tailored to your product!