Intra-organizational tests
Effective test performance requires interaction between the team of engineers who submit the product for testing and the quality assurance (QA) team who test it.
In the process, engineers tend to shift part of their job onto the QA team by performing only basic tests of developed solutions, resulting in lots of petty defects concerning individual modules.
On the other hand the QA team tends to verify the defects only roughly and avoid detailed description for the problems reported to the system making them difficult to be reproduced by engineers.
Good communication on this level saves both sides a lot of time by solving these problems and helping to understand the scope of changes introduced into the project and bound for testing as well as the scope of planned or completed tests.
Extra-organizational tests
The case is different with tests carried out outside of the organization e.g. by the client. To fix the bugs reported from outside it is necessary to reproduce them in the test environment within the organization. Unfortunately most failure descriptions which reach us are limited to a few words and the clients hardy ever know what is a ”reproducibility path”, “initial state”, “expected behavior” or “reproducibility level”.
Obtaining all these data (with or without the client’s help) consumes a lot of QA time and resources.
Communication with the client on this level is essential so it is worthwhile investing some time in the presentation of the failure lifecycle and making the client aware how the quality of bug description influences the repair time. (Unless summary description is indeed intended!)
Quality management
Product quality management usually means estimating the risk of subsequent failures after the execution of a particular set of tests. Notably doing the whole set of test-cases doesn’t guarantee the quality of the product.
Neither can the quality of our product determined by the number of bugs detected without considering the test conditions. Small number of bugs can be result of either their actual absence or hurried and imprecise performance of the tests.
Reduced number of tests due to delivery of incomplete functionalities also affects the quality of performed tests, and results in lower reliability of the product.
The key to success is good communication with the QA department which should be actively involved in the planning of both the scope and duration of the tests. This allows for optimization of the effort needed to ensure the required product quality level.
I hope your dialogs with QA are like this:
QA: „We have found one more critical issue in your project”
PM: “It is good to hear it. We have enough time to fix it and verify it in the next test cycle”
No comments:
Post a Comment