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

[링크 모음] 소프트웨어 테스트 아웃소싱 업체

『 Lv8+の 꽃怪獸』 천년나무 — Wed, 1 Nov 2023 11:40:58 +0900

대한민국 내에서 테스트 아웃소싱 서비스를 제공하는 업체들의 목록입니다.

※ 정렬 기준은 회사의 법인명을 기준으로 ㄱㄴㄷ, ABC, 123순으로 정렬합니다.

노츠

Knotz

This localhost page can't be found No webpage was found for the web address: http://www.knotz.co.kr HTTP ERROR 404 개발되는 모든 소프트웨어는 결함이 있습니다. 노츠 주식회사는 전문 테스트 엔지니어가 탁월한 테스트

www.knotz.co.kr

넷채널

NCL

www.netchus.com

더테스트

소프트웨어 테스트 전문기업-더테스트.

thetest.kr

두루 이디에스

DOOROO EDS 오신것을 환영합니다.

DOOROO EDS에 오신것을 환영합니다.

doorooeds.com

리드워크

(주)리드워크 | L-Walk

최상의 IT 전문 아웃소싱, 국내 최초 QA 외주 플랫폼 서비스를 제공하며 매년 성장하고 있는 스타트업입니다. 기능·성능·호환성·API·자동화 테스트, V&V 영역 등을 제공합니다.

www.l-walk.com

모바일나인

모바일나인㈜

모바일 S/W 테스트 및 관련 엔지니어링 분야의 최고를 목표로 하는 SQA 전문기업

www.mobile9.co.kr

메리티움

메리티움 (주)

We assure High-Quality Software Beyond testing, Governing Software Quality

meritium.co.kr

멘토스

소프트웨어테스트 전문기업 - MENTO's

멘토스는 소프트웨어테스트 및 시스템 운영 사업을 하는 전문 기업으로 다양한 산업 분야에서 고객의 품질 향상을 위한 서비스를 제공하고 있습니다. 고객사에 최고의 멘토역할을 수행하는 멘

mentoss.co.kr

슈어소프트

슈어소프트 | Suresoft

국내 최초이자 최고의 Mission-Critical 소프트웨어 전문기업 슈어소프트테크 입니다.

www.suresofttech.com

스플렉스

스플렉스 | SPLEX

스플렉스는 폭넓고 깊은 경험, 우수한 능력을 보유하고 있으며, 이러한 기술력과 노하우를 바탕으로 고객의 사업 경쟁력을 최고로 끌어 올려 드립니다.

www.splex.co.kr

씨너지큐브

씨너지큐브㈜

CMMI, ASPICE 기반의 시스템 및 소프트웨어 개발 프로세스 구축 컨설팅/심사, SP 품질인증, RAMS, QA, AI 학습데이터 검증

www.cnergycube.com

어니컴

ONYCOM, INC.

QA, 모바일 SI, WEB/APP, 빅데이터 솔루션, ankus, 성능 모니터링 솔루션, 자동화 테스팅 솔루션

www.onycom.com

에스티에이 테스팅 컨설팅

STA테스팅컨설팅-Global Testing Leader

RPA, 이커머스, 금융, 공공, 의료, 자동차, 원자력 시스템 등 여러 고객사가 STA와 함께하고 있습니다.

sta.co.kr

에이치비스미스

HB Smith

hbsmith.io

엔글

엔글 NGLE – THE BEST BUSINESS PLAN

마켓 관리 지원 Apple app store, Google play, One store, Steam, Oculus 등 마켓 별 정책 대응 Know-how 및 Featured 전략에 대해 가이드 · 마켓 앱 등록 가이드· 심의 Reject 사례 분석 및 대응· 마켓 Featured 관련 가

www.ngle.co.kr

엠스텍

http://www.mstech-one.com/

www.mstech-one.com

와이드넷엔지니어링

(주)와이드넷엔지니어링

디바이스 품질 관리, 소프트웨어 및 플랫폼 서비스 QA, 소프트웨어 개발/컨설팅

www.widenet.co.kr

와이즈스톤

와이즈스톤은 국내 최고의 소프트웨어 품질 전문기업으로 다양한 산업분야에서 테스트 서비스와 품질 관련 컨설팅 및 솔루션을 제공하고 있습니다.

wisestone.kr

와이즈와이어즈

전자, 통신, 금융, 전자상거래, 공공, 국방, 원자력, 자동차 - 신속하고 찾아가는 QA 서비스의 지속적 제공, 고객이 경험할 수 있는 다양한 테스트 문제점을 해결하기 위해 최선의 노력을 하고 있습니다.

wisewires.com

유닉솔루션

COMPANY 고객 감동을 실현하는 기업이 되겠습니다. --> 유닉솔루션(주)은 다년간의 현장 경험을 보유한 인력을 바탕으로 설립한 S/W테스트 아웃소싱 업체로서 나날이 강조되고 있는 S/W사업의연구

www.unicsolution.co.kr

이노아이

www.innoi.biz

인퀘스트

인퀘스트 주식회사 - 홈페이지

www.inquest.co.kr

인피닉

INFINIQ | Your Innovating Solution

Specializing in autonomous driving solutions based on artificial intelligence

infiniq.co.kr

제스큐

(주)제스큐

App 서비스 검증영역에서 부터 핀테크서비스영역, 클라우드 서비스 영역, 빅데이터 서비스 영역 등 구성 가능한 시스템의 시작단계부터 최종단계에 이르기 까지 다양한 영역에 대한 서비스의 수

zesq.co.kr

지앤서비스

고객과 통(通)하는 기업, 사람 중심의 기업, 전국적인 서비스망, AS대행, 서비스대행

www.gnsvce.com

컴즈

https://comes.co.kr/

We Expertly Solve Your Business Needs form Development to Testing We Present a Test Method Optimized for Your Own Business Field to Achieve Substantial Quality Improvement. Make Your Business Smarter and Agile with Our Optimized IT Experience and Competenc

comes.co.kr

코어프로세스

신뢰를 최우선으로 여기는 품질전문가집단,코어프로세스입니다.

www.coreprocess.co.kr

큐게임즈

QA,운영 | (주)큐게임즈

게임 및 소프트웨어 품질관리(QA) / 운영(CS) 서비스 전문 기업 (주)큐게임즈

www.qgamesidn.com

큐드

전장시험 전문업체 큐드

CUSTOMER SERVICE|정성을 다해 상담해 드립니다. 031-8019-8402 service_qood@qood.co.kr

www.qood.co.kr

큐로드

국내 게임운영대행 최대급 기업 큐로드

게임운영의 베스트 파트너인 큐로드(Qroad)는 고객사가 게임개발에만 집중할 수 있도록 QA, 커뮤니티운영, 마케팅, CS, 24시간모니터링, 로컬라이즈 등을 서포트하는 기술전문 기업입니다.

www.qroad.net

큐오피스

큐오피스 | Q-OFFICE

QA, 운영 서비스 및 소프트웨어 개발/공급 서울 강남구 언주로85길 24 (역삼동, PNMTOWER) 4층 큐오피스

www.q-office.co.kr

큐앤피플

Q&People

www.qnpeople.com

테스트웍스

테스트웍스 – AI 학습 데이터셋 구축 원스톱 서비스

AI 데이터 자동화 가공 관리 솔루션과 대규모 고품질 데이터셋 구축 경험으로 고객의 인공지능 개발 및 서비스 상용화에 기여합니다.

www.testworks.co.kr

테스트이앤씨

::: 테스트이앤씨 :::

www.testenc.com

티벨

TBELL – 테스트 서비스 전문기업

tbell.co.kr

티스퀘어

(주)티스퀘어

www.t-square.co.kr

티스퀘어랩

T SQUARE Lab – 티스퀘어랩

T SQUARE Lab, Your trustily ENGINEERING Service Partner Providing engineering service for the international automotive in Korea since 2010. And started to expand our area to Japan in 2021. We have strengths in engineering service in the field of Navigation

tsquarelab.com

티큐컨설팅

티큐컨설팅 | 테스트 프로세스 컨설팅, SW테스트교육서비스, 사용성 테스트, 테스트 아웃소싱, 테

서비스 테스트 프로세스 컨설팅, SW 품질 컨설팅, 제품 품질 검증, 사용성 테스트 도메인 금융, 임베디드 SW(자동차, 반도체 등), 모바일 서비스, 기반 기술 및 Package

www.tqconsulting.co.kr

화인폰

인재채용 패기와 열정을 가진 FINEPHONE의 인재를 찾습니다

www.fine-phone.com

휴먼수피아

(주)휴먼수피아

테스트 컨설팅 테스트 프로세스의 최적화 구축을 기반으로 지속적인 관리가 가능하도록 서비스를 제공합니다.

www.humansupia.com

테스트 아웃소싱 업체를 알려주세요.

이 블로그의 필자들은 아웃소싱 회사를 알게될 때마다 여기에 링크를 제공할 예정입니다. 이 페이지에 등록되지 않은 Sofware Testing Outsourcing 업체를 알고 계시다면 소프트웨어 테스팅과 품질 카페 혹은 소프트웨어 테스팅 참고서 제보 양식에 추천해 주세요.

필자들의 판단에 테스트 아웃소싱은 단순히 인력 제공만을 의미하기보다, 기기 대여/관리, 테스트 환경 구축/대여/관리 등을 포함한다고 생각합니다. 관련된 업체 정보를 모두 모아 정리해 보겠습니다.

참여자 정보

• 글쓴이 : 천년나무, 현의노래

• 제보해 주신 분들 모음
▶▶바나칸쵸님 { 큐드, 넷채널, 엠스텍, 와이드넷엔지니어링 }
▶▶eugene님 { 티벨, IGS, 휴먼수피아 }
▶▶빨간맛님 { 유닉솔루션, 모바일나인 }
▶▶가리님 { 큐게임즈 }
▶▶말랑말랑님 { 티스퀘어 }
▶▶채식공룡님 { 엔글 }
▶▶모그리나님 { 코어프로세스 }
▶▶아이디 비공개 요망하신 여러분들 모음 { 큐앤피플, 티벨, 와이드넷엔지니어링, 씨너지큐브, 멘토스 }

[링크 모음] 대한민국 소프트웨어 Testing과 QA 관련 글/영상 모음

『 Lv8+の 꽃怪獸』 천년나무 — Mon, 13 Mar 2023 13:05:28 +0900

대한민국에 있는 기업들 중에 Software Testing과 QA 작업 관련 내용들을 모아봤습니다. 당연히 프로페셔널한 각 개인들의 블로그들도 많습니다. 각 개인 전문가들의 블로그는 별도의 방법으로 소개할 예정입니다.

※ 모든 글은 회사명을 기준으로 ㄱㄴㄷ, ABC, 123순으로 정렬합니다.

강남언니

UT(사용성 테스트)로 고객 이해하기

사용성 테스트를 통해 고객과 친밀도 쌓는 법 by 강남언니 블로그

blog.gangnamunni.com

네이버라인

듀얼 QA 프로세스를 소개합니다 - LINE ENGINEERING

안녕하세요. LINE 플러스 서비스 QA 팀에서 같은 팀 김우영 님과 오픈챗 서비스 QA를 담당하고 있는 김진희입니다. 이번 글에서는 오픈챗 서비스가 무엇인지 간략하게 설명하고 오픈챗 서비스에서

engineering.linecorp.com

LINE의 QA는 어떻게 일할까? - LINE ENGINEERING

안녕하세요. 저는 LINE에서 서비스 QA로 근무하고 있는 김동성입니다. 이번 글에서는 LINE에서 근무하는 QA가 어떤 역할을 담당하고 있으며 어떤 목표를 세우고 어떻게 일하고 있는지에 대해서 이

engineering.linecorp.com

Youtube - Line Fukuoka, QA

사용자의 요구를 만족시키는 사용 품질 확보하기 - LINE ENGINEERING

안녕하세요. Fintech QA 팀의 화창득입니다. 다양한 제품이 쏟아져 나오는 요즘 시대의 사용자들은 끊임없이 서비스의 품질을 판단하며 이용 여부를 결정합니다. 사용자들의 판단 기준은 계속해서

engineering.linecorp.com

QA가 Shift-left와 Shift-right 접근 방법을 통해 더 나은 품질을 확보하는 방법

2022-LINE-engineering-site

engineering.linecorp.com

넥스트스테이지

[지스타] 능동적 QA가 중요, 넥스트 스테이지 '울트라 에이지' 제작기 | 루리웹

지스타와 인벤이 함께 주최하는 게임 컨퍼런스 G-CON X IGC에서 넥스트 스테이지가 하...

bbs.ruliweb.com

넥슨네트웍스

[NDC18] 나는 테스트 정책대로 살기로 했다.

[NDC18] 나는 테스트 정책대로 살기로 했다. 테스트 정책을 수립하면서 깨달은 것들 (폰트는 기본 폰트로 교체함)

www.slideshare.net

테스트 자동화 도구 개발 생존전략

달빛조각사에서 서버 테스트 코드를 작성하는 방법

데브구루

우리는 '어떤' QA를 해야할까?

QA 란 Quality Assurance 의 준말로 , Software QA 는 소프트웨어가 올바르게 구동하는지 테스팅 하고 , 제품의 품질을 높이는 활동을 말합니다 . 표준 프로세스는 존재하지만 어떤 일이든 ...

blog.devguru.co.kr

데브시스터즈

‘테스트 케이스’로만 테스트하면 안되나요?

테스트 케이스 기반 테스팅의 허점과 쉽게 탐색적 테스팅을 수행하는 방법을 알아봅니다.

tech.devsisters.com

고객 접점에서 ‘신뢰’를 만드는 사람들, QA 직군

전 세계 누구나 언제 어디서든 믿고 이용할 수 있는 서비스 ‘품질’은 과연 어떤 사람들의 손을 거쳐 탄생될까요? 서비스의 기획부터, 개발, 라이브, 운영까지 이르는 전 과정에서 함께 호흡하

tech-story.devsisters.com

드라마앤컴퍼니

초기 스타트업의 첫 QA프로세스 구축기

어? 이 소리는 제가 앱을 QA 테스트를 하던 중에 자주 하던 소리입니다. 저의 소리에 팀의 개발자 분들은 “또 버그 나왔어요?” 하며 긴장을 하시고요. 이제까지의 앱 개발과 배포 과정 중 QA

brunch.co.kr

딜라이트룸

QA? 그게 뭐에요? 먹는건가요?

안녕하세요. 딜라이트룸의 품질개선팀을 담당하고 있는 Lloyd입니다. 저희 회사는 “세상 사람들의 아침잠을 효과적으로 깨워주자!” 라는 목표로 현재 알람앱 Alarmy를 개발, 서비스 하고 있습니

medium.com

리디

테스트 환경 개선하기 - 리디 기술 블로그 RIDI Tech blog

불안을 없애려면 테스트가 필요합니다.

ridicorp.com

리멤버

리멤버 QA팀이 하는 일 - DRAMA&COMPANY

안녕하세요. 드라마앤컴퍼니 QA팀 곽수민입니다. 이번 포스팅에서 드라마의 QA팀은 어떠한 업무를 하고 있는지 소개하려 합니다. 삐까뻔쩍한 최신형 휴대폰을 사용해보았더니, 막상 전화 거는

blog.dramancompany.com

마켓컬리

BDD로 테스트에 중독되어 보자

나라가 허락한 유일한 마약

helloworld.kurly.com

뱅크샐러드

테스트 코드, 안드로이드에서는 어떻게 작성해야 할까? | 뱅크샐러드

…

blog.banksalad.com

스타일쉐어

소규모팀에 적합한 QA 프로세스 구축기(스타일쉐어팀의 QA방식) by 스타일쉐어(StyleShare)

안녕하세요. 스타일쉐어에서 PM을 맡고있는 박성환 입니다. 스타일쉐어팀이 QA프로세스를 도입한 것은 약 4개월 정도 되었습니다. 기존에는 QA 프로세스 없이 진행했었지만 주요 기능에 대한 오

www.theteams.kr

스텐 - STA 커뮤니티

https://www.sten.or.kr/

www.sten.or.kr

소포카

테스트 자동화 구축 이야기

도도 카트 애플리케이션 테스트 자동화 구축 과정을 이야기합니다.

spoqa.github.io

쏘카

쏘카 QA는 무슨 일을 하고 어떻게 일하나요?

안녕하세요. 작년 11월에 쏘카 QA 팀에 경력직으로 입사한 카밀라입니다. 신입 때 QA 업무는 반복적인 업무를 하는 단순 직무라 생각했었습니다. 하지만 여러 프로젝트들을 진행하며 커버리지를

tech.socarcorp.kr

씨제이이엔엠

The House of Software Quality

소프트웨어 품질의 집

techblog.cjenm.com

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

QA Engineer는 Testing만 진행하지 않습니다. SDLC 전반을 바라볼줄 알아야 합니다.

techblog.cjenm.com

아이앰큐에이

E2E 모바일 테스트를 위한 17가지 전략

모바일 앱 성능이 중요해짐에따라 QA는 소프트웨어 개발에서 중요한 파트가 되었습니다.하지만 기업에서는 QA를 아직도 선택사항으로 여기는데요. 이번시간은 기업에서 QA가 왜 필요한지와 다양

blog.imqa.io

와이즈스톤

와이즈스톤 공식블로그 : 네이버 블로그

Tested by WISESTONE 4차 산업혁명시대 소프트웨어 품질의 새로운 브랜드입니다.

blog.naver.com

왓챠

테스트 코드를 믿어도 될까 ?

테스트를 작성해온 지난 경험으로 적어본 주관 가득한 감상문

medium.com

엔에이치엔클라우드

실용적인 프론트엔드 테스트 전략 (1) : NHN Cloud Meetup

실용적인 프론트엔드 테스트 전략 (1)

meetup.toast.com

실용적인 프론트엔드 테스트 전략 (2) : NHN Cloud Meetup

실용적인 프론트엔드 테스트 전략 (2)

meetup.toast.com

실용적인 프론트엔드 테스트 전략 (3) : NHN Cloud Meetup

스토리북을 사용해서 시각적 요소에 대한 테스트를 자동화하는 방법에 대해 알아보았다. 기억을 되살리기 위해 우리가 작성하고 있는 할 일 관리 애플리케이션의 실행 단계를 다시 정리해보자.

meetup.toast.com

[Android] Unit Testing Framework - Robolectric : NHN Cloud Meetup

[Android] Unit Testing Framework - Robolectric

meetup.toast.com

Front-End 테스트 환경 (1) : NHN Cloud Meetup

Front-End 테스트 환경을 구축하는 방법을 공유합니다.

meetup.toast.com

Front-End 테스트 환경 (2) - 멀티 브라우저 테스트 환경 구축하기 : NHN Cloud Meetup

Front-End 테스트 환경을 구축하는 방법을 공유합니다.

meetup.toast.com

Github PR을 올리면 자동으로 테스트가? 심지어 멀티 프로젝트에도 가능하다! : NHN Cloud Meetup

저희 팀을 비롯하여 많은 분들이 사내에서 Jenkins를 CI/CD 도구로 사용하고 있습니다.

meetup.toast.com

엔씨소프트

게임 QA 자동화에 도전하다

리니지M, L2M 모바일 게임 테스트 자동화

blog.ncsoft.com

요기요

4년차 QA Engineer, 나는 지금 어디로 가고 있는가

이직을 고민 중인 3~4년차 QE, 우리들의 진로에 대하여

medium.com

요기요 QE Chapter 를 소개합니다.

무엇이든 내 일처럼 진심으로 도와주는 동료들이 가득해요

medium.com

우아한 형제들

QA != 통합테스트 | 우아한형제들 기술블로그

{{item.name}} 안녕하세요. 우아한형제들 품질개선팀에서 근무하고 있는 임선진입니다. 저희 팀에서는 우아한형제들 서비스와 제품에 대한 QA, QC, Testing 업무를 주로하고 있습니다. 이 글은 어찌보

techblog.woowahan.com

자동화된 UI 회귀테스트 도입하기 | 우아한형제들 기술블로그

안녕하세요, 사장님들의 주문처리를 위한 Windows Application 개발, 운영 및 보수를 하고 있는 장정환입니다. 이번 글은 사용자와 상호작용하는 Front-end의 검증 간 활용 가능한 'UI 자동화 Test 도입 배

techblog.woowahan.com

원티드랩

테스트 맵을 활용한 테스트

‘테스트 케이스’는 QA 업무를 대표하는 키워드 중에 하나일 것입니다. 프로젝트 팀원들이 QA 엔지니어에게 바라는 절대적인 작업 산출물이기도 합니다. 어떤 테스트 관리툴을 쓰느냐의 차이는

medium.com

위시캣

초기 스타트업의 첫 QA프로세스 구축기 | 요즘IT

"어?" 이 소리는 제가 앱을 QA 테스트를 하던 중에 자주 하던 소리입니다. 저의 소리에 팀의 개발자 분들은 “또 버그 나왔어요?” 하며 긴장을 하시고요. 이제까지의 앱 개발과 배포 과정 중 QA

yozm.wishket.com

줌

댓글 모듈 레거시 걷어내기 with TDD

서브도메인에서 사용되는 댓글 모듈의 레거시코드를 걷어내고 Vue, TypeScript, 그리고 Jest를 사용하여 효율적인 유지보수가 가능한 댓글 컴포넌트를 만들어 사내에 배포한 과정을 소개합니다.

zuminternet.github.io

카카오

테스트 코드 한 줄을 작성하기까지의 고난

이 글에서 설명한 내용은 11월16일~18일, if(kakao)2021에서 보실 수 있습니다. 안녕하세요. 창작자앱개발파트의 Ronda입니다. 창작자 앱 개발파트에서 브런치와 티스토리 안드로이드 앱을 개발하고 있

tech.kakao.com

테스트는 누구나 할 수 있지만, QA는 준비된 자만이 할 수 있습니다. #리스크기반테스팅 #RST #테스

시작하며 안녕하세요. 카카오엔터프라이즈 서비스품질파트의 테오입니다. 카카오엔터프라이즈는 카카오 워크, 카카오 i, 카카오 i 커넥트, 카카오 i 인사이트 등의 다양한 사업 영역에서 인공지

tech.kakaoenterprise.com

Redis 서비스를 만들어가는 QA Engineer의 기록

시작하며 안녕하세요. 저는 Chaos 팀의 Ella(최윤주)입니다. Chaos 팀은 카카오 i 클라우드의 서비스 전체 및 서비스를 관리하는 주변 플랫폼들에 대한 품질 관리, 즉 QA(Quality Assurance)를 담당하고 있

tech.kakaoenterprise.com

코인원

코인원 QA셀이 하는 일

QA는 매우 어렵고 전문적인 활동입니다. 프로덕트 QA를 위한 하나의 방법으로 ‘테스트’가 있고, QA 활동의 극히 일부의 영역입니다. 테스트는 품질을 향상하기 위한 행위 중 하나입니다.

medium.com

티몬

QE는 무슨 일을 하는 사람일까요?

QA 해주세요. 우리 주변에서 자주 들을 수 있는 업무 요청입니다. 제 생각이지만 한국에 있는 소프트웨어...

blog.naver.com

하이퍼커넥트

멈춰! 버그 멈춰! E2E 테스트로 버그 멈추기 Feat. Playwright

Playwright로 E2E 테스트를 도입한 경험을 공유합니다.

hyperconnect.github.io

화해

Unit Test 시작하기 – 화해 블로그 | 기술 블로그

Unit Test 단위 테스트는 우리가 작성한 코드가 의도한 대로 작동하는지 검증하기 위한 절차로 문제를 방지하는 기능도 있지만, 부수적으로 코드 변경에 의한 사이드 이펙트를 최대한 줄일 수 있

blog.hwahae.co.kr

좋은 글을 소개해 주세요.

이 블로그의 필자들은 대한민국 기업들의 좋은 Testing 관련 글이 있을 때마다 여기에 링크를 제공할 예정입니다. Software Testing과 Software QA 관련 좋은 글을 알고 계시다면 소프트웨어 테스팅 참고서 제보 양식 혹은 Software Testing and QA 카페에 댓글로 추천해 주세요.

※ 특정 개인의 인터뷰 형식의 글은 취급하지 않습니다. 그 회사의 기술이나 일 하는 방식, 혹은 프로세스를 알 수 있는 글들만 알려주세요. 감사합니다.

참여자 정보

• 글쓴이 : 천년나무, 현의노래, 아이티마니

요구 검증을 위한 테스트 케이스 작성은 어떻게 해야 하나요? (feat.설계)

품생품사(品生品死) — Wed, 19 Oct 2022 21:55:01 +0900

질문

ISTQB에는 테스트 케이스 작성하는 방법에 대한 내용이 없네요. 테스트 케이스는 왜 작성해야 하나요? 그리고 테스트 케이스를 어떻게 작성해야 할지 모르겠습니다.

ISTQB 버전

ISTQB Syllabus 2018

답변

테스트 케이스란?

ISTQB 실라버스에서는 테스트 케이스에 대해 "특정 프로그램 경로를 실행하거나 특정 요구 사항을 준수하는지 확인하기 위해 특정 목표 또는 테스트 조건을 개발된 입력값, 실행 사전 조건, 예상 결과 및 실행 사후 조건의 집합이다."라고 정의하고 있습니다.

ISTQB 실라버스 - 테스트 케이스 정의

하지만 ISTQB에서는 테스트 케이스 작성 방법에 대한 안내에 대해서는 설명하지 않습니다. ISTQB는 국제 표준에 가깝고 실무 안내서가 아니기 때문에 그렇습니다. 그래서 ISTQB 자격증을 획득한 사람들도 '실무와 거리가 멀다'라는 의견을 표현하곤 하는데, 사실 ISTQB는 실무와 매우 가깝습니다. '어떻게 해라'라는 방법을 콕 찝어서 설명하지 않는다고 해서 실무와 관련 없는 건 아닙니다.

어쨌든 대부분의 테스터들은 회사에 입사해서야 테스트 케이스 작성 방법에 대해 배우는 경우가 많습니다. 어느 정도 경력이 있는 QA나 테스터라면 여러 종류의 테스트 케이스를 많이 보았거나 작성해 봤을거라 생각합니다. 아마도 실제로 보시면 대부분의 실무에서 작성한 테스트 케이스는 사실 ISTQB 실라버스의 정의에서 이야기한 내용들이 포함되어 있다는 걸 아시게 됩니다. 필자 같은 경우 테스트 케이스 작성 시 아래의 내용들을 포함하여 작성하고 있습니다.

기획서 / 화면설계서 / 스토리보드 등 No.
메뉴 경로 - 분류 (대 / 중 / 소 / 기능명)
사전 조건, 테스트 데이터
시나리오 or 스텝
기대 결과
테스트 결과 입력 - PASS | FAIL | N/A | N/S | BLOCK
이슈 No. → 이걸 작성하는 이유는 아래 설명하겠지만 매우 중요한 개념
확인자
비고

샘플 포멧은 아래와 같습니다. 테스트 케이스의 형태는 회사마다, 제품마다 다르게 작성되므로 '대략적으로 이렇게 생겼구나' 정도로 이해해 주시면 됩니다.

테스트 케이스 샘플 포맷

이 포맷은 필자가 오랜 시간 수많은 테스트 케이스를 작성하면서 개선하고 수정하면서 나름의 최적의 테스트 케이스 포맷이라 느끼고, 근래에는 포맷의 수정 없이 잘 사용하고 있는 포맷입니다. 현재는 테스트 케이스 관리 도구(Zephyr, Xray 등)를 통해 작업을 하고 있지만 업무 외적인 테스트 활동을 할 때는 어김 없이 위 포맷을 통해 테스트 케이스를 작성하고 수행하고 있습니다.

필자가 이야기하고 싶은 내용은 구글링해도 많이 나오는 테스트 케이스 포맷에 대한 이야기를 하려는 것은 아니고, 결론부터 이야기하면 테스트 케이스 활용 목적에 따라 작성법과 수행 방법이 달라져야 한다고 이야기 하려 합니다. 이러한 개념을 ISTQB에서는 테스트 케이스 설계라고 말합니다.

테스트 케이스에 항목들을 구분하는 이유는 버그를 효율적으로 보고하기 위해서입니다. 어떤 항목들을 고려해야 하는 지에 대해서는 '버그 보고'와 관련한 필자 중 한명의 개인 블로그를 참고해 주세요. - 테스팅-버그보고-04편

테스트 케이스 설계란?

테스트 케이스 설계는 영어로 Test Case Design이라고 표현합니다. 여기서 우선 설계(디자인)라는 단어 뜻을 알아야 합니다. 소프트웨어 설계 또는 소프트웨어 디자인이라고 해석하는 Software Design은 "소프트웨어 해결책을 위한 문제해결과 계획 과정이다. 소프트웨어의 목적과 명세가 결정되면 개발자가 설계하거나 설계자를 고용하여 해결책을 위한 계획을 개발하도록 한다. 저수준 요소와 알고리즘 구현 문제, 그리고 구조에 대한 조망이 포함된다."라고 위키백과에 표현되어 있습니다.

필자가 직접 번역했다보니 번역이 조금 어색할 수 있지만 뜻을 좀 직역하면 "설계(디자인)에서 가장 중요한 단어는 문제해결과 계획 과정"이라는 것입니다. 그러므로, 테스트 케이스 설계라는 것은 문제 해결을 위해 테스트 케이스를 개발하고 테스트 수행 계획을 세우는 것을 의미한다고 볼 수 있습니다.

테스트 케이스 설계(디자인)

하지만, 이번 글은 테스트 설계를 어떻게 해야 잘 할 수 있는가에 대해 기법을 소개하는 내용이 아닙니다. 필자는 이번 글에서는 테스트 케이스를 작성하는 목적을 알아보고, 수립된 목적을 잘 풀어내어 효과적이고 효율적인 테스트 케이스 작성 방법을 알아보려 합니다. 사실 테스트 케이스 작성 목적이 명확해지면 테스트 케이스 설계(디자인)를 하고, 테스트 케이스를 작성하는 게 일반적인 절차입니다. 참고하시어 아래 내용을 읽어 보시기 바랍니다.

테스트 케이스를 작성하는 목적은?

테스트 케이스를 작성하기 위해 기본 베이스가 되는 문서가 몇 가지 있습니다. 이런 문서들을 기반으로 테스트 케이스를 작성하고, 이렇게 작성한 테스트 케이스를 이용하여 진행하는 테스트 수행 방식을 ISTQB에서는 명세 기반 테스트 기법이라 부르고 있습니다. 여기서 명세 기반이라는 단어는 바로 테스트 케이스 작성에 기반이 되는 문서를 의미합니다. 테스트 케이스 작성을 위해 활용되는 대표적인 문서는 다음과 같습니다.

테스트 케이스 작성을 위한 베이스 문서

이렇게 명세를 기반으로 작성된 테스트 케이스의 첫 번째 목적은 바로 "요구사항 확인"입니다. 여기서 말하는 "요구사항 확인"에서 "확인"이라는 표현은 검증과 확인(Verification과 Validation)을 의미합니다. 이 두 단어의 차이점을 간단하게 설명하면 검증(Verification)은 "제품을 올바르게 만들고 있는가?"를 의미하고, 확인(Validation)은 "올바른 제품을 만들고 있는가?"를 의미합니다. 우리는 테스트 케이스를 명세 기반으로 작성하였기 때문에 제품이 올바르게 만들어졌는지를 확인하게 되는 것입니다. 그러므로 테스트 케이스 작성의 첫 번째 목적은 요구사항대로 제품이 만들어졌는지를 1차적으로 확인하기 위한 목적이 될 수 있습니다.

두 번째는 예외 케이스를 처리하기 위한 목적의 테스트 케이스입니다. 테스트 케이스의 분류는 요구사항대로 작성된 테스트 케이스와 요구사항에 명시되지 않은 예외 케이스로 분류할 수 있습니다. 요구사항대로 제품이 만들어졌는지 확인이 완료되었다면 예외적인 상황에 대한 테스트 케이스를 작성해야 합니다. 이때, 예외적인 테스트 케이스를 작성하기 위해서는 테스터의 경험이 매우 중요합니다. 누구도 요구사항을 완벽하게 분석해서 기획 명세를 만들 수는 없기 때문에 요구사항 분석에는 다양한 관점이 투입되어야 합니다. 테스터의 관점은 그 중 사용자 관점의 예외 상황들을 도출할 수 있는 관점을 제공합니다. 그러므로, 다양한 산업 환경에서 도메인 지식이 많은 테스터일수록 다양한 예외 테스트 케이스를 작성할 수 있습니다.

세 번째는 테스트 케이스의 재사용입니다. 실무에서 테스트를 하는 테스트 전문가 중 테스트 케이스를 1회성 사용으로 작성하는 사람은 없을 것입니다. 왜냐하면 우리는 리그레이션(회귀) 테스트라는 중요한 숙제를 알고 있기 때문입니다. 리그레이션(회귀) 테스트는 간단하게 신규 혹은 수정 사항으로 인해 기존 잘 동작하는 기능/비기능이 문제없이 잘 동작하는지를 확인하기 위함입니다. 이때, 우리는 기존에 작성해둔 명세 기반의 테스트 케이스를 활용하거나 예외 테스트 케이스를 재사용하게 됩니다.

테스트 케이스는 프로젝트 내에서 변경되는 기획들, 소스 코드의 변경, 혹은 개발 환경의 변화에 매우 민첩하게 반응해야 하는 영역이기 때문에 유지보수가 유연하도록 설계(디자인)하고 작성하는 것도 매우 중요합니다. 이렇게 할 수 있는게 테스트 전문가의 역량이라 할 수 있습니다.

효과적이고, 효율적인 테스트 케이스 작성 방법

프로젝트 기간은 항상 정해져 있습니다. 짧게는 1~2개월, 길게는 6개월에서 1~2년으로 프로젝트 기간을 산정합니다. 프로젝트 기간 안에는 요구사항 분석, 설계, 구현, 테스트 등등 개발 생명주기를 포함하는데요. 어디서든 계획한 대로 일정을 지키지 못합니다. 물론 계획한 대로 잘 진행되면 매우 좋겠지만 보통의 현실은 그렇지 못합니다.

그래서 발생하는 문제는 "요구사항이 명확해야 개발이 들어간다. 개발이 완료돼야 테스트할 수 있다."의 딜레마에 빠지게 되는데요. 결국 마지막에 있는 테스트 일정이 데드라인(출시일 혹은 발주사 이관)을 기준으로 줄어드는 현상이 발생합니다.

그러면 어떻게 해야 제한된 시간 내에 가능한 많은 테스트 케이스를 확인할 수 있을까요? 앞에서도 말씀드렸듯이 테스트 케이스는 시장(Market)의 시시각각 변화하는 상황에서 데이터 변동이 발생하는 경우가 실무에서는 비일비재합니다. 그렇기 때문에 변화에 매우 민첩하게 대응할 수 있도록 작성해야 합니다.

그러기 위해서 최근 필자가 근래에 많이 활용하고 있는 테스트 케이스의 모듈화를 알려 드리려고 합니다.

모듈이란? "기어 톱니의 크기를 나타낸 값. 밀리미터로 나타낸 피치원의 지름을 톱니 수로 나눈 것."입니다. 한마디로 테스트 케이스의 모듈화는 테스트 케이스를 잘게 쪼개는 것을 의미합니다.

그러나, 테스트 케이스를 잘게 쪼개기만 해서는 테스트 케이스의 양만 많아질 것이기 때문에 추가로 알아야 하는 부분이 바로 테스트 시나리오 혹은 스위트(Suite, Set)입니다. 테스트 케이스와 테스트 시나리오에 대한 자세한 설명과 차이점은 본 블로그의 다른 필진이 작성한 글을 참고하시기 바랍니다.

테스트 시나리오는 하나의 흐름으로 시작과 끝이 있는 반면에 ISTQB에서 이야기하는 스위트(Suite)에는 해당 테스트 케이스를 쪼개진 것을 합쳐놓는다는 것에서 사용법이 조금 차이가 있습니다. 물론 스위트(Suite)를 테스트 시나리오와 같이 사용할 수도 있습니다.

테스트 시나리오를 기반으로 한 테스트 케이스 모듈화

로그인에서 A, B, C 기능을 포함하고 로그아웃까지 수행하는 테스트 시나리오가 있다고 가정해 보겠습니다. 이때, [A-1] 기능은 [A]와 연관된 영역으로 리그레이션(회귀) 용도로 추가되었고, [B] 기능은 로그인 기능에서 일부 수정되는 기능입니다. [C] 기능의 경우 [B]의 수정 영향으로 시나리오 수행이 어려워 제외한 테스트 케이스입니다.

이렇게 사용할 때 가장 중요한 것은 시나리오의 흐름을 중간에 멈추지 않고 로그인 ~ 로그아웃을 수행할 수 있어야 합니다. 흐름이 무너지지 않는 선에서 테스트 케이스 모듈을 넣어다 뺐다 할 수 있도록 하는 것이 중요합니다. 또한, 영향 범위를 명확히 알 때 시나리오를 구성하면 테스트 케이스 수행이 매우 효과적으로 될 수 있습니다.

또한, 이렇게 테스트 케이스를 모듈화하여 시나리오까지 구성이 되면 나아가 테스트 자동화 시나리오로도 활용이 가능합니다. 테스트 자동화 시나리오 작성법에 대해서는 나중에 따로 글을 작성해서 설명해 드리겠습니다.

테스트 케이스를 작성해야 하는 이유는?

우리는 회사에서 일합니다. 회사는 사업을 합니다. 사업은 영업 이익을 창출하기 위해 진행하는 활동입니다. 다시 말해, 영업 이익을 창출하기 위해 회사는 사업을 하고, 이를 위해 「사업 요구사항」을 도출합니다. 이 도출된 요구사항을 기반으로 제품과 서비스에 대해 기획을 하고, 시스템을 설계하고 구현합니다.

테스트 케이스는 처음에도 말씀드렸듯이 가장 주된 목적은 바로 사업의 요구사항이 잘 반영되었는지 확인하기 위함입니다. 영업 이익을 창출하기 위한 요구사항을 분석하는 테스트 관점을 더하고, 구현된 프로그래밍 결과물을 요구사항에 기반하여 확인(Validation)하기 위한 목적이죠. 그다음 목적은 예외적인 케이스에 대한 확인, 그리고 마지막으로 기존 기능에 문제가 없는지 확인하기 위함입니다.

그리고 QA라고 하는 포지션을 가진 품질 보증을 하는 분들을 위한 얘기를 간단하게 하자면 소프트웨어 품질을 정량적으로 측정하기는 불가능한 것을 잘 알고 계실 텐데요. 그래서 보통은 정량+정성을 잘 믹스해서 QA 리포트를 발행하곤 할 겁니다. 그리고 이런 정량적 측정을 가능하게 하는 것이 바로 테스트 케이스입니다. 테스트 케이스의 모수를 통해 품질률을 측정하는 것이 바로 그 시작입니다.

예를 들면, 요구 사항대로 작성된 테스트 케이스 100개 > 모두 수행하고, 실패가 없다면 품질률은 100%로 QA 리포트를 발행하면 됩니다. 하지만, 현실 세계의 우리에게는 예외 케이스 발생을 피할 수 없습니다. 물론 요구 사항 명세를 100% 다 작성했다 하더라도 사전 작업 즉, 요구 사항 누락이 발생하거나, 시장 상황이 변화하면서 요구사항이 변경될 수 있습니다. 이런 경우라면 테스트 케이스 수행을 100% 수행했다고 하더라도 빈틈이 발생하는 것이 현실입니다. 그래서 우리는 가정을 합니다. 요구사항 = 테스트 케이스를 100%으로 보자는 약속입니다. (테스트 수행 전 테스트 계획을 리뷰해야 하는 이유는 바로 그 약속을 하기 위함입니다.)

추가로 탐색적 테스트를 통해 발견한 이슈에 대한 리그레션 테스트 케이스를 +alpha로 더해 전체 테스트의 모수로 보자고 약속할 수 있습니다.

그래서 테스트 케이스 작성 포맷에 "이슈 No"를 넣습니다. 다시 한번 간단하게 말씀드리면 바로 「테스트 수행을 위한 준비 작업인 테스트 케이스」와 「테스트 수행 후 발생하는 테스트 이슈」의 분리해서 생각하기 위함입니다. 이 말은 더 단편적으로 표현하면 "이슈 내용 = 테스트 케이스는 아니다."라는 말입니다.

현업에서는 많은 사람들이 Jira나 레드마인에 등록한 이슈로 내용만을 보고 '확인 테스트'를 수행하곤합니다. 그 행위 자체가 잘못된 것은 아니지만 품질률을 측정하는데 요구사항을 중복으로 분석하고, 특정 부분만 집중적으로 테스트하고 나서 '살충제 패러독스'가 발생하면 "우리 제품엔 버그가 없어" 라는 착각을 하게 됩니다.

그래서 이슈와 테스트 케이스는 분리해서 관리해야 합니다. 그리고, 이슈에는 필수적으로 어떤 테스트를 수행하다가 발생했는지 테스트 케이스가 링크되어 있거나, 재현 방법이 기록되어 있어야 합니다.

마치며

테스트 케이스 작성을 어떻게 해야 가장 좋다는 정답은 없습니다. 자신이 속해있는 회사와 사업, 그리고 그 사업이 속해 있는 도메인(산업군)에 최적화된 테스트 케이스를 설계하고 작성해야 하며, 이는 매우 중요합니다. 가장 중요한 것은 사업의 요구사항을 이해 해야 한다는 점이며, 이를 잘 할 수 있는게 테스트 전문가(Test Expert)로서 갖추어야 할 역량입니다.

인터넷 검색을 이용해서 어딘가에서 가져온 다른 사람이 만든 테스트 케이스 포맷만을 가져다 자신이 속해 있는 회사 제품의 테스트 케이스를 작성하는 건 매우 위험한 일입니다. 해당 테스트 케이스의 형태가 본인 회사의 사업과 요구사항을 분석하는 데에 적합치 않을 수 있기 때문입니다. 테스트 케이스 포맷은 일반적일 수 있지만 테스트 케이스 설계 및 작성은 일반적일 수 없다는 것을 명심하시길 바랍니다. 물론, 위에 작성된 내용은 필자들의 경험에 의한 방법이고 모든 사업과 프로젝트에 일반화할 수 없습니다.

사업을 이해하고, 고객 요구사항을 이해하여, 수익을 창출해야 하는 것이 일을 잘하는 사람이겠죠. 테스트 전문가에겐 테스트 케이스 설계를 잘 하는게 프로그래머와 구분할 수 있는 테스터의 경쟁력이며, 이 역량을 키우는 일이 경쟁력 있는 테스트 전문가가 될 수 있는 방법입니다. 테스트 케이스 모듈화의 노하우를 통해 자신만의 테스트 케이스 설계 및 작성 방법을 찾아보시길 바랍니다. 감사합니다.

참여자 정보

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

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

STEEG 개인 의견

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

[테스팅 실무] 더 나은 버그 보고를 위한 테스터의 글쓰기 4편

목차 여러 소프트웨어 테스팅 관련 책에서 참조한 내용 소개 소프트웨어 테스팅 법칙 293가지 Software Testing The Testing Practitioner 개발자도 알아야 할 소프트웨어 테스팅 실무 소프트웨어 테스트 전

xeppetto.github.io

테스트하면서 요구사항 리뷰도 할 수 있나요? (실무 이야기편)

Bykj — Wed, 29 Jun 2022 22:07:28 +0900

질문

챕터 1.2.1의 "성공을 위한 테스팅의 기여" 부분에 보면, 대표적인 예로 든 「요구사항 리뷰」를 언급했는데, 요구사항은 기획자가 리뷰하는 것이 아닌가요? 테스트를 하다가 요구사항 리뷰도 할 수 있나요?

ISTQB 버전

ISTQB Syllabus 2018

답변

본 글은 2개로 나누어 구성하였습니다. 현재 보고 계시는 글은 두 번째 편으로 요구사항에 대한 좀 더 깊은 이야기에 대해 설명하고 있으며 기본 이해 편에서는 요구사항에 대한 기본 개념과 테스트와의 관계에 대한 설명하고 있으니 해당 부분도 함께 참고하여 주세요.

요구사항 리뷰를 왜 해야 하나요?

전쟁터 같았던 직장생활을 뒤로하고 이제 꿈에 그리던 멋진 은퇴를 꿈꾸는 당신. 저 푸른 초원 위에 그림 같은 집을 지어서 제2의 인생을 꿈꾸며 살아가고자 합니다. 그래서 이제 정말로 집을 짓고자 합니다. 잔디가 있는 넓은 마당에서 친구들과 바비큐를 하고, 수영장에서 운동을 즐기며, 나만의 영화관에서 영화를 보고, 밤이 되면 쏟아지는 별들과 함께 잠이 들어 큰 창문으로 들어오는 아침 햇살에 눈을 뜨는 아침을 시작할 수 있는 집을 여러분들도 원하시는지요?

무엇을 꿈꾸던 당신이 원하는 집을 지으려면 이렇게 당신이 원하는 것이 무엇인지 하나씩 나열해 봐야 합니다. 그것들이 모이면 짓고 싶은 집을 어떻게 만들지에 대한 기초가 될 것이며 그것을 바탕으로 집을 만드는데 길잡이가 될 것입니다. 이와 비슷하게 소프트웨어 개발의 기초는 요구사항입니다. 요구사항이란, 어떤 소프트웨어를 만들고 싶어 하는 것인지 나열한 것을 바탕으로 어떤 기능이 어떻게 동작해야 할 것인가를 프로젝트 참여자들이 이해할 수 있도록 만든 기록물이며, 그것을 바탕으로 우리는 개발을 하고, 테스트를 하고, 마케팅을 할 수 있습니다. 머릿속에만 있는 것을 개발할 수는 없으니 문서나 그림 등을 만들어서 공유해야 하는데 여기서부터 어려운 부분이 시작됩니다.

자, 그럼 저 푸른 초원 위 집에 그네를 하나 설치해 볼까요?

프로젝트가 어떻게 흘러가는가를 보여주는 예제

지금 이 글을 읽고 계시는 독자분은 어떤 그네를 원하셨나요?

누군가의 머릿속에 있는 생각을 남에게 설명할 목적으로 이야기를 풀어내는 건 참으로 어렵습니다. 말로 하면 금방인데, 글로 전달을 하려니 더 어렵게 느껴집니다. 내 생각을 표현한다는 데 있어서 어려운 점이 한두 가지가 아니지만 그래도 열심히 글 쓰고 그림을 그려서 요구사항을 전부 담아서 문서를 작성합니다. 자, 그러면 요구사항은 문서로 작성하고 나면 끝일까요? 이 문서가 일관성 있게, 적절한 설명과 함께 모두 이해할 수 있는 수준으로 작성된 것인지 확인을 해야 합니다.

이 문서는 한 사람만이 보는 문서가 아닙니다. 소프트웨어 개발자뿐만 아니라 영업, QA , 디자인, PM, 사장님 등등 프로젝트 전반에 참여하는 이해관계자들이 함께 보는 문서입니다. 모든 사람들이 한 번에 이해하고 바로 프로젝트 진행할 만한 문서였다면 좋겠지만 세상 일이 그렇게 쉽지 않다는 것은 누구나 다 알 것입니다. 각자의 관점이 다르고, 실무에서 활용하는 용어가 다르고, 이해관계가 다르다 보니 해석을 다르게 할 수도 있고, 수정을 요청할 수도 있고, 이해관계가 충돌해서 진행을 하느니 마느니 하는 논쟁이 생길 수 있습니다. 그 모든 의견을 반영해서 다듬고 수정하는 "관리"라는 것을 해야 합니다. 이 작업이 바로 「요구사항 관리」이며, 이를 위해 수행하는 활동 중 하나가 「리뷰」 활동입니다.

"기초가 중요하다"라는 말은 지겹지만 자주 듣게 되고, 또 강조되는 말입니다. 그만큼 현실에서는 잘 되지 않기 때문입니다. 기초를 대충 만들고 집을 짓다 보면 부실공사가 될 가능성이 큰 것처럼, 요구사항이 잘 정의되어 있지 않으면 만들 소프트웨어도 부실공사처럼 문제가 많이 생길 수 있을 가능성이 커집니다. 초반부터 리뷰를 꼼꼼히 하지 않고 진행하다가 개발 막바지에 문제가 터진 것을 확인하게 되면, 호미로 막을 수 있었던 일을 포크레인을 써도 막기 어려운 상황까지 가게 될 수 있습니다. 어렵지만 우리는 아주 가벼운 호미로도 모든 이슈 처리가 가능하도록 하기 위해 요구사항 관리와 테스팅을 위한 리뷰 활동을 진행해야 합니다.

필자 주1 「요구사항 관리」라는 건 하기가 참 어렵지만, 이에 더해 더 심각한 문제는 요구사항 관리를 제대로 하는 사람 혹은 경험해 본 사람을 구하기가 정말 어렵습니다. 또, 요구사항 관리는 Safety Critical 영역에서는 반드시 필요하지만, 대한민국처럼 즉각적인 소비자의 반응이 더 중요한 서비스 수준의 프론트엔드에서는 사용자의 의견을 즉각 반영할 수 있는 시스템 설계가 더 중요하게 부각됩니다. 그래서 이런 시스템들은 대부분 서버단의 영역만 요구사항 관리를 하는 경우가 많습니다. 이런 시스템이 Cloud에 올라가 있는 경우, DB와 API 단의 설계들을 중심으로 서버의 확장성에 따른 비용이 발생하기 때문에 SRS(Software Requirement Specification) 보다는 SDS(Software Design Specification)에 무게를 두게 됩니다. 한국의 IT 시장이 발전하면서 한국 특유의 「빨리 빨리 문화」와 「애자일 문화」가 겹쳐지며 '요구사항 전문가 부재'라는 문제점을 낳은 건 어쩌면 피할 수 없는 필연이 아닐까 싶습니다.

일반적인 실무에서의 리뷰

이런저런 이유들로 우리는 일반적으로 실무를 진행할 때는 요구사항 관리를 거의 하지 않습니다. 실무를 진행할 때는 요구사항을 관리를 해야 하는지, 아닌지에 대해 큰 관심도 없고, 필요성도 잘 느끼지 못하고, 어렵고, 애자일 철학과 뭔가 맞지 않는 느낌이 드니까요. 그래서 '기획 리뷰 정도로 충분하지 않나...' 하고 일상적으로 치부하고 넘어가게 됩니다. 그리고 이렇게 진행하면 "매번", 그리고 "항상" 거의 모든 상황에서 프로젝트의 기획 담당자에게 꽤나 많은 부하를 발생시키게 됩니다. 이는 바로 요구사항 리뷰 활동을 하지 않아서 발생하는 현상입니다. (조직 내에 기획만 하는 담당자가 있으면 그나마 다행이겠지만요...)

요구사항 리뷰를 명확하게 하지 않고 기획 단계의 산출물을 기준으로 업무를 진행하겠다 함은 사실 무척이나 현실적인 가정 사항을 기반으로 작동하게 됩니다.

① 요구사항을 낸 담당자들은 대부분 임원급 사람들의 의견을 기반으로 진행하기 때문에 그들이 틀렸을 리 없다

② 그들이 틀렸어도 내 책임이 아니다

③ 힘없는 일개 노동자인 내가 요구사항 관련해서 의견을 개진해서 책임을 지기 싫고, 기획으로 만들어 오면 거기서부터 보겠다.

...정도의 방어적이고 보수적인 태도에서 개발에 참여하게 됩니다. 우리는 모두 힘없는 월급쟁이 엔지니어일 뿐이니까요.

그런데, 그래서 생기는 실무의 문제들이 있습니다. 요구사항에 대한 리뷰를 하지 않으면 기획을 세부적으로 만들어가면서 발생하는 문제들에 대해 도움을 받기 힘들기 때문에 기획 담당자들에게 너무 큰 부하와 부담이 생기는 점, 그리고 앞단의 잘못된 부분에 대해 누구도 리뷰를 해 주지 않고 진행하면서 발생하는 기획/개발 업무의 부하입니다. "뭐든 앞단에서 바로 잡아야 제대로 잡힌다"라는 부분은 사실 소프트웨어를 개발해 본 사람이라면 누구나 알고 있는 만고의 진리입니다. 그런데 앞에서 리뷰를 제대로 하지 못해서 나중에야 문제가 있음을 발견하게 되고, 이를 수정하려고 했을 때는 이미 구조적인 설계상 더 이상 개선할 수 있는 한계로 인해 덕지덕지 땜빵을 하게 되거나 눈덩이처럼 불어나 버린 이슈에 대한 근본적인 해결이 불가능한 상태로 발전한 무서운 괴물이 될 가능성이 높습니다.

이와 관련해서 이해를 해보고 싶으신 분들은 본 블로그의 다른 글인 "소프트웨어 테스팅의 7가지 원리 - 3. 조기 테스팅" 포스팅과 "개발 초기에 테스팅하라" 포스팅을 참고하시면, 소프트웨어 테스팅과 관련된 원론적인 추가 내용들을 보실 수 있습니다.

단순한 모바일 앱을 하나 만드는 경우에도 UI를 어떻게 어느 정보를 가지고 배치할 것인지, 백엔드(backend)를 어떻게 구성해야 좋을지, 단순해 보이는 기능 뒤에 숨겨진 개발의 난이도는 어떻게 해결을 해야 할지, 성능은 어느 정도 수준을 맞춰야 하는 것인지, 호스팅과 서버는 어떻게 얼마나 구성하고, 유지 비용은 얼마나 청구가 될 것인지 등등 셀 수 없는 고려해야 할 사항들이 가득한데 이런 고민들은 미리 하지 않고 막상 닥쳐야 그때부터 고민하기 시작하는 게 일반적인 실무 환경에서 일어나는 일입니다. 그래서 다들 관련 일을 해본 경력자의 누군가가 해결해 주기를 바라고 있습니다.

필자 주3 - 이 글을 읽으시는 분들의 회사에 어느 정도 경력이 제대로 쌓인 「테스트 전문가」와 함께 하고 계시다면, 그들은 이상할 정도로 개발 프로세스의 앞단으로 진출하려고 노력을 하는 모습을 관찰하게 되실겁니다. 누군가의 입장에서는 "왜 테스터들과 QA들은 뽑아 놓으면 자꾸 정치를 하려고 하지?" 하고 생각하실 수도 있겠습니다만, 사실 그들의 이런 행동(개발 프로세스의 앞단으로 나아가 참여하려는 행동)은 소프트웨어 테스팅을 업으로 삼은 사람이라면 누구나 해야만 하는 당연한 전문성을 발휘한 행동입니다. 마치 프로그래머들이 더 쉽고 강력한 라이브러리를 찾고, 제품에 더 알맞는 좋은 패턴을 찾으려고 노력함과 같이 Testing 분야의 전문가들은 「요구사항과 그 요구의 본질을 향해 테스팅의 칼날을 세워야 품질이 좋아짐을 본능적으로/이성적으로 깨달아 하는 행동」일 뿐 「사내 정치」와 전혀... 0.1그램도 관련이 없습니다. (그러니 "요구사항까지 테스트 범위에 넣어야 한다"라 주장하고 실제로 할 수 있는 사람을 만나거든 모셔서 채용하십시오. 정말 흔하지 않습니다.)

요구사항 리뷰는 어려운 거 맞죠? 그럼, 어떻게 시작하면 좋을까요?

예, 맞습니다. 요구사항 리뷰는 어렵습니다. 요구사항 리뷰를 실제로 진행해 보면 시간이 오래 걸리는 작업이고 결과물이 번듯하게 나오는 것이 아니다 보니 요구사항 리뷰를 프로세스로 넣어 진행 하자는 당위성을 현실에서 찾기도 어렵습니다. 리뷰 자체에 대한 필요성을 느끼지도 못하고 한다고 해서 무언가 눈에 띄게 나아지는 것이 보이지는 않으니까요. 언젠가 소프트웨어 업계 전반의 이해가 발전하기를 바랍니다만, 현재로서는 그렇습니다. 그러니 프로세스가 조금이라도 갖춰져 있다면 그걸 활용하면 되겠지만 그마저도 없다면 매번 프로젝트마다 삽질하는 것을 반복하기를 싫으니 그 현실적인 상태에서 본인이 하실 수 있는 게 무엇인지 찾아야 합니다.

먼저 무언가 화려해 보이는 리뷰 활동보다는 테스팅 업무를 하면서 하나씩 찾아가야 합니다. 하나씩 찾아가면서 이를 해결할 방법들을 찾다 보면, 자연스럽게 테스트 전문가들이 요구사항 관리 단계 내로 들어가게 됩니다. 앞으로, 앞으로 나아가 테스트를 시작하기 전에 테스트 케이스를 만들기 시작할 때부터 기획과 구현 사항을 리뷰해야 합니다. 테스트를 수행하면서도 리뷰를 할 수 있겠지만, 그 시점은 이미 기획과 구현이 많이 완료된 상태이므로, 기획이든 구현이든 시작 단계에서부터 리뷰 할수록 효과는 좋아집니다. 그렇기 때문에 어떤 단계이든 가능한 한 빨리 시작을 해야 합니다. 요구사항을 만들 때 같이 참여하면 더 좋겠지만 보통 대부분의 회사에서는 테스터들에게 그런 기회가 주어지지는 않습니다.

이와 관련한 예들은 본 글의 1편 "테스팅을 하면서 요구사항 리뷰도 할 수 있나요?" 포스팅을 참고하시면 테스트를 하면서 어떻게 진행해야 할 것인지에 대한 감을 익히실 수 있을 것입니다.

단순히 이슈를 찾는 활동이 안정화되어 좀 더 높은 단계로 가고자 하시면 테스트를 하고, 버그를 찾고, 버그를 유형별로 정리하고, 반복되는 이슈들을 확인하여 정리하고, 분류해야 합니다. 그리고 프로젝트 종료 후 그 이슈들의 원인, 근본적 성질을 고민해야 합니다. 그리고 이를 예방하기 위한 방안과 예방 활동을 하지 않은 경우에 대한 비용, 일정, 내부 인원의 역량 등의 상관관계를 고려하여 개선해야 합니다. 그렇게 해서 설계 > 기획 > 요구사항의 순서대로 차분히 앞단으로 나아가야 합니다. 최종적으로는 요구사항들을 명확히 정의하고, 정리하여 사업/개발 관리 가능한 형태로 만드는 게 목표입니다.

필자 주 - 4차 산업혁명이 진행되는 사회는 필연적으로 소프트웨어와 하드웨어의 경계가 모호해지는 산업들이 발생하게 됩니다. 이런 상황에서는 빠르게 구현하고 피드백을 받아 처리하는 사업적 비용보다 예방하고 평가하는 품질관리 방식이 더 잘 통하는 사업군이 발생하게 됩니다. 그래서 결국 요구사항 리뷰를 할 줄 아는 테스터를 보유했으냐, 아니냐는 기업의 경쟁력으로 나타나게 될 걸로 예상합니다. 요구사항 리뷰까지 할 줄 아는 사람은 대략 15년(최소 10년) 이상의 경력을 가진 테스터들인데, 이런 사람들을 회사에서 연봉이 비싸다는 이유로 채용을 꺼리는 경우가 많습니다. 자동차, 금융, IoT로 가려는 회사들은 BA조직을 확보하시거나, 요구사항 리뷰를 할 줄 아는 테스트 전문가를 채용하시라고 조언드리고 싶습니다.

요구사항 리뷰를 굳이 테스트 전문가가 해야 하나요?

요구사항 관련 이야기를 실무에서 하기 시작하면 가장 자주 듣는 이야기 중 하나가 "요구사항 리뷰를 할 거면 그냥 프로그래머가 Test Driven 하면 되지 않나? 굳이 테스트 전문가가 요구사항 리뷰 단계에 참여해야 해? 테스터들은 개발 잘 모르잖아. 테스터들이 할 수 있는 거 맞아?"

요구사항의 리뷰를 테스트 전문가들이 해야 하는 이유는 「테스트 전문가들의 직업병」과 연관되어 있습니다. 일반적으로 한 회사에서 꽤 오랜 근속연수를 가진 테스트 전문가들은 그 회사에서 이력(History)을 담당하는 경우가 많습니다. 왜냐하면 (제품/서비스의 품질을 다루다 보니 생기는 직업병으로) 테스트 전문가들은 제품과 서비스의 프로젝트 내/외부에서 발생하는 여러 가지 이슈들의 발생과 해결 과정까지의 일에 관여하게 됩니다. 그런 상황들이 지속되면서 결과적으로 테스트 전문가들은 그 회사의 제품/서비스 이슈들의 이력을 가장 잘 아는 존재가 되는 경우가 발생합니다. 오래된 제품/서비스일수록 그런 현상은 더욱 두드러집니다.

그래서 하나의 제품/서비스에서 오랫동안 제대로 일 한 테스터 전문가들은 새로운 요구사항을 접하고 그에 따른 다른 기능의 연관관계를 유추할 수 있으며 그 외 발생될 수 있는 요소를 요구사항 리뷰 단계에서 찾아 줄 수 있는 수준까지 발전하게 되며, 이렇게 다방면에서 리뷰/계획/설계/수행 역량을 가진 사람들을 우리는 (테스터가 아닌) "QA(Quality Assurance)"라고 부릅니다.

필자 주 - Tester가 QA인게 아닙니다. 실무에서는 흔히 대충 Test하는 사람을 QA라고 부르고, "Test 기간"을 "QA 기간"이라 부르며, "Test 환경"을 "QA 환경"이라 부릅니다. 하지만, 필자들이 누누히 주장하는 바와 같이 '요구사항'과 관련되지 않은 버그/문제점을 찾는 활동은 QA라 호칭하면 안됩니다. 그 이유는 QA라는 단어를 별도로 독립시켜야, 소프트웨어 품질에서 가장 중요한 '요구사항 관리'라는 항목을 다룰 명확한 역할을 가진 사람들을 확보할 수 있기 때문입니다.

굳이 QA를 양성해야 할까요? 우리는 애자일 하기 때문에 테스터로도 충분한데요.

사실 이렇게 요구사항을 리뷰하고 다룰 수 있는 전문가로 테스터를 양성하여 QA 수준으로 끌어올리는 이야기는 그 누구보다 각 기업의 CTO들에게 가장 좋은 소식입니다.

프로그래머들은 경력이 쌓이면 시니어 혹은 아키텍트로 발전할 수 있고, 서버 전문가, 데이터 전문가 등으로 발전할 수 있습니다. 하지만 테스터들은 어떻게 성장시킬지 감이 잘 안 오셨죠? 테스터는 경력이 15년이 되어도 테스터인 경우가 많습니다. 그런데 현실의 경험을 기반으로 보건대 테스터들은 위에서 설명한 바와 같이 프로젝트 내부, 혹은 제품/서비스 론칭 후 외부로부터 들어오는 여러 이슈들을 다루면서 요구사항 관리에 자연스럽게 눈을 뜨게 됩니다. 그래서 이 사람들을 훈련시켜 조직 내에서 요구사항 리뷰 전문가로 발전시킬 수 있습니다. 이 요구사항 리뷰를 잘하는 사람들은 대부분 10년 이상 정도 품질에 대해 심각히 실무를 해 본 사람들인 경우가 많으며, 15년 정도 경력이 쌓여야 조직의 요구사항들을 리딩(Leading) 할 수 있다고 (필자들은) 생각합니다.

사실 이렇게 제품/서비스의 문제점들을 요구사항 관점에서 관리하고, 다루어 품질을 향상하는 직군을 BA(Business Analyst)라고 부릅니다. 모든 테스트 전문가들이 QA팀장이 될 필요는 없습니다. 리더로서의 성향을 가지지 못한, 엔지니어로서의 관점 역량을 가진 사람들도 많습니다. 그런 사람이라면 BA로 훈련시켜 그 역량을 향상해 사업부와 소프트웨어 기획 부서 사이에서 발생하는 요구사항의 해석, 관리, 현업과의 커뮤니케이션 등을 담당하도록 할 수도 있습니다.

BA를 사업 부서 하에 둘 지, 개발 부서 하에 둘 지에 대해서는 필자들의 의견을 피력하지 않겠습니다. 왜냐면 각 회사의 상황에 따라 다를 듯해서입니다.

마무리 이야기

어떤 독자는 본 포스팅의 내용이 너무 일반론적이고 당연한 내용이라고 생각할 수도 있습니다. 네, 맞습니다. 저희도 '실무편'이라고 해 놓고 사실적인 이야기를 많이 하지 못하는 점이 아쉽습니다. 소프트웨어 테스팅과 품질 관련된 실무 이야기를 하면 실제 있었던 일들을 이야기하게 되다 보니 아무리 각색하더라도 어떤 회사인지, 어떤 프로젝트인지 정보가 글 속에서 비추어지는 경우가 많아 조심스럽습니다.

이런 이야기들은 '콩으로 메주 쑤고, 쌀로 밥 짓는 소리' 같이 일반적인 내용 같이 들릴 수도 있습니다. 그런데, 그런 당연하고 일반론적인 요리의 기본 토대 위에서 누군가는 끝내주는 김밥을 만들어 우리를 천국에 온 듯 행복하게 하고, 또 누군가는 미슐랭 스타 셰프가 되기도 합니다. 과연 기본기가 없이 그런 훌륭한 음식들을 만드는 게 가능할까요? 세상 모든 일은 일반론적인 이론의 토대 위에서 현실의 문제점들을 해결하는 방식으로 진행되어야 하고, 그게 기본입니다. 기본기가 부족한 상태에서 실무만으로 그런 높은 경지에 이르기는 쉽지 않습니다. 기본적인 내용이 지켜지지 않으면 절대 좋은 품질의 결과물을 만들어낼 수 없습니다.

그래서 필자들은 계속 강조합니다. 소프트웨어도 마찬가지입니다. 요구사항 관리, 리뷰 활동에 대해서는 글의 초반에 언급한 바와 같이 '요구공학(Requirement Engineering)'이라는 분야가 따로 있을 정도로 넓고 깊은 지식이 존재합니다. 그런 이론들을 이해하고, 기본기 위에서 우리 회사에서 발생하고 있는 이슈 사항들을 조절하여 해결할 수 있는 것. 그런 활동을 테스팅 활동, 테스팅 분야에서 수행할 수 있다면 바로 여러분이 「테스트 전문가」입니다. 그래서 필자들은 이번 글에서 가능한 소프트웨어 테스팅 실무, 소프트웨어 품질관리 실무 관점에서의 현상들, 이슈 사항들을 나열하였습니다. 그리고 테스트를 하거나 준비를 하면서 만날 법한 상황을 가정하거나 겪은 일들을 중심으로 이야기를 풀어보았습니다.

어쩌면 어떤 독자분에겐 '굳이 이렇게 까지 해야 하나' 싶을 수도 있고, '내 업무를 벗어난 것이 아닌가' 하는 생각이 들 수 있습니다. 그런 생각이 들어도 이상하지 않은 게 현실입니다. 현실의 야생(실무)에서는 아직 소프트웨어 테스팅 전문가를 제대로 활용하지 못하는 회사들이 많습니다. QA와 Testing을 구분하지 못하거나, 구분하는 행위에 대해 못마땅해하는 실무자들도 많습니다. 그래서, 본 글에 언급한 내용들까지 하지 않아도 월급 받는데 지장이 없습니다. 그렇기에 필자들은 현실에 만족하고 사시는 분들에게까지 변화를 강요할 생각이 없습니다.

다만, 이런 글을 찾아 읽을 정도의 당신이라면(우연히 들어왔다고 하더라도), 현재 자신이 처한 답답한 현실이나 한계에 대한 해답의 실마리를 찾는 당신이라면, 오늘보다 더 나아진 것을 바라는 당신이라면, 더 나은 품질을 달성하기 위해 소프트웨어 테스팅을 위한 요구사항 리뷰를 실천해 보시기를 바라는 마음으로 글을 써보았습니다.

오늘도 당신의 성공적인 테스터 생활을 응원합니다.

참여자 정보

• 글쓴이 : Bykj, 천년나무

• 검토한이 : 아이티마니

STEEG 개인 의견

※ STEEG 개인 의견은 각 전문가 개인이 경험한 경력에 따른 의견이므로, 주관적 견해가 개제될 수 있습니다. 개인 의견에 대한 내용은 본 블로그와 관련이 없습니다.

[링크 모음] 한글 테스팅 관련 도서 모음

『 Lv8+の 꽃怪獸』 천년나무 — Fri, 27 May 2022 12:19:27 +0900

※ 알림 : 이 포스팅은 링크프라이스의 제휴마케팅이 포함된 광고로 일정 커미션을 지급 받을 수 있습니다. 1~2%의 커미션이지만 혹시라도 어느 정도 금액이 모인다면 필요한 곳에 기부할 예정입니다.

본 포스팅에서는 대한민국에 있는 한글로 쓰여진 Software Testing 관련 도서들을 모아보려 합니다.

모든 서적은 ㄱㄴㄷ, ABC, 123 순으로 정렬하였습니다.
교보문고에 없는 책들은 제휴마케팅 링크가 아닌 별도 링크로 제공합니다.
이미 절판된 책들도 있을 수 있습니다. 해당 도서들은 출판사로 개별 연락하셔야 합니다.

개발자도 알아야 할 소프트웨어 테스팅 실무

개발자도 알아야할 소프트웨어 테스팅 실무 - YES24

개정 3판은 국제 소프트웨어 테스팅 표준 ISO/IEC29119의 최신 내용을 반영했다. 또한 실제 업무에서 좀 더 쉽게 바로 적용할 수 있도록 테스트 전략 및 케이스 도출 방법을 사례 통해 개정되었다.

www.yes24.com

개발자를 위한 시프트-레프트 테스트

개발자를 위한 시프트-레프트 테스트 - 예스24

소프트웨어 품질을 높이기 위한 개발자 테스트 프랙티스 소프트웨어 품질은 조기에 결정되므로 개발 과정에서 테스트를 뒤로 미루지 않고 최대한 앞 단계에서 수행하자는 것이 ‘시프트-레프

www.yes24.com

개발자에서 아키텍트로

개발자에서 아키텍트로 - 예스24

개발자에서 아키텍트로 거듭나기! 초보 아키텍트를 위한 실전 입문서『개발자에서 아키텍트로』는 개발자에서 아키텍트로, 변화의 첫걸음을 내딛는 이를 위한 실전 입문서다. 설계를 위한 필

www.yes24.com

경영 품질의 이해

경영품질의 이해 - YES24

이 책은 경영품질에 대해 다룬 이론서이다. 경영품질의 기초적이고 전반적인 내용을 학습할 수 있도록 구성했다.

www.yes24.com

경쟁력 있는 소프트웨어 테스터가 되는 법

경쟁력 있는 소프트웨어 테스터가 되는 법 - YES24

이 책은 소프트웨어 테스트 전문회사에서 근무하면서 다양한 서비스 도메인과 고객들과 일하면서 얻은 경험들을 기반으로 한 실무 테스트 기법에 대한 소개를 중심으로 하고 있다. 실제 현장에

www.yes24.com

고품질 앱을 위한 모바일 테스팅

고품질 앱을 위한 모바일 테스팅 - YES24

저자의 실제 경험을 바탕으로 모바일 테스트 계획부터 수행까지 전체 프로세스를 폭넓게 다룬다. 이 책의 핵심은 모바일에 특화된 테스트 방법과 자동화 도구의 설명 및 선택 방법이다. 책에서

www.yes24.com

구글은 소프트웨어를 어떻게 테스트하는가

구글은 소프트웨어를 어떻게 테스트하는가 - YES24

완벽을 추구하는 구글의 혁신적인 소프트웨어 테스팅 방법을 배우고 싶은가? 테스팅 전문가인 제임스 휘태커를 비롯한 저자진이 구글 현직 테스팅 전문가들과의 사내 인터뷰를 통해 구글의 소

www.yes24.com

게임 테스팅

게임 테스팅 3/e - YES24

PC 게임과 모바일 게임을 아우르는 게임 테스팅의 기본 원칙부터 실무에 바로 적용할 수 있는 실용적인 테스트 기법까지 게임 테스팅 전반을 일목요연하게 다룬다. 게임 QA에 입문하려는 초보자

www.yes24.com

린 애자일 기법을 활용한 테스트 주도 개발

린 애자일 기법을 활용한 테스트 주도 개발 - YES24

요구사항을 신속하고 명확하게 결정하지 못하거나, 고객의 바람을 반영하지 못해 프로젝트 후반부에서 곤란했던 경험이 있는가? 이 책은 개발자와 테스터가 소프트웨어 구현 전에 고객과 함께

www.yes24.com

문제로 배우는 소프트웨어 테스팅 2

문제로 배우는 소프트웨어 테스팅 2 - YES24

문제풀이를 하면서 테스팅의 이론과실무, ISTQB 지식체계를 정확하게 습득하도록 문제해설을 구성했다. 책과교육에서 체득하기 어려운 내용을 문제를 풀어보면서 보완할 수 있다. 특히 문제해설

www.yes24.com

버그 정글을 헤쳐 가기 위한 테스터 지침서

버그 정글을 헤쳐 가기 위한 테스터 지침서 - YES24

오늘날은 소프트웨어가 없는 세상을 상상할 수 없을 정도로 대부분 사물은 소프트웨어를 탑재하고 있고, 또한 소프트웨어를 통해서 사물을 제어하고 있다. 이제 제품에 대한 품질은 더는 하드

www.yes24.com

소프트웨어 개발과 테스트

소프트웨어 개발과 테스트 - YES24

애자일, 서버 테스팅, 개발·빌드 환경이 책은 소프트웨어 개발에서 필요한 전반적인 개발과 테스트 프로세스를 저자의 경험으로 다루고 있다. 개발 문화를 이끄는 애자일 스크럼 방법론에서부

www.yes24.com

소프트웨어 개발자 테스팅

소프트웨어 개발자 테스팅 - YES24

더 좋은 코드를 작성하고 버그를 방지하고 싶은 소프트웨어 개발자를 위한 책이다. 테스트 용이성을 이해하고 이를 바탕으로 소프트웨어의 품질을 달성하는 방법을 다룬다. 또한 테스팅에 관한

www.yes24.com

소프트웨어 보안 검사 기술

소프트웨어 보안 검사 기술 - YES24

보안 문제점들을 미리 파악하여 사전에 대처할 수 있도록 최첨단이며 실전적인 각종 검사 기법들을 제공한, 소프트웨어 보안 전문서. 애플리케이션 검사와 침투 검사 분야에서 수십 년간 잔뼈

www.yes24.com

소프트웨어 품질관리 실무 가이드

소프트웨어 품질관리 실무 가이드 - YES24

프로젝트 성공을 이끄는 소프트웨어 품질관리소프트웨어 개발 프로젝트는 정해진 비용으로 계획된 납기 이내에 고객이 만족하는 품질을 가진 결과물을 만들어 내는 과정이라고 요약할 수 있습

www.yes24.com

소프트웨어 (프로세스) 품질인증 취득 가이드

행정사, 경영, 기술지도사 실무를 위한 소프트웨어(프로세스)품질인증 취득 가이드 - YES24

소프트웨어 품질인증제도인 GS인증은 소비자와 기업이 우수한 SW제품을 보다 잘 믿고 쓸 수 있도록 일련의 시험 테스트과정을 거쳐 일정한 수준의 품질을 갖춘 SW제품에 국가가 부여하는 인증제

www.yes24.com

소프트웨어 테스트 실무 가이드

소프트웨어 테스트 실무 가이드 - YES24

단기에 품질 향상의 성과를 볼 수 있게 테스팅 핵심 활동을 정리해 쉽게 따라할 수 있게 구성한 책이다. 중소 규모의 소프트웨어 회사의 여건을 고려한 ‘이해하기 쉽고 꼭 필요한 테스팅’ 이

www.yes24.com

소프트웨어 테스트 자동화

소프트웨어 테스트 자동화 - YES24

효과적인 자동화 테스트의 본질을 설명하며 실제 자동화 프로젝트에서 얻은 가치 있는 경험과 팁, 교훈, 기억해야 할 점 등을 소개하고 있다. 흥미진진하고 잘 작성된 광범위한 케이스 스터디

www.yes24.com

소프트웨어 테스트 자동화 구축과 6가지 핵심 활동

소프트웨어 테스트 자동화 구축과 6가지 핵심 활동 - YES24

성공적인 소프트웨어 테스트 자동화에 대한 방법을 알려주고, 그에 수반한 6가지 핵심 활동을 설명한 책이다. 이 책에서는 미 국방부와 주로 일하는 IDT라는 회사가 실제 현업에서 적용한 소프트

www.yes24.com

소프트웨어 테스트 전문가(CSTS) 가이드

소프트웨어 테스트 전문가(CSTS) 가이드 - 교보문고

『소프트웨어 테스트 전문가(CSTS) 가이드』는 〈테스트 개요〉, 〈테스트 설계기법〉, 〈테스트 프로세스〉, 〈SW테스트 전문가(CSTS) 자격시험 예제〉를 수록하고 있는 책이다.

www.kyobobook.co.kr

소프트웨어 테스팅

소프트웨어 테스팅 - 교보문고

소프트웨어 테스팅이 소프트웨어 개발에 있어서 품질 수준을 높이기 위한 가장 중요한 수단의 하나이며 최후의 수단임에도 불구하고 소홀히 되어온 것이 사실이다. 그 이유는 소프트웨어 개발

www.kyobobook.co.kr

소프트웨어 테스팅 마이크로소프트에선 이렇게 한다

소프트웨어 테스팅 마이크로소프트에선 이렇게 한다 - 교보문고

마이크로소프트 테스팅의 실체를 속속들이 들여다 본다! 마이크로소프트의 유명 현직 테스팅 전문가(SDET)들이 집필한 소프트웨어 테스팅 실무서. 사내 9,000여 명의 테스터가 사용하고 있는 툴과

www.kyobobook.co.kr

소프트웨어 테스팅 법칙 293가지

소프트웨어 테스팅 법칙 293가지 - 교보문고

전문가들의 실전 경험을 통해 검중된 293가지의 소프트웨어 테스팅 법칙을 담은 책. 상세한 설명과 적절한 예제를 통해 테스트하는 방법, 적용하는 시기와 이유를 자세히 기술하고 있다.

www.kyobobook.co.kr

소프트웨어 테스팅 실무 가이드

소프트웨어 테스팅 - 교보문고

CSTS 자격증 대비 | [테스터와 관리자를 위한 소프트웨어 테스팅 실무 가이드]는 한국정보통신기술혐회에서 시행하는 SW 테스트 전문가 자격 시험 CSTS 자격증을 준비하는 사람들을 위한 책이다.

www.kyobobook.co.kr

소프트웨어 테스팅 자동화

소프트웨어 테스팅 자동화 - YES24

테스팅 관련 서적에서 다룬 소프트웨어 테스트 개념이나 이론보다는 오토메이션 툴을 개발하고 실제 소프트웨어 테스트에 적용할 수 있도록 중점을 두었다. 소프트 웨어 테스트에 필요한 기본

www.yes24.com

실전에서 바로 써먹는 업무자동화

실전에서 바로 써먹는 업무자동화 - 예스24

누구나 쉽게 따라 할 수 있는 기적의 업무자동화!똑같은 일도 남들보다 빠르고 편하게 하는 법!우리가 일하는 방식은 왜 그대로일까? 매일 반복적으로 수행하는 업무를 효율적으로 할 수는 없을

www.yes24.com

쉽고 간단한 테스트로 투잡하기

실전 노하우 '쉽고 간단한 테스트로 투잡하기'를 드립니다. | 15000원부터 시작 가능한 총 평점 0점

0개 총 작업 개수 완료한 총 평점 0점인 품생품사의 전자책, 투잡·재테크 전자책 서비스를 0개의 리뷰와 함께 확인해 보세요. 전자책, 투잡·재테크 전자책 제공 등 15000원부터 시작 가능한 서비

kmong.com

아마존 웹서비스 부하테스트 입문

아마존 웹 서비스 부하 테스트 입문 - YES24

20년 베테랑 개발자가 공개하는 AWS 부하 테스트 기초부터 실전까지의 노하우!이 책에서는 부하 테스트의 기본적인 정의부터 다양한 부하 테스트 도구를 설명하였다. 무엇보다 어렵게 느껴지는

www.yes24.com

아직 잘 알려지지 않은 SQA 엔지니어의 세계

QA팀 빌딩 경력을 가진 리더가 SQA 엔지니어의 세계를 설명합니다.

fastcampus.co.kr

역사 속의 소프트웨어 오류

역사 속의 소프트웨어 오류 - YES24

소프트웨어 오류가 직간접적인 원인이 되어 발생한 사고로 지금까지 수많은 사람이 죽거나 다쳤고 막대한 물질적 손실이 발생했다. 이 책은 소프트웨어 오류로 인해 우주, 항공, 군사, 통신, 금

www.yes24.com

애자일 테스팅

애자일 테스팅 - YES24

이 책에서 두 저자는 애자일 테스팅을 정의하고 실제 애자일 팀에서 사례를 통해 테스터의 역할을 묘사하고 있다. 업계의 경험 많은 두 명의 애자일 테스팅 전문가이자 컨설턴트인 리사 크리스

www.yes24.com

자바와 JUnit을 활용한 실용주의 단위 테스트

자바와 JUnit을 활용한 실용주의 단위 테스트 - YES24

『실용주의 프로그래머』의 앤디 헌트와 데이브 토마스가 알려주는실용주의 단위 테스트!클린 코드의 핵심인 단위 테스트, 어디서 어떻게 시작해야 할까? 책에서는 단위 테스트의 개념과 작성

www.yes24.com

지속적인 통합 : 소프트웨어 품질을 높이고 위험을 줄이기

지속적인 통합 - YES24

졸트 상 수상에 빛나는 「지속적인 통합」많은 개발자들이, 수많은 소프트웨어 컴포넌트를 꾸역꾸역 기워 맞추느라 며칠씩 `통합 지옥`을 헤매는 경험을 합니다. 『지속적인 통합: 소프트웨어

www.yes24.com

지식 제로부터 배우는 소프트웨어 테스트

지식 제로부터 배우는 소프트웨어 테스트 - YES24

엔지니어로서의 마음가짐이나 소프트웨어 테스트를 할 수 있는 것과 할 수 없는 것 등 초보자가 먼저 알아야 할 것들에 대해서 설명한다.또한 반드시 실시하는 각종 테스트 기법의 기초와 포인

www.yes24.com

클린 코드를 위한 테스트 주도 개발

클린 코드를 위한 테스트 주도 개발 - YES24

이 책은 웹 애플리케이션의 개발 과정 전반을 다룬다. 또한 애플리케이션을 구축하기에 앞서 어떻게 테스트 코드를 작성하고 실행해야 할지를 알려주고, 테스트 코드를 통과하기 위한 최소 기

www.yes24.com

퀄리티 코드

퀄리티 코드 - YES24

테스팅이 소프트웨어의 품질을 높이는 중요한 역할을 한다는 점은 누구나 인지하고 있으나, 막상 프로젝트를 마주해 테스팅을 하려면 어떻게 해야 할지 막막하다. 개발자들이 정작 테스팅에 대

www.yes24.com

탐험적 테스팅

탐험적 테스팅 - YES24

아무리 빈틈없이 설계, 구현했다고 하더라도 소프트웨어는 늘 예상치 못한 오류를 일으킨다. 테스트도 열심히 해보지만 성긴 그물 사이로 오류가 빠져나오기 마련이다. 그물을 좀 더 촘촘하게

www.yes24.com

테스터 인사이트 패키지 3

testers insight 패키지 3 - YES24

국내 유일의 테스팅 전문 잡지인 Testers Insight 창간호로 국내최대 테스팅 전문가네트워크인 STEN과 ㈜STA컨설팅이 국내외 크고 작은 행사, 컨설팅 및 교육 등의 테스팅 관련 활동과 경험을 통해 획

www.yes24.com

테스트 주도 iOS 애플리케이션 개발

테스트 주도 iOS 애플리케이션 개발 - YES24

처음 요구사항 정의부터 완전히 작동하는 상태까지 테스트 주도 개발 방법론으로 iOS 앱을 한 단계, 한 단계씩 만드는 과정을 설명하면서 테스트 주도 개발에 대한 기본적인 이해도를 높여준다.

www.yes24.com

테스트 주도 개발

테스트 주도 개발 - YES24

Test-Driven Development: By Example아름다운 코드와 즐거운 개발을 위한 테스트 주도 개발테스트 주도 개발은 학계와 업계에서 많은 주목을 받아온 프로그래밍 방법으로, 여러 연구 논문과 실례를 통해

www.yes24.com

테스트 주도 개발 시작하기

테스트 주도 개발 시작하기 - YES24

TDD(Test-Driven Development)는 테스트부터 시작한다. 구현을 먼저 하고 나중에 테스트하는 것이 아니라 먼저 테스트를 하고 그다음에 구현한다. 구현 코드가 없는데 어떻게 테스트할 수 있을까? 여기

www.yes24.com

테스트 주도 개발 TDD 실천법과 도구

테스트 주도 개발 - YES24

어려움을 겪고 있는 국내의 수많은 Java 개발자들에게 도움을 주기 위해 집필되었다. 쉽고 체계적인 설명과 다양한 예제를 통해 테스트 주도 개발 방법론을 활용하고 있는 국내 개발자들의 문제

www.yes24.com

테스트 주도 개발로 배우는 객체지향 설계와 실천

테스트 주도 개발로 배우는 객체 지향 설계와 실천 - YES24

TDD로 좀 더 탄탄한 객체 지향 개발을 이끄는 안내서 소프트웨어 개발의 여러 층위에서 TDD가 어떻게 작동하는지 보여주면서 테스트로 코드를 객체 지향적으로 구성하고 기능을 구현하며 목 객체

www.yes24.com

품질 경영의 이해

품질경영의 이해 - YES24

품질은 최고경영자가 가장 중요하게 여기는 기업경영의 전략적 요소 중 하나다. 품질이 뒷받침되지 않은 제품이나 서비스는 존재할 수 없다. 하지만 품질 개선은 어렵기도 하다. 지금까지 수없

www.yes24.com

품질 경영의 이해 - YES24

기업들이 경쟁력을 높이기 위한 품질경영을 어떻게 하여야 올바르게 할 수 있는지에 관한 책이다. 이 책은 과거의 품질경영이 단순히 검사위주의 품질 시대를 지나 통계적 품질 관리 시대, 품질

www.yes24.com

품질경영의 이해 - YES24

품질경영의 이해

www.yes24.com

품질경영의 이해 - YES24

『품질경영의 이해』는 품질경영론, 표준화와 품질보증, 품질개선 활동으로 총 3부 16장으로 구성되어 있다. 또한 실무에 도움이 되도록 검사실무를 포함하였고 연습문제도 철저히 풀어보도록

www.yes24.com

AI 품질관리 가이드

더 괜찮은 개발자가 되기 위한 AI 품질 관리 가이드 - YES24

신뢰할 수 있는 AI 기술, 보다 높은 품질을 갖춘AI 시스템을 만들고 싶다면...`생활의 일부가 되고 있는 인공지능(AI)은 정의되지 않은 `결함` 때문에 프로그램 디버깅, 정적 코드 분석, 기능 테스트

www.yes24.com

NHN은 이렇게 한다. 소프트웨어 품질관리

NHN은 이렇게 한다! 소프트웨어 품질 관리 + 지속적인 통합 세트 - YES24

NHN의 소프트웨어 품질관리 노하우를 담은 『NHN은 이렇게 한다-소프트웨어 품질관리』와 소프트웨어 개발 프로젝트에서 소프트웨어 품질을 개선하고 위험을 줄이는 원칙과 실천방법을 담은 『

www.yes24.com

Selenium 웹드라이버 테스트 자동화

Selenium 웹드라이버 테스트 자동화 - YES24

Selenium 3.1.0 버전 기준이 책은 구글이 선택한 웹 애플리케이션 UI 자동화 테스팅 도구인 셀레늄(Selenium) 웹드라이버를 사용해 웹 애플리케이션 테스트 프레임워크를 구축하는 내용을 다룬다. 셀레

www.yes24.com

Selenium을 활용한 테스트 자동화

Selenium을 활용한 테스트 자동화 2/e - YES24

셀레늄 3에서 개선된 점을 살펴보고 셀레늄에서 자바 8 API를 활용하는 방법을 알아본다. 기본 사용법부터 조금 더 복잡한 사용자 액션까지 설명한 후, 리모트 웹드라이버와 셀레늄 그리드로 원

www.yes24.com

Selenium WebDriver 길들이기

Selenium WebDriver 길들이기 - YES24

구글 검색 페이지를 대상으로 테스트 스크립트를 작성하는 실용적인 예제로 셀레늄 웹드라이버(Selenium WebDriver) API 사용법을 배워나간다. 기본 사용법을 익히고, 조금 더 복잡한 사용자 액션으로

www.yes24.com

The Art of Software Testing

The Art of Software Testing 3판 - YES24

The Art of Software Testing은 소프트웨어 테스팅 접근에서 입증된, 짧지만 포괄적인 시각을 제공함으로써 특정 개발기술, 언어 또는 테스팅 방법론 등과 같은 기술적 접근이 아니라 소프트웨어 테스

www.yes24.com

UI 테스트 자동화

UI 테스트 자동화 - YES24

『UI 테스트 자동화』는 소프트웨어 자동화 도입을 고려하는 사람이라면 누구나 한 번쯤은 가졌을 고민을 어떤 형태로 풀어나가는지를 설명하고 있다. 단순히 자동화를 통해 이룬 결과물만이

www.yes24.com

좋은 책을 소개해 주세요.

이 블로그의 필자들은 대한민국에서 한글로 번역되거나 쓰여진 소프트웨어 테스팅과 소프트웨어 품질 관련 도서를 본 포스팅에 모아보려 합니다. Software Testing과 Software QA, Software Quality 관련 도서를 알고 계시다면 소프트웨어 테스팅 참고서 제보 양식 혹은 Software Testing and QA 카페에 댓글로 추천해 주세요.

리워드 스폰서 구합니다.

본 포스팅은 링크프라이스의 어필리에이트 프로그램에 가입하여 링크를 제공합니다. 혹여 조금 더 나은 커미션을 지급하실 수 있는 업체가 있으시면 연락주십시오. 필진들 내부 논의 후 스폰서 변경에 따른 링크교체 가능합니다.

※ 알림 : 이 포스팅은 링크프라이스의 제휴마케팅이 포함된 광고로 일정 커미션을 지급 받을 수 있습니다. 1~2%의 커미션이지만 혹시라도 어느 정도 금액이 모인다면 필요한 곳에 기부할 예정입니다.

참여자 정보

• 글쓴이 : 천년나무

• 제보해 주신 분들 모음

▶▶모하구이써 - 버그 정글을 헤쳐 가기 위한 테스터 지침서

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

『 Lv8+の 꽃怪獸』 천년나무 — Wed, 4 May 2022 21:38:10 +0900

질문

옛-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 전문가들의 개인 의견은 각 전문가 개인이 경험한 경력에 따른 주관적 견해입니다.
이런 개인 의견들의 경우는 그룹 전체의 의견을 대표하지 않음을 알립니다.

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

Test와 Test Case와 Test Scenario의 차이

『 Lv8+の 꽃怪獸』 천년나무 — Wed, 23 Mar 2022 21:19:52 +0900

질문

본 포스팅의 질문은 SW테스트와 품질 카페에 올라온 질문을 기반으로 재구성하였습니다.

Test Case와 Test Scenario의 특징과 차이점에 대해 알고 싶습니다. TC와 TS를 작성하기 위해 검색해본 바로 두 개의 사용 기준이 다른 듯 한데 명확히 알고 싶습니다.

ISTQB 버전

ISTQB 전체 지식 체계 및 ISTQB Globassry

답변

본 포스팅의 답변은 SW테스트와 품질 카페에 올라온 원글의 답변 내용들을 기반으로 재구성하였습니다. 제 답변에 더하여, 다른 분들의 답변을 추가하여 재구성하였습니다. 이 부분 감안해 주십시오. 감사합니다.

ISTQB Glossary

먼저 소프트웨어 테스팅의 기준 문서로 활용되고 있는 ISTQB Glossary에 어떻게 정의되어 있는 지 확인해 보겠습니다.

• 테스트 시나리오(Test Scenario)는 테스트 실행을 위한 일련의 활동을 구체적으로 기술해둔 문서입니다. 테스트 시나리오는 「테스트 스크립트」라고 불리기도 하며, 혹은 「수동 테스트 스크립트」라고 부르기도 합니다.

• 테스트 케이스(Test Case)는 「프로그램의 특정 경로를 실험」해보거나 혹은 「프로그램이 특정 요구 사항을 준수하는지를 확인」하기 위한 목적으로 사용합니다. 이 때, 「특정 목적」 또는 「테스트 조건의 확인」을 위해 개발된 「입력 값, 실행 사전 조건, 예상 결과 및 실행 사후 조건」 등을 포함은 내용의 집합을 테스트 케이스라고 합니다.
• 여기에서 하나 더 짚어야 하는 용어가 있습니다. 바로 Test라는 용어입니다. ISTQB Glossary에서는 Test에 대해 다음과 같이 정의하고 있습니다. 테스트(Test)란 한 개 이상의 테스트 케이스의 집합을 의미합니다.

즉, Test라는 용어와 Test Case라는 용어는 다른거고, 또 Test Case라는 용어와 Test Scenario라는 용어도 다른 의미입니다. 실무에서는 이 세 개의 용어를 혼용해서 사용하는 경우가 많습니다만, 원론적으로 이 세 가지 용어는 모두 다른 의미입니다.

영어도 어원은 있다

이런 차이가 나타나는 이유는 다음과 같습니다. 기본적으로 '한국말'에서는 '한국어'의 표현으로 '한글'을 사용하지만, 그 언어의 세부 내용들을 살펴보면 사실 많은 수의 단어들이 한자, 일어, 러시아어, 영어, 유럽어 등에서 차용되었다는 점과 궤를 같이 합니다. 예를 들어 "예절"이라는 단어는 우리 일상생활에서 흔히 쓰는 말이지만 사실 「예절(禮節)」은 '예의와 범절'이라는 의미가 담긴 한자 단어를 기반으로 합니다. 이와 같이 영어의 단어들도 라틴어나 기타 유럽의 언어들에서부터 다양한 영향을 받으면서 발전했고, 유럽의 각 언어권들은 각자 발전하면서 상호 영향을 끼쳤습니다. 그에 따라 현지인들은 각 단어에 담긴 의미를 (우리가 '예절'이라는 단어에서 느끼는 감정처럼) 느낌으로 이해하고 있습니다. 즉, 우리는 테스트 케이스를 TestCase로 받아들이지만, 영어권 사람들은 이 단어를 Test와 Case가 합쳐진 단어로 받아들인다는 의미입니다. 하지만, 이 단어가 한국에 전파될 때는 Test와 Case가 따로 떨어져서 들어오지 않고, TestCase로 붙어서 들어오는 데다가 우리는 라틴어 영향권의 언어를 사용하지 않다보니 용어 혼동이 발생할 수 있습니다.

그래서 필자는 가끔 한국말의 의미가 궁금해서 한자 사전이나, 우리말 어원을 찾아보기도 하며, 또 영단어 볼 때 영어의 어원을 찾아보기도 합니다. 재미있어서요. 적어도 선사시대 이후 인류가 기록을 시작한 뒤로 쌓여온 수 많은 언어들 속에 담겨 있는 다양한 의미들은 그 원어를 추적해서 공부해보면 재미있기도 하고, 공부할 때도 더 잘 이해가 되기 때문입니다. 뭐, 쉽게 말해서 테스트 관련 용어들도 사전을 좀 찾아보시는게 좋다는 의미입니다.

영어 원어를 알려주는 온라인 사전을 소개해 드립니다.

Etymonline - Online Etymology Dictionary

The online etymology dictionary (etymonline) is the internet's go-to source for quick and reliable accounts of the origin and history of English words, phrases, and idioms. It is professional enough to satisfy academic standards, but accessible enough to b

www.etymonline.com

etymonline 사전에서 Case의 어원을 찾아 보면, 이 단어는 13세기부터 "어떤 일이 벌어지는가, 어떻게 될 것인가"라는 의미로 사용되기 시작했고, 이는 프랑스어의 「Cas - 사건, 사고, 이벤트 등」에서 유래했다고 합니다. 이 프랑스어인 Cas는 라틴어의 Casus에서 유래했다고 합니다. 즉, 테스트 케이스라는 의미는 특정 테스트 상황에서 어떤 일이 발생하는가에 대한 점을 확인하는 행위이지요.

어원을 찾아본다는 행위는 굳이 어려운 사전이 아니라도 재미있다고 생각해서 하나 더 소개해 봅니다. [한국민족문화대백과사전 발췌, 하단 링크 참고] 시나리오는 Scenario라고 쓰는데, 이 단어의 어원은 이탈리아어인 Scena에서 유래했다고 합니다. 이 Scena라는 단어는 16세기 이탈리아의 즉흥희극 코메디아 델라르테(Commedia dell’arte)에서 주연자가 극의 줄거리와 배우의 소임, 각 장면의 기본적인 진행 등을 메모하여 공연 참고자료로 쓰게 되면서부터 생겨난 것이라고 합니다.

즉, 쉽게 말해 시나리오라는 단어가 가진 의미는 "하나의 연극 장면에서 배우들과 줄거리와 장면에서 나타낼 장치, 진행 사항 등을 담았음"에서 발생했음을 보여줍니다. 그렇다면 '테스트'라는 단어에 '시나리오'를 붙여 '테스트 시나리오'가 된다면 좀 더 쉽게 이해가 되지요. 특정 테스트 장면, 상황 들에서 발생하는 일련의 줄거리와 흐름, 데이터 등을 확인하는 행위라고 해석하면 됩니다.

그래서, 테스트와 테스트케이스와 테스트 시나리오의 차이는?

자, 다시 본론으로 돌아가겠습니다.

• Test는 기본적으로 명사도 될 수 있고, 동사도 될 수 있습니다. 동사는 '시험하다'라는 의미인거고, 명사는 '시험의 단위'를 의미하는 의미입니다.
• TestCase에서의 'Case'는 그 시험의 특정 '정황'을 의미합니다.
• Test Scenario에서의 'Scenario'는 말 그대로 '각본', 즉, 일련의 이어진 사건들을 의미합니다.

쉽게 예를 들어 설명하면 이렇습니다.

•"장보러 마트 간다"는 테스트입니다. 장보러 가서 뭘 할지에 대한 세부적인 Data Set 혹은 Test Suite가 후술될 것입니다.
•"장보러 마트 가서 당근을 산다"는 테스트케이스입니다. 확인해야 하는 해야 하는 목적과 데이터가 명시되어 있습니다.
•"장보러 마트 갔다가, 간 김에 밥도 먹는다"는 테스트 시나리오입니다. 확인해야 하는 일련의 활동들을 나열합니다.

이런 용어들을 외우실 때 뭐가 더 크고 작고 하게 외우지 마시고, 어떻게 다른지를 고려하여 받아들이시는게 좋습니다. 이런 용어들은 상하 관계를 가지는게 아니라, 그냥 쓰이는 상황이 다른 경우가 더 많습니다. 길이가 긴 요리용 젓가락이 식사용으로 사용하는 짧은 젓가락 보다 상위 개념이 아닌 것과 같은 의미입니다.

이미지 출처1 : http://nearbyshop.co.kr/product/흑단요리용젓가락/61/   -   이미지 출처2 : https://flypo.tistory.com/1059

해외 커뮤니티의 정리

해외의 커뮤니티인 Guru99에는 Test Scenario와 Test Case에 대해 다음과 같이 소개하고 있습니다. 번역하면서 발생하는 모호한 표현에 대해서는 필자가 임의로 추가적인 의미를 부여하였습니다.

테스트 시나리오	테스트케이스
테스트 시나리오에는 처음부터 끝까지 테스트 가능한 기능을 설명하는 개념적인 내용이 포함되어 있습니다.	테스트 케이스에는 명확한 테스트 단계, 테스트 데이터, 애플리케이션의 모든 기능을 테스트하기 위한 예상 결과 등이 포함됩니다.
세부적인 "테스트 방법" 보다 개념적인 "테스트 대상"에 더 중점을 둡니다 .	세부적으로 "무엇을 테스트할지" 와 "어떻게 테스트할지"에 대한 강조하여 가능한 완전한 테스트에 중점을 둡니다.
일반적으로 테스트 시나리오는 한 줄 정도로 제공합니다. 따라서 테스트 수행 중에는 항상 모호함이 존재합니다.	테스트 케이스는 수행 단계, 전제 조건, 예상 결과 등을 정의합니다. 따라서 이런 방식의 테스트에는 모호함이 적으며, 테스터가 임의로 테스트를 수행할 수 없습니다.
테스트 시나리오는 BRS, SRS 등과 같은 제품과 관련한 주요 테스트 문서에서 파생됩니다. • BRS(Business Requirement Specification) • SRS(Software Requirement Specification)	테스트 케이스는 대부분 테스트 시나리오에서 파생됩니다. 단일 테스트 시나리오에서 여러 테스트 케이스를 파생할 수 있습니다.
기능의 처음부터 끝까지 애자일한 방식으로 민첩하게 테스트하는 데 도움이 됩니다.	응용 프로그램을 세부적으로 보면서 철저하게 테스트하고자 할 때에 도움이 됩니다.
테스트 시나리오는 개념 수준의 작업입니다. • 역자 주 - 영어로 High-level은 높은 수준이라는 이야기가 아니라, 개념 수준이라는 의미입니다. "나무 보다는 숲을 본다"는 의미로 받아들이시면 됩니다.	테스트 케이스는 세부 수준의 작업입니다. • 역자 주 - 영어로 Low-level은 낮은 수준이라는 이야기가 아니라, 세부 수준이라는 의미입니다. "숲 보다는 나무를 본다"는 의미로 받아들이시면 됩니다.
테스트 시나리오를 사용하면 문서를 생성하고 테스트를 수행하는 데 필요한 시간과 리소스가 상대적으로 적게 투입됩니다.	테스트 케이스를 사용하면 문서 작성 및 테스트 케이스 실행을 위해 더 많은 리소스 투입이 필요합니다.

필자들은 위 자료 외에도 아래 "관련 참고 자료"란에 여러 링크들을 준비해두었습니다. 번역 도구를 사용하여 다양한 해외 사이트들에서 설명하는 두 용어의 차이점에 대해 확인하시고, 어려운 부분이 있으시면 다시 SW품질과 테스팅 카페에 질문을 주십시오.

실무에서는 어떻게 써야할까?

이번 단락은 이론적인 이야기가 아니라 실무적 관점의 이야기입니다. 이 블로그의 또 다른 필자들이 본 글을 검토하면서 실무 이야기를 조금 써주었으면 좋겠다는 의견을 주셔서 맛보기로 살짝 실무 관점을 남깁니다. 이게 전부라고 오해하시면 안됩니다. 아주 General한 이야기만 하겠습니다.

실무 이야기이다보니 누군가에게는 몽둥이로 뼈를 맞은 듯 아픈 이야기일 수도 있고, 어려움을 겪고 있는 누군가에게는 속시원한 사이다 같은 이야기가 될 수도 있겠습니다.

(1) 테스트 케이스의 특성 : 일반적으로 테스트 케이스를 작성할 때는 세부적으로 자세히 서술합니다. 제품의 스펙을 가능한 모두 테스트해야 할 때 작성하며, 시간이 오래 걸리더라도 가능한 많은 상황에서 다양한 데이터를 테스트해야 할 때 작성합니다. 제품을 잘 모르는 사람도 테스트 케이스를 읽으면서 어떤 상황에 어떤 데이터를 사용해서 어떻게 테스트를 해야 하는 지 (어느 정도) 알 수 있도록 작성하는게 대부분입니다. 그러나, 그렇다는 말은 당연히 수행하는데 시간이 오래 걸리며 많은 인력이 필요하게 됩니다.

(2) 테스트 시나리오의 특성 : 테스트 시나리오는 조금 다르게 제품/서비스의 전체 흐름을 빠르게 확인해야 하는 상황이거나, 전체 모듈에 대한 이해를 갖춘 상태에서 테스트를 빠르게 진행해야 할 때 선택하는 경우가 일반적입니다. 그래서 테스트 시나리오는 제품에 대한 이해가 갖추어진 사람들이 빠르게 여러 상황을 가정하고 데이터를 검증할 수 있는 경우 사용합니다. 우리가 흔히 "경험 기반 테스트"라고 알고 있는 테스트를 진행할 경우에 사용합니다.

아, 맞다. 그런게 있습니다. 실무에서는 「테스트 시나리오」라고 부르지만, 사실 '용어만' 그렇게 되어 있고, 실제로 따져보면 "자동화 코드"이거나 "테스트 케이스"를 그렇게 부르는 경우도 상당히 많습니다. 모든 테스트 실무자가 ISQTB Glossary를 공부하지는 않았으니까 회사마다 실제 용어는 다를 수 있습니다.

예를 들어 보겠습니다. 하나의 프로젝트 내에 100개의 모듈이 있고, 해당 모듈들은 각기 1번~100번까지의 번호로 이름이 매겨졌다고 가정합니다. 그리고 각 모듈은 자기 앞뒤 +1, -1번 모듈과만 의존성을 가진다고 가정합니다. 예를 들어, 3번 모듈은 2번과 4번에 의존성을 가지는 것이지요. 이 때, 우리가 이번 패치로 4번 모듈을 수정했다면 테스트는 어디를 해야 할까요?

당연히 3번과 4번과 5번입니다. 처음부터 끝까지 모든걸 테스트할 필요 없지요. 이런 경우 테스트 케이스를 써야 할까요? 테스트 시나리오를 써야 할까요? 상황에 따라 다르겠지만, 필자라면 테스트 시나리오를 사용하고, 검증할 데이터세트(Data Set)를 구성하여 커버리지(Coverage)를 높이겠습니다. (물론 실무의 상황은 누구나 다를 것이므로, 이는 필자의 의견임을 밝혀 둡니다.)

그래서 즉, 정규 릴리즈/패치가 있을 때는 실제 서비스 상황과 동일한 환경을 갖추어 놓고 테스트 케이스로 처음부터 끝까지 보는게 의미가 있을 수 있겠고, 특정 모듈의 변경이 있는 경우는 해당 시나리오와 데이터 세트를 갖추어 진행하는게 현실적일 겁니다.

이 부분이 사실... 현실의 테스트 전문가들에게는 아픈 이야기입니다. 하지만, 21세기가 된 후 22년이나 지난 지금까지도 SW개발팀 내에서의 Testing팀은 보유한 전문성을 회사에서 잘 인정받지 못하며, "QA팀"이라는 애매한 이름으로 불립니다. "테스트 하자"는 말이 쪽팔리신 건지 자꾸 "QA 하자, QA했어?" 라고 합니다. (음... 「테스트」라는 말이 대체 왜 쪽팔리신지 잘 모르겠습니다만...) 현실에서는 의미만 잘 전달되면 되니 그러려니 합니다만, 사실 QA와 Testing은 다른 행위인데 이를 동일 시 해 버리면 조직의 품질 발전은 언젠가 한계에 부딛힐 수 밖에 없습니다. 그래서, TDD를 도입하고 여러 방식을 도입해도 어느 순간 한계점에 임박하는 거거든요.

그러한 조직들에서는 아주 빈번히 발생하는 문제가 있습니다. "테스트는 완벽해야 한다"면서 아주 조그만 수정을 하고서도 전체를 다 테스트하자는 말도 안되는 소리를 아직도 하곤 합니다. 사업을 관장하는 누군가들은 자기 의지를 관철 시킬 목적으로 개발 부서 내 "테스트 전문성을 재고"하기 보다는 "테스터의 단가를 낮추거나 아웃소싱을 사용"하는 방식으로 테스터의 수를 늘리면 된다고 생각합니다. 그러다가 오류가 나오면 오류를 못 잡았다고 괜히 테스트 담당자에게 난리 치는 경우도 다반사지요. 자, 누군가 동네에 방화를 했으면 불 지른 사람을 찾아 나무라거나, 아니면 앞으로 누구도 불을 못지르게 예방할 생각을 하는게 상식적이고 정상적 접근입니다. 방화를 왜, 누가 했는지 상관 없고, 불을 못 끈건 나쁘다며 소방관만 나무라는 격입니다. 이런걸 사자성어로 적반하장(賊反荷杖)이라고 합니다. 필자는 그런 행동 양식을 "프로그래머의 설계 역량 미숙을 테스트 전문가에게 덮어 씌우는 기만행위"라고 이야기합니다.

그만하겠습니다. 실무 이야기를 하니까 좀 우울하죠? 그래서 테스트 전문가분들이 이 글 읽으시면서 속 시원하시라고 조금 쎄게 써봤습니다. 이 글 읽으시는 테스트 전문가 여러분, 다들 실무 현장에서 건승하시기 바랍니다.

※ 필자 주 : 경험기반 테스트와 탐색적 테스팅은 다릅니다. 두 개를 혼동해서 사용하지 마세요.

• 경험 기반 테스트는 특정 제품/서비스에 대한 이해도가 높고, 해당 제품에 경험이 많은 전문테스터가 시나리오와 변경 예상 부분을 중심으로 테스트를 수행하는 방식의 접근을 사용합니다.
• 탐색적 테스팅은 특정 제품/서비스에 대한 이해도가 떨어질 때 제품의 전체 구간, 설계 시 찾아내지 못한 의존성 등을 Blackbox 관점에서 찾아내기 위해 반복적이고 순차적인 방식의 접근을 사용합니다.

두 개 중 무엇이 더 옳다고 이야기하는 건 틀렸습니다. 두 개는 상황에 따라 상호 혼용 및 보완되어야 합니다. 모든 테스트는 정황에 기반(Context Driven)합니다. 버그를 많이 찾을 수 있는 방식으로 상황에 맞게 사용하시면 됩니다. 그리고 프로젝트 내에서 그렇게 할 수 있는 사람이 테스트 전문가(Test Expert)입니다.

"우리는 애자일팀이니 탐색적 테스팅을 해요."라는 말은 사실은 굉장히 창피한 이야기입니다. 개발팀 내부에 추적 가능한(trace-ability) 설계 프로세스가 없다는 이야기를 하고 있는거니까요. 애자일은 모두 옳고, 전통적(?)인 방법은 모두 나쁘다는식으로 (유치원생이나 할 법한) 이분법적이고 극단적 사고 방식은 좋지 않습니다.

참여자 정보

• 글쓴이 : 천년나무

• 검토한이 : Bykj, 품생품사

STEEG 개인 의견

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

테스트하면서 요구사항 리뷰도 할 수 있나요? (기본 이해편)

Bykj — Wed, 23 Mar 2022 21:19:06 +0900

질문

ISTQB 버전

ISTQB Syllabus 2018

답변

본 글은 2개로 나누어 구성하였습니다. 현재 보고 계시는 글은 기본 이해 편으로 요구사항과 테스트와의 관계에 대한 기본적인 이해를 하기 위한 글입니다. 2번째 실무 이야기편에서는 요구사항과 테스트와의 관계에 대한 한 단계 업그레이드된 이야기에 대해 설명하고 있으니 해당 부분도 함께 참고하여 주세요.

요구사항 리뷰가 뭔가요?

요구사항 리뷰와 테스트와의 관계를 설명하려면 그에 앞서 「요구사항은 무엇인가?」라는 질문에 대한 답부터 찾아야 합니다. 몇 가지 나름대로 공신력 있는 자료들을 찾아보겠습니다.

1. ISTQB Glossary에서 말하는 "요구사항(requirement)"이라는 구분을 그대로 옮기고 번역하면 아래와 같습니다.

A provision that contains criteria to be fulfilled.

충족시켜야 할 기준이 포함된 조항

2. Wikipedia에서는 요구사항에 대해 다음과 같이 표현하고 있습니다.

In product development and process optimization, a requirement is a singular documented physical or functional need that a particular design, product or process aims to satisfy.

제품 개발과 프로세스 최적화에서 요구사항이란, 특정 설계/제품/프로세스가 충족하고자 하는 단 하나의 문서화된 물리적 또는 기능적 필요이다.

3. PMP(Project Management Professional)에서 말는 요구사항이라는 단어의 정의는 다음과 같습니다.

requirement is “a condition or capability that is required to be present in a product, service, or result to satisfy a contract or other formally imposed specification.”

요구 사항은 "계약 또는 기타 공식적으로 부과된 사양을 충족하기 위해 제품, 서비스 또는 결과에 존재해야 하는 조건 또는 능력"입니다.

위 내용들에 따라 요구사항이란 제품이(혹은 프로세스가) 갖춰야 할 항목들에 대한 조항을 모아 놓은 것이라고 할 수 있으며, 문서나 디자인과 같은 형태로 존재한다고 정의할 수 있습니다.

요구사항과 관련된 여러 용어 설명들을 보다 보니 '요구사항(requirement)'이란 용어는 소프트웨어에서만 사용하는 게 아닌 거 같습니다. 그래서 「소프트웨어에서의 요구사항(software requirement)」이란 무엇인가에 대해 짚어볼까 합니다.

소프트웨어 요구사항에 대한 위키피디아의 정의는 아래와 같습니다.

The requirement for a system is the description of what the system should do, the service or services that it provides, and the constraints on its operation. The IEEE Standard Glossary of Software Engineering Terminology defines a requirement as:

A condition or capability needed by a user to solve a problem or achieve an objective.
A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or another formally imposed document.
A documented representation of a condition or capability as in 1 or 2.

시스템 요구사항이란 시스템이 수행해야 하는 작업 및 제공하는 서비스를 말하며, 이에는 작동에 대한 제한 사항을 포함하여 제공합니다. IEEE 표준 소프트웨어 엔지니어링 용어집에는 '요구사항'에 대해 다음과 같이 정의합니다.

문제를 해결하거나 목표를 달성하기 위해 사용자가 필요로하는 조건 혹은 능력
계약, 표준, 세부사양, 또는 기타 공식적으로 부과된 문서의 조건을 충족하기 위해 시스템과 그 구성요소가 보유해야만 하는 조건 혹은 기능
위 1과 2를 만족하는 조건 혹은 기능에 대한 문서화된 표현

위를 단순하게 말하자면, 우리가 만들고자 하는 소프트웨어에 대한 요구를 문서화하여 기술한 내용을말합니다. 그 소프트웨어가 어떤 동작을 해야 할지에 대한 설명이 있는 문서나 디자인과 같은 형태로 존재하게 됩니다.

Software Engineering Body of Knowledge에는 소프트웨어 요구사항에 대해 다음과 같이 표현하고 있습니다.

a software requirement is a property that must be exhibited by something in order to solve some problem in the real world. It may aim to automate part of a task for someone to support the business processes of an organization, to correct shortcomings of existing software, or to control a device—to name just a few of the many problems for which software solutions are possible.

소프트웨어 요구사항은 현실 세계에서 어떤 문제를 해결하기 위해 무언가가 나타내야 하는 속성입니다. 조직의 비즈니스 프로세스를 지원하거나, 기존 소프트웨어의 단점을 수정하거나, 장치를 제어하기 위해 누군가가 작업의 일부를 자동화하는 것을 목표로 할 수 있습니다.

위 내용을 단순화 시켜보자면, "현실에 어떤 문제가 있고, 그 문제를 해결하기 위한 해결책의 속성 목록"이라 할 수 있습니다.

지금까지 "요구사항이란 무엇인가", "소프트웨어 요구사항이란 무엇인가"를 살펴보았는데, 우리가 흔히 실무에서 사용하는 의미와는 좀 많이 다릅니다. 여기에서 우리는 한 가지 인정하고 넘어가야 하는 부분이 있습니다. 우리 모두는 흔히 실무에서 너무 쉽고 당연하게 '요구사항'이라는 단어를 사용하고, 실무를 수행하고 있다고 착각하고 살고 있습니다. 하지만, 사실 요구사항 수집 / 분석 / 관리 / 리뷰 등과 관련된 내용은 (테스팅이 소프트웨어 공학 내에서 별도의 학문으로 분류될 정도로 큰 축을 차지함) 소프트웨어 공학 내 '별도의 학문 영역'으로 나뉘어 있는 아주 깊이 있는 내용이며, 검색 엔진에서 Requirement Engineering이라는 키워드로 전문성 있는 자료들을 쉽게 찾아보실 수 있습니다. 요구 공학과 관련하여 좋은 한글 서적으로는 아래의 도서가 있으므로 관심이 있으신 분들은 참고하시기 바랍니다.

소프트웨어 요구사항 3

요구공학의 고전『Software Requirements』의 세 번째 판이다. 요구사항 관례 개선을 위해 현장에서 실질적으로 도움이 되는 입증된 기법들을 설명한다. 효율적인 요구공학 방법을 적용한 수십 개의

www.aladin.co.kr

이런 중요한 요구사항과 관련된 실무는 왜 꼭 해야 할까요? 어렵지는 않을까요? 누가 해야 하는 걸까요? 와 같은 질문에 대한 궁금증은 요구사항 관련 실무 이야기 편에서 알아보세요

그럼 이제 리뷰란 무엇일까요? 필자들이 풀이하고 있는 ISTQB의 용어 사전인 Glossary에서는 "리뷰(Review)"라는 용어를 아래와 같이 정의하고 있습니다.

A type of static testing in which a work product or process is evaluated by one or more individuals to detect defects or to provide improvements.

정적 테스팅 방식 중 하나로 한 명 이상이 결함을 찾거나 개선을 하기 위해 산출물이나 프로세스를 평가하는 작업이나 프로세스이다.

wikipedia에는 Software Review에 대해 다음과 같이 설명합니다.

A software review is "a process or meeting during which a software product is examined by a project personnel, managers, users, customers, user representatives, or other interested parties for comment or approval"

소프트웨어 Review란 "프로젝트 담당자, 관리자, 사용자, 고객, 사용자 대표 또는 기타 이해 당사자가 소프트웨어 제품을 검토하는 프로세스 또는 회의"를 말한다.

이 외에도 여러 가지 표준에 각 표준을 위한 "리뷰 활동"이 정의되어 있고, 그에 대한 용어들이 각기 다르게 정의되어 있습니다만, 일반적으로 내용은 거의 대동소이합니다. 위 사항들을 종합해보자면 「리뷰」라는 활동은 관련자들이 모여 산출물인 문서나 소스 코드 등을 검토하여 결함을 찾거나 개선을 하는 활동이라고 정의할 수 있습니다. 따라서 소프트웨어가 어떻게 동작하는지에 대한 설명을 적어놓은 요구사항을 관계자들이 모여 다양한 방법을 통해 검토하는 활동을 요구사항 리뷰라고 정의할 수 있습니다.

아래는 소프트웨어 리뷰를 다루는 몇 가지 국제 표준 등을 소개합니다.

• ISO/IEC 23396:2020 Systems and software engineering — Capabilities of review tools에서는 소프트웨어 평가 특성을 정의하는 리뷰 방법에 대해 정의합니다.
• ISO/IEC 20246:2017 Software and systems engineering — Work product reviews에서는 시스템 및 소프트웨어의 관리, 개발, 테스트 및 유지보수에 관련된 모든 조직에서 참조하고 사용할 수 있는 작업 산출물 검토를 위한 일반 프레임워크를 소개합니다.
• IEEE 1028-2008 IEEE Standard for Software Reviews and Audits에서는 소프트웨어 리뷰 및 감사 활동에 대한 일반적인 정의가 소개되어 있습니다.
• 그 외에도 여러 기업의 SDLC(Software Development Life-cycle)에는 모두 Review 활동이 포함되어 있습니다. 여러 기업들의 SDLC를 찾아보고 심도 있게 공부해 보는 것도 Review를 알아가는데에 많은 도움이 됩니다.

이제부터는 테스트를 진행하면서 발생할 있는 상황에 대해 요구사항과 테스트가 어떤 관계를 가지고 있는지 알아보려 합니다.

필자 주 - ISTQB에서 설명하는 리뷰에는 다양한 종류와 방법이 있지만, 본 글에서는 해당 내용에 대한 설명이 아니라 테스트와 관련된 일을 하면서 발생할 법한 상황들에 대한 이야기를 하고자 합니다.

일관되지 않은 사항에 대한 테스트 예

아래는 개발하려는 app의 요구사항 내용 중 일부라고 가정해 봅니다. (필자가 상정한 가정입니다.)

[OO WEB 개발 프로젝트]
.....
◈ 회원정보 관리 페이지
1. password의 최대 길이는 영문기준 30자
.....
◈ 회원 가입 페이지
1. password의 최대 입력 가능한 글자수는 영문기준 20자
.....

요구사항을 바탕으로 이제 테스트를 진행하려고 합니다. 회원 가입하는 페이지에서는 입력을 20자로 생성한 password가 회원정보 관리 페이지 내에서는 30자까지 변경이 가능해집니다. 회원 가입 시 실제 입력 가능한 글자 수가 20자를 넘지 못하는 상황에서 회원 관리 페이지의 최대 30자 지원은 다양한 문제를 만들어낼 가능성이 존재하게 합니다.

하지만 회원 관리 페이지의 password 최대 길이가 30자인 것이 20자의 오타일 수도 있고, 회원 가입 페이지의 20자가 오타일 수도 있고, 알지만 의도한 부분일 수도 있습니다. 이와 같은 상황에서는 의도한 부분보다는 실수일 가능성이 높습니다만, 어느 부분이 잘못되어 있는지는 알 수 없기에 해당 사항에 대한 확인이 반드시 필요합니다.

(1) 단순한 오타라면 최대 길이 지원을 몇 까지 할 것인지 다시 확인한 후 정리하면 됩니다.

(2) 특별한 이유가 있다면 해당 테스트 케이스에 설명을 남겨두어 기록해 놓거나, 해당 상황으로 인해 발생할 수 있는 문제점에 대한 테스트를 고민해야 합니다.

필자 주 - 리뷰를 하는 사람들도 놓치는 부분이 있을 수가 있는데, 테스트하는 분들이 이런 사소한 것 같지만 일관되지 않은 사항을 발견할 가능성이 높다고 생각합니다.

명확하지 않은 사항에 대한 테스트 예

아래는 개발하려는 app의 요구사항의 내용 중 일부라고 가정해 봅시다. (역시나 필자의 가정입니다)

[OO App 개발 프로젝트]
....
◈ 검색 결과
1. 검색 결과가 없는 경우 안내 문구 제공
2. 검색 결과가 있을 경우
<UI 설명>
3. 검색 결과가 11개 이상일 경우는 페이지로 분할하여 표시
4. 검색 결과는 빠르게 표시되어야 함
.....

이번 예시에서 눈여겨봐야 할 부분은 "4. 검색 결과는 빠르게 표시되어야 함"입니다.

"빠르게"는 사람마다 다르게 느낄 수 있습니다. 어떤 사람은 1초 이내면 빠르다고 느낄 수 있고, 어떤 사람은 0.5초 이내여야 빠르다고 느낄 수도 있습니다. 이처럼 모호한 단어가 사용되는 경우에는 테스트 기준도 명확하지 않아 테스트를 하기가 힘든 상황이 됩니다. 테스트를 하려면 "검색 결과는 최대 X초를 넘지 않아야 함"처럼 기준이 있어야 합니다. 그럼 "X초"라는 시간을 어떻게 정해야 할까요? 내가 느끼는 시간만을 기준으로 잡기에는 너무 주관적인 부분이라 역시나 담당자에게 확인을 요청해야 할 것입니다. 요청하기에 앞서 관련된 자료가 있는지 한 번 볼까요?

. 반응 속도에 대한 3가지 기준

제이콥 닐슨(Jakob Nielsen)이 1994년도 발간한 "Usability Engineering"에 따르면, 반응속도에 대한 3가지 기준을 제시합니다.

0.1 초 - 유저가 시스템이 즉각적으로 반응한다고 느끼는 시간
1 초 - 유저가 약간의 지연이 있다고 느끼지만 문제 되지 않을 정도의 시간
10 초 - 유저의 주위를 끄는 최대 시간으로 이 이상 지연될 경우 다른 작업을 하므로, 기다리는 동안 피드백이 필요함

필자 주 - 위는 워낙 오래된 자료라 2021년, 5G 시대의 모바일을 기준으로 하면 이제는 '10초'는 너무 오랜 기다림이지 않을까 생각이 들지만, 이를 제외하고는 의미가 있어 보이는 수치입니다.

. 모바일 페이지 로딩 속도와 이탈률의 관계

모바일 페이지 로딩 속도에 따른 이탈률에 대한 구글의 자료가 있습니다.

이탈율 : 구글 자료

로딩 시간이 오래 걸릴수록 비례하여 이탈률 수치가 커지는 것을 보여주고 있습니다.

. 로딩 속도와 매출 손실의 관계

실제 현장에서 발생한 매출 감소 자료도 있습니다.

속도와 매출관계 사례

구글에서 자료를 찾아보면 로딩 속도 100ms 지연마다 1% 매출 손실이 있다고 하는 등의 로딩 속도에 대한 매출 영향의 실제 데이터들이 존재합니다.

한국은 워낙 인터넷 속도가 빠르다보니 응답속도를 별거 아닌 것 취급하며 쉽게 생각하지만 위와 같은 사례들을 보면 응답속도는 사업에 대단히 중요한 영향을 미치는 요소임을 알 수 있습니다. 이런 사례들을 바탕으로 "이 서비스는 응답속도가 x초 정도는 되어야 하지 않을까"라고 제안을 해볼 수도 있고, 적어도 이 상황에 대해 알리고 해결방안을 찾아야 할 것입니다.

중요한 건 리뷰를 통해 제안을 해야 한다는 것이 아니라, 리뷰라는 테스트 활동을 통해 초기 설계, 기획, 요구사항 등에 잠재적 문제가 있음을 알리고 보완하도록 기회를 갖는 것입니다.

필자 주 - 모호한 표현을 정확하게 수치로 변환하는 것은 단순한 일이 아니기에 이런 자료를 바탕으로 제안하는 것이 더 좋을 것입니다. 스펙은 테스터의 영역이 아니긴 하지만 이런 자료와 테스터들의 경험을 바탕으로 제안을 한다면 조금 더 나은 결과를 도출할 수 있을 것이라 생각합니다.

디테일이 부족한 사항에 대한 테스트 예

아래는 개발하려는 또 다른 app의 요구사항 내용 중 일부라고 해 봅시다. (역시나 필자의 가정입니다)

[OO App 개발 프로젝트]
.....
◈ 비밀번호 생성
1. 비밀번호는 숫자로만 구성된 6자리만 설정 가능
.....
◈ 비밀번호 입력 화면
1. 암호 입력 키패드 표시
◈ 결제 화면
.....

위의 요구사항만을 가지고 개발할 경우에는 암호를 입력하는 키패드를 어떤 것으로 해야 할지가 정의되어 있지 않아 개발자 역량에 따라 구현될 가능성이 높습니다.

keypad 비교

개발자가 비밀번호는 숫자로만 가능한지 아닌지에 대한 사전 조건을 파악하고, 이런 상황에는 qwerty보다는 숫자 키패드가 더 편리하고 오입력을 막아줄 수 있으니 숫자 키패드로 만들어야겠다며 숫자 키패드로 개발하는 것은 어려운 일입니다. 비밀번호에 대한 테스트도 하는 테스터들이라면, 키패드가 숫자패드로 해도 충분하다는 것을 자연스럽게 하게 될 것입니다. 따라서 다른 사람들보다 요구사항의 부족한 디테일을 보완해 줄 수 있는 가능성이 높습니다.

마무리

요구사항 관리, 리뷰 활동에 대해서는 글의 초반에 언급한 바와 같이 '요구공학(Requirement Engineering)'이라는 분야가 따로 있을 정도로 넓고 깊은 지식이 존재합니다. 그래서 이번 편에서 필자들은 테스트를 수행하거나 준비를 하면서 만날 법한 상황을 가정해서 쓴 예들을 제공하였습니다.

요구사항이 테스트 전 단계에서 모두 완벽하게 정리되면 좋겠지만, 현실적으로 힘들고, 요구사항은 계속 변경되고, 누군가 회사에서 중요한 직책을 맡은 한 사람의 한 마디에 의해 뒤집힐 수 있습니다. 프로젝트에 참여한 많은 사람들이 다양한 관점을 통해 요구사항을 수집하는 단계에서 놓친 부분을 발견해서 수정하고, 애매한 사항에 대해 같이 고민해보고, 테스터의 경험을 살려 아이디어를 제공하는 것이 리뷰입니다. 요구사항 리뷰에는 다양한 기법이나 과정들을 통해 하는 방법도 있지만, 그런 것을 잘 알지 못하거나 하지 않아도 예제들과 같은 상황에서 문제점을 확인하고 보완하는 과정을 거친다면 그게 바로 테스트를 하면서도 요구사항을 리뷰하게 되는 실전이 되어, 리뷰의 원래 목적인 요구사항을 보완하는데 도움을 줄 수 있게 됩니다.

테스트 전문가 여러분! 여러분들이 어제 했던, 오늘 하고 있는 업무들이 결과적으로는 요구사항 리뷰가 될 수 있습니다. 그리고 이를 기반으로 여러분들이 하는 활동들이 품질향상의 밑거름이 될 수 있습니다. 그러므로, 남이 지금 당장 알아봐 주지 않는다고 주눅 들지 말고 열심히, 하루하루의 테스트 업무를 수행하십시오. 그렇게 쌓인 데이터는 언젠가 테스트를 넘어서 QA수준의 업무로 향상될 걸로 (필자들은 강력히) 믿습니다, 그리고 여러분들을 지지하고 있습니다.

오늘도 여러분의 슬기로운 테스터 생활을 응원합니다!

참여자 정보

• 글쓴이 : Bykj, 천년나무

• 검토한이 : 품생품사, 아이티마니, 창자로줄넘기

STEEG 개인 의견

[ALM] JIRA - 연재 : 품생품사

품생품사(品生品死) — Wed, 23 Mar 2022 21:09:48 +0900

안내

본 ALM 포스팅은 본 블로그의 필자 중 한 명인 품생품사가 개인적으로 작성하는 포스팅입니다.

본 포스팅의 내용에 관심이 있어 자신의 블로그 글을 본 블로그에 연재/노출하고자 하시는 분들은 아래를 열어 내용을 확인해 주세요.

본 블로그의 필자들은

세상 모든 사람들은 행복해야 하고, 행복하기 위한 방법을 공유해야 한다고 생각합니다.

세상 모든 기술은 사람 필요에 의해 만들어졌고, 쓰임이 있으며,

세상 모든 도구들은 기술의 쓰임에 의해 만들어졌고, 목적은 다양하다고 생각합니다.

본 글에서 필진들은 소프트웨어 도구들의 쓰임을 목적 별로 목차를 만들어 개재해보려 합니다.

단순히 목차를 제공하여 제품 매뉴얼 성격의 구성만 제공하는 목적입니다.

현재 필진이 아니신 분들도 본인 블로그의 글을 공유하고 싶으신 분들은 개제 요청해 주십시오.

SW 테스팅과 품질 카페로 참여 의사를 밝혀주시거나, 연재하고 있는 필자 중 한 명에게 연락해 주세요.

글-수정 권한을 가진 필진들이 열심히 내용을 업데이트 하겠습니다.

도구 소개

지라(JIRA)라는 이름의 유래는 고지라라는 일본식 이름에서 따왔다고 합니다.아틀리시안에 따르면, 190개의 국가에 150,000명의 고객이 지라를 사용하고 있습니다.

Jira 간략 정보

Jira는 190 개국 180,000명 이상의 고객이 이슈 추적 및 프로젝트 관리에 사용하고 있으며, 버그 추적 및 프로젝트 관리를 위해 특정 시점에 Jira를 사용한 조직 중에는 Fedora Commons, Hibernate 및 Jira와 Bugzilla를 모두 사용하는 Apache Software Foundation이 있습니다.

Jira에는 경쟁 업체 Bugzilla에서 마이그레이션 할 수 있는 도구가 포함되어 있고, Jira는 4 가지 패키지로 제공됩니다.

• Jira Work Management는 일반적인 프로젝트 관리.
• Jira Software에는 애자일 프로젝트 관리.
• Jira Service Management는 IT 운영 또는 비즈니스 서비스 데스크에서 사용.
• Jira Align은 전략적 제품 및 포트폴리오 관리.

Jira는 Java 로 작성되었으며, Pico inversion of control container, Apache OFBiz 엔티티 엔진 및 WebWork 1 기술 스택을 사용하고 있습니다. 원격 프로 시저 호출 (RPC), JIRA는 이 REST , SOAP 및 XML-RPC의 인터페이스를. Jira는 Clearcase , CVS ( Concurrent Versions System ), Git , Mercurial , Perforce , Subversion , 및 Team Foundation Server와 같은 소스 제어 프로그램과 통합됩니다.

영어, 프랑스어, 독일어, 일본어 및 스페인어를 포함한 다양한 번역과 함께 제공되고 있으며, Jira는 고객 지원 티켓을 다른 문제 추적 시스템과 공유하기 위해 Networked Help Desk API를 구현하고 있습니다.

기초 지식 정리

[기본 Guide] 야 너두 Jira 할 수 있어 #1

목차 Overview 지라(JIRA)라는 이름의 유래는 고지라라는 일본식 이름에서 따왔다고 합니다. 아틀리시안에 따르면, 190개의 국가에 150,000명의 고객이 지라를 사용하고 있습니다. Jira는 190 개국 180,000

qa-testing.tistory.com

특별 기고

크몽 개발팀 Jira 사용기 : 극대화 편

Jira를 이렇게까지 사용 가능한지 난 몰랐네?

medium.com

크몽 개발팀 Jira 사용기 : 응용 편

Jira 배포 관리 프로세스에 대한 ‘응용 편’을 준비했습니다.

medium.com

실무 적용편

#1 JIRA를 BTS(Bug Tracking System)로만 사용하고 있습니까?

[ALM - 실무적용편] JIRA를 BTS(Bug Tracking System)로만 사용하고 있습니까? #1

목차 JIRA를 BTS(Bug Tracking System)로만 사용하고 있습니까? #1 IT에서 일하고 있다면 Jira에 대해서 한 번쯤 들어 보셨을 겁니다. Jira | Issue & Project Tracking Software | Atlassian Plan, track, and m..

qa-testing.tistory.com

#2 이슈 구분하고 JIRA에 적용합니다.

[ALM - 실무적용편] JIRA를 BTS(Bug Tracking System)로만 사용하고 있습니까? #2

목차 JIRA를 BTS(Bug Tracking System)로만 사용하고 있습니까? #2 이전 글에서는 JIRA를 도입하기 전에 무엇을 준비해야 하는지 알아보았습니다. 앞으로의 글은 JIRA의 기능 설명이 아닌 정말 프로젝트를

qa-testing.tistory.com

#3 작업 흐름을 만들어 봅시다. (1)

[ALM - 실무적용편] JIRA를 BTS(Bug Tracking System)로만 사용하고 있습니까? #3

목차 JIRA를 BTS(Bug Tracking System)로만 사용하고 있습니까? #3 지난 글까지는 이슈가 무엇인지에 대해서 알아보았습니다. 다시 요약하자면 JIRA에서 "이슈 = 해야 할 일"이고, JIRA에서 "프로젝트 = 이슈

qa-testing.tistory.com

#4 작업 흐름을 만들어 봅시다. (2)

[ALM - 실무적용편] JIRA를 BTS(Bug Tracking System)로만 사용하고 있습니까? #4

목차 JIRA를 BTS(Bug Tracking System)로만 사용하고 있습니까? #4 지난 글까지 이슈가 무엇인지 알아보았고, 작업 흐름(Workflow)을 왜 만들어야 하는지에 대해서 알아보았습니다. 그리고 작업 흐름에서 가

qa-testing.tistory.com

[필진 소개] 창자로줄넘기

rod51 — Wed, 15 Dec 2021 21:16:13 +0900

1. 필진 아이디 : 창자로줄넘기

취미로 테스터를 하고 있는 사람입니다.

게임으로 시작해서 어느 순간부터는 이커머스를 테스트하고 있네요

모르는 것도 많고, 알고 싶은 것도 많아 혼자 열심히 공부하고 있으며, 얻은 지식으로 좋은 글들을 한번 남겨 보도록 하겠습니다.

2. 경력

현) 쿠팡이츠 QA

전) 와이즈와이어즈 QA

전) 아시아나 항공 프리랜서 QA

전) 홍인터내셔날 QA

전) 넷마블 개발사 QA

전) CJIG 게임 퍼블리싱 QA

전) 누리엔소프트웨어 QA

3. 주요 관심사

Python automation script

T-map API 활용

농구를 하면서 어떻게 하면 슛이 잘 들어갈까?

낚시를 시작해 볼까?