본문 바로가기

전체 글

테스터들에게 프로그래밍 스킬이 필요한가? 최근 들어 국내에서도 소프트웨어 테스터들에게 프로그래밍 소양을 요구하는 경우가 늘어나고 있다. 일부 회사에서는 개발 경력이 있는 테스터들을 우선해서 채용하기도 하는 모양이다. 개인적으로 테스터들에게 프로그래밍 능력이 필수는 아니지만, 최소한 코드를 읽고 해당 코드가 무슨 기능을 하는 것인지를 파악하고, 간단한 자동화 스크립트 정도는 작성할 줄 알아야 한다고 생각한다. 내가 그 수준이라는 이야기는 아니다. 나도 그 정도 수준이 되기위해 노력하고 있는 테스터 중의 한 사람일 뿐이다. 테스터들에게 프로그래밍 능력이 필요한가라는 문제에 대해, 팀 블로그에 같이 참여하고 있는 의한님(@OEHAN)이 소개해준 블로그 포스트 "Do testers need programming skills?"를 번역해서 올린다. 원 .. 더보기
NHN DeView 2010 참관기 9월 8일 수요일 삼성동 코엑스 인터컨티넨탈 에서 열린 “NHN DeView 2010” 행사에 다녀왔습니다. 몇 년 전부터 NHN이 동일한 행사를 마련했었는데 저는 이런 행사가 있다는 걸 올해에야 알게 되었네요. 일단 사전 등록 한 게 한 달 전쯤으로 기억되는데 그 동안 잊고 있다가 행사 전날 리마인드 메일이 와서 급하게 교육훈련 참가 결재를 올리고 참가했습니다. 10시 30분 부터 입장이라고 행사 관련 웹 페이지에 적혀 있길래 그래도 조금 일찍 10시쯤 코엑스에 도착했습니다. 보통 세미나에서 일찍 오는 참가자들을 위해 Early Bird Pack을 제공하고는 하는데, NHN 역시 이런 팩을 준비했더군요. 키노트 스피치까지 시간이 조금 남아있길래 근처 커피숍에서 커피 한 잔을 마시고 여유롭게 입장했습니다.. 더보기
스타크래프트2 엔딩 크레딧으로 블리자드 QA 엿보기 이 포스팅은 어디까지나 개인적으로 유추한 자료를 바탕으로, 어디까지나 개인적인 추측을 기반으로 작성된 것입니다. 다만 참조하는 자료로만 보시고, 객관적인 자료로 간주하지 않으시기를 부탁드립니다. 아울러 좀 더 구체적인 자료와 정보를 가지신 분들의 댓글 환영합니다. 엔딩 크레딧을 통한 QA팀 분석이라는 영감을 제공해주신 덕경 님에게도 이 자리를 빌어 감사의 말씀 전합니다. 바쁘다는 핑계로 포스팅이 뜸했습니다. CBT가 끝난 주말, 이제서야 미뤄왔던 포스트를 하나 올릴려고 합니다. 오늘 간만에 포스팅 할 주제는 다름 아닌 블리자드의 스타크래프트II 입니다. 뭐 한 마디로 말이 필요 없는 게임이죠. 4천만의 국민 게임이었던 전작 스타크래프트의 명성을 이어 무려 12년 만에 출시되는 후속작인만큼, 뜨거운 관심과.. 더보기
“왼손은 거들 뿐” – 환영 받는 팀원이 되는 방법 이 글은 NBA와 농구를 좋아하고 만화 “슬램덩크”를 대사를 외울 정도까지 좋아하는 분이 본다면 한결 이해하기 편합니다. ^^ 나는 농구를 무척 좋아한다. 매주 일요일 청계천 변의 농구장에 나가서 몇 시간씩 땀을 흘리고, 시간이 될 때마다 동호회에 참석해 같이 시합을 하고는 한다. (그렇다고 남들보다 잘 하는 건 절대 아니다. 오해하지 마시길...) 농구 역시 다른 단체 구기 종목과 마찬가지로 여러 명이 한 팀을 짜고 상대팀과 승부를 겨루는 팀 단위 스포츠다. 그러다 보니 각양각색의 사람들이 한 팀에 섞여 운동을 하게 된다. 농구는 어디까지나 단체 경기고 따라서 승부의 주체는 당연히 ”팀”이다. 팀이 승리하고 지는 것이지, 개별 플레이어들이 이기고 지는 것이 아니다. 한 팀을 구성해 운동을 하는 사람이라.. 더보기
회사는 중세시대? - '권한'과 '역할'에 대한 소고 얼마 전 이런 이야기를 들었습니다. “각 팀 리더에게 주어진 권한은 조직의 최고 책임자가 가지고 있는 전권을 조금씩 위임한 것일 뿐이다. 따라서 원칙상 사내의 모든 행동은 조직의 최고 책임자에게 보고되고 결정되어야 한다. 현실적으로 그것이 어렵기 때문에 각 팀 리더들에게 권한을 준 것이다. 그렇기 때문에 권한을 가지고 있는 사람들은 그에 걸맞은 책임을 져야 한다.” 전 이 이야기를 들으면서 봉건제(封建制)라는 중세의 사회제도가 생각났습니다. 중세에 지방의 영주들이 왕권을 대행하는 대신, 조세와 공물 등을 바치던 제도였죠. 위의 이야기와 비교해 볼 때 큰 차이가 없어 보입니다. “팀장”이 영주를 대신하고, “팀”은 영지를, “보고와 팀의 성과”가 조세와 공물을 대신하는 것으로 보입니다. “팀장”이 “팀”을.. 더보기
리스크 기반 테스팅 - Part 1 최근 많은 사람들이 관심을 가지고 있는 리스크 기반 테스팅에 관해, 렉스 블랙(Rex Black)이 그의 책 『Advanced Software Testing Vol.1 - Test Analyst』에서 설명한 것을 일부 발췌 번역했다. 3.9 리스크[1] 기반 테스팅(Risk-Based Testing) 리스크(Risk)는 부정적이거나 기대하지 않았던 결과(Outcome), 혹은 이벤트가 발생할 가능성을 의미한다. 구체적으로 리스크는 이것이 발생함으로써 고객, 사용자, 프로젝트의 참가자, 혹은 이해당사자들이 가지고 있는 제품의 품질이나 프로젝트의 성공에 대한 인식을 경감시킬 가능성이 있는 모든 문제를 의미한다.[2] 테스팅과 관련되어서는 주로 두 가지의 리스크 유형이 언급된다. 첫 번째 유형의 리스크는 제품.. 더보기
리스크 기반 테스팅 - Part 2 3.9.4 리스크 완화 혹은 리스크 제어(Risk Mitigation or Risk Control) 이미 리스크를 식별하고 그것을 평가했다면, 그 리스크들을 제어해야 할 것이다. 앞서도 언급했듯이, 어드밴스드 실라버스에서는 이를 리스크 완화(Risk Mitigation)라고 칭하고 있는데, 이는 정확한 표현이 아니다. 우리는 아래와 같은 4가지 방법을 통해 리스크를 제어할 수 있다. ■ 완화(Mitigation). 리스크가 발생할 가능성과 그로 인해 발생하는 영향을 줄이기 위해 취하는 예방 조치(Preventive measure) ■ 비상계획(Contingency). 리스크가 발생했을 때의 영향을 줄이기 위해 우리가 가지고 있는 계획 혹은 다중의 계획들. ■ 전이(Transference). 발생하는 리스.. 더보기
一萬人訪問記念所懷 어느새 오늘로 이 누추한 제 블로그에 만 명 남짓한 분들이 방문해 주셨습니다. 그 중에서도 소프트웨어 테스트와 QA 관련된 자료를 찾으신 분들이 꽤 많습니다. 사실 처음엔 단순히 제가 공부한 자료의 저장소가 필요해 시작한 블로그였습니다. 개인적인 일상사와 더불어 제가 보았던 자료를 쉽게 찾을 수 있도록 하나 둘 블로그에 저장하다 보니, 비슷한 주제의 자료를 필요로 하는 분들이 한 두 분씩 방문해 주시더군요. 예전의 포스트에서도 한 번 말씀 드린 적이 있지만, 소프트웨어 테스트와 QA에 대한 자료를 구하기가 매우 힘든 것이 국내의 현실이죠. ‘오죽하면 이런 누추한 곳을 다 찾아오시는구나’라는 생각이 들기도 했습니다. 그렇게 찾아주신 한 두 분이 만 명이 넘었네요. 사실 보잘것 없는 이 곳이 너무 과분한 관.. 더보기