본문 바로가기

방법론3

반성이 없다... 그렇다면 개선도 없다. 지난 15년간 테스터 내지는 QA 엔지니어, PMO, PM 등의 역할을 수행하면서 참 많은 것을 느꼈다. 하지만, 사람은 망각의 동물이기에... 동일한 실수와 동일한 상황에서 똑같은 오류를 만들어낸다.다양한 조직을 다녀보았다. SI, 보안, 모바일, 게임, 패키지, 시스템, 솔루션 개발사들... 도메인도 마찬가지다. 광고, 영상, 임베디드, 웹 프로젝트들도 그랬고... 다양한 조직형태도 있었다. 기획팀 밑에, QA 분사조직, 대표 직속, 연구소 소속, 개발팀 소속, 외주, 파견 등등. 그 조직 중에 QA에 대한 인식이 높은 곳은 한두곳 뿐이다. 그러면서 나에게는 노하우가 쌓였다. 나름 어디가서 한마디도 지지 않을 자신감 같은 것도 생겼지만... 구한말, 갑오경장, 갑오개혁을 겪어보지 못한 사람들에게 품질.. 2019. 1. 2.
QA관점의 Conflict & Complete QA는 소프트웨어 개발의 전반적인 사항을 알고 있어야 한다. 심지어는 어떤 인력이 어떤 일이 있고, 그로 인해 끼칠 영향은 어떤 것이 있고!! 사실 PMO가 해야할 부분이기도 하지만, QA의 관점은 남다를 수 밖에 없다. Ture와 False의 귀납적/연역적 논리를 모두 병행 해보아도. QA는 모든 것을 직시해야 하는 조직이다. 자주가는 블로그에 Conflict에 대한 이야기가 올라왔다. 사전적 의미를 살펴보면, 아래와 같다. 1. (사람이나 국가들 사이의 이해관계로 인한) 갈등[충돌] 2. (국가 간의) 물리적 충돌 3. (심리적 또는 의견들 간의) 갈등 얼핏 보면 Complete와 동일한 발음이라 헷갈릴 수 있겠지만... 그 뜻은 incomplete와 비슷하다고 생각된다. 뭔가 완성되지 않아 불안정한.. 2011. 4. 22.
개발자와 QA는 친구가 될 수 없는걸까? 필자의 블로그에와서 이런 저런 글을 본 사람이라면!! 내지는 이블로그 윗단에 써 있는 내용을 본다면... 이사람이 무슨일을 하는 사람인지 알 수 있을 것이다. 서로 앙숙관계에 놓일 수 밖에 없는 개발자(DEV)와 QA! 스펙을 보면서 새로운 것을 만들어야 하는 개발자! 개발된 산출물과 스펙을 보면서 구현정도를 판단하는 QA! 최근에 이런 트러블이 났었다. 기획서라는 것이 워낙 자주 변경되다보니... Freezing을 외친 6개월 동안! 아무런 것도 바뀌지 않았다. 이미 심신은 지쳐 이 생활에 안주한다는 생각이 들 때쯤!!! QA를 진행하던 나는 말없이 얼굴을 붉히게 되었다~ 기획자와 이야기 하던 사항 중에 기획자 : 이거 스펙인데요... 1번은 개발 모듈상에 그럴수 밖에 없는 사항이구요. 2번은 이번에 .. 2010. 12. 17.