상세 컨텐츠

본문 제목

Software QA/Test Resource Center FAQ 일부 번역

테스팅 번역 자료들

by techbard 2007. 5. 22. 15:09

본문

반응형
http://www.softwareqatest.com/qatfaq1.html
은 지속적으로 갱신되는 QA/Test 관련 정보의 산실(?)입니다. 저도 이곳의 FAQ를 보고 배운것이 많아 초보인 분들을 위해 FAQ의 일부를 올립니다.

지금 다시 보니 예전에는 보이지 않았던 내용들이 더 추가된 것 같습니다. 현재 제 번역에 딱 맞는 링크를 찾을 수 없긴 합니다만 예전 내용들이 그대로 살아 있는 것 같긴 합니다.

도움이 되시길... (December 24, 2004 11:20:17 AM, Translated By jmshin)

http://www.softwareqatest.com/qatfaq1.html

--------------------------------------------------------------------------------------

Q1) QA 활동이 왜 중요하게 관리되기 어려운가?

문제를 해결하는 과정은 눈으로 확인하기 쉬운 프로세스이다. (문제를 예방하는
과정은 눈으로 확인하기 어렵다.)

Q2) 왜 소프트웨어는 버그를 내포하게 되나?

o 의사 소통의 오류나 의사 소통이 없는 경우 - 어플리케이션이 어떤 특정한
무언가를 해야 하는지 하지 않아야 하는지(어플리케이션의 요구 사항)

o 소프트웨어의 복잡도 - 현재의 소프트웨어 어플리케이션의 복잡도는 현대의
소프트웨어 개발 과정을 겪어 보지 못한 사람은 이해하기 어렵다. 윈도우
인터페이스, 클라이언트-서버, 분산 어플리케이션, 데이터 통신, 거대한 관계형
데이터베이스 그리고 어플리케이션의 순수한 크기 등의 모든 요소가 소프트웨어/
시스템의 복잡도를 기하급수 적으로 증가시킨다.

o 프로그래밍 에러 - 프로그래머도 다른 사람들 처럼 실수를 한다.

o 요구사항 변경 - 고객은 요구 사항 변경이 초래할 수 있는 결과에 대해서
이해하든 아니든 간에 요구 한다. 디자인 변경, 엔지니어의 스케줄 조정, 다른
프로젝트에 영향 초래, 이미 완료한 작업에 대해서 재작업하거나 작업 내용을
버려야 하는 요구, 하드웨어 요구 사항 들이 요구될 수 있다. 그게 많은 수의
작은 수정이든 몇 개의 대규모 수정이든 프로젝트의 구성 요소 간의 의존성을
알고 모르는 것은 문제와 관계가 있거나 문제를 유발하는 경향이 있으며 변경
사항을 추적하기 복잡한 경우 에러가 발생할 수 있으며 엔지니어링 스탭의 의욕을
상실하게 할 수 있다. 빠르게 변하는 비지니스 환경에서 계속적으로 요구사항이
변경되는 것은 어찌보면 당연할 일이다. 이런 경우, 관리자는 리스크에 대해서
이해하고 있어야 하며, QA와 테스트 엔지니어는 통제할 수 없는 상황에서
유발되는 필연적인 버그를 관리하기 위해 계속적으로 늘어나는 테스트에 맞는
계획을 세우고 그 계획을 수정해야 한다.("요구사항이 끊임 없이 변하는 경우
어떻게 해야 하나?"를 보라.)

o 일정 엄수 - 소프트웨어 프로젝트의 스케줄링은 잘하기 어렵다. 가끔은 감에
의한 추정이 필요한 경우도 있다. 마감 시간이 닥쳐오게 되면 실수가 생기게
마련이다.

o 문서화가 부족한 코드 - 문서화가 잘 되어 있지 않은 코드를 수정, 유지보수
하는 일은 고달픈 일이며 그 결과는 버그로 나타난다. 많은 조직의 관리자 들은
코드에 대해 문서화를 하거나, 깔끔하게 작성하고, 이해하기 쉬운 코드를
작성하는 프로그래머에 대해서 보상을 하지 않는다. 사실 그건 반대다. 그들은
코드를 빠르게 작성하는데 집중하고 아무도 그 코드를 이해하지 못하는 경우
그들은 그들의 자리(직업)를 지킬 수 있다. ("작성하기 어렵다면, 읽기도 어려울
것이다.")

o 소프트웨어 개발 툴 - 비주얼 툴, 클래스 라이브러리, 컴파일러, 스크립팅 툴
등. 가끔 개발 툴 자체가 가지고 있는 버그나 부족한 문서화 때문에 버그가
발생하기도 한다.

Q3) 어떻게 하면 새로운 소프트웨어 QA 프로세스를 기존 조직에 도입할 수 있나?

많은 부분 조직의 크기와 관련이 있고 위험이 수반된다. 위험도가 높은
프로젝트(사람의 생명이나 금전과 관계된)를 수행하는 거대한 조직에서는 미리
준비된 사전 관리가 필요하며 정규화된 QA 프로세스가 필요하다.

위험이 낮은 부분에서 수행되는 단계적인 프로세스와 정규화된 관리, 조직 그리고
QA 활동은 느린 속도를 보일 수 있다. QA 프로세스는 통제가 되지 않는 활동을
통제되는 상황으로 유지하기 위해서 생산성과 균형을 맞추어야 한다.

작은 규모의 조직이나 프로젝트에서는 고객이나 프로젝트의 유형에 따라 더 많은
ad hoc 프로세스가 적합할 수도 있다. 많은 부분이 팀리더나 관리자, 개발자로
가는 피드백 그리고 고객, 관리자, 개발자, 테스터 간의 적절한 의사 소통에
달려 있다.

모든 상황에서 가장 중요한 것은 요구 사항 관리 프로세스 안에서의 명백하고
완전하며 테스트 가능한 요구 사항 스펙에 대한 노력이다.

Q4) Verification은 머고 Validation은 뭔가?

일반적으로 Verification은 문서, 계획, 코드, 요구사항, 스펙을 평가하기 위한
리뷰나 미팅을 포함한다. 이런 절차는 체크 리스트, 이슈 리스트, 웍쓰루,
Inspection 미팅으로 할 수 있다. Validation은 실제적인 테스팅을 말하며
Verification이 완료되면 발생한다.

Q5) 웍스루('walkthrough')는 뭔가?

평가나 정보 공유 목적의 비공식 미팅을 말함

Q6) 'inspection'은 뭔가?

웍쓰루보다는 좀 더 공식화된 것으로, 일반적으로 조정자, Reader(미팅 자료를
리뷰하는), Recorder(미팅 기록을 남기는)로 구성되는 3-8명의 사람으로
이루어진다. inspection의 주제는 요구사항, 테스트 계획과 같은 문서이다.
목적은 문제를 찾아내거나 무엇이 빠졌는지, 수정할 부분은 없는지 보는 것이다.
참석자들은 이런 종류의 미팅에 참석하기 전에 관련 문서를 읽고 미리 준비해야
한다. 대부분의 문제는 이런 사전 준비에서 발견될 것이다. inspection 미팅의
결과는 리포트로 작성되어야 한다. inspection을 미리 준비하는 것은 어렵지만
버그를 찾아내는 것보다 버그를 예방하는 것이 더 비용 극대화가 가능하다는
사실이 알려진 이후로 품질을 책임질 수 있는 가장 효과적인 방법중 하나이다.

Q7) 소프트웨어 개발 과정에서의 일반적인 다섯 가지 오류는 무엇인가?

1. 요구사항 부실 - 요구사항이 명확하지 않거나, 완전하지 않고 너무
일반적이거나 테스트 가능하지 않으면 버그는 발생한다.

2. 비현실적인 스케줄 - 너무 짧은 시간에 많은 작업이 몰려 있다면 문제는
피할 수 없다.

3. 충분하지 않은 테스팅 - 고객이 불만을 표시하거나 시스템이 크래쉬되기
전까지는 프로그램이 좋은지 나쁜지 누구도 알 수 없을 것이다.

4. 뒤늦은 기능 추가 요구 - 개발이 진행되고 있는데 새로운 기능들의 추가를
요구 하는 것은 아주 아주 일반적이다.

5. 잘못된 의사 소통 - 개발자가 무엇이 필요한지 모른다거나 또는 고객이 잘못된
기대를 하는 경우 문제는 필연적이다.

Q8) 소프트웨어 개발 과정에서의 일반적인 다섯 가지 해결책은 무엇인가?

1. 충실한 요구 사항 - 모든 유관 부서에서 합의된 명확하고, 완전하고,
자세하고, 조직적이고, 실현 가능하고, 테스트 가능한 요구 사항. 프로토타잎을
사용하면 요구 사항을 확정하는데 도움을 얻을 수 있다.

2. 현실적인 스케줄 - 계획, 디자인, 테스팅, 버그 수정, 재 테스팅, 수정 그리고
문서화 등에 충분한 시간을 갖도록 한다.(전 인원의 기력이 다하기 전에
프로젝트가 완료되어야 함)

3. 적절한 테스팅 - 초기에 테스팅이 시작되고, 수정/변경이 이루어진 이후에
재 테스팅, 테스팅과 버그 수정에 충분한 시간을 가질 수 있도록 계획함.

4. 초기 요구 사항을 가능한한 많이 결정한다 - 개발이 진행된 이후 변경이나
추가 요청을 거부할 준비를 하고 변경 되었을 경우 발생할 수 있는 결과를
설명할 수 있어야 함. 변경이 불가피하다면 그것이 관련된 일정에 충분히
반영되어야 한다. 변경이 가능하다면 예상한 것을 볼 수 있게 하기 위해 디자인
과정중에 신속하게 프로토타이핑을 사용한다. 이런 상황은 그들의 요구 사항을
더 안심할 수 있게 하며 이후의 변경을 최소화 할 수 있게 한다.

5. 의사 소통 - 적절한 시점에 '웍쓰루'와 'inspection'이 필요하다. 광범위한
그룹 의사 소통 도구를 사용하게 만들어라.(이메일, 그룹웨어, 다중 사용이
가능한 버그 추적 시스템, change management tool, 인트라넷 활용 등) 문서가
사용 가능하며 항상 최신으로 업데이트 되어 있는지 확인하라.(전자적인 문서가
바람직하고 종이는 좋지 않다.) 팀워크와 협동을 증대시켜라. 사전에
프로토타잎을 사용해서 고객의 예상이 명확하도록 하라.

Q9) 소프트웨어의 '품질'은 무엇을 말하는가?

좋은 소프트웨어는 이성적으로 버그가 없는 것으로, 주어진 예산으로 적시에
출시되고, 요구사항 또는(그리고) 예상을 만족하고, 유지보수가 가능한 것이다.
하지만, 품질은 확실히 주관적인 용어이다. 품질은 "고객"이 누구냐에 따라
좌우되며 다른 것에 미치는 전체적인 영향력이 어떤 계획안에 있는 것을 말한다.
소프트웨어 개발 프로젝트에서 "고객"이라는 용어를 폭넓은 관점으로 보면,
실 사용자, 실제 사용자에게 인도된 것 같은 테스트를 수행하는 테스터,
고객 계약 담당자, 고객 관리, 개발/회계/테스터/영업 조직 관리, 장래에
소프트웨어 유지 보수를 담당할 엔지니어, 주주, 잡지 컬럼니스트 등등이
해당된다. 이러한 형태의 "고객"은 그들만의 "품질"에 대한 관점을 가지고 있다.
(실 사용자는 "품질"을 사용하기 편하고 버그가 없는 상태로 말하는데 반해 회계
관리 부서에서는 "이익"으로 정의할 것이다.)

Q10) 좋은 코드는 무엇인가?

좋은 코드는 작동하고 버그가 없고, 읽기 쉬워야 하고, 유지보수가 가능한
코드이다. 어떤 조직에서는 모든 개발자가 지킬 것으로 가정하는 "코딩 규칙"을
가지고 있으나 모든 사람들은 가장 좋은 방법, 너무 많은 규칙, 너무 적은 규칙에
대한 생각이 각자 다르다. 역시 이런 식으로 다양한 이론과 지침들이 존재한다.
과도한 표준과 규칙은 생산성과 창의성을 제한한다는 점을 유의해야 한다.
피어 리뷰, 코드 분석 툴을 이용한 상호 체크와 같은 것들이 문제를 찾아내거나
표준을 강제하도록 만들 수 있다.

Q11) '좋은 디자인'이란 무엇인가?

디자인은 많은 것과 연관이 있지만 가끔은 기능적인 디자인 또는 내부적인
디자인과 연관이 있다. 좋은 기능 디자인은 고객이나 실 사용자의 요구 사항을
파악할 수 있는 기능을 가진 어플리케이션을 가리킨다. 좋은 내부 디자인은
전체 구조가 명확하고, 이해 가능하고, 쉽게 변경할 수 있고, 유지 보수가 가능한
소프트웨어 코드를 가리키며(에러 처리를 충분히 견디내고, 상태 로그 출력
기능을 제공하는) 수행되었을 때 올바르게 동작하는 코드를 말한다.(이 주제에
대한 논의는 '요구사항에 대해서 버리고 취해야 하는 것은 무엇인가?'를 보라.)

Q12) 'software life cycle'이란 무엇인가?

라이프 싸이클은 어플리케이션이 첫번째로 전달될 때 시작되고 더 이상 사용되지
않아서 끝날때 종료된다. 이것에는 초기 컨셉, 요구 사항 분석, 기능 디자인,
내부 디자인, 문서 계획, 테스트 계획, 코딩, 문서 준비, 통합, 테스팅,
유지 보수, 업데이트, 재 테스팅, 단계 종료 그리고 다른 상황들이 포함된다.

Q13) Will automated testing tool make testing easier?

...

Q14) 어떻게 하면 좋은 테스트 엔지니어가 될 수 있나?

...

Q15) 어떻게 하면 좋은 소프트웨어 QA 엔지니어가 될 수 있나?

테스트 엔지니어와 같은 특성은 QA 엔지니어에게도 도움이 된다. 부가적으로,
전체 개발 과정과 어떻게 하면 조직의 목적과 비지니스적 접근에 근접할 수
있는지 이해하고 있어야 한다. 커뮤니케이션 스킬과 이슈의 다양한 면을 이해하는
능력이 중요하다.

Q16) What makes a good QA or Test manager?

...

Q17) QA로서의 문서화의 역할은 어떤 것이 있나?

문서화는 QA로서 매우 중요한 역할이다. QA 활동을 반복하기 위해 문서화 되어
있어야 한다. 스펙, 디자인, 비지니스 규칙, inspection 리포트, 환경들,
코드 변경, 테스트 계획, 테스트 케이스, 버그 리포트, 유저 매뉴얼 등이 모두
문서화되어 있어야 한다. 이상적으로는 어떤 문서에 어떤 정보가 들어 있는지
문서를 찾기 쉬운 시스템이어야 한다. 가능하다면 문서의 변경 이력 관리도 할 수
있어야 한다.

Q18) '요구사항'에서 빼고 넣어야 하는 요소에는 어떤 것이 있나?

복잡한 소프트웨어 프로젝트에서 문제점이나 실패가 발생하는 확실한 이유는
부족하게 작성된 요구사항 스펙 때문이다. 요구사항은 어플리케이션이 외부적으로
인식되는 기능이나 속성에 대한 자세한 표현이다. 요구사항은 명확하고,
완전하고, 이성적으로 자세하고, 단단하고, 달성 가능해야 하고 테스트 가능해야
한다. 테스트 가능하지 않은 요구사항은, 예를 들어 'user-friendly'(매우
주관적인)과 같다.
테스트 가능한 요구사항은 '제품은 유저가 어플리케이션에 접근하기 위해서는
이전에 입력되었던 암호를 입력하도록 유저에게 요청해야 한다." 와 같은 식이다.

요구사항 수립 단계에서 프로젝트의 명백한 '고객'인 모든 사람이 참여하도록
고려해야 한다. '고객'은 회사내 고객과 회사외의 고객 모두 포함될 수 있다.
또 실 사용자, 고객 접수 테스터, 고객 계약 담당자, 고객 관리 조직, 장래에
제품을 유지 보수할 엔지니어, 영업 등이다.
나중에 프로젝트의 계획을 변경시킬 수 있는 어떤 인원의 기대치를 만족시키지
못하게 될 경우 가능하다면 그를 고객으로 프로젝트에 포함시켜야 한다.

어떤 조직에서는 요구 사항이 높은 수준의 프로젝트 계획, 기능 스펙 문서,
디자인 문서 또는 다양한 상세 수준의 문서에서 끝나기도 한다. 그들이 뭐라고
부르던 간에 자세한 요구사항이 기술되어 있는 문서는 올바른 테스트 계획과
테스트를 수행하기 위해 테스터에게 필요하다. 그러한 문서가 없는 경우 테스터는
소프트웨어 어플리케이션이 올바르게 동작하는지 결정하는 명확한 방법이
없게된다.

Q19) '테스트 계획'은 무엇인가?

소프트웨어 프로젝트에서 테스트 계획은 목적, 범위, 접근 방법 그리고
소프트웨어 테스팅 활동에 대해 기술되어 있는 문서이다. 테스트 계획을 준비하는
과정은 소프트웨어 제품의 만족도를 확인하기 위해 필요한 활동을 생각해보면
쉽다. 완성된 문서는 테스트 그룹 이외의 사람에게 제품을 '왜', '어떻게' 확인할
것인가 이해하게 할 것이다. 그 문서는 충분히 유용해야 하지만 테스트 그룹 외의
인원이 이해할 수 없을 정도로 작성되어서는 안된다.

Q20) '테스트 케이스'란 무엇인가?

테스트 케이스는 입력, 동작 또는 이벤트 그리고 그 이벤트의 예상 결과, 제품의
기능이 올바르게 동작하는지 결정하기 위한 내용을 담고 있는 문서이다. 테스트
케이스는 테스트 케이스 식별자, 이름, 목적, 조건/사전 조건, 입력 데이터
요구 사항, 스텝 그리고 예상 결과와 같은 특정한 내용을 담고 있어야 한다.

보충 설명 : 테스트 케이스를 작성하는 과정을 통해 어플리케이션의 동작을 통해
완전한 고려가 이루어 진 후 요구 사항이나 어플리케이션의 디자인에 남아 있는
문제를 발견하게 해준다. 이런 이유로, 가능하다면 개발 과정 초기에 테스트
케이스를 작성하는 것이 유용하다.


Q21) What should be done after a bug is found?

...

Q22) What is configuration management(CM)?

...

Q23) 만약 소프트웨어에 버그가 많아서 테스트를 모두 수행할 수는 없었다면?

이런 상황에서 최선의 선택은 버그거나, 초기에 나타나는 테스트를 방해하는
어떤 문제던 간에, 심각한 버그에 주의하면서 리포트 프로세스를 밟는 것이다.
이런 종류의 문제가 심각하게 스케줄에 영향을 미칠 수 있고 개발 프로세스에
문제의 근원(충분하지 않은 유닛 테스트, 통합 테스트, 부족한 디자인, 잘못된
빌드나 릴리즈 절차 등)이 있다고 알려지고 나면 매니저는 문제를 알아차려야
하고 문제의 증거인 문서를 제공해야 한다.

Q24) 테스트를 중단하는 시점을 어떻게 알 수 있나?

이 시점은 결정하기 어렵다. 많은 현대의 소프트웨어는 매우 복잡하기 때문에
서로 의존적인 환경에서 구동해 보거나 완전한 테스팅이 가능하지 않다. 테스팅을
종료하는 시점을 정하는 요인은 다음과 같다.

o 데드라인(릴리즈 시한, 테스트 시한 등)
o 테스트 케이스중 X 퍼센티지가 성공한 경우
o 테스트 예산이 모두 소모된 경우
o 코드/기능/요구사항의 커버리지가 특정한 수치를 달성했을 때
o 버그 발견 비율이 특정한 레벨 이하가 될 때
o 베타/알파 테스팅 기간이 끝났을 때

Q25) 테스트를 충분히 수행할 만한 시간이 없다면?

어느 부분에 테스트를 집중해야 하는지 결정하기 위해 위험 분석을 시도하라.
어플리케이션의 가능한 모든 면, 가능한 모든 이벤트의 조합, 모든 의존 관계,
잘못된 수 있는 모든 것을 테스트 하는 것은 거의 불가능하기 때문에 위험 분석을
사용하는 것이 모든 소프트웨어 개발 프로젝트에서 유용하다.

고려 사항은 다음과 같다.

o 프로젝트가 의도하는 목적에서 가장 중요한 기능은 무엇인가?
o 어떤 기능이 사용자에게 가장 많이 보여지는가?
o 어떤 기능이 안전성에 가장 많이 영향을 많이 주나?
o 어떤 기능이 사용자에게 금전적인 영향을 가장 많이 주나?
o 제품의 어떤 면이 고객에게 중요한가?
o 제품의 어떤 면이 제품 개발 과정중에서 먼저 테스트 될 수 있나?
o 어떤 부분의 코드가 가장 복잡한가? 따라서, 가장 에러 유발 경향이 많은
코드는?
o 어플리케이션의 어떤 부분이 급하고 정신없이 작성되었나?
o 이번 프로젝트와 유사하거나 관련이 있는 지난 프로젝트의 어떤 부분이
문제를 유발시켰나?
o 이번 프로젝트와 유사하거나 관련이 있는 지난 프로젝트의 어떤 부분이
가장 많은 유지보수 비용이 발생시켰나?
o 요구 사항이나 디자인의 어떤 부분이 불분명하거나 충분히 고민되지
않았나?
o 개발자가 생각하는 어플리케이션에서 가장 위험한 부분은?
o 어떤 문제가 명성에 나쁜 영향을 미칠 수 있나?
o 어떤 문제가 가장 customer service 파트에 불만을 초래할 수 있나?
o 어떤 종류의 테스트를 수행해야 쉽게 여러 기능을 커버할 수 있나?
o 어떤 테스트가 주어진 시간 대비 가장 위험도가 높은 부분을 커버할 수
있나?

Q26) 넓은 범위의 테스트를 수행할 타당성이 없을 만큼 프로젝트의 규모가 크지 않은
경우는?

프로젝트의 크기가 아닌 프로젝트가 실패했을 경우의 영향을 고려하라. 하지만,
광범위한 테스트가 여전히 정당성을 인정 받지 못하는 경우 위험 분석이 다시
필요하게 되며 이전에 언급한 "전체 테스트를 할 수 없을 정도로 시간이 충분하지
않다면?"과 같은 고려가 필요하다. 테스터는 ad hoc 테스트를 수행할 수도 있고
위험 분석에 따라 제한적인 테스트 플랜을 작성할 수도 있다.

Q27) 요구 사항이 수시로 변경되는 경우 어떻게 해야 하나?

얼마나 요구사항이 변경될 수 있는지 이해시키기 위해 프로젝트의 결정권을
가지고 있는 사람과 초기부터 같이 작업을 한다. 그래서 가능한 한 테스트 계획을
변경하고 전략을 사전에 수립해 놓는다. 만일 어플리케이션의 초기 디자인이
약간의 융통성을 허용한다면 도움이 될 수 있으며 나중에 이루어지는 변경이
버그 방지를 위해 재작업을 필요로 하지 않을 것이다.

o 코드에 설명이 잘 되어 있고 관련 문서가 충분하다면 개발자가 더 쉽게
수정을 할 수 있을 것이다.
o 최소한의 수정과 고객이 요구 사항에 대해 안심할 수 있도록 가능할 때마다
빠른 프로토타이핑을 사용하라.
o 프로젝트의 초기 일정 계획은 변경 가능성에 비례해서 추가적인 일정이
허락되어야 한다.
o 초기 요구 사항으로 1단계 버전의 작업을 진행하면서 새로운 요구 사항은
2단계 버전의 요구 사항이 되도록 노력한다.
o 향후 버전에 더 구현하기 어려운 추가 요구 사항을 구현하도록 계획을
미루면서 쉽게 구현 가능한 추가 요구 사항을 먼저 구현하도록 설득한다.
o 고객이나 관리자가 현저한 요구 사항 변경의 비용, 본래 부터 있었던 위험
요소들, 일정에 미치는 영향 등을 이해하고 있는지 확인하라. 그런다음,
관리자나 고객에게 변경 사항이 정당한 것인지 최종 결정하도록 하라.(결국,
이런 결정은 그들의 일이다.)
o 수정 사항 때문에 예상되는 재 테스트를 위해 자동화된 테스트를
구축하도록 리소스를 적절해 배분하라.
o 자동화된 테스트 스크립트에 약간의 유연성있는 디자인을 하도록 노력하라.
o 거의 변경되지 않은 어플리케이션의 영역에 대해서 초기에 자동화된
테스트를 하도록 집중하라.
o Regression 테스트가 최소화 되게 위험 분석을 하도록 노력하라.
o 테스트 케이스를 유연하게 작성하라.(이건 쉽지 않다. 아마 최고의 방법은
테스트 케이스를 자세하게 적지 않거나 높은 수준의 일반적 테스트 계획을
세우는 것이다.)
o 자세한 테스트 계획이나 테스트 케이스 보다는 ad hoc 테스트에 집중한다.
(이러한 결과가 발생시키는 위험에 대해서 이해해야 함)

Q28) 어플리케이션이 요구 사항에 없는 기능을 가지고 있다면?

어플리케이션에 존재하는 현저하게 예상하지 않았던 또는 숨겨진 기능이 개발
과정 상의 더 심각한 문제를 나타내고 있는지 판단하기 위해서는 매우 많은
노력이 필요하다. 만일 기능이 어플리케이션의 목적에 불필요하다면 설계자나
고객에게 설명되지 않은 알 수 없는 영향이나 의존성이 존재할 수 있기 때문에
제거 되어야 한다. 제거된다면 추가적인 테스트가 필요한지, Regression 테스트가
필요한지 결정하기 위해 디자인 정보가 필요하게 된다. 관리자는 기대하지 않았던
기능의 결과와 같이 심각하게 추가된 위험에 대해서 의식하고 있어야 한다. UI에
대한 사소한 수정과 같이 예상치 않았던 기능이 미치는 범위가 협소하다면 심각한
위험이 아닐수도 있다.

Q29) 어떻게 하면 생산성에 크게 영향을 미치지 않고 소프트웨어 QA 프로세스를
수행할 수 있나?

시간을 가지고 천천히 QA 프로세스를 수행하고, 조직이 성장하고 성숙하면서
프로세스의 승인을 얻기위해 의견 일치를 시도하고, 조정하고 실험하는 과정을
거친다면 생산성은 향상되어질 것이다. 문제를 사후에 찾아내는 것보다 문제를
예방해야 하는 필요가 더 적어질 것이며, 혼돈 상황이나 기진맥진한 상황이
감소하여, 시간을 덜 들이고 향상된 집중력을 발휘하게 될 것이다. 그와 동시에
프로세스를 간단하고 효율적이게 만들어야 하며, 종이를 이용한 작업은 적게,
컴퓨터를 이용해 프로세스를 처리하고 자동으로 추적, 보고가 가능하도록
해야한다. 그리고, 미팅에 필요한 시간을 줄이고 QA 프로세스 작업에 대해서
훈련하도록 해야 한다. 하지만, 아무도 규칙이나 관료적인 것을 좋아하지 않고
(특히 기술적인 것에 재능이 있는 사람들은) 불충분하게 수행되는 경우 수행
속도가 느려질 수도 있다. 전형적인 시나리오는 계획과 개발에 더 많은 일정이
필요하게 되지만 밤늦게 버그를 수정해야할 필요가 줄어들고 고객의 불만이
감소하게 된다.

Q30) 조직이 빠르게 성장하기 때문에 QA 프로세스의 개선이 불가능한 상황이라면?

특히 신기술 분야 같은 소프트웨어 산업에서 일반적으로 발생하는 문제이다.
아래와 같은 해결책 외에는 다른 쉬운 해결책은 없다.

o 능력이 뛰어난 인재를 고용한다.
o 관리자가 고객에 초점을 맞추면서 품질 문제에 "엄격하게 우선순위"를
두어야 한다.
o 조직의 모든 구성원이 고객에게 있어서 "품질"이 무엇을 의미하는지
명확하게 알고 있어야 한다.

Q31) 클라이언트-서버 환경이 테스팅에 어떤 영향을 미치나?

클라이언트-서버 어플리케이션은 클라이언트, 데이터 통신, 하드웨어, 서버가
상호간에 복합적인 의존 관계에 있기 때문에 매우 복잡해질 수 있다. 그러므로,
매우 광범위한 형태의 테스팅이 요구된다. 시간이 제한적으로 주어질 때는(대개
그렇지만) 통합과 시스템 테스트에 집중해야 한다. 추가적으로 부하/스트레스/
성능 테스트가 클라이언트/서버 어플리케이션의 제약 사항과 능력을 결정하는데
유용할 수 있다. 이런 종류의 테스트를 지원하는 상용 툴이 존재한다.

Q32) How can Web sites be tested?

...

Q33) 객체 지향 디자인에 대해 테스트는 어떻게 영향을 받나?

잘 짜여진 객체 지향 디자인은 코드로 부터 내부 디자인, 기능 디자인, 요구 사항
까지 더 쉽게 추적할 수 있게 한다. 객체 지향 디자인은 블랙 박스 테스팅에
적게 영향을 줄 수 있지만 화이트 박스 테스팅은 제품의 객체에서 비롯될 수
있다. 만일 제품이 잘 디자인 되어 있다면 객체 지향 디자인은 테스트 디자인을
간단하게 할 수 있다.

Q34) 디자인 단계가 진행되는 동안 테스트 하는 것이 왜 권장되나?

디자인 단계에서 함께 수행되는 테스트는 이후의 버그를 방지할 수 있다. 아래
3가지 내용에 대해서 확인해 볼 것을 추천한다.

1) 디자인이 잘되어 있는지 확인한다.(효율적이고, 간결하고, 테스트
가능하고, 제품 유지 보수가 가능한지)
2) 디자인이 요구 사항을 충족하고 완전한지 확인한다.(모듈 간의 모든
관계가 언급되어 있고, 데이터가 어떻게 지나가는지, 예외적인 상황에서는
어떤 일이 발생하는지, 각 모듈의 시작 상태 그리고 어떻게 모듈의 상태를
보증하는지)
3) 디자인이 메모리나 I/O디바이스에 충분히 짜넣을 수 있는지, 릴리즈
제품에서 충분히 빠른 실행 시간을 가지는지 확인해야 한다.

Q35) 통합 테스트를 하기 위해 다섯 가지 방법은 뭔가?

1) Bottom-Up Approach : 낮은 수준의 모듈이나 하부 시스템으로 테스트를
시작하고 메인 프로그램이나 모듈, 하부 시스템으로 올라가는 단계를 밟는다.
실행 순서를 결정하기 위해 구조 챠트가 필요하다. Bottom-Up Approach를
완성하기 위한 드라이버의 개발이 필요하다.
2) Top-Down Approach : 메인 모듈이나 하부 시스템으로 테스트를 시작하고
낮은 수준의 모듈이나 하부 시스템으로 내려가며 진행한다.
3) Data Flow Approach : 데이터 흐름에 의한 프로그램, 모듈, 하부 시스템의
통합에 집중한다.
4) Capacity Approach : 기능적인 그룹으로 테스트하며 위에 언급된 세가지
접근 법이 사용하는 구조적인 분석은 사용하지 않는다.
5) Non-incremental or "Big Bang" Approach : 한 번에 실행하기 위해 모든
프로그램, 모듈, 하부 시스템을 결합한다.

Q36) 세가지 소프트웨어 개발 모델은 무엇인가?

1) Waterfall : 프로젝트 활동이 직선적으로 진행함
2) Spiral : 이전 Spiral 단계의 결과를 기초로 진화, 위험, 검증 그리고
계획 활동에 반영되도록 Waterfall의 계획, 요구 사항, 디자인이 세번 반복
수행된다.
진화 방법 : 각 개발 활동의 결과물이 이전과 이후 모두 반영된다.

- 끝 -
반응형

관련글 더보기

댓글 영역