기본 콘텐츠로 건너뛰기

5월, 2014의 게시물 표시

STAREAST를 다녀와서...

STAREAST 2014 참관기 마지막 글입니다. 벌써 3주가 지났습니다. 눈을 감으면 아직도 그 순간이 생생한데.. 막상 머리에 남는건 많지 않네요. 하지만 몇가지는 가슴 깊숙히 간직할 수 있을 것 같습니다. 이 글에서는 세션 중심으로 후기를 적으면서 얘기하지 않았던 제 개인적인 이야기를 적을까 합니다. STAREAST에 참석하기 전까지 전 올랜도는 자동차 이름인줄 알았는데... 미국 도시 이름이더군요.. 그것도 오렌지로 유명한 플로리다.. 비행기로 15시간인가 걸렸던 것 같습니다. 비행기에서 아침해가 뜨는 걸 보는 진기한 경험도 했습니다. 캐나다의 지평선 위로 해가 봉긋 솟아오르는데 생각보다 멋있었습니다. 마이애미 해변으로 유명한 그 플로리다에 있는 도시인데.. 막상 오렌지는 먹어보지도 못했습니다. 우리나라 편의점 비슷한 가게에서 과일을 안팔더군요..(정확히 말하면 팔기는 하는데.. 오렌지가 없더군요.. 바나나, 말라비틀어진 사과는 있는데.. 왜? 오렌지는 없었을까요?) 편의점 얘기를 하니 기억나는것이.. 정말로 SUPERMARKET 이라는 간판을 건 가게도 보았습니다. 그런데 들어가보니 망해가는건지.. 물건이.. 없더군요.. 사람도 없고..어두침침하니 좀 무섭더군요.. 어쨌든 올랜도에 대해 잘 몰랐는데.. 가보니.. 웬걸.. 디즈니랜드가 올랜도에 있더군요.. 세계 지리를 다시 공부해야할려나 봅니다. 디즈니랜드 뿐만 아니라 씨월드라는 수족관하고 워터파크가 있고 유니버셜 스튜디오도 있는 놀이동산의 천국이더군요. 시차 적응을 위해서 튜터리얼 시작 하루 전날 도착했었는데.. 컨퍼런스 장소 탐방을 하고 씨월드에 잠깐 갔었습니다. 우리 나라 놀이동산 생각하고 비싸봐야 얼마나 비싸겠어? 하고 가봤는데.. 헉뜨.. 98달러.. 그냥 눈물을 삼키고 입구만 구경하고 왔습니다. 다음에 돈 많이 벌면 가족과 꼭 같이 오고 싶더군요. 돌이키는 발걸음 뒤로 가족끼리 들어가는 모습이 어찌나 부럽던지.. 그런데, 이런 놀이동

STAREAST 참관기 - The Art of Testing Transformation: Blending Technology with Cutting-Edge Processes

드디어 컨퍼런스의 마지막 세션.. 최종 키노트의 시간이 되었습니다. 그때는 아무 생각 없이 들었는데.. 지금 생각해보니 참 아쉬움이 많습니다. 키노트는 Jennifer Bonine 라는 여성분이 발표를 했습니다. 키노트의 내용을 한마디로 요약하면 이렇습니다. "컨퍼런스에서 배운 것을 돌아가서 적용하세요. 끊임없이 학습하십시오." 그렇습니다. 회사에서 비용을 내주기는 했지만 비싼 돈을 내고 그런 큰 컨퍼런스에 참석했다면 돌아가서 무엇이라도 해봐야겠지요. 하지만 많은 경우 그런 노력이 성공을 거두는 경우는 많지 않습니다. 컨퍼런스에서는 그럴 듯 하고 들어보면 할 수 있을 것 같았는데 막상 돌아가서 해보려면 현실은 만만치 않죠. 그런 경우를 염두에 두고 키노트가 진행되었습니다. 키노트에서는 3가지를 얘기했습니다. 1. 문화를 바꾸어라. 2. 작은것부터 시작해라. 3. 행동을 바꾸어라. 관점을 바꾸어라. 변화라는 것은 사람에 관한 것이므로 사람이 바뀌어야 한다는 얘기를 했습니다. 그리고 테스팅을 잘하는 조직이 되려면 3가지가 갖춰져야 한다고 얘기했습니다. 1. 사람 2. 절차(Process) 3. 기술(Technology) 과연 STAREAST에 참석했던 수백명의 사람들이 자신의 일터로 돌아가 얼마나 많은 것을 바꾸고 실천할 수 있을지는 모르지만 당장 저부터 많은 노력을 해야한다고 느꼈습니다. 2010년 이후로 여러가지 슬럼프에 빠져있었는데.. 이번 컨퍼런스 참석 이후로 자극도 많이 받고 여러가지 많은 것을 생각할 수 있어서 좋았던 시간이었습니다. 이제 다음 글을 마지막으로 참관기를 정리할까 합니다. 마지막 참관기는 컨퍼런스를 포함해서 오고가며 보고 듣고 기억하는 것을을 시시콜콜 적어볼 생각입니다.

메일에 이미지가 안보이네요.

고객 문의 이메일 "그쪽에서 보낸 이메일에 있는 이미지가 안뜹니다. 그래서 매번 이미지 표시하기 버튼을 눌러야 보입니다. 불편하니 고쳐주세요" ...고객님이 쓰시는 웹메일에서 그렇게 보여주는 것이면, 고칠 자신이 없군요... ps. 그래도 요즘 주요 웹메일 서비스들은 이미지의 안전을 확인후에 보여주는 방식으로 바뀌어서 이런 문의가 많이 줄었습니다.

가격이 올랐으면 배송이 빨라져야지..

5천원에 배송이 8일 걸리는 수입상품이 있었는데, 최근 7천원으로 가격 상승. 이걸 주문한 한 고객이, 여전히 배송이 8일이 걸리자 항의를 했다. '2천원이 오른거 보면 배송료가 추가된것 같은데, 왜 시간이 단축되지 않으면서 배송료를 더 받느냐' ....2천원 인상이 배송료라고 한적 없는데요. -_- 지레짐작 쩌는 고객님이심...;;;

내가 말하는건 그게 아니고...

50대쯤의 목소리인 남성 고객님의 전화 고객 "내가 한시간 전쯤부터 OOOO랑 XXXX랑 사려고 그 쇼핑몰 사이트에 들어가서 어쩌구 저쩌구 ~~~~~(장황한 설명 생략) ~~~~~장바구니에 넣고 버튼을 눌렀어." 나 : "네. 그런데요?" 고객 : "안되" 나 : "어떻게 화면이 나오며 안되시는데요?" 고객 : "버튼 누르니 안된다고" 나 : "화면이 안변한다는 말씀이신가요?" 고객 : "그게 아니고 안된다고. 화면이 안되" 나 : ".....창이 안뜨나요?" 고객 : "그게 아니라...." 이런식으로 무한반복. 본인이 한 행동은 엄청 자세하게 설명이 가능하면서, 화면상에 뭐가 있는지는 설명능력 제로인 아저씨. 고객 : "모니터 크기가 100이라면 70밖에 안나와" 나 : "....내용 일부가 안보인다는 말씀이신가요?" 고객 : "그게 아니라. 답답하네. 그러니까 내가 모니터가 27인친데.... 70%밖에 안보여" 나 : "......모니터에 문제가 생겼다는 말씀이신가요?" 고객 : "그런 말이 아니고, 그러니까 모니터에 네이버라든가 인터넷이 뜰거 아니야. 그게 10이라면 7밖에 안보인다고" 나 : "...." 이렇게 30분간 통화. 알아낸건, 결제 프로그램을 설치했더니, 창이 최대화가 자동으로 안된다는 뜻. 원래 윈도XP상에서 IE를 최대화된 창으로만 썼는데, 일반크기의 창으로 떠서 불편하다고. 에휴....

주소 입력란에 왜 이메일을 입력하는것일까요?

주소를 넣으라는 입력칸에 이메일 주소를 넣는 고객이 하루에 몇건씩 있다. 배송지 주소나 사업지 주소라고 설명을 써도 마찬가지. 우편번호 검색부터 해서 주소가 입력되게 해놔도 상세주소에 그딴 짓을 한다. 빨간 글자로 주의를 써놔도 소용없고 이메일 주소를 인식해서 경고가 뜨게 해놨더니, 골뱅이를 빼고 이메일 주소를 넣기 시작한다. ......이젠 어쩌지.

STAREAST 참관기 - Top Practices for Successful Mobile Test Automation

드디어 컨퍼런스 마지막 세션입니다. 하아.. 끝이 보이네요. 마지막으로 제가 선택해서 들은 세션은 'Top Practices for Successful Mobile Test Automation'입니다. 제목과 내용으로 미루어 모바일 테스트 자동화 사례 발표를 기대하고 들어갔는데.. 역시나 이번에도 전혀 다른 내용의 세션이 진행되었습니다. 하지만 내용은 정말 좋았습니다. 세션 내용은 성공적인 모바일 테스트 자동화를 위한 전략에 대한 내용이었습니다. 자동화를 성공하기 위해서는 이렇게 해야한다.. 머 이런 내용이었습니다. 발표는 Fred Beringer 라는 프랑스 사람이 발표를 했습니다. 프랑스에서 왔다는 얘기를 듣고 버터 바른 듯 발음이 마구 굴러다니면 어쩌나 했는데 매우 듣기 좋은 발음이었습니다. 우선 발표 내용은 대략 이렇습니다. 모바일 테스트 자동화 자체가 하나의 프로젝트로 계획과 전략을 잘 세워야 성공할 수 있다. 그리고 테스트 자동화는 선택이 아닌 필수다..(이 얘기도 자주 듣다보니 슬금 슬금 지겨워지기 시작하는..) 모바일 테스트 자동화를 위한 계획과 전략 수립에서 고려해야할 내용은 아래와 같다. 1. 올바른 목표 설정이 매우 매우 중요하다. 2. 목표를 추적해라. 목표에 맞는 메트릭 선정이 중요하다. 측정할 수 없다면 존재하지 않는 것이다. 대표적인 메트릭은 수정시간, 만족도, 결함 숫자, EMTE(Equivalent Manual Test Effort), Customer onboarding time 등이 있다. 기준선을 설정하고 ROI를 측정해라. 비용을 계산해라.(Value = Benefit-cost) 하지만 너무 많은 메트릭은 독이 될 수 있다. 이러한 메트릭은 자동화 프레임워크에 통합되어야 하고 올바른 메트릭을 수집할때까지 반복하고 수정되어야 한다. 3. 모든 것을 자동화해라. 여기서 모든 것이란 테스트만 의미하는 것이 아니라 프로젝트 활동의 모든 것을 자동화해라. 개발, 설계,

다음 달 상품 가격은 얼마입니까?

고객 : OOO 상품 가격이 매번 변하던데 직접 변경하시는 겁니까? 직원 : 네 해당 상품은 환율과 공급 가격변화에 따라서 저희가 매일 변경합니다. 고객 : 그럼 좋습니다. 다음달 15일 가격을 미리 알려주십시오. 직원 : 그건 모르죠. 고객 : 직접 바꾼다면서요? 그런데 왜 모릅니까? ...내가 한달 후 가격을 알려드리면, 고객님은 지능지수를 알려주실래요?...

견적서만 받고 물건은 안사는 고객님

어떤 기업 고객님. 이건 얼마짜리로 해달라, 저건 가격을 얼마 올려달라, 가격 끝자리를 뭘로 맞춰달라, 이런 항목 넣어달라, 문서양식 어떻게 해달라....복잡한 요청사항이 많은 견적서를 요청한다. 그리고 그 견적서를 받고, 주문을 안함.....-_- 이러길 여러번. ...왠지 자신이 할 서류작업을 우리 회사에 시키는 느낌이 드는데.....

내 아이디와 비번이 뭐였더라?

성격 급한 고객이 아이디 비밀번호를 생각해보려 하지도 않고, 아이디/비번 찾기 메뉴에 들어가서 찾기 선택 1차로 아이디와 새 비번이 이메일로 발송됨. 고객이 바로 이메일에 들어갔으나, 아직 도착 안함. (네이버는 오래걸릴땐 3~5분 걸리더라...) 다시 비번 찾기 누름. 2차로 아이디와 새 비번을 이메일로 발송. 급한 마음에 이번엔 문자로 발송을 누름. 3차로 아이디와 새 비번을 문자로 발송. 아직 1차 메일도 안온 사이에, 아이디 비번을 생각해내서 입력. 새 비번이 발급된 상태라 비번이 안먹힘. 1차 이메일 도착. 역시 새 비번이 발급되서 안먹힘... 화가 나서 안된다고 문의. 전화 한 사이에 문자메시지 도착.... ...기록 보니 저 모든게 40초동안 벌어진 일임. (메일이 생각보다 빨리 갔네?) ...이메일 도착에 시간이 걸리니 몇분 기다리라고 안내하고, 짧은 시간에 연속으로 비번 변경 안하도록 알고리즘을 바꿔야 할듯...

꼬우면 쓰지 말라는거요?

내부 규정상 들어주기 불가능한 요구를 하길래 이유를 설명하며 양해를 부탁했는데 "꼬우면 쓰지 말라는 의도시군요?" 이라며 비꼬듯 약올리는 고객. 나중에는 말끝마다 저 말을 붙인다. ....규정이 아니더라도 퍽이나 들어주고 싶겠다.

STAREAST 참관기 - Build the Right Regression Suite with Behavior-Driven Testing

컨퍼런스 2일차 오후 첫번째 세션은 그 유명한 ThoughtWorks 사의 Anand Bagmar 라는 분이 발표한 'Build the Right Regression Suite with Behavior-Driven Testing'라는 세션을 들었습니다. 처음에 들어갈때는 ThoughtWorks 사의 발표인줄 몰랐다가 나중에 보니 ThoughtWorks 사의 발표더군요.. 웬지 모를 급 호감이... 사실 들을만한 세션이 없어서 반은 호기심으로 들어갔던 세션인데 생각보다 세션 내용이 매우 좋았습니다. 발표를 듣는 사람도 엄청 많아서 좌석이 모자라서 서서 드는 사람이 있을 정도였습니다. 웬지 모를 뜨거운 반응이었습니다. 제가 들었던 세션 중 그토록 뜨거웠던 반응을 보인 세션은 이 세션이 유일했습니다. 발표하시는 분이 인도분이라서 발음을 못알아들을까봐 매우 걱정했는데 발음도 좋으시고... 하지만 이 세션을 들어도 사실 전 아직도 BDT를 잘 모르겟습니다. 개념은 대충 알겠는데.. 흠.. 세션 발표내용을 요약하면 이렇습니다. 애자일 개발 조직에서는 단위테스트가 아무래도 자동화가 용이하다보니 단위테스트만 비대해지는 경향이 있다. 그래서 대체로 애자일 개발 조직에서는 테스트가 피라미드 모양이 된다. 아래가 길고 위는 얇은.. 이렇게 되면 필연적으로 GUI 테스트가 약해질 수밖에 없다. GUI 테스트는 아무래도 자동화 테스트가 어려운 것이 사실이다. GUI 테스트를 모두 자동화할 수는 없다. 자동화와 함께 탐색적 테스팅과 같이 사람이 하는 테스트도 중요하다. 그럼 GUI 테스트를 어떻게 자동화할것인가? 그에 대한 방안이 BDD 또는 BDT이다. BDT는 기능이 아닌 행동(액션, 목적)에 집중하는 것이다. 큰 그림을 볼 수 있어야 한다. 기능에 집중하면 테스트 케이스를 많이 만들 수는 있지만 중요한 것을 놓칠 수 있다. BDT를 작성하기 위해서는 퍼소나를 먼저 작성해야하고 그다음 퍼소나의 비즈니스 플로우에 집중해서

비싼 물건을 샀는데 왜 서비스가 없는 것이오?

상품중에 '같은 상품'인데 가격과 수량이 다르게 각각 올라가 있는 경우가 있다. 공급라인이 다르다거나, 한번에 파는 수량이 다르다거나 기타등등 이유이다. 예를 들어, 같은 A라는 상품도, 한번에 1천개씩 파는 경우가 1개씩 파는 경우보다 개당 가격은 절반이다. B라는 상품의 경우, 일본에서 들여오는 재고가, 영국에서 들여오는 재고에 비해 더 싸고, 입고 시간이 단축된다. 그런데 어떤 고객이....같은 상품이 다른 가격들로 올라와 있는 것을 보고, '비싼건 악세사리를 더 끼워주나 보다'라고 혼자 생각해서 비싼 상품으로 주문했다. 그리고 악세사리가 오지 않자 항의 중....-_-

내가 물건을 찾아가겠다는데 그러네..

쇼핑몰 사이트에서 택배 말고 방문 수령을 하겠다고 선택해서 주문한 고객. 상품이 준비되서 문자를 보냈더니 전화가 왔다. 고객 : 거기 차로 찾아가려면 어디로 가야 하나요? 직원 : 방문수령 하시려면 가산동에서.... 고객 : 아니요. 직원 : 네? 고객 : 방문수령이 아니라 찾아가려고요. 직원 : 네??? 고객 : 방문 수령이 아니라 찾아가서 수령하겠다고요. 방문하면 오래걸리잖아요. 직원 : ???? 방문 : [명사] 어떤 사람이나 장소를 찾아가서 만나거나 봄. ...다른 의미로 생각하신듯.

왜 내가 접속할때마다 문제가 발생하나요?

운없는 고객님이 존재한다. 서버 관리상.....새벽에 몇초간 일부 서비스가 멈추거나 십여분간 사이트가 느려질 때, 그 때마다 접속해서 '이 사이트는 왜 매번 안되냐' '들어올 때마다 느리다' 식으로 문의를 하는 고객이 있다. ....매번 비슷한 시간대에 처리하는 일이라 그런가. 잠깐 처리하는 것이라도 조그맣게 공지를 할까 고민중.

그 상품을 내린 이유가 무엇이오?

어제 점심때 전화해서 상품 재고를 확인한 고객. 그러나 어제 저녁에 품절되서 상품을 내리게 되었다. 그 고객이 오늘 늦게 주문을 하려니 상품이 없다고, 항의하며 책임지고 물건을 구해줄 것을 요구. .....책임 없는 것 같은데요. 우리가 견적을 주거나 계약을 한것도 아니고... ps. 고객은 우리가 상품 페이지를 닫은 의도에 대해 의심하고 있음. -_- 의도까지야...있을리가.

STAREAST 참관기 - Performance Testing in Agile: The Path to 5 Star App Reviews

드디어 STAREAST 마지막 날입니다. 짧다면 짧고 길다면 긴 4일의 일정인데.. 그곳에 있을때는 참 긴 시간이었는데.. 지금 돌아보니 정말 찰나였던 것 같습니다. 그 수많은 세션을 다 듣지 못한것이 아쉬울 따름입니다. 지난주에는 제 스마트폰이 갑자기 급사(커스텀 커널 올렸다가 무한 부팅에 빠지는 바람에.. )하면서 스마트폰 복구하고 회사 업무 보느라 미처 후기를 올리지 못했습니다. STAREAST 참관기는 이번주 안에 마무리 지을 생각입니다. 컨퍼런스 2일차는 첫날과 달리 Agile Testing과 Personal Excellence 세션이 빠지고 대신 Mobile Testing과 Performance Testing 세션이 진행되었습니다. 키노트는 Theresa Lanowitz 라는 분의 'Extreme Automation: Software Quality for the Next Generation Enterprise' 였는데. 최신 IT 업계의 트렌드와 함께 이런 트렌드에 맞춰 테스트 자동화가 중요하다는 일반적인 내용이었습니다. 그 다음으로 첫번째 세션으로 Mobile App Testing Secrets 를 들었는데 컨퍼런스 첫날 들었던 Improving the Mobile Application User Experience(UX) 만큼은 아니었지만 저에게는 그다지 영양가가 높지 않은 세션이었습니다. 세션 내용은 결국은 모바일 테스팅의 최신 트렌드는 크라우드 테스팅이고 자신의 회사가 서비스하고 있는 크라우드 테스팅은 이런 장점이 있고 불라 불라.. 머 그런 내용이었습니다. 최근 국내에서도 STA(STEN?)에서 크라우드 테스팅을 시도하고 있는데.. 과연 이 서비스가 국내에 정착할 수 있을지는 저는 좀 의문입니다.(이 크라우드 테스팅이라는것이 머 새로운 서비스도 아니고 벌써 한 10년은 된 서비스인데.. 그동안 국내에서는 말도 안되는 보안 어쩌고 저쩌고에 돈이 들어간다는 이유로 몇번이고 시도는 있었지만 흥하지

인터넷이 안되어서 팩스로 주문하고 싶은데요.

어느 고등학교는 학교내 모든 인터넷을 교육관련 사이트를 제외하고는 전부 차단해서 우리 회사 쇼핑몰이 열리지 않는다고 한다. 그래서 실습에 꼭 필요한 부품을 '팩스'로 주문하고 싶다고 행정실 교직원이 연락해 왔다. -_- ....뭐하는 짓인지...

우리 동네 주소는 그게 아니에요.

고객 : 주소를 입력하려는데 우편번호를 검색해도 맞는 것이 안나옵니다. 나 : 주소가 어떻게 되세요? 고객 : OOO도 OOO면 OOO.... 헤는 '어'에 '이'입니다. 해가 아니라 헤. 나 : 안나오네요. 잠시만요. 추가 검색.... 나 : 저...헤가 아니라 해 아닌가요? O해읍으로 검색되는데요? 고객 : 아닙니다. 헤입니다. '어'에 '이'라니까요. 나 : OOO면에 있는건 '해'가 맞습니다. 우편번호 XXX-XXX 맞죠? 고객 : 아니라니까 그러네. 남들이나 그렇게 쓰지, 우리읍에선 그렇게 안써요. ....배달은 아저씨네 읍내 사람들이 하는게 아닐텐데...

제가 원하는 크기가 없네요..

고객 : OOOO-30 상품의 사양이 잘못 표기된것 같습니다. 직원 : 어떤 부분이 잘못된건가요? 고객 : OOOO-30 상품에 XX수치가 30이라 되어 있는데, 제가 필요한건 45입니다. 직원 : 죄송하지만 OOOO-30는 30이 맞습니다. 고객 : 아니 45여야 합니다. 직원 : 45는 OOOO-45라는 상품으로 별도로 있습니다. 상품이름자체에 수치가 있지 않습니까? 고객 : 아니, 제가 필요한건 OOOO-30인데 45인겁니다. 직원 : ....

카드 결제가 안됩니다.

고객 : 카드 결제가 안됩니다 나 : 어느 과정에서 안되시는 건가요? 고객 : 카드 번호를 넣어서 ISP등록을 하라는데서 안됩니다. 나 : 오류메시지가 나오나요? 고객 : 아뇨. 카드 번호를 몰라서요. 나 : 네? 고객 : 카드를 지금 안가지고 있습니다. 나 : 그럼 카드가 있어야 결제가 가능하겠네요. 고객 : 카드는 있습니다. 제 카드구요. 카드를 안가져와서 번호를 모를 뿐입니다. 나 : .....(어쩌라구?)

공인인증서가 나오지 않아요...

BC카드의 ISP 안전결제 창이 공인인증서 창과 비슷하다보니, "공인인증서가 있는데도 목록에 안나온다"라는 문의가 많이 들어온다. 그런데 이건 비씨카드라는것등을 알지 못하면 사정을 모르니, 회사직원들도 전화 내용만 듣고는 혼동하게 됨...-_-

숙제는 스스로 하세요..

고객 문의글 : "춤추며 노래부르는 휴머노이드 로봇을 만들려는 학생입니다. 필요한 부품 목록과 설계도, 프로그램 일체를 주시기 바랍니다. 설계와 외형 디자인은 남들이 사용하지 않은 독자적인 것으로 제작 해주시기 바랍니다" ....숙제는 직접 하세요-_- (참고로 저희회사는 전자부품쇼핑몰...저항이나 모터 같은거 팜...) <!-- Place this tag in your head or just before your close body tag. --> <script type="text/javascript" src="https://apis.google.com/js/plusone.js"></script> <!-- Place this tag where you want the widget to render. --> <div class="g-post" data-href="https://plus.google.com/108524374726368684068/posts/aouJUi2AJ7p"></div>

그 상품은 저희가 판매한 상품이 아닙니다. 고객님..

우리 쇼핑몰에서 팔지도 않는 상품을 AS문의하는 경우가 발생. 알고보니, 이 사람이 중고로 구입한 상품인데, 거래할때 사용한 박스가 우리 회사 택배 박스. 그 중고상품에 문제가 생기자 AS받고 싶어서 박스에 적힌 연락처로 연락한 것. -_- ....중고 물건 거래한 박스만 보고 AS문의하는 사람도 있구나. <!-- Place this tag in your head or just before your close body tag. --> <script type="text/javascript" src="https://apis.google.com/js/plusone.js"></script> <!-- Place this tag where you want the widget to render. --> <div class="g-post" data-href="https://plus.google.com/108524374726368684068/posts/7wqQbjKKm22"></div>

장바구니에 담았다고 주문이 된건 아닙니다. 고객님..

고객 : 방금 회원가입하고 주문을 했는데, 주문이 정상적으로 들어갔는지 확인 바랍니다. 나 : 회원 아이디가 어떻게 되시나요? 고객 :OOOOOO 나 : (검색) 저, 죄송하지만 주문이 들어오지 않았는데요. 고객 : 그런가요? 방금 주문했습니다만. 이상하다고 느낀 내가 회원의 기록을 조회해보니... 3분전 가입완료. 1분전 장바구니에 물건 담기. (끝) ..... 장바구니에 담은걸 주문이라고 생각하시는 분이 또 있었음....-_- <!-- Place this tag in your head or just before your close body tag. --> <script type="text/javascript" src="https://apis.google.com/js/plusone.js"></script> <!-- Place this tag where you want the widget to render. --> <div class="g-post" data-href="https://plus.google.com/108524374726368684068/posts/CvH27ktfYZc"></div>

STAREAST 참관기 - Meet Big Agile: Testing on Large-Scale Projects

컨퍼런스 첫날 마지막 세션입니다. 이 세션 이전에 'Improving the Mobile Application User Experience(UX)'라는 세션을 들었는데... 언급조차 하고 싶지 않을 정도로 최악이었습니다. 국내에서 제 사용성 테스팅 교육에 들어오시는 분들이 원하는 딱 그런 내용이었습니다. 그냥 싼맛에 사용자 없이 팀 내부에서 기존의 디자인 원칙에 따라 쿵쿵짝짝 고려해야 할 내용들에 대한 사례를 기반으로 한 내용이었는데.. 영양가가.. 0로 수렴하는... 차라리 Erik van Veenendaal의 'Risk-Based Testing for Agile Projects'를 들을걸 후회가 막심했습니다. 에릭은 오랜만에 얼굴을 보니 못알아볼정도로 역변을 했더군요. 제 기억력이 안좋은 건지 처음에는 못알아볼뻔 했습니다. 인사를 할까? 하다가 너무 오랜만이라서 저 같은 사람 기억도 못할 것 같아 소심한 마음에 인사도 못했습니다. 그래서 두번째 세션 후기는 넘어가고 마지막 세션 후기입니다. 이 세션은 Geoff Meyer 라는 분이 발표를 했고, 발표 내용은 Dell의 전사 애자일 적용에 대한 사례 발표였습니다. 델은 미국에 2개, 인도에 2개의 디자인 센터를 운영하며 over sea 프로젝트를 애자일 방법론으로 오래전부터 운영해왔다고 합니다. 이 디자인 센터에서는 서버 시스템 관리 프로그램이나 콘솔 플러그인과 같은 임베디드 소프트웨어를 개발하고 있는데 업데이트 주기가 6개월 이내로 일정 압박이 심하고, 경쟁 제품과 경쟁에 대한 압박 그리고 자주 변경되는 요구사항 등등 초기에는 여러 문제가 발생해서 책을 통해 내부적으로 공부도 하고, 컨퍼런스도 참가해보고 전문가 그룹과 컨설턴트의 도움을 받아 2009년부터 단계적으로 애자일을 도입했다고 합니다. 그러면서 하는 얘기가 애자일 프로젝트 도입은 한번에 완성될 수 없으니 단계적으로 도입하기 위한 로드맵을 잘 구성해야한다고 했습니다. 인상적이었던 내용은

액티브 엑스 설치안하고 카드 결제 안될까?

고객 : 내 나이 60이 되어가는데 이거 참 어렵네. 뭘 설치하라는게 이렇게 많아. 나 : 죄송하지만 카드결제를 하시려면 다 설치하셔야 합니다. 고객 : 설치해야 한다고? 아냐 난 필요없어. 동의 안함. 설치 안해. 나 : 저...그러면 카드 결제가 안되는데요 고객 : 안해도 되게 해줘야 하는거 아냐? 뭐야 이거 ISP플러그인이 설치되지 않아서 안된다고? 이거 왜 이래? 나 : 그러니까 아까 메시지 나온 그거 설치하셔야 하는건데요. 고객 : 아니 장사를 하려면 고객이 원하는데로 하게 해줘야 하는거 아닌가? 나 : 저희도 그러고 싶습니다만.... -_- 설치하라는거 일부러 설치 안하시는데 저희가 어찌 도와드려요... ----- 해외 쇼핑몰 이용하셔야 할듯.. 영어라서 안될까요? 참.. 정말로 이해안되는게.. 왜 쓸데 없는 멀웨어 설치해가면서 구매를 해야는지.. 그걸 강제하는 정부도 웃기고.. 그걸 따라야 하는 업체도 불쌍하고.. 소비자는 봉이고..

비회원도 폼 자동 입력 되게 해줘..

고객 : 주문할 때마다 이름, 주소, 연락처를 매번 입력해야 하는 것이 귀찮은데, 이거 저장했다가 자동으로 넣어주면 안되나? 나 : 지금 비회원 주문을 하시려는 거죠? 회원으로 가입하시고 주문하시면 자동으로 입력 됩니다. 고객 : 그거야 나도 알지. 하지만 회원가입하면 개인정보를 그쪽에서 저장 하잖아. 그게 싫다고. 나 : 저희는 주민등록번호 같은걸 안받고 가입할 수 있습니다. 이름 주소 연락처만 입력하시면 됩니다. 고객 : 그것도 저장되는게 싫어. ....뭘 원하시는겁니까.

스토커 고객

자주 문의 이메일을 보내는 단골(?) 고객 한분은, 매번 이메일에 [긴급] 표시 붙이고, 빨갛고 큰 글씨로 내용을 적어서 보낸다. 중간중간 노란색으로 강조도 해놓고, 그리고 내용 마지막은 몇월 몇시 몇분까지 필히 답장바란다. 답장 해주고 전화 달라. 서둘러 처리 바란다...는 내용이 들어가 있다. ....이게 뭐하는 짓인지. 해주기 싫어지게 만드네. 게다가 문의중 절반은 공지나 구입시 나오는 안내를 읽어보지도 않고 묻는 것이거나, 같은 내용을 재확인 하는 것이다. 이 사람이 주문을 하면, 물건이 발송될때까지 예정일날 확실히 발송이 가능한지 확인해서 답을 달라는 이메일을 매일 보낸다....

탐색적 테스팅은 경험기반기법이 아닌 학습주도테스팅이다.(Explorer Testing is Learning-driven Testing)

제가 얼마전 탐색적 테스팅 교육을 재개정을 했습니다. 5년전인가? 6년전인가? 제임스 바크가 국내에 와서 Rapid Software Testing 교육을 진행했었고(이번 STAREAST에서 바크와 그때 얘기를 잠깐 했습니다. 바크는 한국에서 초대만 해준다면 다시 한번 한국에 꼭 방문하고 싶다고 하더군요.. 어쩌면 자기가 중국에 갈때 들릴 수도 있을 거라고.. 최근 중국에서 바크를 자주 부른다고 합니다.) 이후에 제가 근무하는 회사에서 탐색적 테스팅에 관한 교육을 꾸준하게 진행을 했었는데.. 저는 이런저런 이유로 참석하지 않다 올해 해당 교육과정을 전면적으로 뜯어 고쳤습니다. 그러면서 지난 자료를 다시 한번 검토하고 STAREAST까지 가서 바크의 세션도 듣고 얘기도 나누고 그동안 바크나 마이클 볼튼과 나누었던 트윗도 정리하면서 나름 정리한 제 생각을 몇자 적어볼까 합니다. 아직 완전하게 정리된 상태는 아니기 때문에 논리적으로 취약한 부분은 댓글로 말씀해주시면 같이 얘기를 나눠볼 수 있을 것 같습니다.(꼭 댓글이 아니어도 각종 SNS로 저에게 말을 걸어주셔도 됩니다.) 국내에서 탐색적 테스팅을 하고 있다고 말하는 조직이 꽤 많습니다. 여러 이유로 탐색적 테스팅은 국내에서 꽤 인기가 있는 기법, 방법론 중 하나입니다. 하지만 제 경험상 단언컨데 국내에서 탐색적 테스팅을 제대로 수행하는 조직은 한번도 본적이 없습니다. 형태적으로는 꽤 근접한 경우가 많지만 핵심적인 내용들이 결여된 경우가 꽤 있습니다. 예를 들면 문서가 없어도 테스팅을 할 수 있다거나 문서를 안만들어도 된다거나(웅?) 경험 많은 테스터가 수행하는 테스트라고 생각하거나 테스트 아이디어와 결함 갯수 같은 메트릭을 측정하는 경우 등등 꽤 많은 오해와 잘못된 사례들이 있습니다. 그 중에서 제가 이번에 얘기하고자 하는 것은 경험이라는 부분입니다. ISTQB Foundation Level에 보면 경험기반기법에 탐색적 테스팅이 소개되어 있습니다. 아마 탐색적 테스팅과 경험이

STAREAST 참관기 - The Three Pillars Approach to Your Agile Test Strategy

제가 컨퍼런스에서 첫번째로 들은 세션입니다. 컨퍼런스에서는 첫째 날에는 Test Management, Test Techniques, Test Automation, Agile Testing, Personal excellence, Special Topic으로 주제를 나눠서 세션이 진행되었습니다. 그리고 여기에 추가로 스폰서들을 위한 Technical Presentation 이 있었고 여기는 같은 시간에 3개의 세션이 배정되어서 결국은 같은 시간에 총 9개의 세션이 총 3번 그러니까 전체 27개 세션이 하루동안 진행되었습니다. 그중에 제가 들을 수 있는 것은 3개이니.. 신중하게 골라야 했습니다. 이게 제목과 소개글로만 고르다보니 어떤 경우는 굉장히 내용이 좋은 경우도 있고 어떤 경우에는 정말 잊고 싶을 정도의 내용도 있더군요. 우선 저는 Agile Testing을 우선적으로 골라서 들었습니다. 이 세션은 Agile Testing의 첫번째 세션이었고 Bob Galen이라는 후덕한 아저씨 풍모를 지니신 분이 발표하셨는데 발표 내용은 정말 좋았습니다. 기억에 남는 것은 첫번째는 애자일에서는 테스팅과 개발의 균형이 굉장히 중요하다고 강조했습니다. 때문에 테스팅 전략, 계획이 없는 애자일 개발은 의미없는 테스트 자동화로 인해 위험하다고 얘기했습니다. 두번째는 테스팅 전략과 계획에서 우리가 제품을 제대로 만들고 있느냐가 아니라 우리가 고객이 원하는 제품을 만들고 있는가에 대한 테스트를 수행할 수 있도록 고려해야한다고 얘기했습니다. 세번째는 고객이 원하는 제품을 만들기 위한 애자일 품질 정책의 3가지 기둥(원칙??)으로 1. 개발과 테스트 자동화 2. 소프트웨어 테스팅 3. Cross-Functional Team Practices 를 얘기했습니다. 결론적으로 모든 팀이 품질에 대한 책임감을 가져야 한다는 것이었습니다. 그리고 이러한 것들을 지속적으로 평가하고 재교정함으로써 지속적인 개선을 해나가야 한다는 것이었습니다. 네번

그 숫자는 결제 금액이 아닌 상품 이름입니다. 고객님..

고객님 의 전화. 자신은 만원어치 물건을 주문했는데, 우리에게 수십만원이 결제되었다고 문자메시지가 왔다는 것이다. 알고 보니 구입한 상품 이름이 숫자로 된것이었다. 예를들어 문자 메시지가 "OOO고객님게서는 567890를 주문하셨습니다"라는 식으로 나간것. 저런 숫자를 보고, 자신의 주문한 상품이름과 같다는 생각을 안하고 결제 액수라고 생각해 화를 내며 전화한 것이었다.... 내 설명을 듣고는 고객은 서둘러 인사하고 전화를 끊으심.

확인을 눌렀지만 내용은 읽지 않았다.

고객이 배송이 8일 걸리는 상품을 주문해 놓고, 다음날 왜 배송이 안되냐고 문의함. 배송이 8일 걸리는 수입상품임을 안내하자, 고객은 몰랐다고, 왜 안알려줬냐고 투덜댐. 그런데 이런 상품은 주문과정에서 배송에 걸리는 기간을 3번이나 안내하고, 경고(alert)뜨고, 필수로 동의하는 과정도 거친다....는 점을 확인시켰다. 주문후 내역에 배송예상일자도 표시된다. 그랬더니 고객님이 하신 말씀. "저는 확인 버튼만 눌렀지 내용을 못봤단 말이에요. 이런 중요한 것은 고객이 인식할때까지 계속 확인시켜줘야 하는거 아닌가요?" ....인식할때까지? 고객님이 무한루프를 요구하십니다? ----- 우리나라에서 수년간 액티브 엑스로 떡칠된 사이트로 사용자들을 훈련시킨 결과죠.. 누가 약관을 읽기나 하나요? 보안 경고 메시지 읽기나 하나요? 해결책은 멀까요? 흠..

눈이 온다고 배송 지연이 되면 안되죠..

지역감정 조장이나 차별 같은 의도는 아닙니다만....강원도 분들은 눈이 오니까 그러려니 하고 계신듯 한데, 일부 경상도 분들은 배송지연에 대해 항의전화를 하시는군요. 그깟 눈가지고 물건 안보내주냐는 식으로 눈을 무시하는(?) 말씀도 하시고. 평소에 눈이 잘 안오는 지역이라 택배가 멈춘 경험이 없으셔서 그러신듯.

음....

여성분 전화 "안녕하십니까. OOOO사의 AAA부 XXX팀 BBB라고 합니다. 다름이 아니라 귀사의 사이트에서 회사 동료가 작년에 가입하여 업무에 사용중인 아이디가 있습니다. 동료는 현재 출장중이라 자리를 비운 관계로 현재 제가 그 일을 해야 하는 상황입니다. 따라서 아이디와 비밀번호가 필요합니다. 그런데 귀사에 가입한 아이디는 개인회원으로 가입한 것이라 타인에게 아이디와 비밀번호를 알려줄수 없는 것으로 사료됩니다. 그래서 저희가 무슨 증명서를 보내드리거나 해서 아이디를 알수 있는지 알고 싶습니다. 혹시 절대로 타인에게 알려줄수 없는 것이라해도 저희는 이해합니다. 가능한지요?" ........-_- 나 : "안됩니다." 여성 : "알겠습니다. 감사합니다" 전화 끊음. 말투가 무슨 로봇 같았음.....직장의 신이나 수상한 가정부를 너무 심취한 여성인가.

기계가 인간을 대신할 수 있는가? - 로보캅(2014)

얼마전에 새로나온 로보캅을 봤습니다. 원작을 기억하시는 분들은 괴작이라는 평부터 그냥 그런데로 볼만했다라는 평까지 온갖 평이 난무하던 리부트(리메이크) 로보캅인지라.. 그냥 아무 생각없이 보았습니다. 저도 원작인 로보캅을 1편부터 3편까지 봤던 사람이지만 제 개인적으로는 새로 만들어진 로보캅도 꽤 잘 만든 작품으로 생각됩니다. 막장으로 치닫던 3편에 비하면 준수하죠.. 1편에 비하면 글쎄요.. 시대가 변해서 로보캅이 뛰어도 댕기고 액션도 펼치니 머.. 큰 불만은 없습니다. 다만 이 영화를 보고 그동안 별 생각이 없던 주제 하나를 다시 생각해보게 되었습니다. 원작인 로보캅은 모든 것이 민영화된 세상에 좀 더 초점을 맞췄다면 새로 만들어진 로보캅은 그런 사회적인 내용은 많이 약해지고 대신 인간과 기계에 대해 좀 더 초점을 맞추고 있습니다. 전체 내용 중 가장 기억에 남는 것은 효율, 신뢰 이런것들을 내세우면서 기계가 법을 집행하는 것이 더 낫다고 강변하는 뉴스(버라이어티쇼?)가 계속 나옵니다. 그냥 그 뉴스만 보고 있으면 정말 그럴 거 같다는 생각이 듭니다. 기계는 실수가 없고 인간의 그 끈끈한 정 같은것도 없죠.. 돈으로 매수할 수 있는 것도 아니고요.. 그런데 로보캅이 그런 생각이 틀렸다고 얘기합니다. 만약에 법을 집행하는 그 로봇의 소프트웨어를 만든 사람이 로보캅에게 프로그램했던것처럼 자신에게는 예외 조항을 두면 어떻게 될까요? 아마 그 로봇을 만든 사람은 권력층일텐데.. 그러한 권력층이 어떤 위법행위를 저지르더라도 수사를 하거나 체포를 할 수 없게 되겠지요.. 결국 정의를 구현하기에 만들어진 로봇으로 보이지만 실상은 권력층을 보호하는 완벽한 방어막이 될 수 있다는 겁니다. 만약 이런 소프트웨어를 테스트하게 된다면 테스터는 이러한 문제를 어떻게 처리해야할까요?(직업병이로구나..) ISTQB에서는 고객과 회사의 이익을 보호하며 공공의 이익에 위배되지 않도록 테스터는 윤리적인 행동을 해야한다고 이야기하는데

STAREAST 참관기 - Testing in the Age of Distraction: Flow, Focus, and Defocus in Testing

두번째 키노트인 'Testing in the Age of Distraction: Flow, Focus, and Defocus in Testing' 입니다. Zeger Van Hese 란 분의 발표였습니다. 이 키노트는 첫번째 키노트에 비해서 좀 아쉬운 키노트였습니다. 움.. 머랄까? 임팩트가 부족하다고 할까요? 첫번째 키노트를 너무 열정적으로 들어서 그럴수도 있고 결론적으로 키노트의 내용이 이틀동안 튜토리얼에서 들었던 Rapid Software Testing과 내용이 거의 동일해서 그럴수도 있습니다. 하지만 특이하게도 PT를 Prezi로 만들어와서 굉장히 특색이 있었습니다. 중간 중간 동영상 활용도 꽤 많은 인터렉티브한(영어를 웬만하면 안쓸려고 해도 쉽지 않네요..) 발표였습니다. 발표자료는 http://prezi.com/jpqhbabuheqc/ 에서 보실 수 있습니다. 어쨌든 제가 기억하는 핵심적인 내용은 아래와 같습니다. 첫번째는 멀티태스킹은 좋지 않다. 단순화하고 집중하라. 두번째는 소프트웨어 테스팅은 혼란스럽고 복잡한 환경에서 수행된다. 이런 환경일수록 기존의 테스팅 방법이 아닌 창조적인 방법이 필요하다. 창조적인 생각에는 시간이 필요하다. 즉, 천천히 생각하는 것이 중요하다. 시간이 중요한 측정 지표이다. 고로 세션 기반 테스트 매니지먼트가 좋다. 세번째는 비판적 사고와 창조적 사고의 균형이 중요하다는 것이었습니다. 이 세션을 포함해서 이번 STAREAST 컨퍼런스에서는 Rapid Software Testing의 탐색적 테스팅과 세션 기반 테스팅 관리를 강조하는 세션이 꽤 많았습니다. 제가 그런 세션만 골라 들어서 그럴 수도 있지만 애자일 개발 방법론이 대세가 되다 보니 관련해서 Rapid Software Testing도 덩달하 강조되는 것 같았습니다. 반면에 우리 나라는 글쎄요.. 예전에도 한번 관련 글을 적었던 것 같은데.. 창조적인 테스터를 위한 문화적인 준비가 되어 있는

연휴에는 저희도 쉽니다.

설연휴 이브(?)...즉 연휴 전날밤 11시가 지나가고 있는 이시간에. 급하니 빨리 처리해 달라면서 견적서와 관련서류들을 발급해달라는 고객님이 있네. 어이쿠 감사합니다....최대한 빨리 5일후에 처리해드리겠습니다.

저희는 명의 도용을 하지 않았습니다. 고객님..

어떤 사람의 전화. 스마트택배 앱에 본인이 주문하지도 않은 우리 쇼핑몰에서 배송하는 내역이 조회되었다고. 주문자, 전화번호, 주소...다 본인이 아니란다. 그 사람의 개인정보는 우리회사 서버에도 없다. 우리는 스마트 택배 앱이나 택배회사의 오류인것 같다고, 그쪽에 알아보셔야 할거 같다고 안내. 그 사람은 우리가 관리를 잘못한거나 도용한거 아니냐고 주장....하며 우리보고 알아내서 보고를 하란다 -_- 우리한테 권한이 있지도 않은 개인정보를 어떻게 내역을 알아내냐고, 그거야 말로 불법이라고 설명을 했지만 막무가내. 미치겠네.

STAREAST 참관기 - Principles Before Practices: Transform Your Testing by Understanding Key Concepts

이틀간의 튜터리얼이 끝나고 삼일째 일정이 시작되었습니다. 본격적인 컨퍼런스가 시작되는 날로 이번 참관기는 컨퍼런스 첫날 키노트에 대한 내용입니다. 참고로 STAREAST에서 굉장히 인상 깊었던 것은 거의 모든 키노트의 내용이 비슷한 내용이었는데, 요약하자면 컨퍼런스에서 발표되는 내용을 듣지만 말고 돌아가서 반드시 실천하라는 내용이었습니다. 그리고 발표되는 내용이 모두 옳은 것은 아니니 실무에 돌아가서 많이 고민하고 연습하기를 바란다는 그런 내용들이더군요. 우리 나라의 경우 모든 컨퍼런스가 주제에 맞춰 특정한 내용을 전달하는데 급급하고 키노트의 경우에는 별 상관 없는 유명한 사람들(정치가나 머 그런 사람들 포함해서)의 뜬금없는 이야기를 듣는 경우가 많은데 이틀동안 총 5개의 키노트 세션이 듣고 고민하고 적용하라는 내용을 계속 강조하는 내용들이었습니다. 참으로 인상적이었습니다. 어쨌든 첫번째 키노트의 참관기입니다. 이 키노트에서 기억에 남는 내용은 아래와 같습니다. 발표자가 Randy Rice 라는 분이었는데, ASTQB(ISTQB의 미국 지부??)의 officer더군요. 첫번째는 테스팅은 정황에 의존적이라는 내용이었습니다. 정해진 규칙은 없으니 정황을 최대한 고려해서 테스팅을 수행하라는 것이었습니다. 많은 사람들이 컨퍼런스에 오면 정해진 규칙을 찾고 빠른 시간안에 전문가가 되는 방법을 찾는데 그런건 없다. 정황을 고려하라는 내용이었습니다. 그리고 진정 전문가가 되기를 원한다면 3가지가 필요하다고 했습니다. 첫번째는 지식인데 그런 이 컨퍼런스에 와서 얻을 수 있다. 하지만 중요한것은 그 지식에 대한 충분한 연습이고(이것이 두번째) 수많은 연습을 통한 경험(이것이 세번째)이라고 했습니다. 그래서 반복이 좋다라고 얘기하더군요. 두번째는 ISTQB의 테스팅의 7가지 기본 원리를 간단하게 소개하면서 이것이 전부가 아니라 다른 더 많은 원칙들이 있을 수 있다고 했습니다. 대표적인 것이 모든 테스트를 자동화 할 수 없

조삼모사...

일본의 한 부품 공급업체가 신정에 1주일간 휴무라서, 연말에 그 업체의 부품들 배송소요일을 임시로 1주일에서 2주일로 늘렸다. (하루에 1일씩 소요일 줄여나감) 그러자 한 고객이 자신이 사려는 상품 배송일을 왜 갑자기 늘리냐며 항의하길래 사정을 설명해드렸다. 그 고객은 알았다고 한 다음, 1월 3일에 주문했고, 우리는 1월 6일에 원래대로 배송소요일을 1주일로 줄였다. 그리고...그 고객이 다시 자신이 주문하고 나서 배송소요일을 다시 줄이면 불공평하다고 항의. ....기억력이 나쁘신건지, 이해를 못하신건지...

제가 아는 사람의 아이디와 비번 좀 알려주세요.. / 왜요?

고객 : "아이디와 비밀번호를 몰라서요" 나 : "성함이나 전화번호를 알려주세요" 고객 : "이름은 XXX이고, 전화번호는 모릅니다" 나 : "네? 전화번호를 모르신다고요? 본인이신가요?" 고객 : "아닙니다. 본인에게만 알려주나요?" 나 : "....당연히 본인만 알려드립니다. 남의 아이디와 비밀번호를 막 알려드리면 큰일나죠. 아이디 주인과 어떻게 되시는데요?" (전화번호도 모르면 가까운 사이는 절대 아니겠지....) 고객 : "그냥 아는 사람입니다." 나 : "본인이 전화주셔야 아이디와 비밀번호를 알려드립니다" ....일주일에 2,3번정도 이런 전화가 걸려옴. -_-

둥글게 둥글게...

어느 공대 교수라는 고객의 전화. 사이트를 사용하면서 불편한 점을 개선을 요구하는데, 좀 어거지스럽고 애매하게 말하는 것이었다. 어째튼 내가 요점을 뽑아 확인했다 나 : "그렇다면, 말씀하시는 문제가 견적요청하신 것을 삭제하실 수 있게 해드리면 해결되는 건가요?" 그러자 그 교수는 "중요한건 그게 아니고..." 하면서 또 장황하고 둘러서 이야기를 하기 시작했다. 불편이라는 것의 개념이나 사용자 경험이니 뭐니 아주....살을 덧붙였지만... 나 : "지금 말씀하시는 것도 같은 것 아닌가요? 견적요청 목록을 삭제할 수 있게 하면 해결되는 거죠?" 그러자 그 교수는 또 다른 개념을 이용해서 다른 설명을 하기 시작했다. 그런데 가만히 듣고 있으면 같은 이야기다. 이렇게 십여분을 통화했는데 슬슬 성질이 나기 시작했다. 다른 직원의 사내 메신저로 전달하기를 '같은 말을 돌려가며 계속 하는 이상한 사람이니 그냥 끊는게 좋다' 라고... 아무래도 상대방의 말을 인정하기 싫어하는 타입? 나 : "저, 잠시만요. 견적요청을 삭제 가능하게 해드리면 지금까지 말씀하신 것중에 해결 안되는 것이 있나요?" 교수 : "그렇게 해주시면 제일 좋지요. 하지만 제가 불편하면 굳이 여길 안쓰고 다른 쇼핑몰을 쓸수 있지만 제가 이런 말씀을 드리는 이유는 사용자가 불편을 느꼈을때 가질수 있는 심리적인...." 끝이 안남...

STAREAST 참관기 - Critical Thinking for Software Testers

STAREAST 2일차입니다. 2일차에는 하루종일 진행되는 'Critical Thinking for Software Testers'를 들었습니다. 우리 나라 말로 하면 비판적 사고라고 할 수 있습니다. 하루 종일 참여한 사람들이 질문을 하면 바크가 대답을 하는 식으로 세션이 진행되었습니다. PT와 함께 바크가 이야기하는 경우는 PT의 내용을 참조해서 바크의 이야기를 알아듣기가 용이한데 참여한 사람들과의 토론(?)이 주가 되다 보니 참여자의 얘기는 정말 듣기 힘들더군요. 바크도 점점 말이 빨라지면서 세션을 진행하는 공간의 분위기는 후끈한데.. 저는 점점 사색으로 변해가며 식은땀이.. ㅠㅠ 오전은 어떻게 어떻게 들었는데.. 오후에는 점점 머리가 멍~~ 해지더군요.. 그런 의미로 이번 후기는 그다지 쓸 얘기가 많지 않습니다. 다만 이 세션의 핵심은 이것이었습니다. 바크가 참여한 사람들에게 던지는 질문과 참여한 사람들이 던지는 질문에 대한 대답도 이것이었습니다. 그것은... 다른 관점에서 생각하는 것이었습니다. 이와 관련해서 질문을 하는 기법에 대해 꽤 많은 시간이 할애되었습니다. 대표적인 질문이.. 왜 그런가요? 이렇게 생각할 수 있지 않나요? 정말 그렇게 확신합니까? 그것을 어떻게 증명할 수 있습니까? 머 이런 질문들이었습니다. 결론은 테스터는 테스트를 수행하면서 끊임없이 비판적으로 생각하고 질문을 만들어내야한다는 것이었습니다. 제품에 대한 이해와 테스트의 완성도를 높이기 위해서 끊임없이 생각하고 질문하는 활동을 반복해야한다는 것이었습니다. 보이는 것이 전부가 아니기 때문에 그 이면에 대한 끊임없는 탐구를 멈추지 말라는 것이었습니다. 테스팅은 곧 비판적 사고이다. 제품이 정상동작하는지 단순히 명세를 확인하는 것 이상의 문제를 찾는 탐색의 과정이 테스팅이라는 것입니다. 단순히 명세를 확인하는 것은 테스팅이 아니라 체킹이라고 하더군요. 그리고 이러한 문제를 예측하고

내가 사려는 물건이 첫 페이지에 왜 없는겁니까?

고객 : "OOO라는 상품을 사려고 하는데, 왜 쇼핑몰 첫페이지에 소개되어 있지 않나요?" - 첫페이지에는 아무래도 저희가 홍보하고 싶은 것이 배치되게 마련이어서 그렇습니다. 고객 : "그래도 고객이 사려고 하는 상품을 배치해야 옳죠. OOO 같은. 그쪽 회사에도 그게 더 이익이 될겁니다." ....그건 맞는 말씀인데, 그 상품은 아저씨만 살거 같음...

고객님 컴퓨터에 있는 사진을 어떻게 보나요?

고객에게서 첨부한 사진에 나와 있는 부품을 구하고 싶다고 이메일이 왔는데 사진 경로가 C: 드라이브 경로의 jpg 임. -_- ----- 나이 드신 분 중 정말 많은 분들이 네트워크에 대한 개념을 이해를 못하시더군요. 내 컴퓨터와 웹 서비스가 분리된 것이라는 걸 종종 이해못하시는 분들이..

STAREAST 참관기 - Rapid Software Testing: Reporting

제가 두번째로 들은 세션은 보고서에 관련된 세션이었습니다. 처음에 세션을 신청하고 기대했던 것은 문서 양식이나 문서에 적을 내용에 대한 예시나 예제 같은 걸 기대했었는데...(우리 나라 대다수 사람들이 교육이나 세미나에서 항상 기대하는...) 세션을 듣고 나서 그런걸 기대한 제 자신이 조금은 부끄러워졌습니다. 그리고 RST를 잘하기 위해서는 글도 잘 써야 하는데.. 저는 작문 실력이 미천해서 참.. 답이 안보이는 그런 부끄러운 마음이 들었습니다. 작문 수업을 어디서 체계적으로 받든지 해야 할 것 같습니다. 이 보고서 세션에서 제가 가장 인상깊게 들은 내용들은 아래와 같습니다. 첫번째는 보고서는 신뢰할 수 있도록 작성되어야 한다는 것이었습니다. 너무나 당연한 이야기인데, 다른 관점에서 과연 내가 작성한 테스트 보고서 나아가서 내가 수행한 테스트를 과연 고객이 신뢰하는가? 신뢰를 얻기 위해 나는 무엇을 했는가?에 대해 많은 고민을 하도록 해주는 내용이었습니다. 우리는 일반적으로 신뢰받는 보고서를 작성하기 위해 숫자를 많이 사용하고 보고서 두께를 두텁게 만드는 경향이 있는데 이게 다 부질없는 짓이더군요. 그런다고 신뢰가 쌓이는 것은 아닌데 말이죠.. 바크의 얘기로는 내 테스트가 내 보고서가 신뢰받지 못한다는 몇가지 징표가 있답니다. 첫번째가 의사결정권자가 자신들에게 불편한 정보는 들으려 하지 않는답니다. 두번째가 의사결정권자가 테스터들이 중요한 정보(surprising information)을 숨긴다고(mistaken) 가정한답니다. 세번째가 테스터들이 리스크(문제)에 대해서 과장한다고 가정한답니다. 네번째가 테스트 보고서를 세세하게 관리하려고 한답니다. 듣고 보니 과연 고객들이 나를 얼마나 신뢰하는지 돌아보게 되더군요. 닭이 먼저냐? 달걀이 먼저냐? 의 문제이긴 한데 신뢰를 잃으면 관리자는 테스트를 세세하게 정량화해서 관리하려고 하고 그렇게 되면 테스트는 더욱더 수렁으로 빠져들고 그렇게 되면 신뢰는 더욱더 떨어지고

배보다 배꼽이 더 큰 딜.. 택배 요금을 생각하지 못하셨군요.

고객의 제품 교환 소동. 학생 고객이 상품을 구입하면서 500원을 더 입금했음. 배송후 남은 500원을 입금해줄 계좌를 물었는데 자신이 같은 가격의 다른 상품을 주문해야 하는데 잘못 주문했다고 함. 그러면서 500원을 받지 않을테니, 대신 반품과 교환을 해달라고 딜을 걸었음 -_- 택배 왕복은 2500x2 원이여......

아들과 나는 일심동체..

고객전화.... 고객 : "제 아들이 주문을 했는데 언제 배송될까요" 나 : "아이디가 어떻게 되시나요" 고객 : "OOOOOO" 나 : "그 아이디로 주문하신건 이미 배송되었는데요?" 고객 : "그건 제가 주문한 것이고요. 아들이 주문하려고 합니다" 나 : "네? 그럼 OOOOOO는 고객님 아이디신건가요, 아드님 아이디신건가요?" 고객 : "제겁니다. 아들은 다른거 씁니다." 나 : "그럼 고객님 아드님 아이디를 알려주셔야 주문하신걸 찾아보죠" 고객 : "아직 주문 안했습니다." 나 : "네? 그럼 주문할 상품의 배송시일을 알고 싶으신건가요? " 고객 : "아뇨. 제가 입금은 했습니다." 나 : ".....네? 주문은 안했는데 입금은 하셨다고요?" 고객 : "네. 아이디가 OOOOOO인데 제 이름으로 입금했으니 지금 확인해주십시오" 나 : "입금 확인은 담당자가 할겁니다. 그런데 주문을 해주셔야 처리가 되요. 주문하실 아드님 아이디는 어떻게 되시는데요?" 고객 : "아이디가 OOOOOO입니다" 나 : ".....그건 아드님 아이디가 아니라면서요" 고객 : "제가 입금을 했습니다." 나 : ".........." 끝이 안난다. 미치겠다.......

내 개인 정보는 소중하니 명의 도용으로..

어떤 대학생이 물건을 주문해 놓고 전화번호를 엉뚱한 다른 사람 전화번호로 기재했다. 전화를 했더니 엉뚱한 사람이 받아서, 왜 자기에게 그 사람을 찾냐고 화를 내고있더라. 주문한 학생은 나중에 연락이 닿았는데 '일부러' 그랬다고. 이유는 '그냥'. 뭔짓이지? 원하지 않는 남의 전화를 받은 사람의 반응을 봐선, 하루이틀 일이 아닌거 같은데. ----- 이런 경우에는 콩밥을 먹여야 하는거 아닌지..

팩스 번호로 고객 문의 하시면 어떡합니까?

화가 난 고객의 전화 고객 : "이 전화번호는 받네? 왜 홈페이지에 써진 전화번호는 전화해도 안받나?" 나 : "아, 죄송합니다. 상담원이 전부 통화중이었나 봅니다" 고객 : "통화중이라고도 안나오고 삐익삐익거리기만 하던데? 나 : "네? 몇번으로 거셨는데요?" 고객 : "홈페이지에 나와 있는걸로 걸었다고! 861에 몇번이라고 나온거. 사람을 의심하고 그래! 내가 눈으로 본 번호도 잘못 걸었을까봐!" 버럭 소리를 지르는 고객. 나 : "저...그거 팩스번호입니다"

결제창에서 회원 가입이 안되넹...

나이드신 고객의 전화 문의 고객 : "회원 가입을 하려고 하는데, 여기에 주민등록번호를 넣어도 안맞다고 나오네?" 나 : "그런가요? 저희 사이트는 회원가입할 때 주민등록번호를 넣는 곳이 없는데요? 저희 엘XXX 웹사이트에 들어오신거 맞나요?" 고객 : "맞아. 그런데 인증이 안된다고 나와서 가입이 안되" 몇가지 더 확인을 했는데, 계속 회원가입하고는 동떨어진 이야기를 하신다. 나 : "현재 화면에 뜬 글자들을 읽어주시겠어요?" 고객 : "신한 스마트 결제, 신한카드를 이용해주셔서 감사합니다. 결제 아이디, 주민등록번호....." 회원 가입이 아니라 결제창이었다... -_-

고객님 무얼 원하시는건가요?

비밀번호를 잊어버렸다는 고객의 문의 전화. 사투리와 전화 잡음이 심해서 알아듣기 힘든데다가... 나 : "아이디가 어떻게 되시나요?" 고객 : "그러니까, 내가 OOOOO이랑 XXXXX랑 AAAA랑 BBBB같은 부품을 사려고 사이트에 들어왔는데, 찾다보니가 하나가 없는거요 그래서 내가.... 어쩌구 저쩌구 이러쿵 저러쿵...." 하면서 사이트에서 방황한 사연을 한참 말하심.... 나: "저, 잠시만요, 비밀번호를 모른다고 하셨죠?" 고객 : "네. 그래서 그게 말이에요, 내가 아까 OOOOO이랑 XXXXX랑을 찾는데 말이지.....어쩌구 저쩌구 이러쿵 저러쿵...." ...... 나 : "저....그런 이야기보다요, 비밀번호를 찾으시려면 아이디나 성함을 알려주셔야 하는데요" 고객 : "내가 그래서 말하려고 안허요? 내가 찾는 물건중에 못찾은거시 아까도 말했지만 어쩌구 저쩌구...." .... 나 : "아이디만 말씀해주시겠어요? 아이디가 어떻게 되시나요?" 고객 : "ㅁㅁㅁㅁㅁㅁ" 나 : "그런 아이디가 없는데요?" 고객 : "그래요? 아이디 있을터인데? 내가 아까 장바구니에 DDDDDD상품을 넣었다가 말이죠....어쩌구 저쩌구 이러쿵 저러쿵...." ..........

토요일에는 근무 안하시나요?

회사에 와서 직접 물건을 수령하려는 고객의 전화. 고객 : "토요일은 근무합니까? 저희 회사가 토요일, 일요일에 쉬어서 그때 가려고요." 직원 : "토요일은 근무하지 않습니다" 고객 : "어떻게 안되나요? 꼭 토요일날 찾아야 하는데" 직원 : "죄송합니다. 토요일은 근무를 안해서요" 고객 : "네...하는 수 없네요" 하면서 전화를 끊으며 고객의 혼잣말인듯 이런 소리가 들리더라고 "무슨 회사가 토요일날도 일 안하냐" ----- 사람 마음이 간사한것이 저는 토요일에 근무하는거 안좋아하면서 막상 제가 필요할때는 불만이더라구요.. 흠흠

결제는 세금계산서로 해주세요!!

쇼핑몰 사이트를 이용 하던 고객의 전화 고객 : "주문하려는데 진행이 안되요. 세금 계산서 선택이 안됩니다." 나 : "결제방법은 무엇으로 하셨나요? 혹시 신용카드이신가요?" (신용카드는 따로 세금계산서를 발급 안함.) 고객 : "아뇨. 세금계산서요" 나 : "네? 세금계산서 말고 결제를 무엇으로 하시냐구요." 고객 : "세금계산서요. 결제를 세금계산서로 하려고요" 나 : "네?? 고객 : "여기에 신용카드, 무통장 입금만 나오고 세금계산서는 없어요. 세금계산서로 계산하려는건데." 나 : "....." ...멍... .이 여자분, 뭔가 4차원이다...

아니 왜 확인도 안하고 세금계산서를 발행하는 것이오?

어이 없는 고객 항의. 전화한 사람의 부하직원이 우리 회사에서 물건 구입을 할 때, 전자세금계산서 발행 정보를 입력했고, 우리는 계산서를 발행했다. 그런데 그 상사라는 사람이 전화를 해서, 부하가 무단으로 입력한건데, 왜 확인도 안하고 세금계산서를 발행했냐고 따짐. 자기네들이 잘못한걸 왜 우리 보고 화내나? 그리고 하루에 수백건씩 처리하는걸 전화해서 '이거 정말 발행하려고 입력한거냐. 상사 허가는 받았냐'고 확인하라고? (진짜 하나하나 확인하고 발행해야 한다고 주장하심...) -_-

STAREAST 참관기 - Rapid Software Testing Strategy

지난 5월 5일부터 5월 8일까지 4일동안 세계에서 가장 큰 소프트웨어 테스팅 컨퍼런스라 일컬어지는 STAREAST 2014에 다녀왔습니다. 남들에게는 황금 연휴였고, 그 연휴기간동안 가족을 내팽개치고 다녀온 컨퍼런스였습니다. 회사 지원으로 다녀온 컨퍼런스였기 때문에 가족을 챙길 여력은 없었는데 가보니 가족과 같이 왔더라면 정말 좋았겠다라는 생각이 들더군요. 씨랜드, 유니버셜 스튜디오, 디즈니랜드까지 돈만 있다면 정말 놀기에는 최적화된 곳에서 컨퍼런스가 열렸습니다. 컨퍼런스가 열린 곳이 바로 플로리다의 올랜도라는 도시였습니다. 플로리다에는 마이애미만 있는 줄 알았고, 올랜도는 자동차 이름인줄 알았는데.. 하하하하.. 어쨌든 4일간 제가 들었던 몇몇 세션들과 튜토리얼에 대해서 제가 느낀 내용을 간단하게 블로그에 기록으로 남겨보고자 합니다. 갔다온 내용에 대한 발표는 STEN에서 진행되는 세미나에서 나누거나 아니면 듣고 싶으신 분들이 자리를 마련해주시면 나눠보도록 하겠습니다. 컨퍼런스는 크게 2~3일간의 교육과 2일간의 튜토리얼 그리고 2일간의 컨퍼런스로 구성되어 있습니다. 전체 일정과 주제는 http://stareast.techwell.com/schedule/grid 에서 보실 수 있는데, 후에 URL이 변경될 것 같습니다. 아마 내년쯤?? 저는 2일간의 튜토리얼과 2일간의 컨퍼런스에 참여했습니다. 튜토리얼에는 다양한 세션들이 준비되었는데 저는 먼저 제임스 바크의 'Rapid Software Testing Strategy'를 들었습니다. 5~6년 전인가 바크가 한국에 와서 강연했던 내용에서 많은 부분 변화가 있었습니다. 이번에 바크에게 직접 새로 들어보니 제가 잘못 이해하고 있던 부분도 있었고, 기억이 새록 새록 되살아나는 것이 정말 좋은 시간이었습니다. 그 중에 저에게 가장 뚜렷하게 각인된 몇가지만 공유하도록 하겠습니다. 첫번째는 왜 전략을 강요하는가에 대한 내용이었습니다. 일반적으로 많은 경우