소프트웨어 테스트는 실제로 전문 프로젝트에서 수행됩니까?

나는 오랫동안 개발자 였고 계약자이기 때문에 여러 회사에서 많은 프로젝트에 참여했습니다.

프로젝트의 20 % 미만 이 체계적으로 테스트 된 것으로 추정 됩니다. 체계적으로 테스트하면 계획없는 테스트 이외의 테스트를 의미합니다.

또한 프로젝트의 10 % 미만이 팀의 일환으로 전담 테스터, 테스트 계획 문서, 개발자가 자동화 된 테스트를 작성하고 테스트 범위를 추적하고 결과를 측정하는 경우 철저하게 체계적으로 테스트 된 것으로 추정 됩니다.

두 가지 질문

1. 이 문제에 대한 귀하의 견적은 얼마입니까?
2. 소프트웨어 테스트와 관련하여 귀하의 전문 경험은 무엇입니까?

추가 참고 사항

체계적인 테스트 질문은 상당히 편향된 답변을 얻을 수 있기 때문에 (다른 사람들보다 우월하다고 자랑하는 사람들) 다른 개발자 (방법론 테스트에 노출되지 않은 사람들)도 답변을 제공 할 것을 권장합니다. 회사를 제외한 모든 곳에서 수행됩니다.

경력 테스트를 통해 본 패턴은 프로젝트의 실패 위험과 강한 일치를 보여줍니다. 대규모 프로젝트는 소규모 프로젝트보다 테스트 될 가능성이 높으며, 미션 크리티컬 애플리케이션은 외부 마케팅 웹 사이트보다 테스트 할 가능성이 높으며, 사내 시스템은 공개 프로젝트보다 테스트 할 가능성이 적습니다.

그것은 여전히 ​​과도하게 테스트 된 프로젝트와 충분히 테스트되지 않은 프로젝트가 있지만 소수입니다.

우리가 생산하는 모든 것이 완전히 테스트되었습니다. 내부 QA 팀에 과부하가 걸리면 프로젝트를 테스트하는 해외 팀이 있습니다. 내부 팀만큼 좋지는 않지만 다른 주제입니다.

지난 15 년 동안 제가 일한 세 회사는 모두 자동으로 실행되는 단위 테스트를 받았습니다.

그 회사 중 두 곳에서 회사 소개를 추진했습니다.

지난 9 년 동안 저는 기본적으로 수락 / 회귀 테스트 만 충족했습니다. 몇 가지 단위 테스트 만있었습니다.

예.

테스트 양은 앱에 필요한 신뢰성과 프로그래머 문화의 성숙도에 비례합니다.

웹 사이트는 종종 버그를 겪고 있습니다 (깨진 링크 는 결함입니다).

비디오 게임은 종종 버그가 있습니다.

Windows (마지막)는 상당히 안정적입니다.

라우터는 매우 신뢰할 수 있습니다

병원 모니터 "휴식하지 마십시오"

회계 실패 비용은 신뢰성과도 관련이 있습니다.

10 년 동안 공식적인 코드 테스트로 프로젝트를 수행 한 적이 없습니다.

현재 업무에는 기능 테스트 만 있습니다.

문제는 경영진이 코드 테스트에 대해 아는 사람이 없다는 것입니다. 테스트 부서는 코드 테스트에 대해조차 모를뿐 아니라 높은 수준의 사양을 따르고 행동 / 기능 관점에서 준수하는지 확인합니다.

우리는 우리가 코드를 잘 작성하도록하는 자격을 갖춘 소프트웨어 리더가 없습니다. 결과는 스파게티 코드, 많은 회귀, 누락 된 일정 등입니다.

우리는 남아시아의 중견 외국 기업입니다. 그러나 우리는 항상 미국 기반 프로젝트를 수행하고 미국 회사에서 보낸 요구 사항을 직접 처리합니다.

우리는 구축하는 모든 응용 프로그램에 체계적인 테스트를 적용합니다. 아마도 테스트 품질은 표준이 아니지만 우리는 그것을 사용합니다.

내 순수 주의자는 얼마나 엄격하게 테스트하거나 공식 테스트를 수행할지 여부에 대한 결정에 내재 된 위험 관리가 필요하다는 것을 받아들이고 싶지 않습니다. 필자가 프로그래밍 프로젝트의 큰 비율이라고 생각하는 내부 앱의 경우 버그를 풀고 버그를 발견 한 후 신속하게 패치 하는 데 소요되는 비용은 전체 테스트 팀의 비용보다 큰 경우가 있습니다. 물론 앱과 잠재적 인 실패 비용에 따라 다릅니다.

즉, 위험 관리 계획이 공식화 된 테스트가 부족한 이유라고 생각하지 않습니다. 비 기술적 인 관리자는 그것이 제공하는 가치를 이해하지 못하고 비용 만 보는 결과라고 생각합니다.

내 샘플은 백분율을 추론하기에는 매우 작지만 여하튼 계속됩니다.

하나는 팹리스 칩 + 펌웨어 회사로, 환상적인 테스트를 수행했습니다. 수십 개의 설비에 대한 연중 무휴 자동 테스트, 각각 수십 개의 유닛을 동시에 테스트합니다. 테스트 소프트웨어 개발에 전념하는 소프트웨어 팀. 테스트 장비 제작 전용 하드웨어 팀. 수십 명의 경쟁사에 대한 호환성 테스트 그들은 심지어 칩이 파운드리를 떠날 때 팹이 실행하는 일부 테스트를 개발하고 디버깅하기 위해 수백만 달러의 칩 테스터 설치를 구입했습니다.

다른 하나는 은행이었습니다. 이것은 완전히 다른 환경입니다. 제품 릴리스는 없지만 지속적으로 계속 실행되는 수많은 사내 소프트웨어가 있습니다. 이 사람들은 그들이 한 모든 변화에서 cr * p를 테스트했습니다. 그들은 DEV / QA / PROD 환경을 매우 엄격하게 분리하고, 자동 회귀 테스트, 생산으로 출시하기 전에 최종 사용자가 서명 한 필수 QA 테스트 등을 수행했습니다.

예, 사람들은 체계적인 테스트를 수행합니다. 그러나 당신이 말할 수 있듯이 나는 전형적인 컴퓨터 사용자를 위해 전형적인 GUI 소프트웨어를 제공하는 곳에서 일한 적이 없다.

저는 현재 무선 의료 기기를 만드는 소규모 신생 기업을위한 내장 펌웨어를 작성하고 있습니다. 우리는 엄격한 테스트를 수행해야하며 CEO에게 직접보고하는 사람이 이끄는 완전히 별도의 품질 부서가 있어야합니다. 나는 별도의 테스터에 의해 이전에 코드를 철저히 테스트 한 적이 없었습니다 (비교하는 유일한 시간은 약 15 년 전에 위성 TV 시스템에서 작업했을 때입니다).

우리의 테스트 결과는 FDA에 제출되었습니다 (지금까지 우리는 두 개의 FDA 허가를 받았습니다. 우리의 개발 및 테스트 방법은 모두 정기적 인 감사를받습니다.

따라서 공식적인 테스트를 많이하는 것은 대기업 만이 아닙니다.

참고 – 25 년 이상의 계약 프로그래밍 / 컨설팅에서 저는 공식적인 테스트를 거의하지 않은 많은 회사에서 근무했습니다. 그들 대부분은 더 이상 주변에 없습니다.

거의 모든 회사에서 체계적인 테스트를 수행했습니다. 현재 회사는 몇 가지 기본 단위 스타일 테스트를 가지고 있지만 충분하지 않습니다. 이로 인해 일부 품질 문제가 발생했습니다. 본인 이외의 다른 사람이 사용할 모든 프로젝트에 대해 독립적 인 철저한 테스트를 수행하는 것이 좋습니다. 보낸 돈은 그만한 가치가 있습니다. 작동하지 않는 응용 프로그램은 사용되지 않습니다. 그것은 내면뿐만 아니라 외면에도 적용됩니다.

지난 20 년 동안 8 개 정도의 회사를 통해 경력을 쌓았 지만 테스트 를 하지 않은 프로젝트를 수행 한 적이 없습니다 . 테스트 규모는 각 회사마다 다르지만 필자가 작업 한 모든 전문 개발 프로젝트는 공식 테스트를 수행했습니다. 이는 중소 기업에 동일하게 적용됩니다 ( "소규모"는 10 명 미만, "중소"는 2 천명 이하를 의미).

일부 회사는 자동화 된 테스트를 많이하지 않았고 일부는 수동 테스트를하지 않았지만 적어도 하나는 다른 테스트를 받았습니다.

그것은 고객의 요구에 달려 있습니다. 계약 상황에서는 합격 테스트가있을 수 있습니다. 사내 테스트는 일반적으로 테스트가 거의없는 슬랩 작업입니다. 소비자 물건은 일반적으로 기능이 많지만 가장자리가 거칠습니다.

짧은 답변 : 예

긴 대답 :

1. 나는 첫 번째 범주에 대한 적절한 추정치를 가지고 있지 않지만 (아마도 0에서 약간 떨어져 있지만 얼마입니까?) 실제로 내 경험은 두 번째 추정치와 일치합니다. 테스트의 양과 유형은 개발중인 응용 프로그램의 종류, 사용 가능한 시간 범위, 개발자의 기술과 프로젝트 실행 방법에 따라 다르기 때문에 의미있는 백분율을 제공하기가 어렵습니다. 실제로 개발자에게 가장 중요한 장애물은 수락 테스트가 청구 목적을위한 중요한 이정표이므로 승인 테스트입니다. 그러나 예상치 못한 상황이 발생하고 (더 많은 요구 사항) 개발자가 문제 해결 및 극복에 필요한 시간 외에 가능하고시기 적절한 (이 단계에서) 가능한 모든 임시 테스트를 제공해야하는 경우도 있습니다. 예기치 않은.

2. 위에서 언급 한 여러 가지 요소의 조합으로 다양한 프로젝트를 수행했습니다.

   • 공식적인 단위 테스트, 통합 테스트 및 대부분의 임시 테스트

   • 단위 테스트부터 전용 QA 리소스, 자동화 된 테스트 (테스터가 자체 도구 세트로 수행)와 관련된 세부 테스트 계획 및 코드 커버리지 보고서에 이르기까지 매우 공식적인 범위입니다. 그러나 이것이 관리자들만큼이나 개발자에게 항상 의미있는 것은 아닙니다.

개인 수준에서는 본인이 다루고있는 기술에 적합한 적절한 테스트를 작성할 때 내 선택에 대한 이해를 유지하고 스스로 판단 할 수 있습니다. 기본적으로 실제로 내 작품에 의미가 있고 유익한 것들이 많지만 숫자는 크지 않습니다.