상세 컨텐츠

본문 제목

The top five software-testing problems and how to avoid them by Lars Mats

테스팅 번역 자료들

by techbard 2007. 6. 7. 16:02

본문

반응형

조금은 뻔한 얘기지만 다섯가지 소프트웨어 테스팅에서의 문제란다. 출처는 이곳. PDF 파일 원문도 첨부한다.


이하 번역 나간다. ^^

The top five software-testing problems and how to avoid them

Some common software-testing problems are not severe, and others are more costly to correct. Real-life scenarios provide helpful guidelines that can prevent these problems in the first place.

Lars Mats, Telelogic Technologies MalmöAB -- EDN, 2/1/2001

If you make a list of some of the most important traps in testing, you will realize that in many cases the problems are nontechnical.

만일 당신이 테스팅 분야에서 가장 중요한 함정들의 리스트를 작성할 수 있다면, 많은 경우 그러한 문제들이 기술적인 이슈가 아님을 깨닫게 될 것이다.

More often than not, they are consequences of the test process itself, including the overall composition of the test team and whether the company follows well-integrated processes for formal requirements handling and change management.

자주 그 문제들은 테스트 프로세스 그 자체의 결과이며, 테스트 팀의 전체적인 조직과 회사가 잘 통합된 공식적인 요구 사항 처리와 변경 관리를 따르는지 아닌지가 포함된다.

An informal survey of the relative cost of testing software compared with the overall cost of developing software gives a range of estimates, from 10% in smaller organizations to 70% in some larger and mature organizations.

소프트웨어를 테스팅하는 상대적인 비용과 소프트웨어를 개발하는 전반적인 비용을 비교한 비공식적인 조사에 따르면, 작은 규모의 조직에서는 10%, 크고 성숙한 조직에서는 70%까지 보고되고 있다.

The results indicate the huge discrepancy in the level of importance that different organizations give to testing.

이러한 결과는 서로 다른 조직에서 테스팅이 기여하는 중요도의 레벨이 대단히 불일치 함을 나타낸다.

Some of these problems are more common to younger organizations; others are pitfalls that anyone can encounter.

이러한 문제들 중 일부는 신생 조직에서 더욱 일반적이며, 나머지 문제들은 누구라도 직면할 수 있는 함정들에 속한다.

The following case stories and suggested remedies can help you overcome real-life software-testing problems.

아래의 사례와 이를 해결하기 위한 방안들은 실제 소프트웨어 테스팅 문제들을 해결하는데 도움이 될 것이다.


Problem 1: the confused test team

A project manager fears that his team will not complete the test activities by an aggressive deadline.

한 프로젝트 매니저는 공격적인 마감일에 의해서 테스트 활동들이 완료되지 못하게 됨을 걱정한다.

You make a house call, and as you interview the test team, you find that the members have serious doubts about whether the chosen methods are appropriate and, in fact, whether they work at all.

테스트 팀과 인터뷰하려고 전화를 한다. 당신은 테스트 팀의 팀원들이 본인들이 선택한 방법이 적절한지에 대해서 깊은 우려를 가지고 있음을 발견한다. 사실, 그건 본인들이 모든 것을 다해야 하는지 아닌지에 대한 우려이다.

Your first feeling is that the team is upset over things other than work and is not focusing on how to perform its tasks.

처음 당신이 드는 생각은 그 테스트 팀이 업무 보다는 다른 것들에 혼란을 겪고 있다는 느낌으로, 그들이 그 직무들을 어떻게 수행할 것인가에 대한 이슈는 아니다.

The project is on an aggressive delivery schedule, and, therefore, many of the available trained engineering resources are working 24 hours a day on the design team.

프로젝트는 공격적인 출시 스케줄상에 있었고, 따라서, 가용한 훈련된 엔지니어링 리소스들 대부분이 디자인 팀에서 하루 종일 일하고 있다.

In actuality, a lack of technical leadership leaves the test team flabbergasted and unable to complete the test work on time.

실제로, 기술적인 리더십의 부족이 테스트 팀을 혼란스럽게 하였고, 제 시간에 테스트 업무를 마치지 못하게 하고 있다.

Test activity falling behind schedule and low morale often indicate that the test team does not have enough resources or is unqualified to perform the task at hand.

테스트 활동은 스케줄에 뒤쳐지며, 종종 저조한 사기는 테스트 팀이 충분치 못한 리소스를 가지고 있거나 그 직무를 즉시를 수행하는데 필요한 능력이 되지 않는 것을 대변한다.

This deficiency may be due to limited resources, a lack of training of the individual team members, or a leadership problem, or it could suggest that appropriate testing means are unavailable to the team.

이러한 부족함은 제한된 리소스, 개별 팀 멤버의 훈련 부족, 리더십 문제에 기인한 것으로 보일 수도 있다. 결국 이러한 상황은 적절한 테스팅 방법이 그 팀에게는 불가능하다고 판단된다.

This problem, although grave, is usually easy to fix. The difficult part is detecting the problem, because an unqualified team leader may hide or play down his or her shortcomings.

이 문제는 비록 심각하지만, 대개 쉽게 고칠 수 있다. 어려운 부분은 문제를 찾는 것이다. 왜냐하면, 자격이 없는 팀 리더는 자신의 약점을 감추거나 심각하지 않게 얘기하기 때문이다.

A separate, working quality-assurance team should frequently review overall project progress.

독립된 작업을 하는 QA팀은 자주 전체 프로젝트 진행 상황을 리뷰해야 한다.

Also, because it is often as difficult to test a system as it is to build one, do not make the mistake of putting all the best engineers in software development.

또한, 하나의 시스템을 테스트하기 어려운 만큼 하나로 통합하기도 어렵기 때문에, 소프트웨어 개발에 있어 최고의 엔지니어들을 참여시켜 실수를 없게 해야한다.

Although they may invent brilliant software solutions, if an equally brilliant test team is not detecting problems, the solutions won't necessarily fly.

비록 그들이 훌륭한 소프트웨어 솔루션을 개발할지라도, 동일하게 훌륭한 테스트 팀이 문제를 찾아내지 못한다면, 그 솔루션이 반드시 빛을 볼 수 있는 것은 아니다.

This scenario is particularly true when you are building highly complex software within strict time limitations.

이 시나리오는 특히 당신이 제한된 시간 안에 매우 복잡한 소프트웨어를 만드는 경우에 적용된다.

In those instances, it is vital that the test team and engineers are equally qualified to test complex software requirements under similar time constraints.

그런 경우, 테스트 팀과 엔지니어가 동등하게 유사한 시간 제약하에서 소프트웨어 요구사항을 완전하게 테스트할 수 있는 능력을 가지는 것이 중요하다.

After determining whether you have a leadership, resource, or training problem, or a combination of problems, you can take straightforward measures to remedy the situation.

당신이 리더십, 리소스, 훈련의 문제, 문제의 조합이 있는지 확인한 이후에는 그 상황을 해결하기 위해 직관적으로 측정할 수 있다.

Remember that detecting and correcting problems at an early stage is crucial.

초기에 문제를 발견하고 수정하는 것이 매우 중요함을 기억하라.

The longer the problem continues, the more difficult it is to handle.

계속 문제가 지속된다면, 다루기 점점 더 어려워진다.

In general, you need to balance the available design resources with the available testing resources.

일반적으로 가용한 테스팅 리소스와 가용한 디자인 리소스 간의 균형을 맞출 필요가 있다.


Problem 2: the test-maintenance failure

After 16 months of creating test specifications from a requirements specification, the requirements organization publishes a new version of the requirements specification.

요구사항 스펙으로 부터 테스트 명세를 생성하고 난 뒤 16개월이 지난후, 요구사항 관리 조직은 요구 명세의 새 버전을 내놓았다.

At this point, only very limited traceability exists from the written tests to the corresponding requirements specification.

이 시점에서 이미 작성되었던 테스트들은 요구사항 명세와의 일치성에 아주 제한적인 추적성만 제공한다.

Consequently, locating the tests that you need to update according to the new requirements specifications requires another several months.

결과적으로, 새로운 요구사항 명세를 맞추기 위해 테스트를 업데이트하고 조정하는데 몇 달이 소요된다.

Requirements-specification changes lead to abnormally long turnaround times.

요구 명세의 변경은 비정상적으로 긴 작업 시간을 요구한다.

At its worst, testing cannot cope with requirements changes.

최악의 경우, 테스팅은 요구 사항의 변경에도 대응하지 못한다.

Either the traceability of requirements to test cases is inappropriate, or the test method in use does not localize the effects of changes to requirements or other artifacts that the test specifications depend upon.

테스트 케이스가 부적절한지에 대한 요구사항 추적성 뿐만 아니라, 사용하고 있는 테스트 방법도 요구사항의 변경이나, 테스트 스펙에 의존적인 다른 산출물에 대응하지 못한다.

Design the tests with maintainability in mind, just like you do when you design the system.

테스트를 디자인 할 때 유지보수성을 염두에 두고 작업하라.

Successful uses of this approach include grouping test cases by requirements, implementing traceability to and from requirements, and using abstractions in the chosen test description language.

이러한 접근법의 성공적인 적용에는 요구사항으로 테스트 케이스를 그룹핑하고, 요구사항과의 추적성을 기술하고, 선택된 테스트 기술 언어에 추상화를 하는 것이다.

The added benefit is an ability to calculate requirements and test coverage based on this traceability.

부가적인 이득은 요구사항을 따져보는 능력과 그 추적성에 근거해 테스트 커버리지를 확인할 수 있다는 점이다.

Even better, using test-case-generation techniques to convert specifications into test suites makes test specification less dependent on changes to the specification.

더우기, 요구사항을 테스트 수트로 변환하는 테스트 케이스 생성 기법을 사용해서 테스트 명세가 스펙의 변경에도 덜 의존적이 되게 할 수 있다.

If you do use this method, store not only the test cases but also, and more importantly, the criterion that you use to generate the test cases from specification.

당신이 이러한 방법을 사용한다면, 테스트 케이스를 저장할 수 있을 뿐만 아니라, 더 중요한, 명세에서 테스트 케이스를 도출하는데 사용한 통과 기준도 저장할 수 있다.

Automatically generating test cases from a formal requirements specification typically significantly reduces the turnaround time.

자동적으로 공식 요구 명세에서 테스트 케이스를 생성하는 것은 대개 작업 완료 시간을 극적으로 감소시켜 준다.


Problem 3: manual testing

A test team is spending most of its time running test cases but is executing the tests slowly.

테스트 팀은 테스트 케이스들을 수행하는데 대부분의 시간을 보내지만, 테스트는 매우 느리게 수행된다.

It takes as much as a day just to test one new feature of a system, and often the tests fail due to system time-outs.

시스템의 새 기능 한개를 테스트 하는데 하루가 꼬박 걸릴만큼 시간이 든다면, 종종 시스템의 타임 아웃 때문에 테스트는 자체가 실패한다.

Executing full regression tests has been so expensive that the team avoids doing so whenever possible.

완전한 회귀 테스트의 수행은 가능할 때마다 수행하기에는 비싸서 기피된다.

Needless to say, the test execution is manual.

말할 필요도 없이 그 테스트 수행은 수작업이다.

When applying manual testing, the team is frequently unsure about the repeatability of failing test cases.

수동 테스팅을 적용할 때 팀은 종종 실패한 테스트 케이스의 반복성에 의문을 가진다.

The turnaround time for releasing a new revision of software after it has been sufficiently tested is too long and seems to be ever increasing.

새 버전의 소프트웨어가 충분하게 테스트 된 이후에 출시되는 작업 완료 시간은 매우 길며, 점점 증가하는 것처럼 보인다.

The test team is busy doing manual testing instead of producing new test specifications, or updating old ones to match a new or changed requirement.

테스트 팀은 새로운 테스트 명세나 새롭게 추가되거나 변경된 요구사항에 맞추기 위해 예전 것을 업데이트하는 것 대신에 수동 테스트를 하느라고 바쁘다.

Consequently, test documentation is lagging behind.

결과적으로, 테스트 문서는 뒷전이 된다.

Manually testing a complex system with real-time requirements is, at best, unreliable, and at worst, impossible.

실시간 요구 사항을 가진 복잡한 시스템의 수동 테스트는 아무리 잘해도 믿을 수 없고, 최악의 경우 불가능하다.

Fortunately, significant research and world standardization has occurred in the last 10 years that makes possible reliable automated testing of this type of system.

다행스럽게, 의미있는 연구와 세계 표준화가 지난 10년 동안 이루어졌고, 이런 유형의 시스템의 자동화 테스팅을 믿을 수 있게 해주고 있다.

The ISO (International Standards Organization) has arrived at a standard (9646) on formalized and automated testing of communicating and real-time software, called the TTCN (Tree and Tabular Combined Notation).

ISO는 TTCN이라 불리는 실시간 소프트웨어와 신호전달의 공식화되고 자동화된 테스팅의 표준을 수립해오고 있다.

Make sure from the start that you can test your design using automated methods.

당신이 자동화 방법을 사용할 수 있고 테스트 할 수 있는 그곳에서 부터 시작하라.

It must have accessible interfaces and an architecture that permits possible overhead from test-related components.

그것은 접근 가능한 인터페이스와 테스트 관련 컴포넌트로 부터의 오버헤드도 감당할 수 있는 아키텍쳐여야 한다.

Draw benefits from the standard; tell your clients that you have tested your product according to the ISO 9646 standard.

표준의 장점을 살려서, 당신의 고객에게 당신의 제품이 ISO 9646 표준에 의거해 테스트 되었다고 말하라.

For some applications, primarily in the telecommunications domain, the benefits of standardized test suites provide an excellent starting point for further testing.

어떤 어플리케이션의 경우(주로 통화기기 도메인의 경우), 표준화된 테스트 수트의 이득이 더 나은 테스팅을 위한 훌륭한 시작점이 되기도 한다.


Problem 4: the uncertainty principle

Uncertainty introduced by the testing method is virtually unavoidable.

테스팅 방법에서 오는 불확실성은 사실 피할 수 없다.

The following C code example is a classic, although oversimplified, illustration of the problem:

아래의 C 코드 예제는 비록 매우 단순화 되었지만 전통적인 문제를 보여주고 있다.


if ( x != 0 )

y = x;

else

assert( 0 );

x+=2;


The above code behaves differently if compiled in debug mode than it behaves if you compile it in release mode.

위의 코드는 릴리즈 모드로 컴파일될 때와 디버그 모드로 컴파일될 때의 동작이 각기 다르다.

Because it is in C, the "assert" macro expands to nothing, and the x+=2 statement takes the place of the assertion after the "else" statement.

C에서 "assert" 매크로는 아무것도 아닌 것으로 치환되고, x+=2 구문은 "else" 구문 이후의 "어썰션"으로 치환되기 때문이다.

Other, often more difficult, examples include optimizers being too aggressive when test code in a system otherwise affects its size, speed, or behavior, and when system or component simulators produce incorrect results.

또 다른 더 어려운 경우, 시스템의 코드를 테스트할 때 너무나 공격적인 옵티마이저가 포함되어, 크기, 속도, 동작에 영향을 준다. 따라서, 시스템이나 컴포넌트 시뮬레이터가 부적확한 결과를 산출한다.

A problem that occurs during testing is not repeatable when running a non-test session, and a feature that worked just fine during testing fails in real life.

테스팅 동안에 발생하는 한 가지 문제는 테스트 세션이 아닌 경우 반복할 수 없다. 그리고, 테스팅에서는 정상이었던 기능이 실제 운용에서는 문제가 될 수 있다.

Under test, the system behaves differently than in its release version.

테스트 하에서의 시스템 동작은 릴리즈 버전과는 다를 수 있다.

This situation typically occurs when the test environment affects the behavior of the test subject.

대개 이러한 상황은 테스트 환경이 테스트 주체의 동작에 영향을 줄 때 발생한다.

Examples of factors introducing this behavior are conditionally compiled testing and debugging code, as well as special interfaces for testing.

이러한 동작을 보이는 원인들의 예는 조건적으로 컴파일된 테스팅이나 디버깅 코드 뿐만 아니라 테스팅의 위해 특별히 고안된 인터페이스들이다.

Minimize the differences within the system under test and the software in its final form.

테스트 중인 시스템 내부와 그 최종 형태의 소프트웨어간의 차이를 극소화하라.

In many cases, you can eradicate the problem, although black-box testing through the interfaces that the software under test normally provides often minimizes the need for specialized testing or debugging versions of the software.

비록 테스트 중인 소프트웨어의 인터페이스를 통한 블랙 박스 테스팅이 소프트웨어의 디버깅 버전이나 테스팅에 특화된 어떤 필요를 극소화시키더라도 많은 경우, 당신은 문제를 제거할 수 있다.

Another approach to solving this problem is to deliver the system with the debug code still in it.

이 문제를 해결하는 또 다른 방법은 그 소프트웨어 내부에 디버그 코드를 여전히 탑재한 시스템을 출시하는 것이다.


Problem 5: selecting the right tests

You work with a group that tests software for maintaining a communications network.

의사 소통 네트워크를 유지하기 위해 소프트웨어 테스트를 그룹으로 시행하라.

The software you are testing comprises statistics-gathering nodes, an analysis module, and a user interface for connecting to other components.

당신이 테스팅하고 있는 소프트웨어는 통계 수집 노드, 분석 모듈, 다른 컴포넌트와의 연결을 위한 유저 인터페이스로 구성되어 있다.

The system is distributed, and the user interface runs on a PC.

그 시스템은 분산되어 있으며, PC에서 유저 인터페이스가 구동된다.

The test group has started constructing test cases using an automated tool to test the system through the user interface.

테스트 그룹은 유저 인터페이스를 통해 시스템을 테스트 하기 위해 자동화된 툴을 사용해서 테스트 케이스를 구성하기 시작했다.

After about four months of work, you present the first results—a set of test scripts that invoke the UI tool from Windows and open and close a few dialog boxes.

작업한지 약 4개월 지나서, 첫번째 결과 - 윈도우에서 몇가지 다이얼로그를 열고 닫는 UI 툴을 구현하는 몇 개의 테스트 스크립트- 를 얻어냈다.

The tests are built to search the screen for various icons, check the layout of the dialogs, and check for specific strings in the menus.

그 테스트는 다양한 아이콘. 다이얼로그의 레이아웃 체크, 메뉴에서 구체적인 스트링 체크를 위해서 스크린을 찾는 기능으로 구현되었다.

After running all of these tests, hardly one line of code in the analysis module was tested.

이러한 모든 테스트들을 수행한 이후, 거의 분석 모듈 내의 한 라인의 코드만 테스트 되었다.

According to the architects of the system, 90% of the system complexity is in the analysis module.

시스템의 아키텍쳐에 따라서, 시스템 복잡도의 90%가 분석 모듈에 있었기 때문이다.

In this case, it is clear that the test method and test-case selection should be different.

이런 경우, 테스트 방법과 테스트 케이스 선택이 달라야 함이 명백하다.

The testing may not cover some of the important aspects of the application or system, for instance, by selecting only the expected interactions when testing a fault-tolerant application or testing only some subset of the required functions.

테스팅은 시스템이나 어플리케이셔의 중요한 몇몇 측면들만 커버해서는 안된다. 예를 들면, 오류 내성 어플리케이션을 테스팅할 때 몇가지 기대 조합만 선택한다던지, 요구 기능의 몇몇 서브 세트만 테스팅하는 것들이다.

Most of the time, it is more important to concentrate on determining the technical correctness of a system.

대부분의 시간을 시스템의 기술적인 정확성을 결정하는데 집중하는 것이 더 중요하다.

You need to prioritize all requirements and the functions that are likely to contain critical problems.

당신은 심각한 문제점을 안고 있을 수 있는 기능이나 모든 요구명세에 대해서 우선순위를 가져야 한다.

Most of today's applications are too complex to test in every possible way, through all possible paths and states.

현재의 어플리케이션 대부분이 모든 가능한 경우와 경로, 상태를 테스트 하기 매우 복잡하다.

Prioritizing the paths and scenarios that you test first is a valuable, timesaving lesson for a test team, particularly when resources are limited.

당신이 먼저 테스트해야 할 경로나 시나리오의 우선순위를 정하는 것은 가치있고, 테스트 팀에 있어 시간절약하는 교훈이며, 특히 리소스가 제한적일 때 그렇다.


Be prepared

Testing activities can fail in many ways, however, you can prevent most problems with the following practices:

테스팅 활동들은 다양한 방식으로 실패할 수 있다. 하지만, 당신은 아래의 지침을 따른 다면 대부분의 문제는 예방할 수 있다.

  • form a well-qualified test team with the appropriate means for performing the tests at hand,
  • make testing an integral part of software development,
  • employ change-management processes,
  • ensure requirement traceability to and from tests,
  • automate test specification and execution, and
  • design for testability.

  • 훌륭한 능력을 지닌 테스트 팀을 구성하고, 즉시로 테스트를 수행할 수 있는 적절한 방법을 갖추어라
  • 테스팅을 소프트웨어 개발의 통합된 일부분으로 만들어라
  • 변경 관리 프로세스를 도입하라
  • 테스트로 부터 요구사항과의 추적성, 요구사항으로 부터 테스트로의 추적성을 확보하라
  • 자동화된 테스트 명세와 실행을 사용하라
  • 테스트 가능성을 염두에 두고 디자인 하라

Given the complexity of current and anticipated software and communications systems, you should expect software testing to become even more complicated.

현재 또는 앞으로의 소프트웨어와 통신 시스템의 복잡성을 볼 때, 당신은 소프트웨어 테스팅이 더욱 더 복잡해질 것을 예상해야 한다.

Consequently, even more potent tools and methodologies will emerge over time. Manual testing is becoming a less viable alternative, and integration with the overall design processes and tools will prove necessary to keep pace in testing these complex current and future systems.

결과적으로 유력한 툴과 방법론들이 시간이 지나면서 출현할 것이다. 수동 테스팅은 가능한 대안으로의 가능성은 적어질 것이고, 전체적인 디자인 프로세스와 툴의 통합은 이러한 복잡한 상황과 미래의 시스템을 테스팅하는데 필수적이라는 것을 계속 증명할 것이다.

Author info

Lars Mats is a design manager at Telelogic Technologies (Malmö, Sweden). He has worked as a developer, trainer, and consultant on tools and methodologies for major telecommunications companies in Europe, the United States, and Australia. He holds an MS from Uppsala University (Sweden).

반응형

관련글 더보기

댓글 영역