본문 바로가기

QA

(88)
잘못된 애자일의 다섯 가지 증상 『Methods & Tools』의 2010년 봄호에 실린 Daryl Kulak의 “Five Symptoms of Mechanical Agile”을 여기 소개한다. 계간으로 발행되는 무료 온라인 잡지인 『Methods & Tools』는 각각의 제호에 실린 기사의 제목을 별도로 정리해 놓고 있는데, 이 제목들만 보아도 소프트웨어 산업의 트랜드를 파악하는 데 큰 도움이 된다. “Five Symptoms of Mechanical Agile”은 이미 트랜드라고 부르기엔 너무 일반화되고 유명해진 애자일 방식에 대해, 우리가 애자일이라고 믿으면서 쉽게 오류에 빠질 수 있는 상황들을 우화의 형식을 빌어서 재미있게 표현하고 있다. 애자일을 수행하지 않는 회사라고 하더라도 고착되고 기계적으로 수행되는 프로세스 상에서 우리..
효율적인 테스트 케이스 작성법 - 직관적으로 질문하라 책을 보다 보면, 가끔씩 너무나 자주 사용하면서도 너무나 쉽게 지나치고 있는 원리를 가르쳐 줄 때가 있다. 가능하다면 테스트 케이스에서 작성된 질문들은 “Yes”가 “Pass” 조건 – 소프트웨어가 설계한대로 동작하며 결함이 발견되지 않는 상태 - 을 가리키도록 작성되어야 한다. 어떠한 테스트 케이스에 “No”라고 대답한다는 것은 해당 테스트 케이스를 실행할 경우 문제가 발생한다는 이야기이며, 이러한 결함은 반드시 보고되어야 한다. 여기에는 여러가지 이유가 있지만 가장 직관적인 이유는, 일반적으로 우리는 심적으로 “Yes”와 “Pass”를 동일시하고(둘 다 긍정적인 의미이므로), 같은 방식으로 “No”와 “Fail”을 동일시 하기 때문이다. 또한, 동일한 컬럼 안에서 패스 처리된 모든 항목들을 한 군데에..
누가 소프트웨어 품질을 책임질 것인가? 해외 현업 소프트웨어 테스터들의 생생한 경험과 지식을 담아내고 있는 “Software Testing Help(http://bit.ly/9yDnPN)”에서 흥미로운 아티클을 발견해 여기 소개한다. 테스팅을 하다 보면 누구나 한 번쯤 생각하게 되는 주제를 적절한 비유와 이해하기 쉬운 논조를 사용해 자칫 심각해 지기 쉬운 주제를 재미있게 풀어쓴 것 같다. 저자인 Pradeep Soundararajan 의 개인 블로그(http://testertested.blogspot.com)에도 흥미로운 아티클들이 많으므로 한 번 방문해 보시기를 권한다. 번역 및 포스팅에 대해서는 원 저자의 승인을 받았다. 해당 글의 저작권은 원 저자인 Pradeep Soundararajan에게 있다. 늘 부족한 제 번역에 전문 번역가로서의..
생활 속의 QA - Early Testing 아무래도 직업이 직업인지라, 요즘 가끔은 일상적인 생활 속에도 QA가 적용될 수 있겠다라는 생각이 듭니다. Life QA, 말 그대로 삶의 질을 보증해 주는 것이죠. 일견 장황하게 들릴 수도 있겠지만 소소한 일상 속에서 QA 마인드를 가진다면 조금은 삶이 더 편안해지고 만족스러워질 것 같습니다. 일례를 들어볼까요. 지난 토요일, 집사람과 함께 집에서 가까운 뚝섬의 서울숲을 다녀왔습니다. 중랑천을 지나 한강변을 끼고 걷다 보니 봄내음이 물씬 납니다. 성수대교 근처에서 서울숲으로 진입하는 다리 입구에서는 고라니도 뛰어 놉니다. 남들처럼 멋진 DSLR을 가지고 출사를 나간 건 아니지만, 그래도 간만에 나온 나들이인지라 사진으로 추억을 남기고 싶었습니다. 어린애 마냥 이것 저것 신기해하고 감탄해 마지 않으면서 ..
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)에 기..