본문 바로가기

QA

 (88)
[번역] How Google Tests Software - Part Two How Google Tests Software – Part Two Wednesday, February 09, 2011 6:36 PM By James Whittaker “당신이 만들고, 만든 당신이 해체한다(You build it, you break it)”라는 모토를 실현하기 위해서는, 전통적인 개발자의 역할을 능가할 수 있는 새로운 역할이 필요하다. 특히 개발자가 효율적이고 효과적으로 테스트를 수행할 수 있도록 엔지니어링을 수행할 사람이 반드시 필요하다. 구글에서는 다른 사람들이 좀 더 생산적으로 일할 수 있도록 하는 엔지니어 역할을 만들었다. 이러한 엔지니어들은 스스로를 테스터라고 부르기는 하지만, 실상은 생산성과 관련된 미션을 수행한다. 그들은 개발자들이 테스트를 통해 좀 더 생산적인 업무를 수행할..
[번역] How Google Tests Software - Part One 최근 페이스북이나 트위터 등 여러 소셜 네트워크 서비스에서 “페이스북에는 테스팅을 전담하는 조직이 없다”라는 내용이 화제가 된 적이 있습니다. 여기에 대해 국내에서도 이런 저런 논의가 많았었죠. 마찬가지로 지난 1월부터 구글 테스팅 블로그에 올라오고 있는 제임스 휘태커(James Whittaker)의 포스트 “How Google Tests Software” 시리즈도 화제에 오르고 있습니다. 페이스북과 마찬가지로 구글에서도 개발자들이 테스팅을 원활하게 수행하도록 하기 위해 테스팅 조직이 존재한다는 것입니다. 그 외에도 사람들이 궁금해 하는 구글에서의 테스팅 방법에 대해 많은 내용이 올라와 있습니다. 저는 자잘한 내용들을 조금 더 보충해 전문을 번역한 것 뿐이고, 핵심적인 내용은 흥배님의 블로그 포스트 『구..
그림으로 보는 장애 발생 과정 지난 토요일 스터디 도중 에러(Error) 와 결함(Defect), 장애(Failure) 에 대해 공부하면서 그렸던 메모를 도식화 해봤습니다. 단 하나의 표준이 정해져 있는 것이 아니라서, 회사나 도메인에 따라 사용되는 단어가 틀려질 수 있습니다. ▶ 에러(Error): 주로 사람의 인지상의 실수를 의미함 Error라고 하면 앞에 “Human”이 생략된 것이라고 간주하면 됨 ‘mistake’가 같은 의미로 사용됨 ▶ 결함(Defect): 에러가 코드에 구현된 것 부정확한 구문이나 데이터 정의를 뜻함 ‘버그(Bug)’나 ‘결점(Fault)[1]’이 같은 의미로 사용됨 ▶ 장애(Failure): 결함으로 인해 구현되며 기대결과와 다르게 나타나는 실제결과를 의미함 [1] 『개발자도 알아야 할 소프트웨어 테스팅..
내게 테스팅이란 요즘 QA[1] 관련 글이 뜸합니다. 개인적으로 소프트웨어 테스팅과 관련된 번역 프로젝트에 참여하고 있고, 회사에서도 QA파트가 셋팅되고 본격적으로 테스팅 업무들이 진행되기 시작하면서 눈코뜰새 없이 바쁘다 보니 블로그에는 제대로 신경을 못쓰고 있습니다. 이 와중에 잠시 시간을 내어 지난 주에 있었던 ‘차세대 게임개발 국제 컨퍼런스’에 다녀왔습니다. 기존의 게임 개발 관련 세미나나 컨퍼런스가 주로 개발 자체에 초점을 맞추었던 것과 달리, 이번에는 게임 QA가 행사의 메인 테마였습니다. 국내의 온라인 게임 업계에서도 QA의 입지가 향상되고 있다는 것을 보여주는 단적인 반증이라고 할 수 있을 것 같습니다. 얼마 전 온라인 매체의 기사를 통해 국내에서도 인지도를 높인 캐나다의 게임 테스팅 전문 회사인 엔자임 (..
테스터들에게 프로그래밍 스킬이 필요한가? 최근 들어 국내에서도 소프트웨어 테스터들에게 프로그래밍 소양을 요구하는 경우가 늘어나고 있다. 일부 회사에서는 개발 경력이 있는 테스터들을 우선해서 채용하기도 하는 모양이다. 개인적으로 테스터들에게 프로그래밍 능력이 필수는 아니지만, 최소한 코드를 읽고 해당 코드가 무슨 기능을 하는 것인지를 파악하고, 간단한 자동화 스크립트 정도는 작성할 줄 알아야 한다고 생각한다. 내가 그 수준이라는 이야기는 아니다. 나도 그 정도 수준이 되기위해 노력하고 있는 테스터 중의 한 사람일 뿐이다. 테스터들에게 프로그래밍 능력이 필요한가라는 문제에 대해, 팀 블로그에 같이 참여하고 있는 의한님(@OEHAN)이 소개해준 블로그 포스트 "Do testers need programming skills?"를 번역해서 올린다. 원 ..
스타크래프트2 엔딩 크레딧으로 블리자드 QA 엿보기 이 포스팅은 어디까지나 개인적으로 유추한 자료를 바탕으로, 어디까지나 개인적인 추측을 기반으로 작성된 것입니다. 다만 참조하는 자료로만 보시고, 객관적인 자료로 간주하지 않으시기를 부탁드립니다. 아울러 좀 더 구체적인 자료와 정보를 가지신 분들의 댓글 환영합니다. 엔딩 크레딧을 통한 QA팀 분석이라는 영감을 제공해주신 덕경 님에게도 이 자리를 빌어 감사의 말씀 전합니다. 바쁘다는 핑계로 포스팅이 뜸했습니다. CBT가 끝난 주말, 이제서야 미뤄왔던 포스트를 하나 올릴려고 합니다. 오늘 간만에 포스팅 할 주제는 다름 아닌 블리자드의 스타크래프트II 입니다. 뭐 한 마디로 말이 필요 없는 게임이죠. 4천만의 국민 게임이었던 전작 스타크래프트의 명성을 이어 무려 12년 만에 출시되는 후속작인만큼, 뜨거운 관심과..
리스크 기반 테스팅 - Part 1 최근 많은 사람들이 관심을 가지고 있는 리스크 기반 테스팅에 관해, 렉스 블랙(Rex Black)이 그의 책 『Advanced Software Testing Vol.1 - Test Analyst』에서 설명한 것을 일부 발췌 번역했다. 3.9 리스크[1] 기반 테스팅(Risk-Based Testing) 리스크(Risk)는 부정적이거나 기대하지 않았던 결과(Outcome), 혹은 이벤트가 발생할 가능성을 의미한다. 구체적으로 리스크는 이것이 발생함으로써 고객, 사용자, 프로젝트의 참가자, 혹은 이해당사자들이 가지고 있는 제품의 품질이나 프로젝트의 성공에 대한 인식을 경감시킬 가능성이 있는 모든 문제를 의미한다.[2] 테스팅과 관련되어서는 주로 두 가지의 리스크 유형이 언급된다. 첫 번째 유형의 리스크는 제품..
리스크 기반 테스팅 - Part 2 3.9.4 리스크 완화 혹은 리스크 제어(Risk Mitigation or Risk Control) 이미 리스크를 식별하고 그것을 평가했다면, 그 리스크들을 제어해야 할 것이다. 앞서도 언급했듯이, 어드밴스드 실라버스에서는 이를 리스크 완화(Risk Mitigation)라고 칭하고 있는데, 이는 정확한 표현이 아니다. 우리는 아래와 같은 4가지 방법을 통해 리스크를 제어할 수 있다. ■ 완화(Mitigation). 리스크가 발생할 가능성과 그로 인해 발생하는 영향을 줄이기 위해 취하는 예방 조치(Preventive measure) ■ 비상계획(Contingency). 리스크가 발생했을 때의 영향을 줄이기 위해 우리가 가지고 있는 계획 혹은 다중의 계획들. ■ 전이(Transference). 발생하는 리스..

티스토리툴바