[팀블로그] 소프트웨어 테스팅 참고서

[특별 기고] 옛-ISTQB와 새-ISTQB 비교 및 테스트의 변화

2022. 5. 4. 21:38
글쓴이 © 『 Lv8+の 꽃怪獸 』 천년나무

목차

 

     

질문

옛-ISTQB와 새-ISTQB 비교 및 테스트의 변화

 

 

ISTQB 버전

ISTQB Syllabus 2007 그리고 2018

 

 

답변

이번 포스팅은 ISTQB에 인공지능(Artificial Intelligence) 관련 내용이 본격적으로 ISTQB 지식 체계에 들어오기 전, ISTQB의 변화에 대해 정리해봐야겠다고 생각한 필자들이 정리한 Syllabus 2007년 버전과 2018년 버전입니다.

 

이 두 버전 외에도 다양한 버전들이 있지만, STEN.or.kr에 한글 번역본으로 제공되는 V2007과 최신 버전인 V2018을 비교함으로써 지난 10년간 소프트웨어 테스팅이 어떤 식으로 발전하였는 가에 대해 간략히 이야기를 나누려 합니다.

 

먼저 각 챕터별로 변경점을 비교해 보겠습니다.

 

Chapter 별 변경점 비교

※ 주 : 각 챕터별로 차이점 비교 표기가 조금 다른 부분은 양해 부탁드립니다. 팀블로그 프로젝트를 하며 본 블로그의 필자들이 준비 과정에서 비교했던 내용들이다 보니 비교를 진행한 사람, 진행 시기 등에 따라 차이가 있을 수 있습니다.

 

전체 테이블을 쭉 펼쳐놓기엔 내용이 너무 많기 때문에 클릭하여 보시도록 준비하였습니다. 비교 내용을 세부적으로 읽고 싶으신 경우 아래 각 챕터 별 '변경 내용 비교 보기' 기능을 이용하여주세요.

 

더보기

Chapeter 1 비교

ISTQB-F V2007 ISTQB-F V2018
1.1 테스팅이 왜 필요한가 1.2 테스팅이 왜 필요한가?
     1.2.1 테스팅은 어떻게 성공에 기여하는가
   1.1.1 소프트웨어 시스템 관점에서의 테스팅의 필요성    (1.2.1로 대체된 걸로 보임)
   1.1.2 소프트웨어 결함의 원인    (1.2.3과 1.2.4로 대체된 걸로 보임)
   1.1.3 소프트웨어의 개발 유지보수 운영 시 테스팅의 역할    (삭제 혹은 이동)
   1.1.4 테스팅과 품질    1.2.2 품질보증과 테스팅 (Quality Assurance and Testing)
   1.1.5 테스팅 얼마나 해야 충분한가?    (삭제 혹은 이동)
     1.2.3 에러, 결함, 실패 (Errors, Defects, and Failures)
     1.2.4 결함, 근본원인, 영향 (Defects, Root Causes and Effects)
1.2 테스팅이란 무엇인가? 1.1 테스팅이란 무엇인가? (What is Testing?)
     1.1.1 테스팅의 주요 일반적인 목적 (Typical Objectives of Testing)
     1.1.2 테스팅과 디버깅 (Testing and Debugging)
1.3 테스팅의 일반적인 원리 1.3 테스팅의 7가지 원리 (Seven Testing Principles)
1.4 테스트 프로세스의 기초 1.4 테스트 프로세스 (Test Process)
   1.4.1 테스트 계획과 제어    (1.4.2로 통합 된 듯)
   1.4.2 테스트 분석과 설계    (1.4.2로 통합 된 듯)
   1.4.3 테스트 구현과 실행    (1.4.2로 통합 된 듯)
   1.4.4 테스트 완료 조건(Exit Criterria)과 테스팅    (1.4.2로 통합 된 듯)
   1.4.5 테스트 마감 활동    (1.4.2로 통합 된 듯)
     1.4.1 정황기반 테스트 프로세스 (Test Process in Context)
     1.4.2 테스트 활동과 필요 작업 (Test Activities and Tasks)
     - 테스트 계획(Test planning)
     - 테스트 모니터링과 제어(Test monitoring and control)
     - 테스트 분석(Test analysis)
     - 테스트 설계(Test design)
     - 테스트 구현(Test implementation)
     - 테스트 실행(Test execution)
     - 테스트 완료(Test completion)
     1.4.3 테스트 작업의 결과물 (Test Work Products)
     - 테스트 계획 작업 산출물
     - 테스트 모니터링과 제어 작업 산출물
     - 테스트 분석 작업 산출물
     - 테스트 설계 작업 산출물
     - 테스트 구현 작업 산출물
     - 테스트 실행 작업 산출물
     - 테스트 완료 작업 산출물
     1.4.4 테스트 기준과 테스트 작업 간 차이점 추적 (Traceability between the Test Basis and Test Work Products)
1.5 테스팅의 심리학 1.5 테스팅의 심리학 (The Psychology of Testing)
     1.5.1 인간 심리와 테스팅 (Human Psychology and Testing)
     1.5.2 테스터와 개발자의 마음가짐 (Testers and Developers Mindsets)
더보기

Chapeter 2 비교

ISTQB-F V2007 ISTQB-F V2018
2.1 소프트웨어 개발 모델 2.1 소프트웨어 개발 수명주기 모델
   2.1.1 V-모델(순차적 개발 모델)    (2.1.1로 대체된 걸로 보임)
   2.1.2 반복적-점증적 개발 모델    (2.1.1로 대체된 걸로 보임)
       2.1.1 소프트웨어 개발과 소프트웨어 테스팅
   2.1.3 개발 수명주기 모델에서의 테스팅    2.2.2 정황에 따른 소프트웨어 개발 수명주기 모델
2.2 테스트 레벨 2.2 테스트 레벨
   2.2.1 컴포넌트 테스팅(Component Testing)    2.2.1 컴포넌트 테스팅(Component Testing)
   2.2.2 통합 테스팅(Integration Testing)    2.2.2 통합 테스팅(Integration Testing)
   2.2.3 시스템 테스팅(System Testing)    2.2.3 시스템 테스팅(System Testing)
   2.2.4 인수 테스팅(Acceptance Testing)    2.2.4 인수 테스팅(Acceptance Testing)
2.3 테스트 유형 2.3 테스트 유형
   2.3.1 기능 테스팅(Functional Testing)    2.3.1 기능 테스팅(Functional Testing)
   2.3.2 비기능 테스팅(Non-functional Testing)    2.3.2 비기능 테스팅(Non-functional Testing)
   2.3.3 구조적 테스팅(Structural Testing)    2.3.3 화이트박스 테스팅(White-box Testing)
   2.3.4 변화 관련 테스트: 재테스팅/리그레이션 테스팅(Re-Testing and Regression Testing)    (2.3.4와 2.3.5로 분리된 걸로 보임)
      2.3.4 변경 관련 테스팅(Change-related Testing)
     2.3.5 테스트 유형과 테스트 레벨(Test Types and Test Levels)
2.4 유지보수 테스팅 2.4 유지보수 테스팅
     2.4.1 유지보수가 필요한 상황
     2.4.2 유지보수를 위한 영향도 분석
더보기

Chapeter 3 비교

ISTQB-F V2007 ISTQB-F V2018
3.1 정적 기법과 테스트 프로세스 3.1 정적 테스팅 기초
     3.1.1 정적 테스팅으로 검토할 수 있는 작업 산출물
     3.1.2 정적 테스팅의 효과
     3.1.3 정적 테스팅과 동적 테스팅의 차이
3.2 리뷰 프로세스 3.2 리뷰 프로세스
   3.2.1. 공식적 리뷰의 활동    3.2.1 작업 산출물 리뷰 프로세스
   3.2.2 역할과 책임    3.2.2 공식 리뷰에서의 역할과 책임
   3.2.3 리뷰의 유형    3.2.3 리뷰 유형
       3.2.4 리뷰 기법 적용
  3.2.4 리뷰의 성공요소    3.2.5 리뷰의 성공 요소
3.3 도구에 의한 정적 분석 (3.1에 내용이 포함된 걸로 보임)
더보기

Chapeter 4 비교

ISTQB-F V2007 ISTQB-F V2018
4.1 테스트 개발 프로세스 4.1 테스트 기법의 종류
4.2 테스트 설계 기법의 종류    (4.1.1로 대체된 걸로 보임)
     4.1.1 테스트 기법의 종류와 특성
4.3 명세 기반/블랙박스 기법 4.2 블랙박스 테스트 기법
   4.3.1 동등 분할(Equivalence Partitioning)    4.2.1 동등 분할(Equivalence Partitioning)
   4.3.2 경계값 분석(Boundary Value Analysis)    4.2.2 경계값 분석(Boundary Value Analysis)
   4.3.3 결정 테이블 테스팅(Decision Table Testing)    4.2.3 결정 테이블 테스팅(Decision Table Testing)
   4.3.4 상태전이 테스팅(State Transition Testing)    4.2.4 상태전이 테스팅(State Transition Testing)
   4.3.5 유즈케이스 테스팅(Use Case Testing)    4.2.5 유즈케이스 테스팅(Use Case Testing)
4.4 구조 기반/화이트박스 기법 4.3 화이트박스 테스트 기법
   4.4.1 구문 테스팅과 커버리지(Statement Testing and Coverage)    4.3.1 구문 테스팅과 커버리지(Statement Testing and Coverage)
   4.4.2 결정 테스팅과 커버리지(Decision Testing and Coverage)    4.3.2 결정 테스팅과 커버리지(Decision Testing and Coverage)
   4.4.3 그 외 구조 기반 기법    4.3.3 구문 및 결정 테스팅의 가치(The Value of Statement and Decision Testing)
4.5 경험 기반 기법 4.4 경험 기반 테스트 기법
     4.4.1 오류 추정
     4.4.2 탐색적 테스팅
     4.4.3 체크리스트 기반 테스팅
4.6 테스트 기법의 선택 (4.4를 상세화 하면서 포함된 걸로 보임)
더보기

Chapeter 5 비교

ISTQB-F V2007 ISTQB-F V2018
5.1 테스트 조직                                                         5.1 테스트 조직
   5.1.1 테스트 조직과 독립성    5.1.1 독립적인 테스팅
   5.1.2 테스트 리더와 테스터의 역할    5.1.2 테스트 관리자 및 테스터의 역할
5.2 테스트 계획과 추정 5.2 테스트 계획과 추정
   5.2.1 테스트 계획    5.2.1 테스트 계획의 목적과 내용
   5.2.2 테스트 계획 활동    (5.2.1에 포함된 걸로 보임)
     5.2.2 테스트 전략과 테스트 접근법
   5.2.3 진입 조건    5.2.3 시작 조건과 종료 조건(준비의 정의와 완료의 정의)
   5.2.4 완료 조건    (5.2.3에 포함된 걸로 보임)
      5.2.4 테스트 실행 일정 
      5.2.5 테스트 노력에 영향을 미치는 요소
   5.2.5 테스트 추정    5.2.6 테스트 추정 기법
   5.2.6 테스트 전략, 테스트 접근법    (5.2.2로 순서 변경)
5.3 테스트 경과 모니터링과 제어 5.3 테스트 모니터링과 제어
   5.3.1 테스트 경과 모니터링    5.3.1 테스팅에 사용하는 매트릭
   5.3.2 테스트 보고    5.3.2 테스트 보고의 목적, 내용, 독자
   5.3.3 테스트 제어    (5.3.1에 포함된 걸로 보임)
5.4 형상 관리 5.4 형상 관리
5.5 리스크와 테스팅 5.5 리스크와 테스팅
       5.5.1 리스크의 정의
   5.5.1 프로젝트 리스크    5.5.2 제품 및 프로젝트 리스크
   5.5.2 제품 리스크    5.5.3 리스크 기반 테스팅과 제품 품질
5.6 인시턴트 관리 5.6 결함 관리
더보기

Chapeter 6 비교

ISTQB-F V2007 ISTQB-F V2018
6.1 테스트 도구의 종류 6.1 테스트 도구 고려사항
   6.1.1 테스팅 지원 도구    (6.1.1로 통합된 듯)
   6.1.2 테스트 도구의 분류    (6.1.1로 통합된 듯)
   6.1.3 테스트 관리 지원 도구    (6.1.1로 통합된 듯)
   6.1.4 정적 테스팅 지원 도구       (6.1.1로 통합된 듯)
   6.1.5 테스트 명세 지원 도구    (6.1.1로 통합된 듯)
   6.1.6 테스트 실행 및 로깅 지원 도구    (6.1.1로 통합된 듯)
   6.1.7 성능과 모니터링 도구    (6.1.1로 통합된 듯)
   6.1.8 특정 목적 테스팅 지원 도구    (6.1.1로 통합된 듯)
     6.1.1 테스트 도구의 분류
6.2 도구의 효과적인 사용: 잠재 가치와 위험    6.1.2 테스트 자동화의 효과와 리스크
   6.2.1 도구 지원 테스팅의 잠재 이익과 위험                   (6.1.2로 통합된 듯)
   6.2.2 도구 유형별 고려사항   6.1.3 테스트 실행 및 테스트 관리 도구 고려사항
6.3 조직에 도구 도입 및 배포    6.2 도구의 효과적인 사용
       6.2.1 도구 선택의 주요 원칙
     6.2.2 도구 도입을 위한 파일럿 프로젝트
     6.2.3 도구 성공 요인

 

2007년 이후 소프트웨어의 발전사를 짧게 요약

아이폰이 출시된 2007년부터 2018년까지 소프트웨어는 엄청나게 빠른 속도로 발전해 왔습니다. 

 

스티브 잡스(Steve Jobs)가 2007년 1월 9일, 캘리포니아주 샌프란시스코에서 아이폰(iPhone)을 세상에 공개한 후 소프트웨어 업계는 "모바일의 시대"로 진입하였습니다. 위키피디아에 기록된 소프트웨어의 전체 역사 관점에서 보면. 2007년 이후 세상은 모바일-인터넷 환경에 맞게 「경량화-직관적-개인화」되는 방향으로 급격히 발전하였고, 이는 곧 ISTQB에도 영향을 주었습니다.

 

모바일 기기를 이용한 IT 기술 사용률이 가뿐히 PC 사용률을 넘어섰고, 예전에는 '젊은 세대의 성인'으로 분류되던 사람들만 사용하던 IT 기술들은 남녀노소 모두 사용할 수 있도록 보편화되었습니다. 이제 Personal Computer의 시대는 Personal Mobile Device의 시대로 완전히 진입하였습니다.

 

소프트웨어 개발에 있어서도 뚜렷한 변화가 나타났습니다. 서비스 사용자의 수가 폭발적으로 증가함에 따라 시스템의 규모가 커졌으며, 특히 플랫폼 사업자가 운영하는 시스템의 규모가 어마어마하게 커졌습니다. 이로 인하여 MSA(Micro-Service Architecture)는 이제 누구나 해야 하는 당연한 일이 되어 시스템은 컴포넌트 단위까지 분산되며 수많은 기술들의 사용이 당연하게 되었습니다. 애자일 개발(Agile Development)이 보편화되고 폭포수 및 여러 방법론들과 결합하며 하이브리드 형태로 진화하였으며, (테스트 전문가의 업무가 Checking 쪽에 집중되는 경향이 많이 나타나는 업종인) 웹 기반 서비스, 혹은 Assertion이 간단하거나 작동 방식이 Status Transition 기반으로 구성된 모바일 서비스를 제공하는 회사들에서는 TDD(Test-Driven Development)를 도입하는 곳이 많아졌습니다.

 

이 글을 쓰고 있는 2022년 현재는 온오프라인에서의 다양한 서비스의 융합이 발생하며 사용자의 행동 기반으로 테스트하며 진행하는 BDD(Behavior Driven Development)를 도입하는 회사들도 많아지고 있습니다.

 

ISTQB 발전에 대한 필자들의 분석과 생각

ISTQB Syllabus의 V2007과 V2018의 변화 내용을 살펴보면 (차이점이라기보다) 몇 가지 방향이 보입니다. 

 

먼저 알아볼 수 있는 점은 용어들의 정리입니다. ISTQB는 초기부터 '용어집(https://glossary.istqb.org)'을 제공해왔지만, Syllabus에 있는 내용들은 조금 더 간결하게 정리되었습니다. 예를 들어, V2007에서 1장의 '테스트 기초'는 V2018에서는 '테스트 활동'이라고 재-정의하여 설명하였고, 4장에서는 '명세 기반, 구조 기반'이라는 표현을 본문에 녹여 넣음으로써 각 Chapter의 구절들이 표현하는 바를 명확히 하려 했다는 점처럼 여러 군데에서 용어를 조금 더 명확히 표현하려 한 점이 눈에 띄게 나타납니다.

 

둘째, ISTQB는 테스팅 기법보다는 테스트를 왜 하는 가에 대한 고찰, 활동의 종류, 작업 결과의 종류와 분석, 위기관리, 도구와 자동화 등 전반적인 테스팅 업무에 대한 설명과 이에 대한 접근 방법을 설명하는 쪽으로 특화되어 가고 있다고 보입니다.

 

셋째, 전체적인 카테고리의 재-정리가 되었다고 보입니다. 분산되어 있으나 공통점이 있는 부분들은 합치고, 세부적으로 분리하여 나눌 부분은 나누어 다시 정리한 느낌이 있습니다.

 

이런 커다란 방향성은 위에서 설명한 모바일 시대로의 진입 이후 소프트웨어는 누구에게나 필요한 일이 되었고, 특별한 기술을 가진 테스트 전문가들이 필요함과 동시에 소프트웨어 개발 생명주기 내의 참여자들도 테스팅 활동에 참여해야 함을 의미합니다.

 

※ 참고 : ISTQB는 단 한 번도 "Testing이라는 작업은 Tester만 해야 한다"라고 말한 적이 없습니다.

 

언젠가 ISO/IEC/IEEE 29119 표준에 대해서도 필자들이 설명할 기회가 있겠지만, 일단 ISTQB Syllabus 내에서의 변화는 모바일의 시대 이후 다양화되고 구체화된 여러 소프트웨어 기술들에 대응하는 소프트웨어 테스트 방법론의 변화들을 수용한 걸로 보입니다. 또한, 애자일(Agile)의 시대에 맞추어 애자일 개발 방식으로 일할 때 필요한 여러 접근 방식을 29119 표준 내에 차용하면서, 이는 ISTQB에도 영향을 주고 있습니다. 조금 더 먼 미래를 보자면, 앞으로 테스팅 표준들은 자율운행, 인공지능 등을 접목한 방향으로 계속 발전할 걸로 보입니다. 이미 ISTQB에서 인공지능과 관련된 지식 체계를 정리하기 시작했고, 곧 출간될 예정입니다.

 

※ 참고 : KSTQB에 표시된 자격증 기준으로 자격증의 종류

• CTFL : SW 테스팅 Foundation Level 
 CTFL - AT: Certified Tester Foundation Level Agile Tester (CTFL-AT)
 CTFL - AI: Certified Tester AI 테스팅 (ISTQB CT-AI)
 CTFL - AUT: Certified Tester Foundation Level Automotive software Tester (CTFL-AuT)
 CTFL - MAT: Certified Tester Foundation Level Mobile Application Testing (CTFL-MAT))
 CTFL - MBT: Certified Tester Foundation Level Model-based Tester (CTFL-MBT)
 CTAL: Certified Tester Advanced Level (CTAL)
 CTA: - TAE: CTAL Test Automation Engineer [(ISTQB CTAL-TAE)]

 

이렇게 꾸준히 변화해가는 소프트웨어 산업에서 소프트웨어 테스팅 지식 체계는 그 발전에 맞추어 기술을 검증하는 역할을 맡고 있으므로, 업계의 전반적인 변화 속에 함께 발전할 수밖에 없는 운명을 가지고 있는 듯합니다. 이런 변화 속에서도 결국 큰 틀에서의 「품질 관리」는 변화하지 않고, ①설계, ②기획, ③구현, ④검증이라는 일련의 과정을 거치게 됩니다. 그리고 이를 수행할 수 있는 가장 주요한 활동은 역시 "테스팅 활동"입니다. 

 

그러니 ISTQB를 공부하신 테스터들이 「테스트 전문가」로서의 역할을 현재, 그리고 미래에도 계속하기 위해서 필자는 다음과 같은 의견을 드립니다. 

 

① 소프트웨어의 품질은 설계에 기반하므로, 아키텍트/설계-단에서부터 Test Plan & Design을 할 수 있는 역량 확보

② 새로운 기술의 개념을 접목할 수 있는 안목과 개발 역량 향상

③ 모듈화 되어 가는 테스트 라이브러리/도구들을 다룰 수 있는 자동화 역량 향상

④ 하지만, 가장 중요한 건 「소프트웨어 테스팅」이 전문 분야임을 알고, 전문가로서 본인의 입지를 확고히 하기 위해 체계적인 지식을 보유하고, 이를 조직에 전파하여 실무에 사용할 수 있는 역량 확보

 

마지막 이야기

ISTQB는 중요합니다. 왜냐하면 응용하는 방식은 바뀔 수 있어도 기본기는 변화하지 않기 때문입니다.

 

테스트 전문가가 할 일은 본인이 담당한 프로젝트/운영 업무에 대해 가능한 단계에서 「테스트 분석, 설계, 계획을 수립」하는 일입니다. 그리고 우리는 그것을 「QA, Quality Assurance」라고 부릅니다.

 

테스팅을 수행하는 데에 초점이 맞춰진 행위는 'QA가 아니라 테스팅'입니다. 테스팅 활동을 수행하는 건 프로그래머가 해도 되고, 기획자가 해도 되고, 그래픽 디자이너가 해도 되며, 사장님이 해도 됩니다. 테스트는 누구나 할 수 있는 일이니 누구나 수행하면 됩니다. 물론 전문성을 가진 테스트 전문가가 수행하는 테스트는 조금 달라야 합니다.

 

일반적으로 회사에서 'QA'라고 분류된 사람들이 테스트를 수행해도 됩니다. 하지만 "QA는 테스트 전담반이 아니어야 한다"는 점을 필자들은 힘주어 주장하고 싶습니다. 사업 내에서 모두가 함께 테스트할 수 있는 방법을 찾고, 각자의 역할을 나누어 각 개인이 할 수 있는 가장 좋은 테스팅 활동을 수행할 수 있도록 계획을 세우고 업무를 설계할 수 있어야 합니다.

 

그리고 QA와 테스트는 다르다는 점, 그리고 "테스트 전문가"는 테스팅 업무에 대한 전반적인 이해를 가지고 설계와 계획을 진행하고 관리해야 한다는점이 이 블로그 필자들의 공통적인 관점입니다.

 

테스트 표준화의 목적은 제품, 프로세스 또는 서비스 등 표준화의 대상이 본래의 의도된 목적으로 작용하도록 개선하여 모든 이해관계자의 원활한 의사소통, 공공이익 및 무역장벽의 제거 등을 추구하는 데 있습니다. 또한, 생산, 소비, 유통 등 여러 분야에 있어서 능률 증진 및 경제성 향상을 통해, 제품의 품질 개선과 생산 능률의 향상, 상거래의 단순화 및 공정화의 형태로 그 효과가 나타나기도 합니다.

 

테스트 표준(ISTQB)은 앞으로도 소프트웨어 테스트의 미래를 예측 혹은 현재의 트렌드를 반영할 것입니다. 또한, 과거의 잘못된 부분이나 불편한 점을 개선할 것입니다. 그리고, 실무자인 우리 역시 지속적으로 변화하는 표준에 적응해야 하며, 새로롭고 변화하는 기술에 맞추어 트렌드를 배우고 습득해야 할 것입니다. 그것이 「테스트 전문가」들이 나아가야 할 방향입니다.

 

 

참여자 정보

• 글쓴이 : 천년나무, 품생품사

• 검토한이 : 아이티마니, Bykj, 현의노래

 

 

STEEG 개인 의견

※ STEEG 전문가들의 개인 의견은 각 전문가 개인이 경험한 경력에 따른 주관적 견해입니다. 
    이런 개인 의견들의 경우는 그룹 전체의 의견을 대표하지 않음을 알립니다.

본 글과 관련한 전문가 의견이 아직 없습니다. 

 

 

관련 참고 자료

 ※ 아래는 필자들이 선정한 관련 외부 자료입니다. 
     아래 자료들은 필자들이 작성한 본문 의견과 다를 수 있으며, 필자들과 관련되지 않았을 수 있습니다.

 

 

Downloads - ISTQB® International Software Testing Qualifications Board

 

www.istqb.org

 

KSTQB

ISTQB® Foundation Level이 2018 버전으로 새롭게 업데이트되었습니다. 2019년 2월 26일 특별시험 부터 진행되는 ISTQB CTFL 자격시험은 ver.2018로 시행됩니다. 실라버스와 샘플문제를 첨부해 놓았습니다. IS

www.kstqb.org

 

History of software - Wikipedia

Software is a set of programmed instructions stored in the memory of stored-program digital computers for execution by the processor. Software is a recent development in human history, and it is fundamental to the Information Age. Ada Lovelace's programs f

en.wikipedia.org

 

ISTQB Glossary

 

glossary.istqb.org

 

What is SDLC? Phases of Software Development & Models

Discover what the Software Development Life Cycle is. 7 critical Phases of the SDLC, Models, & Best Practices for 2020. Start building quality software today!

phoenixnap.com

 

SDLC - Overview

SDLC - Overview Software Development Life Cycle (SDLC) is a process used by the software industry to design, develop and test high quality softwares. The SDLC aims to produce a high-quality software that meets or exceeds customer expectations, reaches comp

www.tutorialspoint.com

 

ISO/IEC/IEEE 29119-1:2022

Software and systems engineering — Software testing — Part 1: General concepts

www.iso.org

 

마이크로서비스 - 위키백과, 우리 모두의 백과사전

마이크로서비스(microservice)는 애플리케이션을 느슨하게 결합된 서비스의 모임으로 구조화하는 서비스 지향 아키텍처(SOA) 스타일의 일종인 소프트웨어 개발 기법이다. 마이크로서비스 아키텍처

ko.wikipedia.org

 

Software quality assurance - Wikipedia

Means of monitoring the software engineering process Software quality assurance (SQA) is a means and practice of monitoring the software engineering processes and methods used in a project to ensure proper quality of the software.[1]: 10–5  It may in

en.wikipedia.org

 

 

관련 동영상

iPhone Presentation in 2007

이 글을 공유합니다.

facebook twitter kakaoTalk kakaostory naver band