[기술포스팅 원문] https://www.florianbellmann.com/blog/never-taught-qa 

[기술포스팅 요약]

본 글은 소프트웨어 프로젝트에서 품질 보증(QA) 조치가 부족한 상황에 대해 설명하며, 이를 개선하기 위한 접근법을 다룹니다. 많은 기업들이 QA를 중요하게 여기면서도 예산 문제로 인해 프로젝트 막바지에 QA를 수행하는 경우가 많습니다. 이로 인해 소프트웨어의 품질이 저하되고, 이러한 문제는 다음 릴리스 주기에도 반복됩니다. 본 글에서는 QA의 중요성을 강조하고, 이를 효과적으로 적용하기 위한 전략을 제시합니다.

• 대학교에서 배우는 내용: 컴퓨터 과학 전공에서는 QA에 대한 교육이 부족합니다. 대부분의 시간은 알고리즘, 컴퓨터 동작 방식, 언어의 역사 등 기초적인 부분에 할애되며, 프로젝트 관리 접근 방식과 스크럼이 포함되지만 QA는 제외됩니다.

• 회사에서의 QA 부족 문제: 예산 문제로 인해 QA 조치가 자주 생략됩니다. 개발이 지연되거나 범위가 확대되면 QA 시간도 부족해져 결과적으로 불완전한 테스트가 진행됩니다. 이는 소프트웨어의 품질 저하로 이어집니다.

• 릴리스 주기와 QA: 일부 팀에서는 QA 표준이 있지만, 종종 팀원들이 QA 없이 프로젝트 관리를 위해 최소한의 테스트만 수행합니다. 표준이 있어도 팀이 실제로 QA를 적절히 적용하는 데는 어려움이 따릅니다.

• 햄스터 휠에서 벗어나기: QA 조치가 부족한 프로젝트에서 경험과 자신감을 쌓아가는 것이 중요합니다. 관리직과의 논의, 릴리스 시의 압박, 실패한 시스템 처리 등을 겪으면서 문제를 해결하려는 노력이 필요합니다.

• 비용에 대해 이야기하기: 소프트웨어의 안정성이나 유지보수 용이성을 설명하는 것보다, QA를 수행하지 않았을 때의 비용 증가를 설명하는 것이 효과적입니다. 개발 비용이 15% 증가할 수 있음을 설명하며, QA 조치가 장기적으로 비용 절감에 기여함을 강조합니다.

• 최소 효과적 투입량(MED): QA 조치를 과도하게 설계하기보다는 소프트웨어의 핵심 기능을 보장할 수 있는 최소한의 조치를 취하는 것이 중요합니다. 핵심 기능이 제대로 작동하도록 하고, 이를 통해 안정성을 점진적으로 확장하는 접근을 추천합니다.

• 주의할 점: 새로운 프로젝트에서는 QA 개념이 마련되어 있는지 확인합니다. 무엇을 배포하고, 무엇을 보장해야 하며, 어떤 조치를 취하지 않을지에 대해 문서화된 계획을 갖는 것이 좋습니다. 또한, 코드를 작성하면서 테스트를 병행하는 것이 코드의 구조를 개선하는 데 도움이 됩니다.

• 프로젝트의 이점: QA 조치를 통해 프로젝트가 건강하게 성장할 수 있으며, 개발자와 관리자의 작업 환경이 개선됩니다. QA 조치를 통해 프로젝트에 기여하고, 이를 통해 개인의 성장과 프로젝트의 성공을 동시에 이룰 수 있습니다.

• 프로젝트 개선하기: 프로젝트에서 QA 조치를 도입하고자 한다면, 작은 단계에서 시작하여 MED 접근 방식을 적용해보세요. 팀 내에서 변화를 주도하고, QA를 필요로 하는 접근법을 예를 들어 교육하며 대화를 시작하는 것이 중요합니다.

이 게시글은 [GPT-4o model]를 통해 요약되었으며, 정보 공유 목적으로 게시되었습니다. 원문 게시물에 대한 책임이나 이해 관계가 없습니다. - 소프트웨어QA 포럼