swtest
테스팅의 심리학
by Kitle · 2017. 06. 08.
테스팅의 독립성
1. 테스트 중인 소프트웨어의 작성자가 설계한 테스트
2. (개발팀 내의) 다른 인원이 설계한 테스트
3. 독립적인 테스트 팀과 같은 다른 그룹의 인원 또는 테스트 전문가가 설계한 테스트
4. 다른 조직이나 회사 소속의 인원이 설계한 테스트
일반적으로 1<2<3<4 로 갈수록 독립성이 높아져 더 효과적인 시각을 제공하기에 추가적인 장점들이 많다고 한다.
물론 1<2<3<4 로 갈수록 비용과 시간이 많이 드는 것은 당연한 이야기지만,
품질에 대한 마인드와 테스팅에 대한 마인드가 있는 회사라면 당연히 못해도 3번이나 4번정도의 조직을 갖추고 진행 하고 있을 것이다.
보통 개발자는 개발 할 시간도 벅차고 다양한 테스트 전략을 수립하거나 시도하기도 벅 찰 것이다.
개발단의 입장에서는 다른사람이 작성한 코드에 대해서 일일이 이해하기도 어렵거니와 그것을 테스트한 코드나 케이스를 설계한다는 것도
상당히 고도의 작업이 되기 때문이다.
물론 사용자 입장에서나 메뉴얼, 동작설명서(검사절차서, 검사서, 테스트케이스, 등등)등을 간단하게 작성할 수는 있지만, 내가 봐온 현업에서는 아주 기본적인 요구사항만 작성하는 것이 현실이다.
아니 개발 및 결함 수정에도 바쁜 개발자가 이런 케이스나 메뉴얼 작성까지 한다고 하니, 결국 현업에서는 말단 개발자들이 도맏아 하고 있지 않는가. 이런것은 거의 고급 개발자(관리자)가 작성하는 것이 정석이지만, 야근만으로도 충분히 버티지 못하고 있는 게 현실이다.
그럼 이번엔 독립적인 테스트팀과 같은 다른 그룹이 설계한 테스트를 보자.
개발 내에 테스팅 인력을 두거나, 개발팀외에 테스팅 팀을 갖추거나, 또는 개발과는 독립적으로 QA팀 등을 두어 운용 하는게 현실이다.
개발팀에 테스팅 팀을 갖추는 경우는 상당히 테스팅과 개발이 빠르게 돌아간다. 피드백도 빠르고 그에 대한 테스팅도 빨라져 개발자는
개발하는데 도움이 된다. 또한 각종 필드에서 들어오는 다양한 이슈들을 재현하고 확인하는 것들도 상당히 소모적인(이런 표현을 쓰는
것이 괜찮을지 모르겠다)일이기도 하지만, 잘 안되는 경우 익숙한 테스팅 팀에서 오히려 재빠르게 해결하여, 개발에 전념을 할 여유도 줄 수 있다.
현업에서 해당 개발팀에 소속된 테스터로 일한 적이 있는데, 개발팀에서는 인사치례로 그런말을 했는지 몰라도.
개발하면서 바로바로 테스팅을 해주니까 없을 때 보다 개발 진도가 빨리 나간다는 것이다.
물론 단점도 있을 것이다. 테스팅 버전을 릴리즈하면 신속히 올라오는 버그들에 대해 느끼는 허무함... 압박감.
그리고 오히려 테스트를 고려 안하게되는 마인드.. 테스팅팀에서 잘 잡아주니까 일단 돌아가면 빌드하고보자 뭐 이런마인드?
그런 것들은 현업에서 잘 해쳐 나가길 바란다.
다음은 다른 조직이나 회사 소속의 인원이 설계한 테스트.
가장 독립성이 높고 END USER에 가까운 다양한 테스팅을 할 수있으며 전혀 고려하지 못한 부분까지 말그대로 독립성이 강하다.
아웃소싱으로 테스트케이스까지 작성하며 테스팅을 진행한 경우가 있었는데, 나중에는 정말 혀를 내두를 정도다. 이런 케이스는
상상도 못했다고..
물론 다양한 결함을 찾아 올리는 것도 올리는 것이지만, 제3자의 입장에서(아웃소싱의 입장에서 좋은말만 하는 방법도 있지만
절대 그것은 좋은 방법이 아니다) 독설을 마구마구 날려야 한다. (물론 싸울 필요는 없지만)
설계서가 있다면 설계서를 기본으로 작성만 하고 마는 아웃소싱 회사도 있다. 좀더 효과적으로 설계서에 논리적으로 잘못 된것은 없는지, 다양한 설계자가 작성한 설계서들이 일반적으로 통일화 할 부분은 없는지, 설계서에 누락되어 테스트가 중복으로 되거나 안되고 있는 것은
아닌지, 진짜 유저 입장에서 어떻게 느끼는지...
테스팅 심리학이라고 해서 다양한 말들을 써 놓았다.
독립성도 좋고, 다 좋지만. 테스팅 심리학 보다는 결국 테스팅에 대한 많은 지식, 경험. 그리고 마지막으로 테스트 하고 있는 소프트웨어를
징글징글한 버그덩어리로 바라보지 말고, 사용자가 사용하다 감동을 느낄 수 있는 따뜻한 S/W를 만들도록 설계하고 테스팅하고 보고하는 것이 최고가 아닐까 생각한다.
마지막으로 개발과 테스터가 함께 일하는 노하우~
1. 협력으로 시작 : 더 나은 품질을 위한 공통적인 목표를 주지
2. 결함 리포팅은 중립적으로 : 객관적이고 사실적(논리적인) 인시던트 리포트 작성.
>> 사실 이런 것 보다는 힘들 때 가서 어깨한번 주물러 주고, 더 빠르고 효과적인 테스팅을 위한 노력, 개발도 테스팅과 확인을 소홀하지 않는
서로 힘든데 도와가며 하는자세가 제일 중요할 것 같다!
1. 테스트 중인 소프트웨어의 작성자가 설계한 테스트
2. (개발팀 내의) 다른 인원이 설계한 테스트
3. 독립적인 테스트 팀과 같은 다른 그룹의 인원 또는 테스트 전문가가 설계한 테스트
4. 다른 조직이나 회사 소속의 인원이 설계한 테스트
일반적으로 1<2<3<4 로 갈수록 독립성이 높아져 더 효과적인 시각을 제공하기에 추가적인 장점들이 많다고 한다.
물론 1<2<3<4 로 갈수록 비용과 시간이 많이 드는 것은 당연한 이야기지만,
품질에 대한 마인드와 테스팅에 대한 마인드가 있는 회사라면 당연히 못해도 3번이나 4번정도의 조직을 갖추고 진행 하고 있을 것이다.
보통 개발자는 개발 할 시간도 벅차고 다양한 테스트 전략을 수립하거나 시도하기도 벅 찰 것이다.
개발단의 입장에서는 다른사람이 작성한 코드에 대해서 일일이 이해하기도 어렵거니와 그것을 테스트한 코드나 케이스를 설계한다는 것도
상당히 고도의 작업이 되기 때문이다.
물론 사용자 입장에서나 메뉴얼, 동작설명서(검사절차서, 검사서, 테스트케이스, 등등)등을 간단하게 작성할 수는 있지만, 내가 봐온 현업에서는 아주 기본적인 요구사항만 작성하는 것이 현실이다.
아니 개발 및 결함 수정에도 바쁜 개발자가 이런 케이스나 메뉴얼 작성까지 한다고 하니, 결국 현업에서는 말단 개발자들이 도맏아 하고 있지 않는가. 이런것은 거의 고급 개발자(관리자)가 작성하는 것이 정석이지만, 야근만으로도 충분히 버티지 못하고 있는 게 현실이다.
그럼 이번엔 독립적인 테스트팀과 같은 다른 그룹이 설계한 테스트를 보자.
개발 내에 테스팅 인력을 두거나, 개발팀외에 테스팅 팀을 갖추거나, 또는 개발과는 독립적으로 QA팀 등을 두어 운용 하는게 현실이다.
개발팀에 테스팅 팀을 갖추는 경우는 상당히 테스팅과 개발이 빠르게 돌아간다. 피드백도 빠르고 그에 대한 테스팅도 빨라져 개발자는
개발하는데 도움이 된다. 또한 각종 필드에서 들어오는 다양한 이슈들을 재현하고 확인하는 것들도 상당히 소모적인(이런 표현을 쓰는
것이 괜찮을지 모르겠다)일이기도 하지만, 잘 안되는 경우 익숙한 테스팅 팀에서 오히려 재빠르게 해결하여, 개발에 전념을 할 여유도 줄 수 있다.
현업에서 해당 개발팀에 소속된 테스터로 일한 적이 있는데, 개발팀에서는 인사치례로 그런말을 했는지 몰라도.
개발하면서 바로바로 테스팅을 해주니까 없을 때 보다 개발 진도가 빨리 나간다는 것이다.
물론 단점도 있을 것이다. 테스팅 버전을 릴리즈하면 신속히 올라오는 버그들에 대해 느끼는 허무함... 압박감.
그리고 오히려 테스트를 고려 안하게되는 마인드.. 테스팅팀에서 잘 잡아주니까 일단 돌아가면 빌드하고보자 뭐 이런마인드?
그런 것들은 현업에서 잘 해쳐 나가길 바란다.
다음은 다른 조직이나 회사 소속의 인원이 설계한 테스트.
가장 독립성이 높고 END USER에 가까운 다양한 테스팅을 할 수있으며 전혀 고려하지 못한 부분까지 말그대로 독립성이 강하다.
아웃소싱으로 테스트케이스까지 작성하며 테스팅을 진행한 경우가 있었는데, 나중에는 정말 혀를 내두를 정도다. 이런 케이스는
상상도 못했다고..
물론 다양한 결함을 찾아 올리는 것도 올리는 것이지만, 제3자의 입장에서(아웃소싱의 입장에서 좋은말만 하는 방법도 있지만
절대 그것은 좋은 방법이 아니다) 독설을 마구마구 날려야 한다. (물론 싸울 필요는 없지만)
설계서가 있다면 설계서를 기본으로 작성만 하고 마는 아웃소싱 회사도 있다. 좀더 효과적으로 설계서에 논리적으로 잘못 된것은 없는지, 다양한 설계자가 작성한 설계서들이 일반적으로 통일화 할 부분은 없는지, 설계서에 누락되어 테스트가 중복으로 되거나 안되고 있는 것은
아닌지, 진짜 유저 입장에서 어떻게 느끼는지...
테스팅 심리학이라고 해서 다양한 말들을 써 놓았다.
독립성도 좋고, 다 좋지만. 테스팅 심리학 보다는 결국 테스팅에 대한 많은 지식, 경험. 그리고 마지막으로 테스트 하고 있는 소프트웨어를
징글징글한 버그덩어리로 바라보지 말고, 사용자가 사용하다 감동을 느낄 수 있는 따뜻한 S/W를 만들도록 설계하고 테스팅하고 보고하는 것이 최고가 아닐까 생각한다.
마지막으로 개발과 테스터가 함께 일하는 노하우~
1. 협력으로 시작 : 더 나은 품질을 위한 공통적인 목표를 주지
2. 결함 리포팅은 중립적으로 : 객관적이고 사실적(논리적인) 인시던트 리포트 작성.
>> 사실 이런 것 보다는 힘들 때 가서 어깨한번 주물러 주고, 더 빠르고 효과적인 테스팅을 위한 노력, 개발도 테스팅과 확인을 소홀하지 않는
서로 힘든데 도와가며 하는자세가 제일 중요할 것 같다!