오랜만(?)에 문제점에 대한 지적을 받았다.
발주사로 부터 지적 받은 것은 QA에 대한 기본이 갖춰지지 않았다는 것.
사실 내용에 대해서는 이견을 제시하고 싶었지만, 갑-을 관계상 혹시라도 있을지 모르는 '갑'의 심기 불편이 있을 수 있어
이견을 제시하지 않았다.
개인적으로는 서로 이견을 주고 받으면서 지적유희? 를 즐기고도 싶지만 (사실 그럴만한 지식도 없지만.. ^0^~~)
글에 대한 표현이 혹시라도 상대방의 마음을 상하게 할까봐, 그리고 내가 글을 잘 쓰는 편이 아니어서 포기해야 했다.
혹시 제 블로그에 들어오셔서 이글을 발견하신다면, 이슈에 대해서는 진심으로 이견을 제시했을 뿐임을 알아주셨으면 합니다.
한편으로는 '기본이 갖춰지지 않은 회사'로 판명 받는 상황을 어떻게 잘 설명해야할 지 모르겠다.
이것은 나를 제외하고라도 나와 같이 일하고 있는 사람들의 명예를 실추하는 일이 아닌가 싶어 메일을 작성하였으나,
삭제되고 말았다.
어떻게 받아 들이셨는지는 모르겠지만 개인적 판단으로
이슈가 된것은 QA진행 전체에 대한 큰 틀 보다는 'Test Case를 누가 작성하느냐'의 문제이다.
Use case 작성한 곳에서 검증을 위한 Test case를 작성해야한다는 것이 나의 이견 제시였고,
반대쪽의 입장에서는 개발사에서 별도의 QA인력을 배치하여 작성해야 한다는 것이었다.
물론 우리가 개발자 이외에 QA만을 담당하기 위한 인력을 별도로 둘만큼 규모를 갖추지 못한 회사라 언급했고,
QA에 대한 인력을 갖출 생각이 없는 회사는 QA에 대한 기본이 되어있지 않다는 것이 그분의 의견이었다.
또한 조엘의 이야기도 언급해주셨는데, 아무래도 '3. My customers will test the software for me' 부분을 적용시킨것 같다.
여기에 대한 나의 의견은
기획, 즉 use case를 작성한 곳에서 test case 작성없이 ' 배포->사용자 버그리포팅->버그fix->마이너 버젼 업 릴리즈' 라는 조엘도 언급한 대로 대단히 용감한(?) Test procedure를 적용한 사례이다.
반면,
이번의 경우는 use case를 받아 개발을 우리가 적용한 상태인데, 개발 기간 중의 테스트는 당연히 실행이 되었고, QA지원을 위하여 보다 detail한 exception상황을 찾아내기 위해서 use case를 작성한 곳에서 test case를 작성하고 이에 따른 testing 및 debugging을 진행하는 것이 개발사의 입장에서는 예산내에서 움직이기 가장 좋은 범위라 생각이 든다.
물론 예산의 범위는 각 사의 입맛에 따라 다르겠지만...
또한 최근(?) 각광 받고 있는 대부분의 RUP/XP/Agile등에 핵심적인 부분이 Use Case Driven의 기본 골격대로 최초 작성된 Use Case가 설계, 개발, 테스팅까지 Tracing이 가능한 구조를 갖도록 하기 때문에 use case를 작성한 사람이 test case를 작성하는 것이 맞다고 생각한다. 어짜피 개발사에서 작성을 한다 하더라도 use case를 작성하고 서비스를 기획한 곳에서 검증이 필요할 것이다. 결국 최초 기획하고 시나리오(use case)를 작성한 사람이 가장 효율적일 test case를 작성할 수 있지 않을까가 나의 생각이다.
여기까지 읽은 사람은 아시겠지만.
맞다.
양쪽의 의견이 같다. Testing의 중요성을 공감하고 있으나. 서로의 예산, 즉 투입인력이 난제인 것이다.
어찌 보면 한국문화에서는 개발사가 다해야 하는 정서가 맞겠지만, 또한 어찌 생각하면 개발사의 억지 주장? 일 수도 있지만
현재 상태 범위(예산, 기간, 지리적 원거리, 등...특히 예산)안에서 서로의 양해가 된다면
가장 이상적인 방법은 우리측 의견에 한표가 아닐까 생각된다.
개인적인 잡담으로는, 기본이 갖춰지지 않은 회사는 아닙니다. ㅎㅎㅎ.
살짝 상처를 입었죠. 분발해야겠다는 생각도 있고요.
발주사로 부터 지적 받은 것은 QA에 대한 기본이 갖춰지지 않았다는 것.
사실 내용에 대해서는 이견을 제시하고 싶었지만, 갑-을 관계상 혹시라도 있을지 모르는 '갑'의 심기 불편이 있을 수 있어
이견을 제시하지 않았다.
개인적으로는 서로 이견을 주고 받으면서 지적유희? 를 즐기고도 싶지만 (사실 그럴만한 지식도 없지만.. ^0^~~)
글에 대한 표현이 혹시라도 상대방의 마음을 상하게 할까봐, 그리고 내가 글을 잘 쓰는 편이 아니어서 포기해야 했다.
혹시 제 블로그에 들어오셔서 이글을 발견하신다면, 이슈에 대해서는 진심으로 이견을 제시했을 뿐임을 알아주셨으면 합니다.
한편으로는 '기본이 갖춰지지 않은 회사'로 판명 받는 상황을 어떻게 잘 설명해야할 지 모르겠다.
이것은 나를 제외하고라도 나와 같이 일하고 있는 사람들의 명예를 실추하는 일이 아닌가 싶어 메일을 작성하였으나,
삭제되고 말았다.
어떻게 받아 들이셨는지는 모르겠지만 개인적 판단으로
이슈가 된것은 QA진행 전체에 대한 큰 틀 보다는 'Test Case를 누가 작성하느냐'의 문제이다.
Use case 작성한 곳에서 검증을 위한 Test case를 작성해야한다는 것이 나의 이견 제시였고,
반대쪽의 입장에서는 개발사에서 별도의 QA인력을 배치하여 작성해야 한다는 것이었다.
물론 우리가 개발자 이외에 QA만을 담당하기 위한 인력을 별도로 둘만큼 규모를 갖추지 못한 회사라 언급했고,
QA에 대한 인력을 갖출 생각이 없는 회사는 QA에 대한 기본이 되어있지 않다는 것이 그분의 의견이었다.
또한 조엘의 이야기도 언급해주셨는데, 아무래도 '3. My customers will test the software for me' 부분을 적용시킨것 같다.
여기에 대한 나의 의견은
언급된 netscape의 경우는자신들의 상품을 직접 기획을 하고서도 테스트는 일반 사용자들에게 맡기는 경우로 나와있다. 즉, 이 경우 테스터가 되는 일반 사용자들은 제품의 기획 내용을 알지 못한채, 그냥 그 제품을 쓰면서 버그들을 숨은 그림 찾 듯이 찾아서 리포팅 해야 하는 구조를 언급한 것이라 생각된다.
기획, 즉 use case를 작성한 곳에서 test case 작성없이 ' 배포->사용자 버그리포팅->버그fix->마이너 버젼 업 릴리즈' 라는 조엘도 언급한 대로 대단히 용감한(?) Test procedure를 적용한 사례이다.
반면,
이번의 경우는 use case를 받아 개발을 우리가 적용한 상태인데, 개발 기간 중의 테스트는 당연히 실행이 되었고, QA지원을 위하여 보다 detail한 exception상황을 찾아내기 위해서 use case를 작성한 곳에서 test case를 작성하고 이에 따른 testing 및 debugging을 진행하는 것이 개발사의 입장에서는 예산내에서 움직이기 가장 좋은 범위라 생각이 든다.
물론 예산의 범위는 각 사의 입맛에 따라 다르겠지만...
또한 최근(?) 각광 받고 있는 대부분의 RUP/XP/Agile등에 핵심적인 부분이 Use Case Driven의 기본 골격대로 최초 작성된 Use Case가 설계, 개발, 테스팅까지 Tracing이 가능한 구조를 갖도록 하기 때문에 use case를 작성한 사람이 test case를 작성하는 것이 맞다고 생각한다. 어짜피 개발사에서 작성을 한다 하더라도 use case를 작성하고 서비스를 기획한 곳에서 검증이 필요할 것이다. 결국 최초 기획하고 시나리오(use case)를 작성한 사람이 가장 효율적일 test case를 작성할 수 있지 않을까가 나의 생각이다.
여기까지 읽은 사람은 아시겠지만.
맞다.
양쪽의 의견이 같다. Testing의 중요성을 공감하고 있으나. 서로의 예산, 즉 투입인력이 난제인 것이다.
어찌 보면 한국문화에서는 개발사가 다해야 하는 정서가 맞겠지만, 또한 어찌 생각하면 개발사의 억지 주장? 일 수도 있지만
현재 상태 범위(예산, 기간, 지리적 원거리, 등...특히 예산)안에서 서로의 양해가 된다면
가장 이상적인 방법은 우리측 의견에 한표가 아닐까 생각된다.
개인적인 잡담으로는, 기본이 갖춰지지 않은 회사는 아닙니다. ㅎㅎㅎ.
살짝 상처를 입었죠. 분발해야겠다는 생각도 있고요.
덧글