본문 바로가기

QA

 (88)
QA, QC 그리고 테스트 엔지니어링의 차이 얼마 전 같은 회사의 다른 부서에서 QA 매니저를 하시는 분이 "QA와 QC의 차이"에 대해서 진지하게 질문을 던진 적이 있다. 나름대로 생각하고 있던 바를 같이 논의해 보긴 했지만 서로가 명확한 개념을 잡고 있지 못했던 것 같았다. 이 참에 인터넷의 여기 저기를 뒤지다가 구글 테스팅 팀 블로그에서 QA와 QC, 그리고 테스트 엔지니어링에 대해 정의해 놓은 글을 실어왔다. 아직도 QA 분야에서 사용되는 단어들이 사전적인 의미로 통일되어 사용되는 예는 드문 것 같다. 그만큼 나름대로의 주관적인 해석도 가능하다는 이야기도 되니 이 포스트는 단지 참조만 하시면 되겠다. 아울러 포스트에 달린 댓글들도 외국의 QA들이 나름대로 이 주제에 대해 생각하고 있는 것들을 보여주는 것 같아 같이 번역했다. The diff..
훌륭한 테스트 팀을 만들고 유지하기(Hire and KEEP A Great Test Team) By Jeff Feldstein[1] 지금까지는 애플리케이션과 개발자가 모든 관심을 받아왔다. 그러나 오늘날 방대하고 미션 크리티컬한 소프트웨어 애플리케이션을 테스팅 하는 것은, 애플리케이션을 개발하는 것만큼이나 복잡하다. 사용자들은 언제나 더 많은 것들을 원하고, 여기에 더해 새로운 기능, 좀 더 고상하고 신속한 성능, 증가된 사용자 편의성과 스케일을 요구하고 있다. 상급 관리부서는 이러한 모든 요구사항들이 비용은 절감하면서 충족되도록 요구하고 있고, 개발 리더들은 새로운 방법을 제안하는 반면 우리는 언제나 그렇듯 무척이나 바쁘다. The Test Team 테스트 엔지니어, 테스트 매니저 그리고 품질 보증 파트로서 우리는 우리가 맡은 역할대로 다양한 요구의 균형을 잡기 위한 시도를 한다. 그러나 우리 ..
생선썩는 내 - "프로젝트는 애시당초 기한 내에 끝날 가망이 없다. 관련자 대다수가 알면서도 함구한다." 이 요상한 제목의 글은 지금 읽고 있는 『프로젝트가 서쪽으로 간 까닭은』 이라는 책의 앞 부분에 나온다. 읽으면서 따옴표 하나, 빈 칸 하나에도 진심으로 공감했다 해도 과언이 아닐 것이다. 일부분을 인용해 본다. 대다수 IT 프로젝트는 목표가 간단명료하다. 한 마디로 표현하면 이렇다. 이런저런 기능을 이만한 정확도와 저만한 안정성으로 어느 날짜까지 구현한다. 이에 팀을 만들고, 목표와 제약을 상세한 요구사항과 설계로 변환하고 모두에게 공지한다. 그런데 한 가지 커다란 비밀은 어느 누구도 프로젝트가 성공하리라 생각하지 않는다는 사실이다. 목표를 조정하지 않는 한 일정 달성은 꿈에서나 가능하다. 신기하게도 프로젝트에 생선 썩는 내가 진동한다는 사실을 아무도 언급하지 않는다. 프로젝트는 그리스 비극처럼 전개된..
부하 테스트와 스트레스 테스트의 차이 보리스 바이저(Boris Beizer)가 faqs.org 에 올려놓은 글을 번역해 보았다. 부하 테스팅, 스트레스 테스팅과 함께 볼륨 테스팅도 가끔 혼돈되는 의미로 사용되는 데 거기에 대해서는 추후 포스팅 예정... 가장 일반적으로 사용하는 용어이면서도 잘못 사용되고 있는 예로 “부하 테스팅(Load testing)”과 “스트레스 테스팅(Stress testing)”을 들 수 있다. 우리는 종종 이 단어들을 동일한 의미로 사용하는 것을 발견할 수 있다. 이런 용어가 잘못 사용되는 것이 중요하게 다루어져야 하는 이유는, 시스템이 적절하게 “부하에 대한 테스트가 수행되지도 않을”뿐더러, 충분하게 “스트레스 테스트”도 이루어지지 못하게 할 수 있기 때문이다. 1. 스트레스 테스팅은 시스템이 부하를 처리하는 데..
만약 당신이 새로 부임한 QA 매니저라면 소프트웨어 테스팅 전문가인 James A. Whittaker가 Google Testing Blog에 얼마 전에 올린 포스트다. 최근 관심있는 테스트 매니저의 R&R과 관련된 글인지라 관심이 갔다. 원래 하나의 제목에 2개의 포스트가 이어진 것을 한 번에 번역했다. 참조해 보시길. “만약 당신이 새로 부임한 QA 매니저라면…” By James A. Whittaker 오늘 아침, 나는 한 독자로부터 아래 내용의 메일을 수신했다. “나는 테스트 관리자(Test supervisor)로 일하다가 어제부로 QA 관리직(QA Management position)으로 임명되었습니다. 한편 흥분되기도 하지만 한편으로는 두렵기도 하네요. 이런 마음을 어떻게 정리해야 할 지 잘 모르겠습니다. 스타웨스트(StarWest)에 ..
동등분할(등가분할)기법에 대한 몇 가지 단상 렉스 블랙이 쓴 책에서 동등분할(혹은 등가분할)에 관한 부분을 읽으면서 느낀 몇 가지를 적어보면 다음과 같다. 이 양반이 글은 좀 어렵게 쓰는 경향이 있지만 그래도 경력이 경력인지라 생각할 거리를 꽤 많이 던져준다. 1. 명세 기반 테스트는 요구사항에 기반하고 있다(Specification-based tests are requirement-based). : 명세 기반 기법, 그리고 블랙박스 기법 중의 대표적인 기법이 동등분할이다 보니 그 얘기하면서 다시 리뉴얼해주는 부분임. 명세는 요구사항을 반영하고 있어야 한다. 당연한 이야기. 2. 등가분할을 통해 나누어진 각 클래스 간에는 교집합 영역이 없어야 한다. : 등가분할은 동일한 메타 태그 아래 동일한 성격을 가지는 데이터(무엇에 관한 것이라도 상관없다)로..
리스크 기반 테스팅에 대한 몇 가지 단상 1. 사용성 측정을 어떻게 할 것인가? o 메트릭을 정해놓고 1부터 5까지의 점수를 줘서 평균내는 방법 o QA나 개발자가 평가하는 것은 의미가 없다 o UX(User eXperience) 팀과 같은 전문가가 있어야 한다(특히 게임과 같은 Customer Target 도메인에서) 2. 테스트 계획 단계에서 리스크 분석이 수행되고 그 결과는 프로젝트의 이해당사자들에게 공유 및 승인되어야 한다. 3. 잔존 리스크(Residual Risk): 테스트 종료 시점에서 아직 해결되지 않은 버그들 역시 잔존 리스크로 봐야한다. -> These should be reported through test result report! 4. Severity Integrity Level(안전 무결성 수준) 5. 위험에 대한 추적..
개발자에 대처하는 우리의 자세 CBT가 코앞으로 다가오면서 바빠지고 있다. 중요한 마일스톤을 넘어갈 때마다, QA가 해야할 일이 별로 없다면 얼마나 행복한 상황인가. 하지만 역시 현실은 시궁창. 늘 그렇듯이 크리티컬한 이슈는 하루가 멀다하고 터지고 심지어는 가장 기본적인 컴포넌트에서조차 빵구가 나기 시작한다. 덕분에 마무리 작업은 순조롭지 못하다. 빌드가 매일매일 릴리즈되고 테스트도 거의 매일 수행된다. 그저께도 밤늦게까지 테스트를 수행했지만 결과는 그리 신통하지 못했다. 나쁜 일이 만성이 되는 것처럼 무서운 일이 있을까. 아무렇지도 않게 시험 실패 보고서를 날리고 피곤한 몸을 이끌고 자정이 다되어서야 집으로 들어갔다. 다음날 아침, 출근해보니 몇몇 핵심 개발자들이 이미 출근해 있었다. 보고서를 날리기 전에 크리티컬 이슈가 터질 때마..

티스토리툴바