본문 바로가기

분류 전체보기

 (130)
“왼손은 거들 뿐” – 환영 받는 팀원이 되는 방법 이 글은 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에 대한 자료를 구하기가 매우 힘든 것이 국내의 현실이죠. ‘오죽하면 이런 누추한 곳을 다 찾아오시는구나’라는 생각이 들기도 했습니다. 그렇게 찾아주신 한 두 분이 만 명이 넘었네요. 사실 보잘것 없는 이 곳이 너무 과분한 관..
넋두리와 변명 새벽 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”을 동일시 하기 때문이다. 또한, 동일한 컬럼 안에서 패스 처리된 모든 항목들을 한 군데에..

티스토리툴바