자동화 된 테스트 : 비즈니스 가치 설명

나는 이것이 생각하지 않습니다 시작하려면 반복 의 다른 질문 에 대한 단위 테스트 . 내가 도움을 원하는 것은 프로그래머, 분석가, 관리자 및 테스터 팀에게 그 가치를 분명히 표현하는 것입니다. 자동화 된 테스트를 통해 단위 테스트 (예 : JUnit), BDD (예 : JBehave, Fitness) 및 UI (Selenium, Watir)를 구별 할 필요가 없다고 생각합니다. 동의하지 않는 답변을 작성하십시오 :))

다음은 내가 확인한 목록입니다. 확장하거나 세분화하는 데 도움이되는 답변을 찾고 있습니다.

1. 시간 / 비용 절감 : 자동화 된 테스트 작성은 작성된 테스트 사례보다 시간이 더 걸릴 수 있습니다. 그러나 테스트가 여러 번 실행되는 것을 고려 하면 자동화 된 테스트 를 실행 하는 한계 작업 (예 : 비용 / 시간) 이 몇 배나 줄어 듭니다. 자동화 된 테스트가 저렴하므로 시간이 지남에 따라 시스템을 쉽게 변경할 수 있습니다.
2. 문서 : 시스템이 테스트보다 작동하는 방식을 알 수있는 더 확실한 방법은 없습니다. 다른 모든 문서는 일반적으로 작성된 시점에서 오래되었지만 테스트 (적어도 통과 한 문서)는 실제로 작업 방식을 보여줍니다. 이는 최종 사용자 및 API 문서 모두에 해당됩니다.
3. 코드 품질 : 테스트 작성을 통해 다음을 수행 할 수 있습니다.
   • 테스트는 클라이언트이기 때문에 클라이언트를 고려하십시오
   • 코드를 테스트 할 수있게 만드는 종속성은 종종 다른 대형 시스템을 사용할 필요가없는 코드를 만드는 방법을 찾는 것을 의미합니다.

내 생각 중 몇 가지 :

1. 자동화 된 테스트를 작성하는 데 더 많은 시간이 소요될 수 있습니다. 단위 레벨 TDD (자동 테스트에 투자하려는 경우 시작점으로 권장)를 수행하는 경우 기능을 코딩하는 데 약 30 %의 추가 시간이 필요할 수 있습니다. 여기서 중요한 점은이 추가 30 % (팀이 좋은 테스트를 작성하는 방법을 배우면서 처음에는 30 %보다 높음)가 시간이 지남에 따라 비용을 절감하기 위해 구축 된 투자임을 설명합니다. 최소한 단위 레벨 TDD를 사용하면 시스템 설계가 느슨하게 결합되고 응집력이 높아서 시간이 지남에 따라 시스템을 변경할 수 있습니다. 새로운 요구 사항과 예기치 않은 버그는 항상 시스템을 변경해야합니다.
2. 이러한 테스트를 작성하는 데 걸리는 시간, 테스트를 실행하는 데 걸리는 시간 및 필요한 유지 관리의 양을 고려할 때 수용 수준 및 UI 수준 테스트의 가치에 대해 많은 논쟁이 있습니다. James Shore 가이 기사 를 읽는 것이 좋습니다 .
3. 자동화 된 테스트 세계에는 좋은 방법과 나쁜 방법이 있습니다. 경영진에게 자동화 된 테스트를 던지고 있다면 팀이 좋은 테스트를 작성하도록 훈련시키는 방법을 함께 제시 할 것입니다. Roy Osherove의 단원 테스트 기술, Michael Feathers의 레거시 코드를 효율적으로 사용 및 James Shore의 민첩한 개발 기술은 이러한 주제를 직간접 적으로 다루는 훌륭한 책입니다. 또한 일종의 코치 또는 공식 교육도 살펴 봐야합니다. 큰 변화입니다.
4. 비즈니스 가치 측면에서 위의 포인트 중 # 2 및 # 3은 실제로 첫 번째 포인트를 제공하므로, # 1 포인트로 귀환하여 # 2 및 # 3이 어떻게 더 큰 포인트를 제공하는지에 대해 이야기하겠습니다. 문서화는 시스템을보다 이해하기 쉽게 만들어 팀의 작업 속도를 높여줍니다. 코드 품질을 통해 시스템을 변경에 맞게 조정할 수 있으므로 팀 작업 속도가 빨라집니다. 비즈니스 사람들에게는 아이디어가 제시된 시점부터 아이디어가 작동하는 소프트웨어로 제공되는 시점까지 가치 흐름을 극대화하는 것이 중요합니다.

확실한 가치 중 하나는 자동화 테스트를 지속적으로 실행할 수 있다는 것입니다. 재건 또는 이와 유사한 시간마다. 이렇게하면 프로그래머가 문제가있는 코드를 작업 한 후 몇 시간 또는 며칠 내에 버그 나 회귀가 빠르게 열리므로 컨텍스트 전환이 훨씬 쉬워집니다. 지속적인 테스트의 두 번째 이점은 테스트를 작동 상태로 유지해야한다는 것입니다. 오래된 테스트를 모두 수정하는 테스트주기의 첫 주를 보내는 것보다 더 지루한 것은 없습니다. 자동화 할 수 있으면 언제든지 실행할 수 있으며 정기적으로 실행하면 테스트 나 코드에서 버그를 빠르게 발견 할 수 있습니다.

시험 비용

자동 테스트가 작성되면 몇 줄의 비용으로 컴퓨터에서 실행할 수 있습니다. 동등한 수동 테스트를 위해서는 급여 담당자가 지침 목록을 작성해야합니다.

테스트 신뢰성

컴퓨터는 항상 동일한 테스트 절차를 충실하게 수행 할 수 있습니다. 인간은 실수를 저지르고 게으 르기 쉽다.

컴퓨터의 테스트 실패 모드도 훨씬 쉽게 알 수 있습니다. 충돌 (테스트 보고서 표시가 중지됨), 잘못된 테스트 결과를 초래 한 약간의 오류가있었습니다 (결정적 테스트를 다시 실행하면 결과가 다름). 사람이 발걸음을 놓치고 "확인"을 체크 오프하면 어떻게 알 수 있습니까?

내구성 테스트

자동화 된 테스트는 실행하기 위해 구체적인 아티팩트 (예 : 코드 조각) 여야하며 다른 소프트웨어 개발 아티팩트 (소스 저장소)에 자연스럽게 포함됩니다. 테스터가 메모 용지에 수동 테스트를 개발하여 공식화 할 수는 없습니다. 비즈니스는 이러한 상황이 발생하지 않도록 프로세스를 필요로 할 가능성이 높습니다.

시험 값

테스트 결과를 일관되고 쉽게 분석 할 수있는 형태로 출력하도록 컴퓨터를 프로그래밍 할 수 있습니다. 개인이 동일한 항목을 생성하기 위해 데이터 입력을 수행 중이거나 분석가, 개발자 또는 관리자가 요약해야하는 자유 형식의 메모를 기록하고 있습니다.

대부분 (테스트 범위에 따라) 버그가없는 코드이며, 가장 큰 논거 중 하나는 관리자에게 발견 된 버그에 대한 테스트를 작성할 수 있다고 말하면 향후에 언제라도 알게 될 것입니다. 그 버그는 다시 온다 :)

내 의견으로는 단위 / 통합 테스트가 가장 중요하지만 MVC와 같은 UI 패턴을 적용하면 대부분의 프로젝트에 충분합니다. 나는 일반적으로 컨트롤러 / 발표자에 대한 모든 작업을 테스트하고 데이터 바인딩을 뷰에 남겨 둡니다.

물론, 자동화 된 테스트는 사용자가 할 수있는 가장 사소한 일을 파악하려고 시도하면서 애플리케이션을 둘러싼 오래된 포인트 앤 클릭을 대체하지 않습니다.

지속적인 통합 의 포인트도 있습니다 .

코드 품질로 인해 제품 품질, 비즈니스 가치 및 유지 관리 성이 향상되도록 노력해야합니다. 그렇지 않은 경우 코드 품질이 중요합니다.

"저비용"과 "더 많은 기능 / 단위 시간"/ 작은 사이클 타임의 마술 포인트로 이끌어야한다고 생각합니다.

그러나 사건을 제기하기 전에 귀하의 상황을 반영하는 것이 좋습니다. 귀하의 질문으로 인해 자동화 테스트의 잠재적 단점에 대한 블로그 게시물 을 작성 했습니다 .

리팩토링의 용이성은 여기서 큰 요소입니다. 훌륭하고 읽기 쉬운 (!!!) 단위 테스트로 적용 범위를 넓히면 기존 기능을 손상시키지 않아도 시스템을 리팩토링 할 수 있습니다.

개념을 팔아야합니다. 코드를 향상시킬 것이라고 말하지 않아야합니다. 코드에 대한 투자가 있으면 즉시 안티 / 자동 테스트를 실시하게됩니다. 그들이 좋다면 그들은 또한 GIGO를 이해할 것이므로 그것이 적용되지 않는 이유를 이해하지 못할 것입니다.

Fitnesse와 같은 것들도 문서화 측면으로 판매하고 싶습니다. 그러나 경험하기 전에는 시각화하기가 어려울 수 있습니다.

나는 그것을 판매하는 행운이있을 것 같아요 영역

1. 단위 테스트는 많은 개발자 하네스를 대신 할 수 있습니다. 모든 로그인 / 메뉴를 거치지 않고 디버그 / 테스트 할 영역에 응용 프로그램을 만들 수 있습니다.

2. 테스트를 통해 테스트 데이터를 설정하는 데 많은 시간을 소비하지 않고 (특히 적절한 조롱 시스템 사용) 문제 상황을 설정하고 쉽게 반복 할 수 있습니다.

3. BDD 및 UI 테스트 스위트를 빌드 할 때 테스터가 다음에 볼 때 기다리는 것보다 간단한 휴식이있는 경우 훨씬 빠른 응답을 얻습니다.

4. BDD 및 UI 테스트는 변경으로 인해 영향을 받았을 수있는 모든 측면을 확인하기 위해 버튼을 반복해서 누르는 것을 피하고 모든 영역을 기억할 필요가 없습니다.

5. 자동 빌드는 종종 누군가 코드 체크인을 잊었을 때 강조 표시됩니다.

6. 테스트는 버그가 다시 나타나지 않도록 도와줍니다.

7. 단위 테스트와 알맞은 조롱은 상호 연결된 코드가 적고 해결하기 쉬울 것입니다.

당신이 그것을 팔려고하고 종교로 개종하지 말아야한다는 것을 명심하십시오. 그러므로 작은 발걸음을 받아들이고 반대하지 마십시오. 또한 좋은 시험을 작성하고 조정하는 데 시간이 걸립니다.

누군가가 그 문제에 대한 제안 된 해결책을 받아들이 기 전에 문제가 있다고 생각해야합니다.

자동화 된 테스트는 버그 수정 비용을 절약 할 수 있으므로 동료가 버그 수정 비용이 크거나 과도하다는 것을 믿지 않으면 확신하기 어렵습니다. 그 비용이 높거나 과도하지만 사람들이 그 비용을 믿지 않는다면 먼저 그 비용에 대한 설득력있는 데이터를 얻어야 할 수도 있습니다.

기업이 좋아하는 것은 가치를 높이고 비용을 낮추는 것입니다. 자동화 된 테스트가 추가 비용을 발생시키기 때문에 어떻게 가치가 증가하는지 설명해야합니다.

코드가 모듈 식인 경우 재사용 할 수 있습니다. 즉, 테스트를 다시 작성할 필요가 없으며 기존 코드 위에서 작업 할 수 있습니다.

레거시 프로젝트가있는 경우 자동화 된 테스트를 통해 리팩터링이 훨씬 쉬워집니다. 기술 부채는 일정 시점에 상환되어야합니다.

당신이 제공하는 문서 논쟁은 그리 좋지 않습니다. 테스트를 최신 상태로 유지하고 문서를 최신 상태로 유지하는 것의 차이점은 습관입니다.

"내가 도움을 원하는 것은 프로그래머, 분석가, 관리자 및 테스터 팀에게 가치를 분명히 표현하는 것입니다. 자동화 된 테스트를 통해 단위 테스트 (예 : JUnit), BDD ( 예를 들어 JBehave, Fitness)와 UI (Selenium, Watir)는 모두 비슷한 가치를 제공한다고 생각하기 때문에 (그러나 동의하지 않는 답변은 자유롭게 작성하십시오)) "

좋아, 나는 그 도전을 할 것이다;)

나는 주로 프로그래머 및 QA와 함께 일하며 내 도구는 루비, 레일, 테스트 장치, rspec, 재스민 및 셀레늄입니다.

rspec 및 testunit의 BDD / TDD 도구는 프로그래밍의 일부입니다. 당신은 그것들을 나누지 않고 경영진과 별도로 이야기하지 않으며, 시간 부족으로 인해 그것들을 연기하지 않으며, 모든 시간 견적에 포함시킵니다. 정말 밀어 붙였다면 사람들이 컴퓨터 과학과 프로그래밍에 대해 설명 할 시간이 얼마나 필요한지 물었습니다. 이 테스트는 프런트 엔드에 사용하지 않습니다

GUI / UI / Jasmine / Selenium. 이것들은 다릅니다. 프로그래머 배경 지식이있는 QA 직원이이 작업을 수행했습니다. 우리는 테스트가 가능한 한 강력하고 레이아웃이 아닌 컨텐츠를 기반으로 작성되었는지 확인합니다. 이것의 (아마도 새로운) 비용은 변화된 비용 으로 설명되어야한다 . 나중에 소프트웨어 고장, 고객 손실 및 고가의 수정 비용을 지불하는 대신 몇 가지 간단한 방법으로 비용을 상대적으로 적게 지불합니다.

핵심은 '자동화 된 테스트'가 아닌 특정 범주의 테스트에 대해 이야기하는 것입니다. 후자는 조금 성 가시고 걱정이 될 수 있으며 시간 낭비가 발생하는 위치의 예를 생각해 내기가 너무 쉽습니다.

항상 테스트를 4 개의 그룹으로 나누는 것이 좋습니다 (자세한 내용은 여기 참조 ). 여기 나와 함께, 나는 이것이 당신이 다른 사람들에게 테스트를 한 순간에 판매하는 데 어떻게 도움이되는지 알게 될 것입니다.

1. 핵심 기능 테스트 . 즉, 웹 사이트 모니터링 도구의 경우 모니터링중인 웹 사이트에 대해 발생해야하는 경고 테스트입니다. 이 테스트를 통해 이러한 것들이 끊어지지 않도록합니다.
2. 전체 응용 프로그램의 연기 테스트 . 예를 들어, Selenium을 사용하여 웹 앱의 모든 링크 / 버튼을 탐색하고 서버에서 오류가 없는지 확인하십시오. 이 테스트는 빌드가 완전히 손상되어 테스터에게 시간을 낭비하지 않도록합니다.
3. 취약한 코드를 테스트합니다 . 즉, 이전 모듈의 경우 아무도 만지기를 원하지 않거나 항상 버그가있는 복잡한 코드입니다.
4. 개발자가 업무를 지원하기 위해 작성하고자하는 테스트 . 때때로 테스트는 무언가를 쓸 때 유용하지만 위의 범주에 속하지는 않습니다.

테스트를이 범주로 나누면 이제 다른 토론을 할 수 있습니다. 처음 세 그룹 (어쨌든 개인의 재량에 따름)을 취해 사람들이 그러한 코드 조각에 대한 테스트가 가치가 있다고 생각하는지 물어보십시오. 동의를 얻을 수 없다면 지금은 해당 테스트를 포함하지 않을 수 있습니다. 가능하다면, 즉 사람들이 각 커밋에서 실행되는 핵심 기능에 대한 테스트가 유용하다는 데 동의하면 추가를 시작하십시오.

유용 할 수있는 다른 그룹 은 수동으로 수행하기 어렵거나 시간이 많이 걸리는 테스트입니다 . 수동 테스트 시간을 절약하거나 시간이 부족하여 건너 뛴 테스트를받는 것과 관련하여 이점을 설명하기가 매우 쉽습니다.