단순 Tester 부터 시작해서 QC팀 인턴 업무까지 수행하면서 솔직히 테스팅 이론을 적용시켜서 업무를 한 적이 없는 듯 싶다.
QC팀 인턴을 하고 있는 현재도, 사수님들이 작성한 테스트 케이스 형식을 보면서 어깨 너머로 테스트 케이스 작성을 해보았고, 온갖 구글링을 통해서 파이썬으로 자동화 테스트까지 조금 경험해 보았다.
항상 검증할 때에, 전체적으로 어떻게 테스트 할 지 구조화 시킨 후에 하면 좋을텐데 이론들이 머릿속에 정리가 되있지 않아서 이것 저것 눌러보며 테스트하기 일쑤였다.
인턴 기간이 마무리 되기 전에 꼭! 주요 테스팅 이론들을 정리해 보려고 한다.
1. 테스팅의 정의
- 테스팅 활동은 단순히 소프트웨어를 실행하고 결과를 확인하는 테스트 수행에 국한되는 것이 아니다.
- 소프트웨어 테스팅이란 테스트 계획, 분석, 설계, 테스트 구현, 테스트 진행 상황 및 결과 보고, 테스트 대상 품질 평가 등 많은 활동을 포함한다.
2. 테스팅 VS 디버깅
- 테스트를 실행하면 소프트웨어 결함으로 인한 장애를 찾아낼 수 있다.
- 디버깅은 그러한 장애의 원인을 찾고 분석해 수정하는 개발 활동이다.
3. QA(Quality Assurance) VS 테스팅
- QA와 테스팅을 혼용해서 사용하는 경우가 많은데, 둘은 다른 개념이다.
- 둘 다 포괄적인 개념인 품질 관리(Quality Management)에 속한다.
- QA는 적절한 품질 수준을 달성했는지 확신을 얻기 위해 적절한 프로세스를 준수하도록 하는 것에 초점을 둔다.
- 테스팅 활동은 전반적인 소프트웨어 개발 및 유지보수 프로세스의 일부 일 뿐이며, QA에서는 전반적인 프로세스의 올바른 수행 여부에 관심을 가지기 때문에 올바른 테스팅의 적용에도 관심을 가진다.
4. 테스팅의 일반적인 목적
- 요구사항, 사용자 스토리, 설계, 소스 코드 등과 같은 작업 산출물 평가에 의한 결함 예방
- 명시된 모든 요구사항이 충족됐는지 검증
- 테스트 대상의 완성 여부 확인과 사용자와 기타 이해관계자의 기대치 대로 동작하는지의 확인
- 장애 및 결함 발견과 이에 따른 부적절한 소프트웨어 품질의 리스크 레벨의 감소
5. 테스팅의 7가지 원리
- 테스팅은 결함이 존재함을 밝히는 활동이며, 결함이 없음을 밝히는 활동이 아니다 (개인적으로 중요하다고 생각한다!!)
- 완벽한 테스팅은 불가능하다
- 조기 테스팅으로 시간과 비용을 절약할 수 있다
초기부터 시작하는 테스팅을 시프트 레프트(shift left)라고도 부른다.
- 결함은 집중된다
- 살충제 패러독스에 유의하라
같은 테스트를 계속해서 반복 실행한다면, 결국 해당 테스트로는 결함을 더 이상 발견할 수 없게 된다.
새로운 결함을 발견하기 위해서는 기존의 테스트와 데이터를 바꾸고 새로운 테스트를 작성해야 한다. - 테스팅은 정황(context)에 의존적이다
테스팅은 정황에 따라 다르게 진행된다. 가령, 애자일 프로젝트에서의 테스팅은 순차적 소프트웨어 개발 수명주기 프로젝터에서의 테스팅과는 다르게 진행된다.
- 오류 부재는 궤변이다
조직에 따라서.. 테스터가 모든 가능한 테스트를 실행하고 존재하는 모든 결함을 발견하기를 기대하는 경우도 있지만, 이는 불가능하다. 뿐만 아니라, 단순히 많은 결함을 발견하고 고쳤다고 해서 시스템의 성공이 보장된다고 생각하는 것은 궤변(잘못된 믿음)이다.
가장 지금의 나에게(?) 위안이 되는 항목은 1,2,7번이다.
Naver에서는 SDK를 테스트 했기 때문에 실제 사용자들의 목소리를 들을 기회가 없었지만, 곰앤컴퍼니에서는 달랐다.
CS팀과 함께 업무를 했고, 실제 크리티컬한 이슈가 발견되어서 긴급 배포를 한 적도 몇 번 있었다.
팀에 인원이 워낙 부족했어서, 들어간 지 한달도 채 안되서 혼자서 업데이트 검증을 진행한 적이 있었는데, 혹여나 제대로 검증하지 못해서 VOC가 많이 들어오면 어쩌나 걱정했던 시기가 있었다.
위 항목들을 가슴에 새겨두어야겠다.
6. 테스터의 사고방식
- 호기심, 전문적 비평 능력, 비판적 시각, 세밀한 것에 주목하는 태도, 긍정적인 의사소통과 관계 수립에 대한 동기 등의 사고방식을 가지고 있어야 한다.
내가 개발자보다 QA 직무가 더 맞을지도 모르겠다고 생각이 들었는데, 6번 문항을 보니 더욱 그런 생각이 든다.
특히 곰앤컴퍼니에서 근무할 때에 사수님께 가장 많이 한 질문이 '이 동작은 이슈는 아닌데요.. 왜 이렇게 동작을 하는지 이해가 안가요' 였다.
정말 여러가지 동작이 있었다. 가장 기억에 남는건 인코딩 진행 중에 일시정지 버튼을 누른 후 인코딩 닫기 버튼을 누르면 '닫겠습니까' 팝업이 나오는 동시에 인코딩이 재실행 되는 시나리오 였다.
실제 인코딩 중 일시정지를 누를 사용자가 거의 없을 것으로 예상되나, 논리적으로 이해가 가지 않았던 동작이다.
지금에서 생각해보면 항상 내가 발견하는 이슈들은 남들이 해보지 않을 것 같은 시나리오의 이슈들이었다.
많은 이슈들을 찾아왔고, 더욱이 앞으로 내가 QA 직무로 일을 하게 된다면 많이 찾을테지만! 그 이슈들을 사용자 중심에서 더욱 개선해나가고 올바른 길로 해결해 나가고 싶다.
출처 ISTQV FL v2018 실러버스_v3.1한글
