(*원제의 Quality into Your software를 어떻게 번역해야 할지 고민했다… 그렇긴음.(뭔가 평범한 제목이라서 이런 제목으로 감히 글을 쓰려고 하면 내용에는 바뀐 내용이 있지 않으냐며 기대했는데 무난한 내용 같습니다.).원제목:Are You Testing The Quality Into Your Software?작성자:By Richard Estra. 작성일:September 25,2020. URL:https://www.techwell.com/techwell-insights/2020/09/are-you-testing-quality-your-software서론.시험 팀은 소프트웨어 품질을 개선할 책임이 없고 품질이 이미 소프트웨어에 포함되어 있을 필요가 있습니다.품질이 소프트웨어에 들어 있지 않은 경우는 몇가지 미묘한 지표로 나타납니다.프로덕션(실제 환경)릴리스 전에 경영진이 시험 팀이 릴리스에 대해서”승인” 하고 소프트웨어가 요구 사항 및 품질 기대치를 충족시키고 있음을 보이는 것은 드물지 않습니다.이 승인은 프로젝트의 종료시에 이루어지기 때문에, 테스터는 테스트 배포에 이어지는 여정에서 소프트웨어에 도입된 모든 문제를 파악해야 한다는 부담을 지게 됩니다.대신, 소프트웨어 개발 라이프 사이클 전체에서 정기적으로 사인 오프가 발생할 필요가 있습니다.현대의 소프트웨어 개발 프로세스의 짧은 도래(comings)일반적으로 문제는 부적절, 중단 또는 존재하지 않는 프로세스에 의해서 소프트웨어로 도입됩니다.최신 소프트웨어 개발 프로세스를 사용해도, 고품질의 제품을 구축하고 있다고 확신할 수 없어요.코드를 작성하기 전에 테스트를 작성하고 실행하는 TDD(Test-Driven Development)를 사용하면 좋은 단위 테스트를 작성할 능력이 필수적이며, 종종 간과됩니다.DevOps를 사용한다고 실패하는 주된 원인의 하나가 사람입니다.협업은 불가결한 특성입니다.사람들은 팀 간의 격차를 좁힐 수 없습니다.팀 간의 협업과 커뮤니케이션은 인적 및 비 기술적 장애를 일으킬 가능성이 있습니다.다른 문제는 툴 선택 시험 적용 범위의 결정 및 통합의 문제와 함께 재능 있는 사람을 고용하는데 어려움이 있습니다.개발자와 테스터가 함께 새로운 코드의 유효성을 검사하고 작업하는 CI/CD(계속적인 통합 및 지속적인 송신)을 활용할 경우 잘못된 테스트를 수행하고 잘못된 프로세스를 자동화하는 문제의 원인이 됩니다.이는 CI/CD를 계속적으로 부정확/ 수많은 결함을 의미하게 다시 정의할 수 있습니다.제품의 품질이 시험 중임을 확인 중인 품질은 소프트웨어가 시험에 배포된 뒤 작성된 결함 수에서 가장 분명합니다.그러나 심각성에 관계 없이 연기할 수 없는 결함은 문제를 강조할 뿐입니다.지침으로서 연구에 따르면 코드 1000줄당1개의 결함은 일반적으로 고품질의 제품의 표시로 간주됩니다.열악한 소프트웨어 품질의 미묘한 징후는 다음과 같습니다.이전에 수정 확인된 결함이 다시 문제로 일반적으로 배포상 쓰기에 의해서 발생합니다.회귀 테스트는 에러를 갚겠습니다.그 이유는 코드의 복잡함, 미숙한 개발자 혹은 어떤 영역의 코드 업데이트가 다른 영역의 문제를 일으키는 부주의로 인한 가능성이 있습니다.소프트웨어가 시험된 뒤 예상되는 동작에 동의하기 위해서 팀 대화가 필요합니다.이는 존재하지 않는 불완전 또는 애매하거나 모순되는 요건의 결과일 가능성이 있습니다.최적(optimal)의 시나리오 실행 중에 결함이 발견되자 Happy Path기능이라고도 불립니다.이 맑은 날의 시나리오에서 문제가 발견되면 항상 품질이 나쁘다는 경고 신호입니다.소프트웨어에 의한 최적인 패스에 결함이 있을 경우 합리적이고 가능성이 낮은 패스에도 문제가 있는 것으로 확신할 수 있습니다.. 마지막에, 고객이 소프트웨어 문제를 보고하고 있습니다.문제는 마지막 방어선인 테스트 조직을 회피하고 있습니다.해결 책차 같은 몇몇 베스트사례로 제품의 품질을 향상시킬 수 있습니다.테스터 개발자 및 기타의 이해 관계자는 SMART철학에서 이상적으로 작성된 요구 사항을 철저히 검토하고 이해하고 수용을 승인합니다.소프트웨어 설계 및 코드의 둘러보다 검사, 요구 사항에서 역추적 가능 업체 승인 지침의 적용 수준 팀원의 승인.코드 복잡도 툴을 사용하고 복잡하거나 오류가 발생하기 쉬운 코드 또는 유지 관리가 어려운 코드를 식별합니다.허용될 때까지 다시 설계·시험 전략·테스트 사례는 개발자 및 상급 시험기에 의해서 승인되어 승인된 요구 사항까지 추적할 수 있습니다.개발자가 승인, 실행 및 승인한 단위 테스트.개발자가 승인, 실행 및 승인한 통합 테스트.자동화되는 테스트에 대한 팀 합의의 결론 어떤 소프트웨어 개발 프로세스를 사용해도 품질 검증 단계를 통합하고 각 결과에 품질이 기본적으로 포함되도록 하는 것이 중요합니다.TDD에서 QTDD에 이동합니다.DevOps에서 QDevOps로, CI/CD에서 QCI/QCD에, 예방 조치는 항상 시정 조치보다 낫습니다.계단을 청소하는 것처럼, 항상 위에서 시작해서 아래로 내려갑니다.이 최초의 접근은 소프트웨어의 품질과 기관의 품질에 있어서도 마찬가지입니다.누구도 혼자서 교향곡을 부르지 못하도록 품질은 모든 사람의 책임입니다.
