X
STEN 회원이 되시면 테스팅에 관한 많은 정보와 자료를 공유할 수 있도록 저희가 돕겠습니다.
아이디
패스워드
자동로그인 사용
 
아직 회원이 아니십니까?    
아이디/패스워드를 잊으셨습니까?    

     
   
테스팅 프로세스를 표준에 맞추면 무엇이 좋을까요?
글쓴이 : 똘칠 날짜 : 19-03-26 22:32 조회 : 1400


“테스팅 실무는 실무이고, 프로세스는 프로세스이고, 표준은 그냥 표준이지!”라고 생각하시는 분들이 여기저기 방방곡곡 생각보다 많이 계시더군요. 곰곰이 생각해보면 몇 가지 이유가 있다는 생각이 들었습니다.

실무가 바빠 프로세스나 표준을 돌아볼 여유가 되지 않거나, 테스트와 관련한 표준이 있다는 것은 알지만 제대로 읽어본 적은 없는 경우, 지금까지 경험했던 업무 프로세스에 문제가 많아 프로세스에 대한 무한 불신이 생긴 경우, 마지막으로는 예전에 적용해보았지만 그다지 효과가 없었던 경험 등이었던 것 같네요.

실무가 쉬지 않고 돌아가는데 프로세스를 들여다본다? 당연히 어렵습니다. 선임자들이 만들어 놓은 불필요한 절차에 대항하기보다는 굴복해야만 하는 입장이라면, 역시나 프로세스의 ‘프’자만 들어도 경기를 일으킬 수 있죠. 세상에 태어나 살아 돌아다니는 표준은 너무나도 많기 때문에 실무 적용이 쉽지 않은 표준도 당연히 존재합니다.

테스팅 업무를 하려면 가장 먼저 필요한 것은 문서 템플릿입니다. 테스트 결과를 어딘 가에 정리해야 하니까요. 업무는 진행해야 하니 급한대로 필요한 항목을 넣어 테스트 케이스 문서, 테스트 결과 리포트 등을 만들었습니다. 시간이 조금 흐르면 프로세스의 필요성을 느끼게 되었습니다. 우리의 일은 많은 사람과 엮여 흘러가기 때문에 서로의 업무 순서와 절차가 많이 중요하기 때문입니다.

그럭 저럭 프로세스를 만들어 진행하다 보니 각 프로젝트마다 흘러가는 일의 모습이 매우 다르다는 것을 경험하게 되었습니다. A 프로젝트의 테스트 프로세스는 군더더기가 많고, B 프로젝트는 꼭 해야 하는 작업을 놓치고 있습니다. C 프로젝트는 테스트 케이스의 수준이 낮아 테스트 결과를 신뢰하기가 어렵습니다. 결국 우리 조직 내에서 공통적으로, 반드시 해야 하는 일을 정의하지 않았기 때문에 업무가 비효율적으로 돌아간다는 것을 느끼는 순간이 온 것이죠.

그러한 느낌 적인 느낌일 때 다시 테스트 표준을 찾게 되었습니다. 일전에 다른 테스트 표준을 적용해보았지만 표준 기반의 문서와 실무의 활동이 물과 기름처럼 겉돌고 있다는 생각이 들어, 만들었던 산출물들을 스리 슬쩍 종량제 봉투 속으로 묻어버렸던 찜찜한 기억이 있었습니다. 그럼에도 불구하고 ‘결론은 표준이 아닐까?’ 라는 실낱 같은 생각으로 29119 표준을 들여다본 것이죠(지금은 한글 버전을 배포하였지만 제가 공부하던 당시에는 영문 표준밖에 없어 눈과 뇌에 상당한 부하가 발생하였던 기억이 있습니다.)

예상보다 29119 표준은 실무와 가깝게 정의가 되어 있더군요. 생계형 테스트 템플릿도 부록에 가득 담겨 있었고요. 따라서 작성만 하면 적용이 가능한 정도였습니다. 은근한 기대가 생겨 회사에서 정의하고 있는 실무 프로세스와 29119에서 정의하고 있는 테스트 프로세스를 한 땀 한 땀 비교해 보았습니다.

의외로(?) 현업에서 우리가 하고 있던 활동 중 표준 프로세스 내에서 정의하고 있는 활동들이 꽤 되더군요(으쓱! 으쓱!) 당연히 누락되어 있던 구멍들도 보였습니다. 실제로 테스트 환경 구축 현황은 실무자들끼리 구두로 확인하고 테스트 리포트에 몇 줄 현황만 작성했는데, 표준에서는 테스트 환경 요구사항과 준비 리포트를 작성해야 한다고 정의하더군요. ‘이런 활동들을 제대로 확인하지 않아 업무가 종종 뒷산으로 갔었나…?’ 싶은 생각이 들었습니다.

현업에서 사용하던 테스트 템플릿도 표준에 기반하여 재정리하였습니다. 테스트 활동의 꽃은 리포트라고 하죠? 결국 상위 관리자에게 우리의 업무를 증명할 방법은 테스팅 리포트인지라, 29119 표준에서 정의하고 있는 테스팅 리포트 항목들을 현업에 반영하기 위해 노력했습니다(이 활동은 시간이 좀 필요합니다.) 표준에 기반한 템플릿 정리는 초기에는 하나의 프로젝트를 대상으로 진행하였고요, 이후 점진적으로 다른 프로젝트까지 확산하였습니다.

테스트 케이스의 품질 향상을 위해 29119 표준에서 제안하고 있는 테스팅 기법들을 업무에 적용하는 것은 간단한 문제가 아니었습니다. 테스트 매니저뿐만 아니라 테스트 케이스를 작성하는 테스트 디자이너들이 기법에 대해 잘 이해하고 있어야 하고요, 각 기법을 적용하기 위한 테스트 전략이 필요했습니다. 갈 길은 멀었지만 우리가 할 수 있는 수준에서 차근 차근 대처했습니다.

테스트 기법이 무엇인지 모르고 테스트 케이스를 작성하던 프로젝트 팀원들에게는 테스트 기법에 대한 교육을 받도록 했고요, 어느정도 테스트 기법을 알고 있는 테스트 디자이너들에게는 테스트 전략을 기반으로 테스트 케이스를 작성할 수 있도록 테스트 계획서의 충실함을 강조하였습니다.

테스트 케이스의 품질 향상은 사람의 역량 향상과 관련이 있기에, 이 작업은 매우 꾸준히 진행되어야 한다는 생각입니다. 업무를 위한 교육에의 투자도 필요하고요. 회사 차원의 지원이 없다면, 실무자 차원에서 가능한 부분은 매우 제약적인 편이죠.

그래서 ‘테스트 표준을 적용해서 무엇이 좋아졌는가?’라고 물으신다면 이렇게 말씀드릴 수 있겠습니다.
첫째로는, 기본적인 테스팅 활동이 누락되지 않습니다.
둘째로는, 업무를 위한 테스트 템플릿이 체계화됩니다.
마지막으로, 보장성이 높은 테스트 케이스를 확보할 수 있습니다.

대내적으로는 더 이상 주먹구구 식으로 업무를 하고 있지 않고, 구성원들이 지속적으로 성장하고 있다는 생각을 하고 있음을 느꼈습니다. 대외적으로는 고객 제안서에 29119를 기반으로 업무를 수행한다고 명시할 수 있게 되었습니다. 이전의 제안서 보다 훨씬 체계적으로 업무를 수행한다는 인상을 남기더군요.

아직까지도 표준을 기반으로 한 개선 작업은 진행 중에 있습니다. 우리에게 필요한 Testing Metric들이 조금씩 확정되어 가면서, 매뉴얼로 작성하던 리포트를 점차 대시보드 형태로 자동화하는 작업을 진행하고 있습니다. 그리고, 프로세스 내에서 사용하는 다양한 체크리스트들을 주기적으로 합의하여 고도화하고 있고요.

테스트 계획서 내부에 있는 리스크 관리나 테스트 전략 수립 등의 항목은 한 순간에 catch-up이 가능한 활동이 아닙니다. 따라서 지속적으로 업무 담당자들을 교육하면서 관련 프로세스를 개선해 나가야 합니다. 테스트 프로세스 개선을 위한 프로세스 전문가들도 점차 조직 내부에 생겨나고 있습니다.

시도해보십시오.
이러한 변화의 첫 시작은 개인적인 학습이었다는 것도 잊지 마시고요.

복어수 19-03-27 08:44
글 잘읽었습니다 하지만 29119적용해서 어떤것이 효과가 나타났다는 정량적 통계가 없습니다. 29119를 전사 적용한다고 하여 품질이 얼마나 올라갈까요?
magnet 19-03-27 09:59
소중한 글 감사히 잘 읽었습니다.
똘칠 19-03-27 10:10
투자대비 효과를 말하기는 조금 어려운 것 같습니다.
(정량적인 이익)/(ISO29119 표준 구입비+투입인원) 으로 계산해야 할까요? 저에게는 딱히 아이디어가 없네요 ^^;;
제 글에서 말씀드린 바 대로 빠졌던 활동을 챙길 수 있는 정도로도 어느정도 품질은 향상될 수 있을 것 같습니다.
만일 조직 내에서 ASPICE나 KOLAS 인정을 목표로 하신다면 무조건 29119를 준수해야 하기에, ROI를 따지기는 어렵지 않을 듯 합니다(ASPICE 인증 비 획득시의 손실비용 같은 것이죠)
표준을 기반으로 조직 내의 활동이 통일되면 각 조직(프로젝트) 별 검증 업무에 대한 비교 분석이 가능해지죠. 그 이후엔 공통된 품질 향상 목표를 잡고 점차 상향할 수 있습니다. 다양한 Metric들로 표준을 적용하기 이전의 상황과 그 이후의 상황을 비교할 수 있게 되니 그것으로 증명할 수 있지 않을까요?
     
복어수 19-03-27 13:35
똘칠님이 다르게 알고 계신 것이
ASPICE 인증 취득 해야 한다고 해서 반드시 29119 준수 하지 않습니다.물론 OEM마다 다르겠지만, OEM에서 29119를 요구 하지 않습니다.  케바케죠.
제가 양산 개발팀서 프로젝트서 2년동안 ASPICE 인증 준비 햇던 실무자였고, 29119 실질적으로 얘기 하는 사람 별로 없었습니다. ASPICE PAM 3.1의 레퍼런스에 나오긴 하죠. 하지만 그건 레퍼런스 일뿐이니 29119 잘 적용 하지도 않습니다. 그렇다고 ASPICE의 프로세스가 29119-2를 모두 적용 하느냐 꼭 그렇지 않습니다.
제가 경험한 심사원은 29119-3 기준으로 테스트 문서를 다 만드냐라고 묻지도 않습니다.

솔직히 ASPICE는 SW의 프로세스에 대한 인증을 보는 것이고, 유럽OEM이 PPAP 양산 전 인증을 좋아 하기에 취득 하는 것입니다.
프로젝트로 보면 29119를 적용 해서 뭔가 효과를 보는 것은 미미하다고 보여집니다.
29119의 모든 표준을 다 읽었고 리뷰 했던 사람으로서, 테스트 표준 적용 보다, 다른 것 적용 하는게 훨씬 효과적입니다. ASPICE 심사 비용도 구체적으로 알고 있는 저로선, 프로젝트에서의 품질 비용은 심사 인증이나 29119 보다는 제대로된 스펙 협의 미준수의 이슈가 훨씬 크죠. 29119 제대로 적용 한다고 해서 ASPICE의 인증을 취득 하는데 큰 도움이 되거나, 프로젝트 내에서의 SW품질이 올라가는건 아닙니다.
          
똘칠 19-03-27 13:57
저 역시 ASPICE 심사를 받는 업무를 해보았기에 말씀 드렸던 것입니다. 프로젝트 내에서 사용하는 테스트 계획서가 29119-3을 따라야 한다고 명시되어 있기에 조직의 구성원들 모두 이의 없이 29119를 기반으로 템플릿을 보완했습니다. 게다가 관련한 지식들도 테스트 엔지니어들과 공유했고요(심사 때 전혀 다른 답변을 하면 안되니까요.) 물론 심사원이 29119에 대해 매우 구체적으로 질문하지는 않습니다만, 전체 프로세스가 유기적으로 흘러가는 모습을 보여주기 위해서는 표준에 기반하여 업무를 수행하는 것이 결코 나쁘다고 보지 않습니다. 바람직한 모습이죠.
일례로 심사시에 세부 항목에서, 테스트와 관련한 답변을 29119가 아닌 다른 이론을 기반으로 답변한 동료가 있었습니다. 그 때 상당히 많은 질문이 들어왔었고요. 그 이후로는 가능하면 29119에 기반하여 답변을 하자는 의견들이 있었습니다.
어떻게 본다면 테스트와 관련한 내부 프로세스가 탄탄한 조직이라면 29119에 기반하지 않아도 심사에 특별히 문제가 없을지도 모릅니다. 하지만 처음 시작하는 조직이라면 시작을 29119의 프로세스 기반으로 set-up 하는 것은 아주 바람직하다고 생각합니다.
기능안전에서도 29119-4에 대한 언급이 있습니다. 관련 기법을 모두 사용해야 하는 것이 아님은 알고 있습니다만, 관련한 지식을 조직 내에서 학습하고, 어떻게 테스트 케이스를 작성할 때 녹여내야 할지에 대해 논의하며 개선하고 있습니다.
               
복어수 19-03-27 14:58
오히려 제가 테스트팀에 29119-3 기반의 문서로 나눠서 테스트 문서들을 가는게 어떻느냐 했을때 다 반대 했습니다. 각 레벨별 담당자에게 물어도, 표준은 알겠으나, 문서를 쪼개서 가는건 테스트 팀  담당자들도 무리라고 했습니다.

또한 형상 관리자 담당자에게도, 계획서, TC(설계 포함), 결과서 이외 29119-3 기반으로 테스트 문서를 나누는 것에 대한 생각을 물었을 때도, 반대 하더군요. 기본적으로 ASPICE에서 형상 관리자가 관리 해야하는 문서는 기본 60종이 넘어가고 HW까지 하면 기본 100종은 훌쩍 넘어가는데, 어떻게 테스트 문서를 더 분류 하느냐 하더군요.

그리고 제가 속한 회사도 29119 모두 반영 하지 않습니다. 프로세스 조직서 넣자고 해도, 반발이 심하기 때문에 적용 하기 어려울겁니다.

프로젝트서 29119 반영 한다고 하여 그 효과성은 미미합니다. 정확한 측정도 어려울 뿐더러, 오히려 리소스 낭비 측면도 있습니다. 차라리 29119 적용 보다 다른 부분에 시간을 더 투자 하는 것이 프로젝트에서 비용을 줄이는 방법으로 볼 수 있습니다.
                    
Won님 19-03-29 21:23
29119 반영해 프로세스를 개선하고 테스팅 업무를 보는 것의 효과성은 그것을 적용하는 분이 어떻게 하느냐에 크게 좌우된다 생각합니다.
정확한 측정은 29119 적용 때만 어려운 것이 아니고 모든 경우에 어렵고,
리소스 낭비는 이를 어떻게 적용하느냐에 따라 실제 낭비가 될 수도 있고 그렇지 않을 수도 있다고 생각되고요...

29119 적용보다 다른 부분에 시간을 더 투자하는 것이 프로젝트 비용을 줄이고 효과를 볼 수 있다면 그렇게 해야겠지만, 테스트를 전문으로 하는 입장에서는 어렵더라도(시행착오를 거치더라도) 테스팅 분야의 국제표준인 29119를 효과적/효율적으로 적용하는 경험을 갖는 것이 중요할 수 있다는 생각입니다.

제가 표현하신 의도를 잘못 이해하고 제 의견을 적었을 수 있으니, 혹시 그렇다면 양해 바합니다.
똥구라미 19-03-27 10:50
저는 양산하는 조직에 있는데 똘칠님의 글이 많이 와닿습니다.
QA의 대우는 누구나 할 수 있는 쉬운 일이라고 여겨지며, QA 파트로 전배를 오는 것은
쉬어가는 곳,, 누구나 softlanding이 가능한 직군으로 여겨집니다.
개발자에게 가장 많이 듣는 말 중에 하나가 바로 "전문성이 없다"는 이야기 입니다.
눈물 나죠,

Test에 대한 업무를 어떻게 정량화 할 것인가.. 전문성을 어떻게 보여줄 것인가..
이런 부분은 제가 제일 고민합니다.
저도 이러한 부분을 해결하기 위해 시도한 것이 바로 표준화 프로세스화 입니다.

사실 양산을 하거나 진단을 받으면 모든 활동에 대한 산출물에 대한 "근거/ 커버리지"입니다.

표준으로 이야기를 하니, 시간절약 및 커뮤니케이션 이슈들이 해결이 됨을 느낍니다.
제가 하는 말이 표준에 근거된 말이며 행동이니 전문성도 어필할 수 있고요.

이 글을 읽고 저만 이런 고민을 하는게 아니구나 라는 생각에 안도감도 들며 기분도 좋네요.

좋은글 잘 읽었습니다.
dani 19-03-27 12:47
좋은 글 감사합니다.

저는 작성자님의 글을 읽고 도입하려는 분의 의지와 지식이 굉장히 중요하다는 생각이 들었습니다.
프로세스에 관련된 표준들 중에서 29119에 대한 지식을 좀더 습득하시면서 좋은 점들이 보인게 아닐까라는 개인적인 생각이 들었습니다.

저도 국제 표준이라는 걸 접하면서 드는 생각이 백과사전같다라는 생각을 했었거든요.
예를 들면, 백과사전은 모두가 살 수 있는데 실제 활용할 수 있는 수준까지 가려면 참 많은 부분 시행착오를 겪어야 하지 않나 싶습니다.
저도 ISO/IEC/IEEE 29119의 영문버전부터 관심을 가지고 지켜보던 사람으로,
작성자님의 마지막 멘트에 적극 동감합니다~^^
좋다니까 써보자는 식은 모든 업무 과중의 원인일거 같습니다^^
우유아빠™ 19-03-28 09:22
비슷한 일 하시는 분들이 여기저기 눈에 띄어 행복합니다. ^^;;
저도 프로세스를 적용시켜 보면서, 또 과거에 컨설팅을 해 보면서 느낀 것 중 하나가
단기간 효과가 나타날 것으로 기대하는 임원진이 많다는 점입니다.
내재화가 될 때 까지 인내심을 가지고 기다릴 필요가 있는데, 당장 효과가 없다며 또 바꾸죠.
익숙해 지기 전 까지는 모든 절차가 마찬가지지만 일이 늘어날 수 밖에 없잖아요?

보통 프로세스를 레시피로 많이 비교 하는데, 새로운 조리법은 레시피를 보면서 하다보니
늦을 수 밖에요. 익숙해져야만 안보고도 가능해져서 빨라지는 것인데.. 그 익숙해짐을 못 기다리는 경우가 너무 많더라는 거죠.
효과, 효율도 바로 측정이 불가능 한 것이 누적된 데이터로 보여 줄 수 밖에 없으니
더욱 그런 것 같습니다.

아무튼 관련직종 분들 화이팅입니다.~ ^^/
오성환 19-03-28 15:47
ISO29119가 정책적으로 대한민국 품질 표준으로 인정되었으면 좋겠네요.
     
우유아빠™ 19-03-29 09:12
품질이라는 큰 범위에서 보면 29119는 한정된 부분을 커버하고 있어요.
저는 개인적으로 자동차나 의료 분야에서 기능안전성 표준을 준수해야 하는 것 처럼
분야별로 피해도가 발생할 수 있는 도메인에 따라 반드시 준수하게 만드는 기준을 정의 했으면 좋겠다는 생각을 합니다.
아무리 내부에서 발버둥 쳐 봐야 다수가 못한다 안한다고 하면 방법이 없거든요.
Won님 19-03-29 21:24
재밋게 잘 봤습니다.
댓글도 재밋게 잘 봤고요...^^

귀한 글 너무 감사합니다.
테스트아키텍트 19-05-03 10:36
좋은 글 감사합니다.
첫 문장 “테스팅 실무는 실무이고, 프로세스는 프로세스이고, 표준은 그냥 표준이지!의 맥락에 대해서도
평소 주변에 얘기하던 내용이라 더 공감이 되네요.
감사합니다.
     
똘칠 19-05-12 21:25
읽어주셔서 감사합니다 :)