Tag Archives: Verification

Verification 및 Validation관점에서 Safety에 대한 차이


이런 질문을 던지고 싶다.

  • Safety를 Verification 관점에서 본다면 어떻게 평가해야 할까?
  • Safety를 Validation관점에서 본다면 어떻게 평가해야 할까?

 

굳이 평가 행위를 Verification과 Validation으로 나누고 싶지는 않은데, 그냥 생각해보자는 거다.

Scope을 나누기는 하더라도 실제 평가 방법이나 평가 환경은 동일할 수도 있다. (물론 다를 수도 있다..)

Verification을 한다면 Safety function의 의도된 행위의 여부에 중점을 둬야 할 것이다. 즉 ‘의도한 대로의 행동’을 보였는가?

하지만 Validation을 한다면 Safety function의 의도적 동작이 아니라, Safety Attribute의 달성 여부에 중점을 둬야 할 것이다. 즉, ‘충분한 safety가 달성되었는가?’

시스템 개발을 할 때, 고장모드 분석을 해서 발생 가능한 failure mode를 식별해서 plan을 세웠을 것이다. 그것이 operation이 되었건, system의 logic이 되었건…

그때 verification관점에서는 failure mode의 발생으로 인한 의도된 safety function이 구현되었느냐를 확인해야 할 것이다. 예를 들어 Air bag의 경우 박치기 조건에서 펑 튀어 나오냐..

Validation관점에서는 그런 fault injection혹은 non-nominal조건으로 충분한지에 대한 검토가 필요할 것이다. 박치기의 다른 조건을 본다던지, 아니면 펑 튀어 나오는 것의 로직이 타당한지에 대한 것이나, 아니면 그 로직의 malfunction에 대한 고려를 한다던지… 뭐 그런식..

별결 다 따진다고 하는지 모르겠다. 하지만 이게 어디 scope인지를 계속 따져야 나중에 개발 및 검증 범위를 명확히 하는데 도움이 된다.

경험한 사례로 SW수준의 설계를 System 아키텍처라고 한 것이나, System 요구사항을 Sw요구사항이라고 기술된 것을 봤다. 그런 방식으로 했을 때 별일 없을 거라고 생각하면 오산이다.

개발이 안되고 검증이 안된다.

그런 개념이 장착되지 않으면 대충 개발하고 대충 검증하게 되며, 품질도 대충대충된다.

그러면서 어쩔 수 없다고 항변할 것이다.

scope의 모호함으로 생기는 문제이다.

scope을 명확하게 잡게 되면

달성해야 하는 것과 포기해야 하는 것을 명확하게 나눌 수 있다.

반드시 지켜야 하는 것과 지키지 않아도 되는 것을 나눌 수 있다.

 

 

 

 

Advertisements

QA Engineer의 능력이 developer의 능력보다 떨어져 보이는 이유?


QA Engineer는 developer보다 역량이 부족하다고 생각하는 회사들이 꽤 되는 것 같다. 그렇다고 developer가 verify를 할 능력이 되느냐면 그것도 아닌거 같고, 그래서 verification에 다들 관심이 많은 것 같다.

어떤 QA Engineer에게서 이런 고민을 들은 적이 있다. 인터페이스 시험을 하는데에 어려움이 있다. 무슨 무슨 시험을 하는게 어렵다. 어떻게 하냐..

설계한 것을 들여다봤다. 일단 QA engineer의 입장에서 보면 어려움이 이해가 된다. 다른 사람이 만들어놓은 것이 art도 아니고 엄청 복잡하게 만들어놨는데, 설명하는 문서도 없고 그거 이해하기가 쉽지 않을 것이다.

그런 난해한 것으로 시험을 하라는데 이해도 안되는 것을 어떻게 시험할 수 있겠는가? 당연히 못하는 것이 자연스러운 것이고 당연한 것이다.

그럼 방법은 없는가? 있다. review에 참여해야 한다. 참여해서 작성자에게 그 내용의 의미를 물어봐야 한다. 그리고 QA engineer의 관점에서 그 문서를 검토해야 한다. review가 단순히 서류상으로만 존재하게 해서는 안된다. review가 통과된 산출물에 대해서는 QA engineer가 test를 수행하는 것에 책임을 져야 한다. 만약 test를 못할 것 같으면 review에서 강하게 태클을 걸고 설계상의 문제점들을 지적할 수 있어야 한다.

검토 회의에서 치고박고 싸우라는 의미가 아니다. 개발자는 순수 개발 관점에서 설계를 하겠지만, 그 설계가 검증이 용이한지, 아니면 유지보수나 사용편의성이나 그런 다른 관점에서 괜찮은 quality인지를 누군가가 봐줘야 하는데 그 역할을 관련 이해관계자가 해야 한다. 그 이해관계자 중 하나가 QA engineer이다.

QA engineer의 능력이 발휘되도록 하기 위해서라도 review는 반드시 해야 한다.

Review는 정말 중요한데 왜 안하는 걸까?


프로세스 개선 사례를 보면 비용대비 가장 효율적인 검증 활동은 Review라고 한다. 그런데 주변을 둘러보면 제대로 review를 하고 있는 곳을 보질 못했다. ISO 26262뿐만 아니라 DO-178C나 DO-278A같은 다른 개발 표준에서도 review를 상당히 중요하게 생각한다.

왜 현업에서는 review를 안하는 것일까?

1. 쓸데 없어 보인다. 

최근에 워낙 모델링, 분석 및 검증 도구가 강력한 것이 있어서 그것만 있으면 만능이라고 생각하고 CASE TOOL만능주의에 빠져서 그런지 review활동을 많이 무시한다. 코드 리뷰 같은 경우에도 그렇다. 대부분 MISRA-C:2004 혹은 MISRA-C:2012를 기반으로 하여 툴을 돌리고 나온 결과를 검토한다. 그러면 다 된 것으로 생각한다.

정말 그런가?

사람들은 인간이 하는 활동는 오류가 많이 개입될 수 밖에 없다고 생각하고 그렇기 때문에 도구의 힘을 빌리려고 하고 보다 형식화시키고 정형화 시키려고 한다. 그런데 그런 형식화와 정형화는 만능은 아니다. 어느 특정 영역에서는 도움이 되고 유용하기는 하다. 하지만 그것이 전부는 아니다. 형식화시키기 어려운 것들이 존재하기 때문이다. 그 부분에 있어서 형식화를 시키려고 시도하는 것이 형식주의자들의 목표이겠지만 일반인이 적용하기에는 쉬운 문제는 아니다.

MISRA표준이 나오게 된 것도 많은 경험자들이 과거의 실패사례와 경험을 집대성하여 나온 결과물들이고 툴이 나오기 전에는 코드를 하나하나 읽어가면서 점검을 했을 것이다. 지금이야 코드를 읽으면서 그런 규칙을 위반했는지를 검사할 필요는 없겠지만..

검토의 대상이 코드에 대한 것만 있는 것은 아니다. 요구사항도 검토 대상이고, 설계도 검토대상이고 모든 개발 산출물이 검토 대상이다. 그런데 동료에 대한 믿음이 강해서(?)인지 검토를 잘 하지 않는다.

믿지 않겠지만 cost대비 가장 효과적인 검증 활동이 review이다. 이런 얘기하는 나에게 야유를 보낸다. 진짜라니까? 책에서 그렇게 얘기했어..라고 얘기해봤자 현실을 모른다는 말만…

설계를 하고 설계검토를 생략한채 테스트를 해서 버그를 찾는 경우, 그 오류를 수정하기 위해서는 코드를 수정해야 하고, 수정된 코드의 재시험(단위, 통합, 최종)을 수행해야 한다. 설계 검토에서 오류 발견되었으면 그런 삽질 안해도 되는데..

필드나가기 전에 시험은 왜 하는 목적을 생각해본다면 구현하기 전에 설계 검토를 왜 하는지를 이해할 수 있을거라고 생각하는데, 모든 사람이 동의하는 것 같지는 않다.  인식의 전환이 매우 중요하다.

2. 바쁘다.

프로세스 개선하는 업무에서 검토하는 것이 좋다고 얘기했을때, 즉각적인 현업 담당자의 반응은 이랬다.

“할일이 엄청 많은데 검토 할 시간이 어딨냐? 현실을 너무 모르시네.”

그렇다. 바빠죽겠는데 무슨 얼어죽을 검토냐.. 검토할 시간에 다른거 하나 더 하는 것이 개인에게는 더 유리할 것이다. 누가 알아주지도 않는 검토따위 해서 뭐하랴? 사전에 문제를 예방한다고 누가 상을 준다더냐? 사고 터지고 수습하는 한이 있어도 예방은 하지 않으리라…

어찌보면 회사의 문화가 예방을 중시하는 문화인지 아닌지의 여부에 따라 달라질 수 있는 부분이다.

바쁘지 않아도 프로세스를 지켜서 하라는 것이 정말 짜증나는 일이 될텐데(왜냐면 각 개인별로 습관화된 업무 방식과 맞지 않으므로) 바쁘면 그게 지켜지겠나?

그런데 보통 회사에서는 바쁜데도 불구하고 프로세스를 지켜서 일을 하라고 하기는 한다. 그래서 잘 되는가? 일부는 잘 하기도 하지만 보통 그렇게 하는 척을 한다. 그래서 검토는 흉내를 내게 된다.

3. 어떻게 하는지 모르겠다.

검토에도 교육이 필요하다. 산출물을 검토하는 것을 가이드할 수 있는 체크리스트 같은 것들이 필요하다. 보통 체크리스트 하면 상당히 애매하고 모호하고 적용하기 어려운 체크리스트를 떠올리는 사람들도 꽤 있는 것 같다. 그래서 희한한 체크항목으로 검토했다고 show를 하는 곳을 많이 봤다.

체크리스트는 두가지 관점에서 만들어야 한다. 하나는 형식적 요소이다. 형식적 요소를 추출하기 위해서는 산출물의 템플릿이 있어야 한다. 템플릿으로부터 다음의 형식적 요소를 뽑아낼 수 있다.

1. 작성자가 기술되었는가?

2. 문서의 버전이 기술되었는가?

3. 문서의 개요가 기술되었는가?

다른 관점은 기술적 관점인데, 이는 개발 표준으로부터 추출해야 한다. DO-178C나 DO-278A에서는 검토하기 위한 표준(요구사항 표준, 설계 표준)을 요구하기 때문에 그 문서로부터 체크리스트를 만들면 쉬운데, ISO26262같은 경우는 그러한 표준을 요구하지 않아서 ISO26262만 알고 있는 사람은 이 부분을 어떻게 하라는 것인지 어려워 하는 것이 사실이다.

이 부분은 ISO26262외부에서 찾아봐야 한다. 가장 애매한 부분이기도 하지만 내부적으로 품질 기준을 수립해서 규칙을 정의할 수도 있다.

요구사항 같은 경우 요구사항에 대한 시험 가능성 관점에서 테스트 케이스를 만들 수 있는지를 검토하는 것도 중요한 검토항목중의 하나가 될 수 있다.

아니면 외부의 출처문서들을 조사해보면 다른 domain에 있기는 하지만 적용 가능한 유용한 점검항목들을 작성할 수 있다. 미국의 FAA나 NASA이나 유럽의 EURO CONTROL이나 Euro자금을 funding받아서 운영중인 프로젝트들을 보면 많은 도움을 얻을 수 있다.

체크리스트는 그 정도면 될 것 같고…그 외에도

검토하기 위한 절차서 혹은 검토 계획서가 필요하다. 실무자들은 검토절차서 및 검토 계획서에 대해 교육을 받아야 한다. 검토 회의에서 누구를 참석시킬 것인지 무엇에 대해서 논의할 것인지 몇시간 할 것인지 등 구체적인 사항들을 계획해야 한다. 일반적으로 권장되는 방법은 다른사람이 어떻게 했는지를 벤치마킹하는 것이다. Karl Wiegers의 Peer reviews in Software를 추천한다.

4. 싸운다.

개발자들 중 일부는 자기 산출물에 대한 다른 사람의 의견에 대해 상당히 못마땅해 하는 사람들이 있다. 의견을 제기하는 사람들이 비난하듯이 얘기한 것이 아님에도 불구하고.. 그러다보면 검토하다가 말싸움을 하게 되고 급기야 회의가 중단된다.

말하는 사람이 문제일 수도 있지만 듣는 사람이 문제일 수도 있다. 물론 네번째 이슈도 세번째와 같이 교육을 통해 인식의 전환을 유도해야 한다.

검토해달라고 해서 무엇에 문제가 있다고 지적하면 분위기가 싸해진다.

나름 신경써서 시간내서 봐줬더니만, 검토자도 기분이 나쁘다.. 검토받는자도 기분나쁘기는 마찬가지이다. 건방진놈이라고 생각하고 있을지도 모르겠다.

이런 상황에 대한 해결책은 리뷰 회의시의 커뮤니케이션 스킬을 높이는 것이다. 모리사키 슈지의 리뷰의 기술과 브라이언 피츠패트릭의 협업의 기술을 추천한다.