The following strategies and practices can help IT developers and engineers do that, even if they don't have previous experience in QA:
Developers can write automatic tests. Developers already know how to code - that's what they do throughout the day - so study automatic testing frameworks and writing tests for that is not a big problem for them. If you have a staff developer, you don't need a QA engineer to write your automatic test. (Even if you have QA staff, developers can always help in writing automatic tests.)
IT engineers can contribute to "Shift-Right" testing. Shift-right testing means testing in production. In a certain sense, that's what engineers have done when they monitor the application. To get your IT engineer to play a direct role in QA, ask them not only to monitor problems but also to find ways to use the insight of monitoring products to improve the quality of the software as a whole.
Sustainable feedback. Without a full-time QA team, no one ensures that the developer knows about the quality problems of the software that appears in production (and is detected by IT engineers). The engineer also does not have a good way to find out how the developer expects the application to behave. That is why it is important to establish direct sustainable feedback between developers and IT engineers, so that each team can discuss software quality problems with other teams.
Collective ownership of the quality of the software. From a cultural perspective, every IT developer and engineer must share in ownership of the quality of the software. This must happen to the title even if you have a full-time QA team. But in the absence of QA, there is no main job is the testing and quality of the software; As a result, he fell to the developer and it had to have a full QA.
Be efficient. It's hard to sell the developers and engineers by having a QA if they think it will mean more work and time. That is why it is very important to empower them with tools to make QA efficient, such as testing automation (which eliminates human needs to spend time running tests manually), extended debugging (which helps interpret the test results quickly), and parallel testing (which allows more Many tests to run at once).
In the perfect world, every company will have a large and dynamic QA engineer team that spends their days perfecting the quality of each release code that goes down from the CI / CD pipe. In the real world, many organizations do not have a QA team at all, or lack of large enough to handle all QA's own obligations. That's another reason why the QA responsibility of everyone involved in software engineering is very important.
No comments:
Post a Comment