RSS DEV 커뮤니티

QA가 전략적으로 되지 못하는 것은 무엇인가? (그리고 게임을 바꾸는 방법)

"모든 사람이 품질을 책임지는 개념은 잘 이해되고 있지만, 실제로는 그냥 이론에 머물러 있습니다. 스퀘이드는 품질을 QA에 아웃소싱하고, 개발자는 코드를 커버리지 없이 푸시하고, PM은 속도를 품질보다 우선시합니다. 품질의 가장 큰 장벽은 기술적인 것이 아니라 게으른 마음가짐과 용기의 부족입니다. 회사는 품질이 우선순위라고 말하지만, QA를 고립시키고, 개발자는 테스트를 하지만 80%의 커버리지를 QA에 맡깁니다. 사실은 QA가 "배송 보증자"로 여겨질 때까지 엔지니어링은 자신감을 가지고 실수를 계속할 것입니다. 진화를 방해하는 세 가지 행위는 QA가 준비된 코드 검사관, 개발자가 기능 배달자, PM이 백로그 디스패처입니다. 각 역할은 직면하여 책임을 져야 하며, 개발자는 테스트 가능한 코드를 작성하고, 테크 리드는 테스트를 요구하고, PM은 속도보다 품질을 우선시해야 합니다. 품질의 올바른 구조는 이미 존재하지만, 이를 심각하게 받아들이고, 고위 리더쉽은 품질의 기둥입니다. 변화는 어려울 수 있지만, 비품질의 비용이 더 아프며, 품질은 전략적 투자로 보아야지 비용으로는 안 됩니다. 궁극적으로는 누가 매일 첫 번째 커밋부터 품질을 구축하는지 용기를 가지고 있는지의 문제입니다."
favicon
dev.to
What still prevents QA from being strategic? (And how to change the game)
Create attached notes ...