본문 바로가기
Knowledge Base/소프트웨어 공학

QA Engineer가 알아야 할 ISO/IEC/IEEE 12207

by 코드네임피터 2023. 7. 6.
반응형

IT업계 종사하는 우리는 주어진 과업 수행에 있어 엄청난 양의 자료와 다양한 업무를 수행하는 이해관계자들과 함께 목표로 한 산출물을 만들어 가야 한다.
고객이나 비즈니스 측면의 정제/정련된 요구사항은 실무자에게 해야 할 일로 다가오며, 이를 곧 우리 프로젝트팀을 해내야 한다.
그리고 서로가 생각하는 원하는 방향을 제시하고 반드시 내지는 정황에 맞는 기준을 제시하게 된다.

QA Engineer는 비단 Testing 뿐만 아니라 유관한 많은 표준, 가이드, 절차 등을 접한다. 그래서 오늘도 우리는 정신없이 많은 프로세스에 올라타거나 놓치고 때론 치이며 살아가고 있다.
우리가 늘 접하는 그 프로세스의 기준인 표준(Standard)은 깊이(Depth)나 너비(Width)는 모두 제각각이며, 표준을 제정/개정하는 기구도 여러 곳이며, 그 연관도 모두 상이하다.

그렇다면, QA Engineer는 어떤 것을 알고 있어야 할까? 그것을 알아보자.

[국제 표준화 기구 및 체계 소개]

우선 표준 체계를 알아보기 전에 표준화 체계를 간단히 확인해보도록 하겠다.

  • ISO : International Organization for Standardization, 국제표준화기구
  • IEC : International Electrotechnical Commission, 국제전기기술위원회
  • IEEE : Institute of Electrical and Electronics Engineers, 국제전기기술자협회

표준에 포함되어 있는 표준화 기구 로고

모든 표준화 기구는 전 세계적인 참여로 생성된 것은 아니다. ISO의 경우에는 75년 전 25개국 대표가 런던에서 표준화의 미래를 논의하며 그 틀을 갖췄다고 한다.
조금 더 그 이력을 살펴보면 ISO의 관계자는 영국 토목기술협회에 대부분 소속되어 있었고, ISO의 사례와 같이 IEC나 IEEE도 당시 주력 비즈니스였던 토목 내지는 전기에 표준화를 진행해왔다.
그리고, 현대에는 소프트웨어까지 확장하여 그 영역을 계속 확장하고 있다.

우선, 업(業, Job)을 수행하면서 도움 될 표준과 그 연관성을 알아보도록 하자. 우선 표준은 다음과 같은 구조로 구성되어 있다.

  • {표준화 기구} + {일련번호} + : {생성 연도} + — {Part #} = 표준명

표준화 기구이 여러 곳이면 고유 일련번호를 가지며 릴리즈 연도에 따라 고유한 상태를 갖는다. 그리고 표준에 따라 다수의 파트 체계로 구분 관리될 수 있다.
앞서 언급한 ISO나 IEC, IEEE가 소프트웨어 국제 표준의 선두 그룹이며, 국내에는 KS와 같은 체계를 갖고 있다.

그럼 소프트웨어 생명 주기 전반에 유관한 내지는 알아두면 쓸 데 있는 표준들을 정리해보자.

  • ISO 9001:2015 QUALITY MANAGEMENT SYSTEMS
  • ISO/IEC 9126:2001 SOFTWARE ENGINEERING — PRODUCT QUALITY
  • ISO/IEC/IEEE 12207:2017 Systems and software engineering — Software life cycle processes
  • ISO/IEC 12119:1994 INFORMATION TECHNOLOGY — SOFTWARE PACKAGES — QUALITY REQUIREMENTS AND TESTING
  • ISO/IEC 14598:2001 SOFTWARE ENGINEERING — PRODUCT EVALUATION
  • ISO/IEC/IEEE 15288:2008 Systems and software engineering System life cycle processes
  • ISO/IEC 15504:2012 INFORMATION TECHNOLOGY — PROCESS ASSESSMENT
  • ISO 21500:2021 Project, programme and portfolio management — Context and concepts
  • ISO/IEC 25000:2014 SYSTEMS AND SOFTWARE ENGINEERING — SYSTEMS AND SOFTWARE QUALITY REQUIREMENTS AND EVALUATION (SQUARE)
  • ISO/IEC 25010:2011 System And Software Engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality model
  • ISO/IEC/IEEE 29119:2022 SOFTWARE AND SYSTEMS ENGINEERING — SOFTWARE TESTING
  • IEEE 829:2008 IEEE Standard for Software and System Test Documentation
  • IEEE1008:1987 IEEE Standard for Software Unit Testing
  • IEEE1012:2012 IEEE Standard for System and Software Verification and Validation

이외에도 많은 형태가 존재하지만, 필요에 따라 찾아 습득해둔다면 표준화 체계 이해에는 도움이 되겠다고 생각한다.
개인적인 생각이지만, 필자는 표준화 연구 노력이 어떤 수준인지 대략 알기에 표준화 기구의 표준을 존중한다.
하지만, 맹신할 필요는 없으며 정황에 맞게 커스터마이징하는 것은 개인이나 이를 수용하는 조직의 능력이라고 생각한다.

[ISO/IEC 9126, ISO/IEC 25010 근간은 바로 ISO 9001]

이제 본격적으로 소프트웨어 품질에 관해 이야기를 해보자.
모두 1차 산업에서 채취된 자원이나 생산물을 인간에게 필요한 재화로 변경하면서 2차 산업이 발전하게 되었다.
표준화 기구도 2차 산업에 근간을 두고 있으며, 효과/효율적으로 잘 만들고 관리하는 것들이 표준으로 제정되고 릴리즈되었다.

ISO 9001은 산업의 품질 경영의 기본일 뿐만 아니라 이를 기반으로 이후 산업에서의 품질의 초석으로 사용되었다.
산업 혁명을 거쳐 대부분의 시스템은 자동화되었고 소프트웨어 시스템으로 그 체계가 변화되었다.

출처: 정보통신기술진흥센터

ISO 9126은 소프트웨어(Product)의 품질 특성을 공학 관점에서 풀어 표준화한 내용이다.
아래 표준 간의 연관을 표현한 이미지다. Product 측면에서의 품질을 주로 언급하고 있다. 어떠한 Activity와 Task가 Product에 어떤 결과를 도출한다는 흐름으로 볼 수 있다.

출처: https://www.semanticscholar.org/paper/SquaRE-The-next-generation-of-the-ISO%2FIEC-9126-and-Azuma/07ce604fe9b9a7043170d6ae012d220539e48f9e

최근에는 이를 기반으로 유관 표준이 생겨나고 유지하다가 ISO/IEC 25010으로 확장 통합된 표준이 배포되었다.

[ISO/IEC/IEEE 12207은 필수 지식]

QA Engineer는 제품 사이드에서 테스트만 전담하지 않으므로, 프로세스와 성숙도 측면으로 확장해 나갈 필요가 있다.
그래서 필요한 표준은 바로 ISO/IEC 12207이다. 이 표준에서는 깊이는 얕지만, 프로세스 전체를 표현하여 상대적으로 상당히 넓은 편이다.
그리고 프로세스가 완성도를 더해가면서 성숙도에 대한 측정 등이 필요한 상황이 지속되기 마련이다. 성숙도 확인은 ISO/IEC 15504에서 그 방법을 표준화해두었다.

ISO/IEC/IEEE 12207과 성숙도, 품질 연관성

ISO/IEC/IEEE 12207은 소프트웨어 생명 주기 전반을 설명하고 있으며 유관 표준의 기초로 사용된다.
방법론에서 자주 사용하는 House 나 Square Model에서 주로 밑바탕으로 사용된다. 그리고 그 안에서 품질이나 프로젝트 관리, 성숙도에 대한 기둥을 세우는 방식으로 구현하곤 한다.

QA Engineer는 소프트웨어 생명 주기(SDLC)에서 Testing만 담당하지 않는다. 어쩌면 프로젝트에서 모든 이해관계자나 의사 결정자를 만날 수 있는 유일한 사람일 수도 있다.
요구사항 분석 → 설계 → 구현 → 테스트 → 이행(배포)으로 구성된 일반적인 모든 단계에서 테스트 단계로 연결하는 그런 역할이 바로 QA Engineer이다.

속된 말로 품질 쟁이는 SDLC 전반의 이해를 갖고 業에 임해야 한다. 그래야 원활한 커뮤니케이션을 통한 효율적인 품질 활동을 할 수 있을 것이며, 이는 곧 산출물의 성과로 이어질 것이다.

2008 → 2017 품질 관련 체계 변경 도식

본 표준은 2017년에 개정되며 IEEE의 표준으로 채택되었으며, 시스템과 소프트웨어 경계를 통합한 체계로 재편되었다.
그리고 성숙도 척도로 많이 사용되는 정량화된 관리는 조직이나 기술적인 프로세스에 포함되었다.

[마무리하며]

오늘을 살아가면서 ‘당면한 나무만 보고 하루하루를 살아가는 건 아닌가?’라는 의문을 던져봅니다. 한 발짝 멈춰서서 내지는 한 걸을 뒤로 물러서서 이제 숲을 살펴볼 노력도 필요하다고 생각합니다.
그리고 앞서 설명해 드린 것과 같이 확장한 개념으로 시스템이나 서비스, 표준을 이해하는 습관을 갖는 것이 어쩌면 이 시대의 IT인의 덕목이 아닐까 싶습니다.

오늘의 한마디!

  • Can’t see the forest for the trees. : 나무를 보지말고 숲을 봐라.
  • 走馬看山(주마간산) : 달리는 말위에서 산천을 구경하다.
  • 井底之蛙(정저지와) : 우물안 개구리
반응형

댓글