'QA'에 해당되는 글 4건

  1. 2008.07.24 한메일 서비스 장애에 관한 단상 (2)
  2. 2008.07.23 SW Quality Insight 정기 세미나
  3. 2008.07.11 V3 대란에 대한 단상 (1)
  4. 2007.12.15 [A] first of QA A to Z
2008.07.24 01:45

한메일 서비스 장애에 관한 단상

7월 22일 발생한 한메일 서비스 장애에 관한 소식을 자주 방문하는 동호회 사이트를
통하여 간접적으로 듣게 되었습니다.
타인 계정의 메일 목록이 노출되어버리는 문제점이라고 하더군요.
사실 한메일을 사용하지 않는 저로서는 피해는 없었지만,
혹시나 하는 마음에 몇일이 지난 오늘에서야 다음에서 근무하시는 윤석찬님의 블로그를 방문했습니다.
솔직히 다음에서 노출되고 있는 장애에 관한 사과문보다는 좀더 기술적으로 접근이 가능하지 않을까하는
마음에 블로그를 검색하던 중  한메일 타인 계정 노출 사고 유감 이라는 글을 읽게 되었고, 이에
QA Engineer 입장에서 몇자 적어보려고 합니다.

1. 왜 작업을 평일 낮시간대에 하였는가?

   - 사실 이 부분이 가장 이해가 되지않는 부분입니다.
     사용자의 수, 사용 빈도수를 봤을때 사용량이 상당히 높은 시간일것입니다.
     보통 이런 작업들은 새벽시간 사용자들의 접속이 낮은 시간대에 해야하고,
     대부분의 기업들이 그렇게 하고 있습니다.
     특히나 로그인관련 부분이라면 각 서버별로 로그인 세션등을 고려했을때,
     모든 접속자의 세션을 끊어버리고 작업을 진행해야하는것이 정석이라 생각됩니다.
     정말 개념없는 행위입니다.
     아무리 사소한 부분의 업그레이드라도, 만약을 대비해서 배포가 실패하거나 오류가 발생하여
     RollBack(이전 상태로 되돌리기) 을 해야하는 상황까지 고려가 되어있어야합니다.
     결론적으로 전혀 고려가 되어있지않다는 결론입니다.

2. 배포 시간

"개발자 시각에서 객관적으로 봤을 때, 한메일 서버는 대략 수백 대가 넘고 특정 업그레이드를 배포하는데 시간에 따라 순차적으로 진행합니다. 따라서, 문제가 된 코드가 배포되는 중 사용자들의 어떤 서버가 어떻게 피해를 입었는지 파악하기 위해서는 물리적으로 시간이 필요 합니다. 게다가 문제를 발견했을 때 수정본을 배포하는데 걸리는 시간도 만만치 않았을 겁니다." from Channy

   -만약 이런 사실을 알고 있다면 더욱 사용자 접속을 막아놓은채 작업을 진행했어야합니다.
    개인적인 경험으로 봤을때, 각 서버로 배포하는데 그리 오랜 시간이 걸리지 않는것으로 알고 있습니다.
    물론 각 서버별로 순차적으로 반영을 하는것이겠지만, 오래 걸렸던것 같지는 않습니다.

3. 테스트는 충분히 이루어졌는가?

대개 프로그램 상에서 어떤 기능을 수행할 때 인증된 사용자 정보를 확인하고, 기능을 호출하게 되어 있는데 타인 계정의 메일 목록이 보였다는 것은 기능 향상 배포본에서 인증 기능을 실수로 빠뜨렸거나, 계정 정보를 받아오는 루틴에서 오류가 났거나 했을 것 같습니다. 타인 메일 목록만 보였다는 점에서 그런 가능성이 있습니다. (이것은 물론 회사의 입장이 아니라 개인적인 추측입니다.) from Channy

   - 차니님께서 말씀하신것처럼
      만약 배포본에서 인증 기능을 실수로 빠뜨렸다면 개발완료본과 배포본이 다르다는것입니다.
      형상관리가 제대로 이루어지지 않는다는 이야기이고, 배포본으로 테스트가 이루어지지않았다는
      이야기입니다.
      계정 정보를 받아오는 루틴에서 오류가 났다는 이야기는 프로그램 자체 오류일 수도 있고,
      테스트 서버와 실제 서버의 환경이 정확히 일치하지 않았을 수도 있다고도 생각 할 수 있겠습니다.
      그래서 항상 테스트 서버에서 테스트가 끝나면 실제 서버에서도 꼭 확인을 해야합니다.
      결론적으로 개발이 제대로 이루어지지 않았을뿐만 아니라 테스트도 제대로 이루어지지 않았다는
      이야기입니다.

본인이 특정 기업의 개발이나 QA에 관하여 뭐라고 평가하기에는 다소 무리가 있겠지만,
이전 V3 대란 이후로 다음이라는 큰 기업에서 이런 문제가 발생한것에 대해 다소 유감을 표명하는 바입니다.
이로서 품질보증을 위한 일련의 행위들이 얼마나 중요한 것인가를 다시금 생각해 볼 수 있는
좋은 기회가 아닐까 하는 생각을 해봅니다.

이전에도 중요성을 강조했지만, 이런 문제가 발생하게 되면 고객 혹은 사용자로 부터 신뢰를 잃게 됩니다.
품질은 곧 신뢰입니다.

결론적으로 충분한 테스트가 이루어지지 않았다는 생각이 들고, 문제가 발생했을 경우를 대비하는 부분이
미흡했다고 생각됩니다. 문제 발생을 예상했다면 적어도 낮시간대에 작업을 진행하지는 않았겠죠?
사용자를 배려하여 업그레이드를 진행했지만, 정작 사용자를 혼란스럽게 만들고 마는 결과를 초래했습니다.

앞으로 좀 더 철저한 품질관리가 필요할 것같습니다.

신고
크리에이티브 커먼즈 라이선스
Creative Commons License

Trackback 0 Comment 2
2008.07.23 10:40

SW Quality Insight 정기 세미나

사실 최근 QA관련 세미나 혹은 컨퍼런스등 많은 행사가 진행되고 있지만,
솔직히 부담이 되는 참가비때문에 회사를 다니고 있지않은 사람들에게는 부담이 되기 마련입니다.
간혹 무료로 진행하는 행사도 있어서 빠지지않고 참석하고 있습니다.
관심있으신분들은 참석해보시길...

물론 어디까지나 많은것을 바라지말고, QA에 관한 감을 잊지말자는 취지하에...

아래 신청하기 페이지로 이동하셔서, 회원가입 후에 신청하시기 바랍니다.

신청하기

SW Quality Insight 정기 세미나
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

Trackback 0 Comment 0
2008.07.11 10:52

V3 대란에 대한 단상

문제의 요지는 V3와 Win XP SP3간의 충돌문제였습니다.
V3 엔진이 운영체제 파일을 악성코드로 오인하여 발생한 문제더군요.

일단 V3 대란이 발생하게 된 원인을 살펴보고 싶습니다.
안랩의 테스팅 혹은 QA 관한 자세한 내용을 모르고 있기때문에,
뭐라고 말하기에는 조금 부족하겠지만...
일단 소프트웨어의 테스팅에 있어서 최소한 다양한 환경에서의 확인이 필요한 것은
당연한 이치인데, 아마도 이점이 부족하지 않았나 생각됩니다.

Windows XP SP3와의 호환성 내지는 최소한의 확인작업이 이루어져야한것은 당연한
일이겠죠?

일단 안랩에서의 사후조치는 잘한것이라고 생각이 들지만,
신뢰를 잃어버린것은 당연한 결과라 생각됩니다.

사용자들의 불편이 이만저만 아닌 상태여서 사후조치를 한들 사용자들이
이미 신뢰를 저버린 상태이기때문에, 신뢰를 회복하기에는 아마 오랜 시간이 걸릴것같습니다.

아무쪼록 피해를 입으신분들은 하루빨리 복구하셔서 예전 모습을 되찾으셨으면 합니다.

안랩 사과문

복구관련

무엇보다도 소프트웨어의 품질이라 함은 결론적으로 그 회사의 신뢰와 아무 밀접한 관계가 있다고 생각합니다.
따라서 소프트웨어의 품질 = 신뢰 라는 결론이 내려지는군요.
테스팅이나 QA활동의 전반적인 부분은 어떤 문제점을 찾아서 해결하기 위한 활동들이 대부분이고
이런 활동들이 결론적으로 그 회사의 신뢰를 높이는데 기여한다는 것입니다.
특히나 요즘은 다양한 사용자 환경속에서 어느부분에서 문제가 발생할지 예측하기 힘듭니다.
좀더 다양한 환경에서 테스팅이 진행되어야함은 물론이고 사용자에 대한 배려가 필요한 시기인것같습니다.

P.S
혹자는 이번 사태가 안랩쪽 문제만은 아니라고 하는군요. 거대한 음모가 뒤에 숨어있다는...
진실은 저 너머에...여기까지~ 더 알면 다쳐요~

신고
크리에이티브 커먼즈 라이선스
Creative Commons License

Trackback 0 Comment 1
2007.12.15 17:10

[A] first of QA A to Z

사용자 삽입 이미지
'A' 알파벳의 처음 Character 입니다.

 QA의 처음 혹은 기본이 무엇이라 생각하십니까?
정답이 없는 질문이지만, 한번쯤은 생각해봐야하는 부분임에는 틀림이 없으리라 생각합니다.
 대학교 2학년때로 기억됩니다.
스포츠과목이 있었는데, 그때, 테니스를 배웠습니다.
첫날부터 끝나는 날까지 기본 스윙만 배웠던것으로 기억합니다.
코트는 한번도 못들어가봤죠...ㅠㅠ
매번 벽에 공을 튀기면서 기본 스윙만 했고, 물론 실기시험도 벽에 공튀기기...그때 교수님께서는 공을 놓치지 않고 많이 튀기는것을 보시는것이 아니라, 스윙을 어떻게 하는지 평가하셨습니다. 교수님께서 강조하신것은 바로 기본이 되어야한다는 것이었습니다.
기본도 안되어있으면서 어떻게 코트에서 테니스를 할 수 있겠느냐는것이 교수님의 생각이셨습니다.
스포츠에서 가장중요한것은 바로 기본기입니다. 물론 어떤 일이든 기본이 되어있지않으면 그 다음으로 나아갈 수 없을것입니다.
 서론이 길었습니다. QA도 마찬가지입니다. 가장 처음, 기본이 되어있지않으면 원하는 만큼의 결과가 나올 수 없을것입니다.
버그를 많이 잡아 낼 수 있는 기술일까요? 아니면 QA의 이론을 많이 아는것일까요?
버그를 많이 잡아내려면 그것이 버그인지를 알아야합니다.
아무리 이론적으로 많이 안다고해서 그것을 실제로 모두 적용이 가능할까요?
여러분은 QA의 처음 혹은 기본이 무엇이라 생각하십니까?
개인적인 생각으로는 아는것 혹은 경험이라고 생각합니다.
 요즘 '아는것이 힘이다' 라는 베이컨의 말을 실감하고 있습니다.
물론 열정 혹은 열의가 없으면 안되겠죠.
하지만 열정 혹은 열의만 가지고 어떤 일을 할 수 있을까요?
아는것이라고만 말한다면 너무 막연합니다.
이론적인 부분을 포함하여 경험을 말하는것입니다.
개인적으로 경험주의 테스팅을 추구하는 사람중에 하나입니다.
어떤일을 하려고 할때 가장 주저하게 되는 원인중에 하나가 바로 모르기때문입니다.
하지만 일단 한번 알고나면 그다음부터는 쉬워집니다.
물론 어려워지는 경우도 생기기 마련이죠.
QA도 마찬가지입니다. 너무 어렵게만 느끼면 어렵게 느껴지기 마련입니다.
일단 경험하시기 바랍니다.
앞으로 여러분을 QA의 세계로 안내해드리겠습니다.
나름대로 경험은 많이 했다고 생각은 하지만, 경험주의를 바탕으로 QA에 대한 이론은 비롯하여
제가 프로그래머로 일하면서, QA Engineer로 일하면서 쌓은 노하우를 바탕으로 여러분에게
QA 입문을 위한 글들을 준비하고자 합니다.
자 그러면 QA의 세계로 함께 떠나보시죠.
이제 막 A 처음 시작하게 되었습니다.
Z까지 끝날때쯤이면 여러분들은 QA가 어떤것이구나 느껴질 수 있도록 잘 준비해보도록하겠습니다.
아직 실력은 많이 부족하지만, 언젠가는 QA입문자를 위한 글을 쓰고 싶었고, 벌써 미루어온지도 벌써1년이 넘어가고 있습니다.
열의가 부족한 탓입니다.
아무쪼록, 좋은 글 올려서 많은 분들이 공감하시고, 많은 정보 얻어가셨으면 합니다.
감사합니다.
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

Trackback 0 Comment 0


티스토리 툴바