부품화 및 테스트

1. 테스트를 통해 품질 확인
테스트, 테스트를 하지 않으면 품질이 높은지, 완성되었는지 판단할 수 없다.
　　　　
개발이 진행되었을 때 테스트가 끝난 후에야 비로소 완성된 셈이다.
오류가 없는 프로그램이라도 테스트를 통해 검증되지 않으면
완성이라고는 할 수 없다.
이 공사는 한 번 보면 누구나 완성할 수 있다고 여겨지기 쉽다
이것은 최종 사용자에게 납품할 때의 마지막 보루의 중요한 공사이다.
이래도 되나'라는 생각에서 재시험으로 바뀐 사례도 종종 듣는다.
2. 잘못을 묻는다
혼자서 개발한 작은 프로그램이라면 시험은 매우 간단하다.
지령 등으로 몇 번 이동해 보면 문제가 없는지 알겠지.
한편, 개발 현장 등 수십~수백 개의 등급으로 구성된 대형 프로그램이라면
시험이 너무 어려워졌어요.
시행해 보세요 오류가 발생하면 거대한 프로그램에 뭐가 문제인지 확인하세요
판단하기 어려워서요.
예를 들면, 광활한 사막에서 오아시스를 찾는 것과 같다.
프로그램이 클수록 오류를 발견하기 어렵다.

3. 부품화
2에서 보듯이 큰 프로그램을 한 번 테스트하면 어렵다.
한 번의 테스트가 여러 학급으로 구성된 절차는 어렵다는 것이다.
단숨에 시험을 보면 상당히 많은 일이 있어도 거의 없겠죠.
실제 개발 현장은 아래 그림과 같다.
'단일 테스트','결합 테스트','종합 테스트'의 단계를 거쳐 천천히 테스트를 진행한다.

4. 팀 개발 ※ 필자의 노트 같은 것이기 때문에 관심이 없으니 아는 사람은 건너가세요.
위에서 설명한 바와 같이 큰 프로그램 개발일수록 많은 개발자가 필요하다.
의사소통 능력이 있느냐는 질문을 자주 받는다. 왜 그런지 생각해 보자.
A씨는 기술력이 뛰어나지만 의사소통이 어렵고 진전과 고장 보고가 애매하다.
그리고 가끔 회사에 안 와요.
한편, 미스터 B는 사업 개발 경험이 얕아 공부하고 있다는 느낌을 준다.
그러나 보고 연락 상담은 부족하지 않은 사람이고 의사소통이 쉬운 사람이다.
결석률도 낮다.
그럼 여기 엔지니어가 더 쉬워요?
기술력만 따지면 A가 더 필요한 것 같아요.
하지만 대부분의 개발 현장에는 미스터 B 같은 개발자가 필요하다.
왜 기술력에서 뒤떨어졌는데도 미스터 B라는 생각이 들지도 모른다.
팀 개발이라는 이유에서다.취미에 따라 프로그램을 만드는 것이 아니라 팀워크입니다.
큰 프로그램을 만들어야 하니까.
부품화 작업도 있지만 개인게임은 아무리 기술이 좋아도.
이상은 어때요?
또 잘못된 지식 등이 있으면 지적해 주세요.