본문 바로가기

전체 글596

서울특별시의회 전자회의시스템 프로젝트 프로그램 개발자 폭행사건 - 내 소견 (을이고, 빽없고, 돈없고, 권력 없으면 많은 사람들 앞에서 두들겨 맞아도 할말이 없다?) 사람들이 싸우는 일은 아주 당연스러운 일일수도 있다. 하지만, 그 사람의 직책과 업무에 따라 그에 따른 가중이 주어지는 법이다. 서울 특별시의회의 특정 사람이 사람을 구타하고, 그에 따른 미온적 대처는 참으로 어처구니가 없다고 생각한다. 시연을 하기 위해 어느정도 완성도가 있는 부분을 테스트 없이 변경해달라고 요청한 사람이나, 테스트 시간이 없음에도 계속적으로 그렇게 밖에 할 수 없었던 사람들에 대한 일적인 촉박함은 이해가 된다. 하지만, 최소한 테스트를 할 시간은 필요했던건 누가 봐도 당연한 일이 될 것이다. 대한 민국 IT인프라 최강인 우리 나라... IT선진국... 이런 말이 무슨 필요가 있단 말인가? 사람들.. 2008. 10. 30.
Test Project 준비에 따른 소견 (무릎팍 도사의 손예진!!! 메롱!) 딱 이런 느낌이다. 프로젝트를 정말 하고 싶을 때가 있지만… 그것이 항상은 아니다. 프로젝트는 나의 커리어에 도움을 주겠지만… 나의 정신 건강에는 도움이 안된 때가 더 많다. 무언지 모르겠지만… 하고 싶어서 열심히 할 때, 하기 싫지만 꼬박꼬박 월급을 받기 위해 할 때… 아주 우스운 이야기지만… 나도 사람인지라… 느슨해질 때가 있다. 프로젝트를 준비하게 됨에 있어 나는 여러 가지를 고려한다. 일단 프로젝트 볼륨! 프로젝트 볼륨을 산정해보고는… 한숨을 쉴 때도 있고, 오히려 후딱 해치우자 라는 생각으로 매진하는 경우가 있다. (대부분 후자의 경우이다.) 그리고 나의 컨디션… 컨디션이 좋고 나쁨에 따라 일에 대한 속도나 output은 양질로 흘러갈 수 있다고 믿는다. 요.. 2008. 10. 29.
QA? Q&A? (모습이 너무나 닮았다. 하지만 다르다...약간은 낮 부끄러운 사진이기도 하다~^^;;) 채용 사이트에서 QA를 검색해보면... QA와 Q&A로 구분되어 여러가지 업종을 살펴볼 수 있다. QA는 Quality Assurance다. Q&A는 Question & Answer다. 공통점도 있고, 다른점도 있다. 그리고 업무를 병행하는 곳도 있다. CS는 항상 고객에 전면 배치되어 있는... B2P나 C2P의 말단에 존재하는 아주 극단의 고객 지원 업무를 말한다. 시대가 발달함에 따라 이 업무 또한 장족의 발전을 요하는 아주 중요한 산업이라고 말할 수 있겠다. QA는 제품 개발의 말단에 배치되어 있는 그룹이다. 당연히 초반부터 투입되어야 Risk를 줄일 수 있는 것이겠지만... 업태의 형태나 인식이 떨어지는 그.. 2008. 10. 28.
About TestProcess Without KnowledgeBase (내가 개인 적으로 좋아하는 사진이다. 테스터의 입장을 적랄하게 표혀한 사진이다.) 오늘의 테스트 관련된 이야기는 바로 Process이다. Process는 모든 Management나 Output의 중심에 있기 마련이다. 더구나 QA와 같이 산출물이 제품과 같은 형태로 만들어 지는 것이 아니기 떄문에... 더욱 민감한 항목이라고 할 수 있겠다. 허나... 잘 만들어진 Test Process에서도 안에서 말도 안되는 현상이 발생하고, 또, 아주 높은 음역대 앞에 놓인 파카글라스 유리처럼... 후덜덜 떨리며 결국 깨지긴 한다. 지속적인 관리가 필요하다는 이야기가 되겠다. 프로세스를 관리하는 부분에 있어 지식이 필요하다. 사유로는 여러가지가 있을 수 있겠다. 첫번째로, 항상 근거를 준비해두어야 한다. 앞에서 이.. 2008. 10. 27.
Test Manager로 산다는 일 필자는 테스트 엔지니어로 3년 반을 살았고, 이제 테스트 매니져로 1년을 살았다. 나는 테스트가 좋다. 제품의 결함을 의도한 곳에서 찾아 내는 것이 좋다. 어떤 PM은 이런 이야기를 했었다. "테스트 엔지니어 경력 10년차 넘은 분중에 제품에 손을 올려놓고 눈을 감으면, 제품의 대략의 Tracking될 만한 버그의 수치가 보인다"고... - 나는 아직 그정도는 아니지만... 어떠한 제품이라도 많은 버그를 찾을 수 있는 자신 감이 있다. 그러나 테스트 매니져는 조금 다르다. 테스트 매니져는 테스트 엔지니어가 버그를 찾듯이 Process, Product, Progress에 따른 Risk를 찾아야 하는 것이다. 3P - R = high Quality (개인의 이론이니~ 어디 다른 곳에 가서 이야기 하면, 콧방.. 2008. 10. 24.
[테스트 뒷담화]STB 테스트 경험담 (본 이미지는 본인이 테스트 한 제품이 아니니 오해 마시기 바랍니다.) 예전에 이런 적이 있었다. STB 테스트를 위해 파견을 간 적이 있었다. 대기업이라서 그런지 보안도 철저하고 나름의 시스템은 어쩌면 나를 주눅들게 만들 정도 였다. 그 안에서 나는 STB를 테스트 하기로 했다. STB가 다수 준비되지 않아, 저녁 6시부터 다음날 6시까지 근무해야 했다. 모두가 없고 테스트를 위해 남아 있는 나~ 어쩌면 조금은 무서웠을 지도 모른다. (실은 적적함과 더위와 싸워야 했다.) 결론은 중소기업의 개발자와 대기업의 개발자는 같은 개발자였다. 보통 중소기업의 개발자들과 많은 커뮤니케이션을 해본 나는 대기업 개발자의 엄청난 뱃보를 기대했지만... 같은 버그, 같은 문제, 같은 실수를 범하고 있었던 것이다. 더 심.. 2008. 10. 23.
세상에서 가장 큰 요인... 사람! 세상에서 가장 큰 요인은 바로 사람이다. 사람이 만드는 피조물들에는 항상 문제가 있기 마련이다. 다만 조금 더 신경쓰고 그것에 대한 오류를 줄여나가는 선행 작업을 하기 때문이다. 어떤 프로젝트에서는 이런 일이 있었다. PM, QM, DEV, 외 각 담당자들(2명)으로 총 5명끼리 회의를 하였다. 첨부한 사진 처럼... 회의를 하던 도중에 조는 사람도 있었고, 혼자서 열내던 나같은 사람도 있었고, 멍때리던 사람도 있었고, 심지어는 고개를 돌려버리는 사람도 있었다. 그런데 참 신기하게도!!! 회의가 끝날 시점에는 집중도가 높아진다. 그래서 회의는 처음부터 다시!~ 말도 안되는 관심사를 이야기 하고 있는 것이다. 그 회의는 회의록을 기재하는 사람만 힘들었지... 정작 남는 것은 없는 것이였다. 그리고 몇일 뒤.. 2008. 10. 22.
goodsharp.tistory.com 블로그를 열면서... 내가 얼마나 이쁘고 좋은 글을 쓸지는 모르겠다. 사는데 있어 글은 내 생각의 한통로일 뿐이다. 손짓과 발짓을 다해도 모자랄 나의 행동과 표정 하나 하나의 의미를 최대한 담아 보련다. 사는 것 만큼 큰 용기가 없다고 생각하는 사람중에 1인이다. 어쩌다 어쩌다 보면... 내가 살아가는 이유가 블로그나 내 표현 하나에 걸린 것일 수도 있겠다라는 생각이 든다. 난 단지 그뿐이다.^^ 2008. 10. 22.