우리의 코드 기반은 현재 20 년 동안 성장하고 있습니다. 우리는 약 10 개발자 + sqa와 500kloc을 사용하고 있습니다. 얼마 전 우리 팀 (2 명, sqa 출신)이 자동화 된 테스트 프로그램을 시작했습니다. 현재 한 번의 실행은 11 시간이 걸리며 어떻게 든 통합 테스트입니다. 우리는이 문제를 해결하기 위해 노력하고 있으며 오 탐지를 줄이고 그 과정에서 좋은 진전을 보이고 있습니다. 그러나 세부 사항은 중요하지 않습니다.
정상적으로 작동하고 있으며 계속 개선하고 있습니다. 우리 (작은 팀)는 그것을 매우 좋아합니다. 우리가 무언가를 깨 뜨리면, 우리는 하루가 지나고 sqa가 살펴볼 때 2 개월이 아니라는 것을 알게됩니다. 또한 우리의 관리자 (dev + sqa)는 아이디어를 좋아합니다. 그러나 팀의 다른 사람들은 테스트 결과를 무시합니다. 체크인 후 테스트가 실패하면 코드 변경이 아니라 테스트 문제이며 장난감 프로젝트 일뿐입니다. 실패한 테스트가 실제 오류 인 경우 여러 차례 토론을했습니다. 대부분의 경우입니다.
우리는 무언가를 강요 할 수없고 원하지도 않습니다. 자동화 된 테스트가 중요하다는 것을 어떻게 알 수 있습니까?
11
이것은 소프트웨어 엔지니어링 문제가 아닙니다. 사람들의 문제입니다.
—
Robert Harvey
@RobertHarvey 나는 "의견에 근거한"의견과이 사이트가 완벽하게 적합 할 것이라는 의견 (그리고 그 의견에 대한 의견) 때문에 SO에 대한 의견을 구했다. 그래서 : 어디서 물어봐야합니까? 저를 교육 시키십시오.
—
피터 슈나이더
나는 이것이 사람들 문제라는 것에 대해 @RobertHarvey와 함께 있습니다. 그러나 Workplace에 따르면 귀하의 질문은 아마도 속임수로 간주 될 것입니다. 예를 들어 기본적으로 무엇을 요구하고있다이 질문을 참조 workplace.stackexchange.com/questions/44964/...
—
피터 M
이 다운 보터 (또는 가까운 투표자)가 낙심하지 않도록하십시오! 어떤 사람들은 그러한 질문이 중요하다는 것을 이해하고 도움을 줄 수 있습니다. 그건 그렇고, 이전 버전 (자동 테스트가없는)이 버그 상자 임에도 불구하고 동료들은 자동 테스트의 유용성을 보지 못했습니다. 한 가지만 변경하고 관련이없는 것처럼 보이는 몇 가지를 중단하십시오. 어떤 사람들은 배우기를 원하지 않습니다 (새로운 것을 배우는 것에 대한 열린 저항이 있음).
—
Bernhard Hiller
이 질문이 종결 된 것은 부끄러운 일입니다. 소프트웨어 엔지니어링이 의미가 있다면 실제 사람들과 함께 일하는 문제를 의미하며 그러한 문제에 대한 답변에는 의견이 수반됩니다. 즉, 몇 가지 간단한 아이디어는 다음과 같습니다. (1) 테스트에서 잘못된 부정을하면 결과가 시간 낭비처럼 느껴지므로 확실히 푸시 백이 증가합니다. (2) 가능하면 런타임을 중단하십시오. 11 개월은 2 개월보다 훨씬 나아도 즉각적인 느낌이 들지 않습니다. (3) sqa는 이러한 테스트를 그들이 보는 메트릭으로 채택 할 것입니다. 그들은 이미이 분야에서 당신의 조직에 의해 인정 받고 있습니다.
—
Dale Hagglund