기본 콘텐츠로 건너뛰기

쓸모 없는 구글 드라이브 관련 미립자 팁..

제가 사는 아파트는 지역난방입니다. 난방비는 유량을 기준으로 계산되는 방식입니다. 지난 달에 이사하고 지역난방에 대한 이해가 전혀 없는 상태에서 난방을 하다가 난방비만 50만원이 나오는 폭탄을 맞았습니다. 그래서 최근에는 매일 매일 유량을 확인하면서 춥게 살고 있습니다. 아파트가 정말 최악중의 최악이라서 단열 자체가 안됩니다. 제 블로그를 보신 분은 아시겠지만 지은지 이제 겨우 20년된 아파트의 샷시가 어찌나 부실하던지 외풍 차단 자체도 안됩니다. 정말 올해 겨울에는 단열도 안되고 외풍도 심한 아파트에서 난방비를 아끼기 위해 정말 눈물겹게 보내고 있습니다.(사실 난방의 의미는 거의 없다고 보아도 무방한 환경입니다.) 이런 곳에서 앞으로 얼마나 더 살아야할지 생각하면 더 눈물납니다. ㅠㅠ 어쨌든 그래서 매일 매일 유량을 체크하고 가상의 난방비를 계산하는 시트를 구글 드라이브에 만들어서 매일 매일 쓰고 있습니다. 그런데 아내님께서 이왕 만든거 매일 매일 기온을 알면 기온에 따라서 얼마나 더 쓰고 덜 쓰는지 알 수 있지 않겠느냐는 특명을 내리셨습니다. 그래서 어떻게 하면 자동으로 매일 매일의 기온을 구글 드라이브에 자동으로 입력시킬 수 있을가(머.. 매일 매인 손으로 입력하는 것도 방법이긴 합니다. 어차피 매일 유량도 수작업으로 기록하고 있으니까요.. 하지만 저라는 사람.. 워낙에 게을러서 입력값이 하나에서 최저기온, 최고 기온을 포함한 3가지로 늘어나는것이 너무 귀찮아서..)를 고민한 결과를 간단하게 공유해볼까 합니다. 도데체 이런 팁이 어느 분에게 도움이 될지는 모르겠지만.. 그래도 알아두시면 좋을 2가지 팁을 공유합니다. 첫번째 팁은 매일 매일의 최저 기온과 최고 기온을 자동으로 얻어오는 방법입니다. 프로그래밍을 좀 하실 수 있는 분, xml 데이터를 좀 다룰 줄 아시는 분은 아주 쉽게 기상청이나 다른 기상 예보 사이트에서 xml을 분석하셔서 해당 데이터만 파싱해서 불러오는 방법이 있습니다만.. 저는 그런 거에 까...

메트릭.. 그거 측정해서.. 뭐할라고? (대부분의 메트릭은 쓸모없다.)

2009년부터 4년 넘게 이 공간에 쓸데 없이 주절 주절 소프트웨어 테스팅과 관련이 있다고 생각하는 글을 137편을 끄적거렸습니다. 매달 2편 정도의 글을 썼습니다. 그다지 많이 쓰지도 않았는데.. 이제는 예전에 제가 무슨 글을 썼는지 잘 기억이 안납니다. 이 블로그 서비스는 구글이 제공하는 서비스임에도 불구하고 검색 기능은 아주... 엉망인지라... 지금 쓰고자 하는 이 글도 예전 언젠가 썼었던 기억이 있는데.. 아무리 찾아보아도 아니보여서 다시 써봅니다. 이번에 제가 얘기하고 싶은 주제는 메트릭입니다. 우리는 소프트웨어를 개발하고 테스트를 진행하면서 제품의 품질과 테스트의 진척을 판단하기 위해 꽤 많은 메트릭을 사용하고 있습니다. 결함 갯수, 수정된 결함 수, 잔존 결함 수, 결함 수정 기간, 작성된 테스트 케이스 수, 품질 지표, 실행된 테스트 케이스 수, 실패한 테스트 케이스 수 등등등... 정말로 많은 메트릭 종류가 있습니다. 그리고 이러한 메트릭을 기반으로 사람을 평가하고 제품을 평가합니다. 많은 조직에서는 좀 더 의미있는 메트릭을 수집하고자 매우 많은 노력을 하고 있습니다. 그래서.. 그 많은 메트릭을 수집하셔서 품질이 좀 나아지셨습니까? 테스터의 역량이 향상되셨습니까? 개발자로부터 유입되는 결함은 좀 줄어드셨나요? 물론, 괄목할만한 성과를 얻는 조직도 있습니다. 하지만 많은 조직은 분명 열심히 하고 있다고 생각하는데 성과는 높지 않습니다. 그리고 더 나은 메트릭을 찾아서 킬리만자로의 표범처럼 헤메이고 있습니다. 자.. 더 나은 메트릭을 찾아 헤메기 전에 왜 나아지지 않는 것일까요? 수집하는 메트릭이 좋지 않아서일까요? 잘못된 메트릭을 수집하고 있어서 그런걸까요? 결론적으로는 메트릭을 수집하기 때문에 그렇다고 볼 수 있습니다. 어쩌면 메트릭을 수집하지 않음으로 인해 더 나은 경험을 해보실 수도 있습니다. 이 무슨 해괴한 이야기인가 싶으신가요? 관리자는 숫자에 대한 맹신과...

소프트웨어 테스트 설계 잘하는 법(?) - 10년차 야매 테스터의 꼼수

테스터로 사노라면 참 쉬운일이 하나도 없습니다. 물론 요구사항 수집, 분석, 정의하고 설계하고 개발하는 모든 일이 쉬운게 없습니다. 사람마다 차이가 있겠지만 테스트를 하다보면 가장 막막한 것이 얼마나 테스트를 해야 충분한걸까? 나는 테스트를 잘 하고 있는걸까? 테스트 케이스는 어떻게 만들어야 하는걸까? 결함을 어떻게 하면 잘 발견할 수 있을까? 머.. 이런것이 아닐까라고 생각해봅니다. 비슷한 질문은 수없이 많겠지만 결론적으로 말해보면 커버리지(테스트의 충분함)은 테스터의 영원한 숙제가 아닐까 합니다. 모든 경우를 고려한 테스트가 불가능하다는 것은 이론적으로 체험적으로 이미 아는 사실이고.. 그렇다면 어떻게 테스트를 하면 충분한 테스트일까요? 어떻게 테스트를 해야 발 뻗고 잠이 들까요? 도데체 어떤 테스트를 해야할지 어떻게 결정할 수 있을까요? 이런 고민을 해결하고자 혼자서 공부도 해보고 교육도 들어보고 컨설팅도 받아보지만 딱 부러지게 맘에 드는 해답이 없는게 현실이 아닌가 싶습니다. 그래서 이제 10년차가 된 야매 테스터(전 소프트웨어 공학을 전공한적도 없고.. 남들 다 있다는 석/박사 학위도 없습니다.)의 꼼수를 알려드릴까 합니다. 물론.. 미천한 저의 경험이기 때문에 도움이 많이 되시지 않으시다면 저에게 가르침을 주시면 고맙겠습니다. 자.. 먼저 생각해볼 것은 왜 그렇게 우리는 테스트를 막연하게 생각하는 것일까요? 왜 무엇을 얼마나 해야할지 쉽게 결정을 내리지 못하는걸까요? 이 질문에 대답을 하기 위해서 필요한 것이 소프트웨어란 무엇인가입니다. 知彼知己 百戰不殆 不知彼而知己 一勝一負 不知彼不知己 每戰必敗 (지피지기 백전불태 부지피이지기 일승일부 부지피부지기 매전필패) 라고 손자병법의 유명한 구절이 있습니다. 적을 알고 나를 알면 백번 싸워도 위태로울 것이 없으나 나를 알고 적을 모르면 승과 패를 각각 주고 받을 것이며 적을 모르는 상황에서 나조차도 모르면 싸움에서 반드시 패배한다는 것입니다. 테스트를 잘 하기 위해서는...

아이디를 까먹었습니다. 알려주세요

이메일 내용이 '아이디를 까먹었습니다. 알려주세요' 이게 전부....하아... 상대방이 어떻게 아이디를 찾아낼지에 대한 고민은 전혀 없는건가. 발송 이메일 주소로도 검색 안되고, 이름이나 전화번호를 알려달라고 답장 보냈는데 이틀간 답도 없고.