기술 스타트 업에서 소프트웨어 테스트는 어떻게 수행됩니까?

10

소프트웨어 테스트의 이점을 자랑하는 많은 연구 기사와 기술 블로그를 보았습니다. 나는 그것을 확신했다. 그러나 모든 소프트웨어 테스팅 리서치가 대규모 소프트웨어 회사에서 수행되기 때문에 스타트 업에 실제로 적용되는 것은 아닙니다. 신생 기업은 대기업과 비교하여 요구와 제약이 다릅니다.

그래서 이것은 의문을 제기했습니다. 기술 스타트 업은 자동화 된 테스트를 작성해야합니까? 그렇다면 대기업과 같은 방식으로 이루어 집니까? (연기 테스트, 회귀 테스트 등)이 주제에 대한 일부 연구 기사를 참조 할 수 있다면 가장 좋습니다. 내 자신을 찾을 수 없기 때문에.

(여전히 경력이 아직은 없지만 자동화 된 테스트 작성에 진지한 신생 기업은 아직 보지 못했습니다.)

testing startup

— ming_codes
소스

5

나는 10-yo의 작은 스타트 업에 합류했으며 실제로 야간에 실행되는 테스트를 처음 추가했습니다. 내가 천재 였기 때문은 아니지만, 관리자 (코더)는 추가 할시기가되었고 마침내 인력이 있다는 사실을 처음으로 인식했습니다. 스트랫 업은 종종 먼저 생존하고 나중에 완벽해야합니다. 물론,이 스타트 업은 비 기술자들에 의해 시작되었으므로이 기능은 "스킵"되어야했습니다.

— Job

5

10 살짜리 스타트 업 ...?

— pap dec

딜버트는 "업계의 모든 사람이 모범 사례를 채택하면 모범 사례는 평범한 것이된다"고 말했다. 나는 그것이 사실이라고 생각합니다.

— ming_codes

10 살짜리 스타트 업 ... 그들은 자바를 사용해야합니다 : 3 세 디자인 + 7 개발 :) 농담 (나는 자바 개발자 btw입니다)

— nuvio

11

해야 할 일과 현실적으로해야 할 일 사이에는 항상 상충이 있습니다. 그렇습니다. 많은 스타트 업이 프로젝트 주도 개발 및 자동화 된 테스트를 포기하여 프로젝트를 시작하고 실행하는 데 시간을 단축했습니다.

소셜 네트워킹 사이트와 모바일 앱 회사는 현재 큰 거품이며 경쟁 이 치열 합니다. 때로는 4 개월과 5 개월 사이의 생활 차이가 당신을 잃는다는 것을 의미합니다.

시장 출시 시간이 핵심이며, 성공이 발생하면 확장 할 시간입니다. 테스트되지 않은 소프트웨어를 리팩터링 할 가치가있는 시간이 충분합니다.

— maple_shaft
소스

시장 출시 시간은 약간의 신화입니다. 시장에 늦게 진입 한 참가자는 기존 플레이어 (friendter> myspace> facebook)를 날려 버릴 수 있습니다.

— Joeri Sebrechts

@JoeriSebrechts 저는 소프트웨어의 진보와 소프트웨어가 늦은 참가자의 성공과 어떤 관련이 있는지에 관한 흥미로운 기사를 읽었습니다. 사용중인 변수가 있으며, 비슷한 솔루션을 사용하는 늦은 참가자의 안전 기간은 소프트웨어 사용자 기반이 얼리 어답터에서 일반 사용자로 변환되는 시간과 같습니다. 비슷한 솔루션은 물론 시장에 처음 진입 한 사람과 비교할 때 비슷하고 획기적인 기능을 의미합니다 (예 : Facebook은 MySpace와 비교하여 획기적이었습니다). 얼리 어답터의 임계 대량에 도달하면 일반 사용자가 마이그레이션을 시작합니다.

— maple_shaft

12

소프트웨어 테스팅은 종교가 아닙니다. 아주 좋은 생각입니다.

지금 시험을 작성할 인력이 없다고하십니까? 알았어 괜찮아. 6 주 후, 적절한 테스트를 실시한 경우 즉시 발견 될 수있는 응용 프로그램과 충돌하는 버그를 찾을 수있는 인력이 있습니까?

테스트가 너무 많으면 개발 속도가 느려질 수 있습니다. 테스트가 너무 적 으면 속도가 느려질 수 있습니다. 당신은 올바른 균형을 찾아야하며, 보통 그것이 어디에 있는지 말하기가 어렵습니다. 그리고이 중 어느 것도 대기업이나 소기업에 국한되지 않습니다.

— 마이크 바란 차크
소스

4

수년 동안 소기업과 신생 기업에서 일하는 동안 "코드에 대한 단위 테스트를 작성할 시간이 충분하지 않았다"는 오해가 있었습니다.

테스트를했을 때, 그들은 부풀어 오르고 무거운 것들이 필요하다는 것을 알았을 때 단위 테스트를 작성해야한다고 생각하게 만들었 습니다 .

최근에 내가 사용하는 것이 좋습니다 봤는데 테스트 기반 개발을 하고 나는 그것이 것으로 밝혀 완전한 계시 .

지금하고있어 단단히 내가 확신 "에 시간이없는 없는 쓰기 단위 테스트" .

내 경험상 테스트를 염두에두고 개발하면 더 깨끗한 인터페이스, 더 집중된 클래스 및 모듈 및 일반적으로 더 많은 테스트 가능한 SOLID 코드가 생깁니다.

단위 테스트가없는 레거시 코드로 작업하고 수동으로 무언가를 테스트해야 할 때마다 "이 코드에 이미 단위 테스트가 있으면 훨씬 빠를 것"이라고 생각 합니다. 높은 커플 링으로 코드에 단위 테스트 기능을 추가하려고 할 때마다 "이것이 분리 된 방식으로 작성된 경우 훨씬 쉬울 것"이라고 생각 합니다.

지난 몇 년 동안 내가 발견 한 것이 있다면, 신생 기업에서 일하는 경우 소프트웨어 개발 방법 론적 의미가 아니라 민첩 해야합니다 . 나에게 TDD는 민첩 하게 시작하고 유지할 수있는 중요한 도구입니다 .

— 마크 부스
소스

1

누가 소프트웨어 테스팅을해야하는지가 아니라 소프트웨어 테스팅은 일종의 소프트웨어 개발 철학이다. 소프트웨어 테스팅은 좋은 소프트웨어 품질의 기초를 설정했으며, 스타트 업에서는 대기업의 인수가 모퉁이에있을 때 소프트웨어 품질이 보너스입니다.)

— 프란시스코 발데즈
소스

1

모범 사례는 할머니를 웹 사이트로 만들거나 위성에 대한 안내 시스템을 만들 때 산업 전반에 적용됩니다. 그들은 항상 자신을 전문적으로 생각하고 싶은 사람들이 따라야합니다. 그래서 그들은 최선의 방법이라고 불립니다.

— 리탈
소스

모범 사례가 모든 산업 분야에 해당되는 것은 아니라는 사실에 놀랄 수도 있습니다. thedailywtf.com

— Gary Willoughby

@ 이론은 업계 전반에 걸쳐 더 많은 이론을 제시하거나 프로젝트가 현실적인 타임 라인을 가지고 HTML이 의미 론적 의미를 갖고 관리자가 더 나은 의사 결정을 내리는 데 도움이 될 기술적 지식이 없음을 인정하는 유토피아 세계의 일부를 제공합니다.

— Ryathal

"모범 사례"는 일반적으로 다른 모든 사람들이하는 것처럼 평균 결과를 산출하는 것을 의미합니다. 평균적으로 설립 된 회사는 합리적으로 잘 수행하지만, 평균적인 기술 스타트 업은 놀라 울 정도로 크지 않습니다.

— David Thornley

1

@DavidThornley-아니요, "최상의 실습"은 시간, 에너지 또는 경영 승인을 받았는지 여부에 관계없이 대부분의 사람들이 해야 할 일 이라고 생각 합니다. * 8 ')

— Mark Booth

@Mark Booth : 일반적으로 문구를 들었을 때 내가 말한 것을 의미합니다. 물론 YMMV. 그러나 Ryathal은 프로젝트가 현실적인 타임 라인을 가지고 있으며 비즈니스에서 반드시 가능하지는 않은 세계를 말합니다. 두 달 늦게 제품을 출시하면 결과가 중요하지 않거나 치명적일 수 있으며 (특히 돈이 부족할 수있는 스타트 업에) 성가신 경우가 많지만 최대한 빨리 문을 여는 무언가를 얻는 강력한 비즈니스 사례가 있습니다. 회사를 망칠 수있는 "모범 사례"를 믿기가 어렵다는 것을 알게되었습니다.

— David Thornley

1

그렇습니다. 신생 기업은 때때로 코너를 자르고 적절한 테스트를 암시하지 않습니다. 때때로 이것은 적절하다 (작은 프로젝트 나 시간 / 돈이 중요한 경우)

이것은 신생 기업에만 국한되지 않습니다. 공급 업체 IT 계약자 중 하나는 테스트 환경도 갖추고 있습니다. 모든 것이 곧바로 이루어지고 이것은 대규모 다국적 소프트웨어 회사입니다 (무서워요!).

— 톰 스콰 이어스
소스

1

그들은해야합니까? 예. 실제로는 그렇게 자주하지 말고 실제로 그렇게하십시오.

가장 일반적인 이유는 개발자 시간, 전담 또는 파트 타임 테스터 고용 비용, 테스트 환경 설정 비용 등을 포함한 자원이 부족하기 때문입니다. 소규모 기업뿐만 아니라 대기업 환경에서도 이러한 변명을 찾을 수 있습니다.

다른 방식으로 살펴보면 테스트는 개발 일정에서 가장 쉬운 방법 중 하나입니다. 특히 눈에 띄는 결과를 내기 위해 시간 압력 및 / 또는 비용 압력이 매우 엄격한 테스트입니다. 자세한 설계 작업과 함께, 많은 관리자들에 의해 '솜털'로 간주되며 가장 먼저 "스케줄과 예산 작업을 할 수 있도록 잘라 내고 왜 코딩을하지 않습니까?"라고 말합니다.

일부 회사에는 푸시 테스트를 수행하는 사람이 있습니다. 일반적으로 이것은 고용 된 개발자가 될 것이며 대개 경험이있는 사람 일 수도 있고 회사에서 어떤 종류의 재정적 이해 관계가있는 사람 일 수도 있습니다. 이 "DNA"로 시작하는 회사는 처음부터 테스트를 수행 할 것입니다.

— jfrankcarr
소스