[1/1000] 글쓰기가 무섭다.

글쓰기가 무섭다.

글쓰기 공포를 이겨 내기 위해 1000의 글을 쓰자.

아마 도중에 끝낼 수도 있지만 그 때는 지금 보다 좋은 글을 쓰고 있겠지?

개발자의 테스트

테스트는 전수 또는 일부만을 한다.

전수는 모든 기능을 한다. 각 기능에 대한 발생 가능한 경우의 수를 나열하고 확인 한다.

일부 테스트는 그 중 일부분만을 한다.

점수 또는 일부

전수는 시간이 너무 소모 되고 그래서 일부만 하게 되다.

일부만 테스틑 한다면 테스트를 정해진 시간에 우선순위에 따라 해야 한다.

• 사용자가 자주 사용하는 기능,
• 새롭게 추가된 기능.
• 추가된 기능과 연관이 있는 기능들.
• 개발자가 놓치는 자주 발생하는 버그들.

테스트는 책임이다.

• 개발자는 소스코드 수정에 대한 권한이 있다.
• 권한에 따른 일차 책임을 가지고 있다.

개발자 테스트의 맹점

• 자주보게되는 기능을 지나치로 확인하지 않게 된다.

하지만 그래도 개발자 테스트

• 장점으로는 기능에 대한 상세히 알고 있기 때문에 어떠한 경우에 문제가 발생 할 수 타게팅 테스트를 할 수 있다.

기계적인 테스트

그래서 어느 정도 기계적인 테스트가 필요 한다.
- 테스트할 대상 목록과 절차가 필요.
- 자동화가 가능한 것은 해놓는다.
- 자동화 할 수 없는 것은 사람이 감정을 배재하고 정해진 절차에 따라서 확인한다.

품질자동화팀의 피드백을 믿고만 있을 수 없다.

우리는 개발자다.
분명 제3자가 우리의 자식을 어디가 아픈지 진찰해 줄 수 있다.
전문적으로 건강상태를 점검해 줄 수 있다.

하.지.만 나태해지는 제품에 대한 열정을 유지해야 한다.

팀장에게 뻥을 치자.

시간을 벌어서 테스트를 해야 한다.