본문 바로가기

전체 글

넋두리와 변명 새벽 2시입니다. 원래는 이 포스팅 대신 지금 제가 처한 상황에 대한 기나긴 넋두리를 썼었습니다. 한 시간이 넘도록 지금 제가 처한 답답한 상황을 풀어가며 정말 기나긴 넋두리를 썼습니다. 쓰고 나니 마음이 조금 편안해 지기는 했습니다. 하지만 글을 블로그에 올리려고 하다가 문득 스스로에게 물어봤습니다. 누군가가 나를 동정해주길 바라는 건가? 누군가가 대신 나서서 해결해 주기를 바라는 건가? 누군가가 손을 내밀어 그 손을 잡으면 모든 것이 해결되기를 바라는 건가? 아닙니다. 그런다고 달라질 것은 없습니다. 누군가가 나서서 해결해 준다고 해도, 제 스스로가 스스로 처한 상황을 개선한 게 아니죠. 그럼 결국 저는 달라지지 않겠군요. 아마 다음 번에도 또 누군가가 손 내밀어주길 바라겠죠. 그 시간에 그냥 더 치.. 더보기
잘못된 애자일의 다섯 가지 증상 『Methods & Tools』의 2010년 봄호에 실린 Daryl Kulak의 “Five Symptoms of Mechanical Agile”을 여기 소개한다. 계간으로 발행되는 무료 온라인 잡지인 『Methods & Tools』는 각각의 제호에 실린 기사의 제목을 별도로 정리해 놓고 있는데, 이 제목들만 보아도 소프트웨어 산업의 트랜드를 파악하는 데 큰 도움이 된다. “Five Symptoms of Mechanical Agile”은 이미 트랜드라고 부르기엔 너무 일반화되고 유명해진 애자일 방식에 대해, 우리가 애자일이라고 믿으면서 쉽게 오류에 빠질 수 있는 상황들을 우화의 형식을 빌어서 재미있게 표현하고 있다. 애자일을 수행하지 않는 회사라고 하더라도 고착되고 기계적으로 수행되는 프로세스 상에서 우리.. 더보기
효율적인 테스트 케이스 작성법 - 직관적으로 질문하라 책을 보다 보면, 가끔씩 너무나 자주 사용하면서도 너무나 쉽게 지나치고 있는 원리를 가르쳐 줄 때가 있다. 가능하다면 테스트 케이스에서 작성된 질문들은 “Yes”가 “Pass” 조건 – 소프트웨어가 설계한대로 동작하며 결함이 발견되지 않는 상태 - 을 가리키도록 작성되어야 한다. 어떠한 테스트 케이스에 “No”라고 대답한다는 것은 해당 테스트 케이스를 실행할 경우 문제가 발생한다는 이야기이며, 이러한 결함은 반드시 보고되어야 한다. 여기에는 여러가지 이유가 있지만 가장 직관적인 이유는, 일반적으로 우리는 심적으로 “Yes”와 “Pass”를 동일시하고(둘 다 긍정적인 의미이므로), 같은 방식으로 “No”와 “Fail”을 동일시 하기 때문이다. 또한, 동일한 컬럼 안에서 패스 처리된 모든 항목들을 한 군데에.. 더보기
누가 소프트웨어 품질을 책임질 것인가? 해외 현업 소프트웨어 테스터들의 생생한 경험과 지식을 담아내고 있는 “Software Testing Help(http://bit.ly/9yDnPN)”에서 흥미로운 아티클을 발견해 여기 소개한다. 테스팅을 하다 보면 누구나 한 번쯤 생각하게 되는 주제를 적절한 비유와 이해하기 쉬운 논조를 사용해 자칫 심각해 지기 쉬운 주제를 재미있게 풀어쓴 것 같다. 저자인 Pradeep Soundararajan 의 개인 블로그(http://testertested.blogspot.com)에도 흥미로운 아티클들이 많으므로 한 번 방문해 보시기를 권한다. 번역 및 포스팅에 대해서는 원 저자의 승인을 받았다. 해당 글의 저작권은 원 저자인 Pradeep Soundararajan에게 있다. 늘 부족한 제 번역에 전문 번역가로서의.. 더보기
생활 속의 QA - Early Testing 아무래도 직업이 직업인지라, 요즘 가끔은 일상적인 생활 속에도 QA가 적용될 수 있겠다라는 생각이 듭니다. Life QA, 말 그대로 삶의 질을 보증해 주는 것이죠. 일견 장황하게 들릴 수도 있겠지만 소소한 일상 속에서 QA 마인드를 가진다면 조금은 삶이 더 편안해지고 만족스러워질 것 같습니다. 일례를 들어볼까요. 지난 토요일, 집사람과 함께 집에서 가까운 뚝섬의 서울숲을 다녀왔습니다. 중랑천을 지나 한강변을 끼고 걷다 보니 봄내음이 물씬 납니다. 성수대교 근처에서 서울숲으로 진입하는 다리 입구에서는 고라니도 뛰어 놉니다. 남들처럼 멋진 DSLR을 가지고 출사를 나간 건 아니지만, 그래도 간만에 나온 나들이인지라 사진으로 추억을 남기고 싶었습니다. 어린애 마냥 이것 저것 신기해하고 감탄해 마지 않으면서 .. 더보기
출사표(出社表) 2년 반 동안 몸 담았던 회사를 떠나게 되었습니다. 운 좋게도 좋은 사람들을 만나고 좋은 시간을 보내었던 곳을 이제 떠나게 되었습니다. 사실 늘 즐거운 시간들만 가득했던 건 아닙니다. 누구에게나 주어지는 시련이 저에게도, 그리고 우리에게도 있었습니다. 몇 달을 고생하며 테스트한 게임이 결국엔 제대로 빛도 보지 못하고 사라질 땐 마치 오랜 친구를 떠나 보내며 가슴에 묻는 것처럼 아쉬웠습니다. 때로는 서로의 등만을 의지하며 무력하게 힘든 시간을 보내야 할 때도 있었습니다. 그로 인해 떠나는 사람에게 미안했고 새로 만나는 사람에게 부끄러웠습니다. 하지만 그런 시련 덕분에 좋은 사람들이 주위에 있다는 것을 알게 되었고 그 좋은 사람들 덕분에 주어진 시련을 함께 견뎌나갈 수 있었고 그 시련을 이겨낸 덕분에 지금 .. 더보기
Cloud QA Testing Experience 9호 에서 발췌해서 번역한 글. 웹 QA와 관련된 글이기는 하나, 게임 및 기타 도메인에서도 사용자 환경을 어떻게 에뮬레이팅 해서 테스팅을 진행할 지에 대한 조언이 담겨있다. 구체적인 툴과 서비스 명을 명시해서 제시하기는 했지만, 방대한 사용자 환경을 어떻게 담보할 것인지, 그리고 테스트 자동화를 어떻게 구현할지에 대한 고민을 조금이나마 덜어줄 수 있으리라 기대해 본다. 필자가 몸담고 있는 곳에서도 가상 이미지 제작 툴인 고스트(Ghost)를 사용해 사용자가 많이 사용하는 OS와 애플리케이션들을 가상 환경으로 꾸미고 테스트하고 있다. 원 저자가 제안한 툴들이 아니더라도, 다양한 툴이 존재하는 만큼 자신이 처한 환경에서 가장 적합한 툴을 선택할 수 있는 가이드가 되길 바란.. 더보기
실용적인 심각도 선정 가이드 최근 필자가 재직하고 있는 품질관리 팀 내에서 심각도(Severity)에 대한 기준을 다시 정리하는 작업을 진행했다. 국내에서 테스트 엔지니어들이 그들의 현업에서 바로 적용할 수 있을 정도의 심각도에 관한 기준이 세세하게 기록된 문서를 가지고 있는 회사가 과연 얼마나 많을지 의문이다. 아무리 테스트 업무를 오랫동안 진행한 부서라고 하더라도 결함의 심각도를 판단하는 유일한 기준이 오직 개별 테스트 엔지니어의 경험과 주관뿐인 경우가 허다한 것이 현실이다. 상황이 이러하다 보니 당연히 심각도 선정에 대한 객관성이 보장되지 않았고, 이로 인해 개발자와 테스트 엔지니어 사이에 결함의 심각도에 대한 의견 차이가 빈번하게 발생했을 뿐만 아니라, 테스트 팀 내에서도 동일한 결함에 대해 서로 다른 의견이 제시되고는 했다.. 더보기