QA팀의 팀 빌딩(?) TALKS

오늘 회사에서 오후 시간 내내 팀 전체가 모여서 팀 빌딩을 했다. 팀 빌딩? 음.. 말하자면 이 회사에서 우리 팀을 포지셔닝하고.. 비전을 찾기 위한 시간이라고 보면 될까.. 우리 회사가 NHN에서 분리되어 셋팅된지 2-3개월 정도 되어가는 시점에서 정말 필요한 시간이었다.

서기를 하느라 적느라고 정신 없었다. 정말 많은 의견들이 오고 갔다. 열심히 적긴 적었는데.. 너무 브레인스토밍 방식으로 talk가 진행되지 않았나 싶다. 팀장님이 몇가지 화두를 던져주고 조별로 그 화두 중 몇개를 선택하여 자유롭게 의견을 나누는 방식으로 진행했는데.. 결국은 다들 공감대가 있던 이슈들.. 그것을 하나 하나 확인해 가는 시간이었던것 같다. 아무튼 꼭 필요한 시간이었음.

4시간의 시간동안 진행했는데 결국은 결론을 못내고 의견 취합만 하고 끝내야 했다. 할 것들이 정말 많다. 공부해야 할 것도 많고… 테스트 자동화에서 부터 테스트 엔지니어와의 협업.. 개발 이슈까지…

뭐 일단 좋은 의견.. 당연히 해야 할 일들 다 나오긴 한것 같다. 한가지 두려운 것은 이제 여기서 소위 액션 아이템이라는 것을 뽑아내려 할것 같은 분위기. 이제 우리 팀이 사실상 회사의 유일한 QA 조직으로서 가져야 할 Vision statement, 그리고 로드맵의 부재가 아쉽다.

암튼.. 조금씩 정형화된 QA 프로세스를 반복 수행하면서  매너리즘에 빠져들려고 할 때 쯤.. 개인적으로도 어떻게 career path를 가져가야 하고 어떤 기술적인 roadmap을 갖고 공부를 해나가야 할지 고민을 시작해야 할듯…

효율적인 테스터의 7가지 습관

효율적인 테스터의 7가지 습관
(The Seven Habits of Highly Effective Testers)

원문 URL (URL of the original article): http://www.qaguild.com/weekly_article.php?id=35

이 글은 글의 원 저자인 Steve Miller의 구두 허락 하에 한국어로 번역되고, 개인 블로그에 포스팅되었습니다.
This article has been translated into Korean language with the permission of the original auther, Steve Miller.

Stephen R. Covey가 1989년에 쓴 성공하는 사람들의 7가지 습관이라는 책이 있습니다. 이 책은 수백만명의
사람들이 일과 인생의 효율성에 있어서 진정한 상호 의존성(interdependent effectiveness)을 성취하는데 많은
도움을 주었습니다. 이 글을 통해 효율적인 테스터가 취할 수 있는 7가지 좋은 습관에 대해 제시하고자 합니다. 이 7가지 습관을
요약하자면 다음과 같습니다.

  1. 적극적인 자세를 가질 것 (Be proactive)
  2. 끝을 염두에 두고 시작할 것 (Begin with the end in mind)
  3. 기본적인 것들을 먼저 시작할 것 (Put first things first)
  4. 윈/윈 전략을 취할 것 (Think Win/Win)
  5. 이해받으려 하기 보다 먼저 이해하십시오. (Seek First to Understand, Then to be Understood)
  6. 시너지를 낼 것 (Synergize)
  7. 날을 날카롭게 할 것 (Sharpen the Saw)

습관 1 – 적극적인 자세를 가질 것 (Be proactive)

떤 소프트웨어 프로젝트에 있어서든, 테스터의 목표는 소프트웨어가 높은 수준의 품질로 릴리즈되는 것입니다. 소프트웨어 프로젝트가
낮은 품질로 인해서 실패한다면, 그 요인이 무엇인지 분석을 해야 합니다. 이 때 테스터는 적극적으로 분석을 할 수도 있지만
소극적인 자세를 취할 수도 있습니다. 만약 소극적인 자세를 취한다면 아마도 비난할 다른 사람 또는 그렇게 될 수밖에 없었던
상황과 환경을 찾을 것입니다. 반대로 적극적인 자세를 취한다면 우선 그 실패에 대한 책임을 지고 미래의 프로젝트들에서 그 문제가
재발하지 않도록 하기 위한 방법을 찾을 것입니다.
모든 프로젝트는 종료 시점에 “포스트 모텀 (Post mortem)”
또는 “Retrospective”를 수행함으로서 그 프로젝트에서 무엇이 성공적으로 이루어졌고 무엇이 많이 부족했었는지를
공개적으로 토론합니다. 미래의 프로젝트에 있어서 적극적인 자세를 취할 수 있는 몇가지 아이디어를 제시합니다.

1.
소프트웨어 요구사항에 대해 책임감을 가지십시오. – 빈약한 요구사항 정의와 관련하여 다른 사람을 비난하지 마십시오. 대신 관련
팀과 함께 요구사항 정의가 완벽하게, 정확하게, 그리고 테스트 가능하게 작성되었는지 적극적으로 확인하십시오.
2. 추적성을
확보하십시오. – 테스트 케이스를 작성할 때 어떤 요구사항에 대해 어떤 테스트 케이스가 만들어졌는지 추적할 수 있는 매트릭스를
만들면 테스트 케이스의 커버리지, 테스트 적합성 (testability), 완전성을 분석하는데 많은 도움이 됩니다. 테스트
케이스 작성자가 요구사항을 정확하게 이해했는지 그리고 작성된 테스트 케이스가 적절한 커버리지를 갖는지 리뷰하기 위해 적극적으로
팀 미팅을 주최해야 합니다.
3. 효율적으로 커뮤니케이션 하십시오. – 테스팅 기간 동안 프로젝트 구성원 모두가 테스트
작업의 진행 상황을 공유해야 하는 것은 매우 중요합니다. Email이나 포럼을 통해 매일 매일의 테스트 진행 상황을
공유하십시오. 결함 건수, 요구사항 커버리지, 수행된 테스트 케이스 건 수, Passed/Failed된 테스트 케이스 건 수 등
사용 가능한 다양한 메트릭(Metrics)을 사용하십시오.
4. 발견한 결함을 효율적으로 설명하십시오. – 결함을 설명할
때는 결함 재현 절차와 예상 결과 등을 포함하여 훌륭한 결함 설명을 작성하기 위해 공을 들여야 합니다. 스크린샷이나 기타 사용
가능한 정보는 모두 사용하여 결함에 대해 설명하십시오. 이를 잘 지키면 QA와 관련된 재작업을 최소화할 수 있습니다.


습관 2 – 끝을 염두에 두고 시작할 것 (Begin with the end in mind)

프트웨어 프로젝트와 관련하여 여러분의 최종 목표는 고객의 요구를 만족하는 좋은 품질의 소프트웨어를 제공하는 것일 것입니다.
코딩이 시작되기 전에 반드시 이 프로젝트가 성공했다고 결정할 수 있는 결정 기준 (success criteria)을 만들어야
합니다. 예를 들어, 다음과 같은 기준을 설정할 수 있습니다. – 소프트웨어가 특정 결과물을 생성해내는가, 알려진 결함이
해결되었는가(또는 소수의 중요도 낮은 결함은 허용), 문서화가 잘 되었는가, 사용하기 쉬운가, 기타 등등. 초기 단계에 결정
기준을 설정함으로서 프로젝트 진행 도중에 수시로 프로젝트가 성공적으로 수행되고 있는지 검토할 수 있습니다. 결정 기준을 정의할
때에는 모든 팀 멤버 (PM, 테스터, 자동화 엔지니어, 개발자, 문서화 전문가 등)로 부터 도움을 구하십시오. 개인이 아닌
팀으로서의 시각으로 성공 결정 기준을 확립한다면 더 훌륭하고 많은 정량적인 기준을 확보할 수 있을 것입니다.

습관 3 – 기본적인 것들을 먼저 시작할 것 (Put first things first)

양한 작업들에 대해 우선순위를 부여하는 것은 매우 중요합니다. 일을 할 때는 가장 중요한 작업부터 시작해서 덜 중요한 작업들로
진행해야 합니다. 예를 들어, 네거티브 테스팅(Negative Testing)이 일반적인 소프트웨어 사용자의 사용 패턴이 아닌
특수한 사용 시나리오의 경우에 대해 … 한다는 것은 모두가 동의하고 인정합니다. 그러나 포지티브 테스팅(Positive
Testing)과 비교해봤을 때 네거티브 테스팅은 훨씬 덜 중요합니다.따라서 테스트를 시작할 때에는 미리 설계된 시나리오대로 잘
동작하는지에 대한 테스트를 먼저 시작하고, 또 이러한 테스트를 더 집중적으로 수행하십시오. 이 작업이 완료된 후에 네거티브
테스팅을 진행하는 것이 좋습니다. (경계 테스팅, 부적절 데이터 입력, 오버플로우, 인젝션 등)

습관 4 – 윈/윈 전략을 취할 것 (Think Win/Win)

은 조직에서 개발팀과 테스팅팀은 서로간에 비난하고 책임 소재를 돌리면서 팀간의 긴장감을 조성한다. 이는 상당히 파괴적이며
소프트웨어의 품질과 UX(User Experience)에 좋지 않은 영향을 미칠 수 있다. 개발팀과 테스팅팀은 공동의 목표를
가져야 한다. (고객이 최상의 품질의 소프트웨어를 가질 수 있게 하는 것) 이것이 공동의 목표가 될 때 모든 팀 멤버는 서로를
도울 수 있는 마인드를 가질 수 있게 되고 결국 훌륭한 품질의 소프트웨어가 완성되어 고객도 행복해지고 그로 인해 팀 멤버들도
성취감을 얻을 수 있다. 상호 신뢰의 분위기를 조성하고자 한다면 윈/윈할 수 있는 팀을 육성해야 한다. 이에 대한 몇가지 팁이
있다.

1. 지식 공유 – 여러분의 지식을 혼자 갖고 있지 말고 다른 사람들과 적극적으로 나누십시오.
2. 소셜라이즈(Socialize)하십시오 – 회사의 다른 팀 멤버들과 함께 점심 식사를 하십시오. 그들에 대해 더 배우고, 그들의 취미나 개인적인 목표 등에 대해 관심을 가지십시오.
3.
다른 사람들을 격려하십시오 – 타인이 훌륭하게 업무를 해내었다면 그 사람을 칭찬하고 격려하는데 인색하지 마십시오. 여러분의
(또는 그 사람의) 조직장에게 그 사람이 얼마나 잘 하고 있는지 말하십시오. 그 사람의 노력에 대해 얼마나 감사해하고 있는지
말하십시오.
4. 바쁜 팀 멤버들에게 도움을 주십시오 – 업무로 인해 많이 바쁜 팀 멤버들을 보면 그 일에 함께 뛰어
들어서 도움을 주십시오. 아마도 여러분이 나중에 도움이 필요할 때가 있을 것이므로 도움을 배푸는 것은 윈/윈 관계를
만들어나가는데 큰 도움이 됩니다.

습관 5 – 이해받으려 하기 보다 먼저 이해하십시오. (Seek First to Understand, Then to be Understood)

리 대부분은 우리 의견이 전달되기를 너무나 원하는 나머지 대화를 끊어버리고 상대방으로 부터 들으려하지 않는 아주 나쁜 습관을
갖고 있습니다. 모든 테스터와 팀 멤버는 서로 다른 다양한 경험과 시야(perspectives), 동기(motivations)를
갖고 있습니다. 어떤 문제를 해결하기 이전에 해결해야 할 문제를 완벽하게 이해하기 위해서 주의깊고 적극적으로 듣는 자세가
필요합니다. 모든 사실(facts)을 충분히 갖게 되었다고 느끼면 다양한 해결 방법을 생각해내십시오. 선택 가능한 몇가지 옵션을
가져감으로서 다양한 상황에서 여러가지 대안을 생각할 수 있고 더 낳은 협의를 할 수 있습니다. 만약 어떤 접근법에 대해 동의하지
않는다면 그 접근법을 제안한 사람을 공격하지 마십시오. 대신 여러분의 과거 경험에 기반해서 왜 더 낳은 접근법이 존재할 수
있는지 설명하십시오.

습관 6 – 시너지를 내십시오 (Synergize)
팀의 시너지를 발휘하는데 있어서 가장 중요한 것은 팀 협업입니다. 시너지를 낼 수 있는 팀은 서로 다른 능력과 서로 다른
백그라운드와 서로 다른 시야를 가진 다양한 멤버들로 구성됩니다. 이런 다양성 가운데서 최대한의 시너지를 내려면 도구의 사용이
중요합니다. 고도로 협업적인 (Highly Collaborative) 팀은 그들의 달력 (스케줄)를 공유하고 각 구성원의 현
상황을 적극적으로 포럼에 올려서 모두가 다른 사람들이 지금 무엇을 하고 있고 무엇을 성취하고 있는지 알게 하는 것으로서
커뮤니케이션합니다. 이런 팀은 각 구성원이 각 날짜마다 수행한 작업들과 업무를 수행한 시간, 그리고 어떤 작업을 수행하기까지
계획되었던 시간에 대해 남은 시간 등을 기록합니다. 또한 이러한 팀에서는 각 구성원들이 업무를 수행하면서 배우게 된 것들을
최대한 잘 설명할 수 있는 문서를 생산해내고 이를 공유합니다.

습관 7 – 날을 날카롭게 할 것 (Sharpen the Saw)
생산적인 테스터들은 계속해서 테스팅 기술들을 연마하고 새로운 기술과 베스트 프랙티스와 다양한 접근법들을 배우는 것을 좋아합니다.
그들은 지식에 대한 목마름을 갖고 가능한 모든 테스팅에 대한 책들을 읽습니다. 그들은 자신들의 업무를 쉽게 할 수 있는 방법을
배웁니다. (테스트 케이스를 자동화하고, 베스트 프랙티스를 적용함으로서 QA타임을 최소화하는 한편 소프트웨어 품질을 최대화함.)
이들은 QA Guild나 Sticky Minds 또는 다른 테스팅 커뮤니티에 계속적으로 참여합니다. 그러나 역시 이들은 언제
인생을 즐길지도 압니다. 훌륭한 휴가나 좋은 취미나 활동을 함으로서 방전된 배터리를 충전합니다.

저자에 대하여 (About the author)
Steve Miller는 Pragmatic Software의 사장이자 CEO이며 회사의 전략적 목표를 설정하고 이끌어가는 역할을
수행합니다. Pragmatic Software의 주력 제품은 소프트웨어 개발 생명 주기의 모든 phase를 관리할 수 있는
어플리케이션 라이프사이클 매지니먼트 (ALM) 도구인 Software Planner입니다.

아직도 사용되는 옛날 흑백 ATM

작년봄 전주에 갔다가 찾은 옛날식 ATM 화면 (새마을금고로 기억함..)
정말 오래 쓴다… 저 화면은 LCD도 아니고 옛날식 흑백 CRT스크린.. 아마 소프트웨어도 90년대 사용되던 그대로겠지..?
플젝중인 시스템도 이렇게 오랜 세월 문제 없이 잘 돌아갔으면 좋겠다..

사용자 삽입 이미지

옥션에서 IE8로 1시간 만에 쇼핑 성공 T_T

SD 메모리카드와 메모리카드 리더기를 사야 해서 늘 그러는것처럼 옥션에 들어갔다.
아.. 그런데 어제 Internet Explorer 8 브라우저를 설치하고 나서 처음 옥션에서 물건을 구입해보는 것이다.
따따따쩜옥션쩜… 키보드로 입력하며.. 뭐.. 같은 IE인데 큰 문제는 없겠지.. 했는데..
결과부터 말하자면 1시간만에 구입 성공.
일단 사야할 물건을 고르는데는 5분도 채 걸리지 않았다.

먼저 메모리카드 리더기를 장바구니에 담고..
SD 메모리를 사야했는데,
같은 판매자에게 구입하면 배송비를 절약할 수 있기 땜에 그 판매자의 스토어에 들어갔다.
여기서부터가 험난하다..

사용자 삽입 이미지
사진에서처럼 SD메모리카드 카테고리를 아무리 클릭해도 물건 리스트가 안나온다.
물건 리스트를 iframe에 뿌려주는것 같은데 iframe 리사이즈가 작동하지 않아서 한참을 이리 저리 해보다가

사용자 삽입 이미지iframe 내부를 마우스 드래그해서 사야할 물건을 겨우 겨우 찾아냈다는..ㅡㅡ;

우선 하나를 장바구니에 담고..
2GB짜리 메모리 2개를 사야 했기에 장바구니에 가서 수량을 1개->2개로 변경 시도..

사용자 삽입 이미지그런데 역시 캡처 화면 처럼 키보드로 수량을 변경하고 “변경”버튼을 클릭해도 아무런 반응이 없다.
textbox에서 엔터를 치니 그냥 전체 화면이 refresh됨..
다시 장바구니에서 물건 삭제하고 SD메모리를 다시 장바구니에 담으며, 2개를 담으려 했다.
그런데 이번엔 요 판매자가 구매 수량 제한을 1개로 걸어놨어.. 정말..ㅡㅡ;
다른 동일한 제품을 다시 찾아서 장바구니에 2개를 담는다는 것이 요번엔 내 실수로 1개만 담아버렸다.
슬슬 짜증이 조금씩 밀려온다.. 귀찮아서 그냥 Firefox를 열어서 장바구니에서 수량만 1개에서 2개로 수정해서 성공~ㅋ

아~ 이제 됐다 하고 주문을 넣는다.
집 주소로 되어 있는 배송지 주소를 회사로 바꾸고 싶어서 우편번호 찾기를 눌러 회사 주소를 찾았다.
그리고….

사용자 삽입 이미지우편번호 검색 결과에서 특정 주소를 아무리 클릭해도 반응이 없따..
이것만은 정말 방법이 없었다. Firefox로 배송지 주소를 수정한다 해도 같은 페이지에서 신용카드 결재를 해야하는데 Firefox에서 카드 결재를 할 수 있으리란건.. ActiveX땜에 꿈도 못꾸는 일..
결국은~ 쩝.. 그냥 집에서 물건 받아보자..

결재 방법으로 신용카드 선택하고 결재 버튼 클릭..
수도 없이 브라우저 상단 노란줄을 클릭해야 했다.
이미 설치되어 있는 ActiveX임에도 불구하고 단지 얘를 실행시키는 것도 이제는 노란줄 클릭해서 화면 refresh를 시켜야 하나보다.
설치안된 ActiveX 설치하고, 실행시키려 또 노란줄 몇번 클릭하고 카드 정보 입력하고 가까스로 주문 성공…

여기까지 오는데 거의 50분이 걸렸다. 물건 고르는데 걸린 시간은 5분..
너무 오래 걸렸어.. 옥션에도 훌륭한 QA 조직이 있는걸로 알고 있는데..
IE8에 대한 테스트는 아예 하지를 않나보다.. 아직 IE8이 베타라서 그런가..
한 PC에 여러 버전의 IE를 깔 수 있는 것도 아니고, Firefox나 다른 브라우저에서 옥션 사이트는 정말 쓰레기처럼 보여지고, 카드 결제도 절대 불가능한데..
같은 MS 제품인데도 IE8을 쓰는 사람은 물건 사기가 이리도 힘이 든다. 흠.. 나야 개발자 출신이라 이렇게 오기로(?) 구입은 했지만 일반인은 그냥 쥐마켓이나 다른 쇼핑몰로 벌써 가버렸을듯.

아!!
근데 지난번 건대 새천년관에서 했던 IE8 런칭 행사때 옥션에서 나와서 IE8 기능을 옥션에서 활용하는 발표까지 했는데.. 뭐지..ㅡㅡ;

사용자 삽입 이미지

여담이지만.. IE8의 웹슬라이스, 액셀러레이터 같은 새로운 기능은 너무너무 이기적이다.
IE8의 독자적인 기능을 위해서 결국은 웹 페이지에 이 기능들을 사용할 수 있게 해주는 코드를 집어넣어야 하는 이상한 짓을 해야 한다.
웹을 IE8 제품에 종속되게 만드는 좀 이상한.. 정말.. 마이크로소프트의 모토는 Be Evil인가…

아..! Auction 직원분이 이거 보시면 QA팀에 전달하심 될듯 하네요..^^ 언능 고치셔서 저같은 royal customer 놓치지 마시길..

실용주의 개발 환경 목록

웹에 상당히 많이 돌아다니는 링크 목록인데.. 작성한 사람이 누구인지는 모르겠다..


개인용으로 쓰기 위해 일단 내 블로그에 갈무리..^^




  1. 개발 도구

    1. Eclipse : http://www.eclipse.org/
    2. Netbean : http://www.netbeans.org/community/releases/60/index.html
    3. Firebug : http://www.getfirebug.com/

  2. 소스코드 관리

    1. CVS : http://www.cvshome.org
    2. Subversion : http://subversion.tigris.org
    3. MS Visual SourceSafe
    4. BitKeeper : http://www.bitkeeper.com
    5. ClearCase : http://www-306.ibm.com/software/awdtools/clearcase/

  3. 빌드 스크립트 도구

    1. make : http://source.redhat.com/cygwin
    2. Automake : http://www.gnu.org/software/automake
    3. Ant : http://ant.apache.org
    4. NAnt : http://nant.sourceforge.net
    5. Groovy : http://groovy.codehaus.org
    6. Rake : http://rake.rubyforge.org/
    7. SCons : http://www.scons.org/

  4. 빌드 시스템

    1. Maven : http://maven.apache.org
    2. Maven2 : http://maven.apache.org/maven2/index.html

  5. CI 도구

    1. CruiseControl : http://cruisecontrol.sourceforge.net
    2. CruiseControl .NET : http://sourceforge.net/projects/ccnet
    3. DamageControl : http://damagecontrol.codehaus.org
    4. AntHill : http://www.urbancode.com/projects/anthill
    5. Continuum : http://maven.apache.org/continuum
    6. LuntBuild : http://luntbuild.javaforge.com/
    7. Buildix : http://buildix.thoughtworks.com/

  6. 이슈 추적 도구

    1. Bugzilla : http://www.bugzilla.org
    2. JIRA : http://www.atlassian.com/software/jira/default.jsp
    3. FogBugz : http://www.fogcreek.com/FogBugz
    4. PR-Tracker : http://www.prtracker.com
    5. Trac : http://trac.edgewall.org/

  7. 테스트프레임워크

    1. JUnit : http://www.junit.org
    2. NUnit : http://www.nunit.org
    3. xUnit.NET : http://www.codeplex.com/xunit
    4. MbUnit : http://www.mbunit.org
    5. HTMLUnit : http://htmlunit.sourceforge.net
    6. HTTPUnit : http://httpunit.sourceforge.net
    7. JWebUnit : http://jwebunit.sourceforge.net
    8. Cobertura : http://cobertura.sourceforge.net
    9. Clover : http://www.cenqua.com/clover
    10. Cactus : http://jakarta.apache.org/cactus/
    11. Emma : http://emma.sourceforge.net/
    12. Fit : http://fit.c2.com
    13. Fitness : http://fitnesse.org
    14. Watir : http://wtr.rubyforge.org
    15. Systir : http://atomicobject.com/systir.page
    16. AUT : http://aut.tigris.org/
    17. UnitTest++ : http://unittest-cpp.sourceforge.net/
    18. TestNG : http://testng.org/doc/
    19. CppUnit : http://sourceforge.net/projects/cppunit
    20. CppUnit2 : http://cppunit.sourceforge.net/cppunit-wiki/CppUnit2

  8. 프로젝트 관리

    1. OpenProj : http://openproj.org/openproj
    2. dotproject : http://www.dotproject.net/
    3. Mantis : http://www.mantisbt.org/

  9. 커뮤니케이션 도구, 위키

    1. MoinMoin : http://moinmoin.wikiwikiweb.de/
    2. Confluence : http://www.atlassian.com/software/confluence/
    3. TWiki : http://twiki.org/
    4. SocialText : http://www.socialtext.com/
    5. Springnote : http://www.springnote.com/ko

  10. 성능분석

    1. ANTS Load : http://www.red-gate.com/products/ants_load/index.htm
    2. JunitPerf : http://www.clarkware.com/software/JUnitPerf.html
    3. Jmeter : http://jakarta.apache.org/jmeter/

  11. 기타

    1. Agitar : http://www.agitar.com/
    2. Structure101 : http://www.headwaysoftware.com/index.php
    3. FreeMind : http://freemind.sourceforge.net/wiki/index.php/Main_Page
    4. Capistrano : http://manuals.rubyonrails.com/read/book/17