개발과 QA에 관한 간단한 토론?

영화 300을 패러디해서 개발자의 고뇌를 다룬 영상입니다. 즐감하세요..ㅎㅎ 1편 2편 3편 4편 5편 6편 7편

그리고... 다음의 리플들을 꼭 읽어보세요.

위의 내용은 이렇게 하면 안된다는 내용입니다.

리플이 매우 소중한 내용입니다.

쿨러~  [11/29 12:39]  ::  자... 작풀.

:::..BIT光..:::  [11/29 12:44]  ::  풉.... 주말에 근무하러 나와서는.... 정신없이 보고있네요....ㅎㅎ

나비효과  [11/29 12:50]  ::  이건 영화 한편을 다 올렸네요 -0-;;

Yoopeang  [11/29 12:53]  ::  ㅋㅋ 재미있네요  영화 300 또 보고 싶어졌네요.

이봉석  [11/29 12:53]  ::  1편을 보고 있자니  몬헌프론티어의 키린 언덕하메가 생각나네요..

모리모리  [11/29 12:54]  ::  오 잼있네요.  못알아 듣는 용어가.... 공부 열심히 하라는 이야기인가...ㅡ_ㅡ;;

[11/29 12:57]  ::  푸하하하 재밌네요 ... :D

키라라  [11/29 13:10]  ::  개발자이신 클리앙 분께서 용어 설명을 해주시리라 ....  QA, Grand Refactoring, Side Effect , WaterFall 등등...

kakiii  [11/29 13:18]  ::  테스트는 QA가 한다.  농담으로 그런건지 모르겠지만 제작자가 정석으로 알고있다면 큰 문제네요.  QA 프로세스에 테스트라는 항목은 있지만 주업무가 테스트는 아닙니다.  테스트팀 이라고 바꾸시는게 낫겠네요.

Felix  [11/29 13:42]  ::  저게 잘못된거라고 패러디를 하신것 같은데요. ㅎㅎ  QA는 품질 보증(Quality assurance) 업무입니다. 그러나 영상에서 얘기하는건 QC(품질 관리, Qiality Control)를 얘기하는것 같네요.  뭐 우리나라같이 열악한 곳에서야 QA고 QC고 구분 지어봤자 비웃음당하기 좋기만 합니다만...

Escape  [11/29 13:43]  ::  저도 잘은 모르지만, WaterFall은 아이디얼한 개발방법론의 하나이고, Side Effect는 버그 하나 고치다가 실수로 다른 버그를 만들 때 쓰는 용어입니다. 7편은 영원히 오지 않을 거 같은 현실!

[11/29 13:46]  ::  허걱... 학교에서 대기업쯤 되면 SQA 부서가 따로 있어서  그쪽에서 테스트 가이드라인 잡아주는 거랑 테스트를 해주는 게 주 업무라고  배우는데 현실은 아닌가봐요?

꾸엑  [11/29 13:56]  ::  '이 버그는 재현도 쉽지 않다' 는 말이 가슴에 와 닫네요..  최근에 고객으로부터 받은 bug report "20시간 이상 MP3 play 하면 시스템이 죽어요"  재현이 쉽지 않는 버그가 짱이죠.~

Felix  [11/29 14:04]  ::  WATERFALL은 개발 시작함 도중 테스트 없이 쭈욱 가는거다!! 하는 개발론입니다. 개발 완료 후에 테스트를 합니다만 최종결과물에 버그가 터질 경우 크리 맞을 확률이 크죠.  그렇다고 나쁘기만 한건 아닙니다. 어쨌든 개발일정과 비용은 절약되거든요.

스나엘  [11/29 14:06]  ::  사실 버그가 QA에서 되돌아오는 건 부끄러운 일이죠.  테스트팀은 개발팀에 포함되어야지 QA에 테스트를 넘기면 안되죠.  국내 많은 소프트웨어 업체들이 QA팀을 구성하지만  단순 뒷치닥거리를 하는 정도로 알고 무시하는 경우가 좀 있죠.  하지만 제품의 마지막 마무리를 판단하는 QA를  난 창조적인 일 하는 거고 너네는 그냥 뒷치닥거리나 하는 거라고  무시하는 개발자는 퇴출되어야 할 것 같습니다.

[11/29 14:07]  ::  푸하하.. 근데 결국 다 말아먹고 재개발 하는군요.. ㅡㅡ;; 글고.. 개발자는 BT도 안하나..

JY in Ottawa  [11/29 14:33]  ::  캐나다에서 개발자로 일하고 있습니다.  테스트는 QA 팀이 합니다.  개발과 QA는 완전히 분리되서 돌아갑니다.  QA 팀은 인정사정 안보고 이상한 건 다 버그로 등록합니다.  버그는 부끄러운 것이 아닙니다. 버그를 숨기는 것이 부끄런 것이죠.

Huni  [11/29 15:42]  ::  뭐 프로세스에 따라 다르겠죠 ^^;  물론 개발자도 개발자 테스트를 게을리 해선 안되겠죠?  버그를 부끄러워 할 필요는 없을 것 같구요. 인간이니까 실수도 할 수 있죠.  하지만 개발자 테스트까지라도 철저하게 해서 돌려준다면 테스트팀도 수월하게 업무를 진행하겠죠~

슬램상  [11/29 19:24]  ::  지금까지 서로 다른 3사에서 QA팀 혹은 테스트팀이라 불리는 곳에서 일해오고 있습니다. 개발자로 시작한게 아니라 테스팅으로 경력을 쌓아온 셈이죠. 우리나라 경우 QA팀과 테스트팀이 딱히 구분되지 않는 것 같습니다. 팀 안에서 두 가지 일을 같이 하는 경우가 대부분인것 같습니다. 그리고 테스트 인력도 충분히 고급화 될 수 있다에 가능성을 가지고 일해가고 있습니다. 물론 때때로 뒤치닷거리(똥치우는 일) 하는 것 처럼 느낄 때도 있지만, 그건 개발자도 삽질하는 거보면 어떤 일을 하던 어려움은 있는것 같고, 각자가 맡은 일을 잘 해나갈때 품질은 좋아지는 거라 생각합니다. 품질은 테스트팀이 높이는게 아니라 개발팀과 테스팀이 함께 만들어가는거죠 ^^

saxboy  [11/29 20:27]  ::  개발조직에서의 테스트와 QA, QC + 입고검사까지 모두 다른 일을 하는 팀입니다. 대부분 개발 일을 하시는 분들은 개발자 우월주의에 심각하게 빠져 있는 경우가 많은데 제품의 시작에서 끝까지 개발이 차지하는 비중은 20% 정도밖에 되지 않지요. 특히 소프트웨어 개발 쪽은 이런 경향이 심한 편이고요.  현실은 어쩄든 다릅니다만 개발팀에서 테스트를 하지 않는 것이 맞다고 자신있게 저런 패러디를 만든 분은 아직 몇 년 더 일을 하시면서 배우셔야겠네요.