본문 바로가기

분류 전체보기

 (130)
누가 소프트웨어 품질을 책임질 것인가? 해외 현업 소프트웨어 테스터들의 생생한 경험과 지식을 담아내고 있는 “Software Testing Help(http://bit.ly/9yDnPN)”에서 흥미로운 아티클을 발견해 여기 소개한다. 테스팅을 하다 보면 누구나 한 번쯤 생각하게 되는 주제를 적절한 비유와 이해하기 쉬운 논조를 사용해 자칫 심각해 지기 쉬운 주제를 재미있게 풀어쓴 것 같다. 저자인 Pradeep Soundararajan 의 개인 블로그(http://testertested.blogspot.com)에도 흥미로운 아티클들이 많으므로 한 번 방문해 보시기를 권한다. 번역 및 포스팅에 대해서는 원 저자의 승인을 받았다. 해당 글의 저작권은 원 저자인 Pradeep Soundararajan에게 있다. 늘 부족한 제 번역에 전문 번역가로서의..
생활 속의 QA - Early Testing 아무래도 직업이 직업인지라, 요즘 가끔은 일상적인 생활 속에도 QA가 적용될 수 있겠다라는 생각이 듭니다. Life QA, 말 그대로 삶의 질을 보증해 주는 것이죠. 일견 장황하게 들릴 수도 있겠지만 소소한 일상 속에서 QA 마인드를 가진다면 조금은 삶이 더 편안해지고 만족스러워질 것 같습니다. 일례를 들어볼까요. 지난 토요일, 집사람과 함께 집에서 가까운 뚝섬의 서울숲을 다녀왔습니다. 중랑천을 지나 한강변을 끼고 걷다 보니 봄내음이 물씬 납니다. 성수대교 근처에서 서울숲으로 진입하는 다리 입구에서는 고라니도 뛰어 놉니다. 남들처럼 멋진 DSLR을 가지고 출사를 나간 건 아니지만, 그래도 간만에 나온 나들이인지라 사진으로 추억을 남기고 싶었습니다. 어린애 마냥 이것 저것 신기해하고 감탄해 마지 않으면서 ..
출사표(出社表) 2년 반 동안 몸 담았던 회사를 떠나게 되었습니다. 운 좋게도 좋은 사람들을 만나고 좋은 시간을 보내었던 곳을 이제 떠나게 되었습니다. 사실 늘 즐거운 시간들만 가득했던 건 아닙니다. 누구에게나 주어지는 시련이 저에게도, 그리고 우리에게도 있었습니다. 몇 달을 고생하며 테스트한 게임이 결국엔 제대로 빛도 보지 못하고 사라질 땐 마치 오랜 친구를 떠나 보내며 가슴에 묻는 것처럼 아쉬웠습니다. 때로는 서로의 등만을 의지하며 무력하게 힘든 시간을 보내야 할 때도 있었습니다. 그로 인해 떠나는 사람에게 미안했고 새로 만나는 사람에게 부끄러웠습니다. 하지만 그런 시련 덕분에 좋은 사람들이 주위에 있다는 것을 알게 되었고 그 좋은 사람들 덕분에 주어진 시련을 함께 견뎌나갈 수 있었고 그 시련을 이겨낸 덕분에 지금 ..
Cloud QA Testing Experience 9호 에서 발췌해서 번역한 글. 웹 QA와 관련된 글이기는 하나, 게임 및 기타 도메인에서도 사용자 환경을 어떻게 에뮬레이팅 해서 테스팅을 진행할 지에 대한 조언이 담겨있다. 구체적인 툴과 서비스 명을 명시해서 제시하기는 했지만, 방대한 사용자 환경을 어떻게 담보할 것인지, 그리고 테스트 자동화를 어떻게 구현할지에 대한 고민을 조금이나마 덜어줄 수 있으리라 기대해 본다. 필자가 몸담고 있는 곳에서도 가상 이미지 제작 툴인 고스트(Ghost)를 사용해 사용자가 많이 사용하는 OS와 애플리케이션들을 가상 환경으로 꾸미고 테스트하고 있다. 원 저자가 제안한 툴들이 아니더라도, 다양한 툴이 존재하는 만큼 자신이 처한 환경에서 가장 적합한 툴을 선택할 수 있는 가이드가 되길 바란..
실용적인 심각도 선정 가이드 최근 필자가 재직하고 있는 품질관리 팀 내에서 심각도(Severity)에 대한 기준을 다시 정리하는 작업을 진행했다. 국내에서 테스트 엔지니어들이 그들의 현업에서 바로 적용할 수 있을 정도의 심각도에 관한 기준이 세세하게 기록된 문서를 가지고 있는 회사가 과연 얼마나 많을지 의문이다. 아무리 테스트 업무를 오랫동안 진행한 부서라고 하더라도 결함의 심각도를 판단하는 유일한 기준이 오직 개별 테스트 엔지니어의 경험과 주관뿐인 경우가 허다한 것이 현실이다. 상황이 이러하다 보니 당연히 심각도 선정에 대한 객관성이 보장되지 않았고, 이로 인해 개발자와 테스트 엔지니어 사이에 결함의 심각도에 대한 의견 차이가 빈번하게 발생했을 뿐만 아니라, 테스트 팀 내에서도 동일한 결함에 대해 서로 다른 의견이 제시되고는 했다..
게임 QA를 꿈꾸는 분들에게 최근에 제가 일하고 있는 품질관리 팀에 지원한 신입사원 몇 분의 면접을 봤습니다. 제가 일하고 있는 팀의 정식 명칭이 품질관리 팀(Quality Management Team)이기는 하지만, 통칭 QA라고 많이들 부르죠. 아울러 아시는 분들은 다들 아시겠지만, 제가 일하고 있는 회사는 온라인 게임을 만들고 있는 회사입니다. 이 두 가지 요소가 결합하면 시너지 효과가 발생하는 게 아니라, 오히려 일종의 역효과가 발생하는 것 같습니다. 국내의 소프트웨어 업계에서 QA 분야만큼 제 가치를 인정받지 못하고 있는 부분도 없는 것 같습니다. 좀 더 솔직히 말하면, 일부 SI 업체나 대기업을 제외하고는 파견직이나 계약직으로 팀의 절반 이상이 채워지고 상부로부터의 체계적인 지원 따위는 꿈에도 바라기 힘든 것이 현실이죠...
소프트웨어 테스팅의 종류 업무상 필요해 소프트웨어 테스트의 종류에 대해 조사하다가 일목요연하게 잘 정리된 글을 발견했다. 각 항목들에 대해 최소한의 정의들로만 구성되어 있어 논란의 여지가 남아있는 항목도 있다. 아직까지도 정확한 단어 사용이 힘들지만, 여기에 사용된 단어의 정의에 대해서는 업계의 대다수 사람들이 공감할 수 있으리라 생각된다. Happy Testing!!! 출처: http://www.softwaretestinghelp.com/types-of-software-testing/ 블랙 박스 테스팅(Black box testing) – 시스템의 내부 설계(Internal system design)는 이 테스팅 유형에서 고려할 대상이 아니다. 테스트는 요구사항(Requirement) 및 기능성(Functionality)에 기..
QA, QC 그리고 테스트 엔지니어링의 차이 얼마 전 같은 회사의 다른 부서에서 QA 매니저를 하시는 분이 "QA와 QC의 차이"에 대해서 진지하게 질문을 던진 적이 있다. 나름대로 생각하고 있던 바를 같이 논의해 보긴 했지만 서로가 명확한 개념을 잡고 있지 못했던 것 같았다. 이 참에 인터넷의 여기 저기를 뒤지다가 구글 테스팅 팀 블로그에서 QA와 QC, 그리고 테스트 엔지니어링에 대해 정의해 놓은 글을 실어왔다. 아직도 QA 분야에서 사용되는 단어들이 사전적인 의미로 통일되어 사용되는 예는 드문 것 같다. 그만큼 나름대로의 주관적인 해석도 가능하다는 이야기도 되니 이 포스트는 단지 참조만 하시면 되겠다. 아울러 포스트에 달린 댓글들도 외국의 QA들이 나름대로 이 주제에 대해 생각하고 있는 것들을 보여주는 것 같아 같이 번역했다. The diff..

티스토리툴바