REGRESSION TESTING by Wayne Mallinson

생소하지만 co.za를 사용하는 남아프리카 공화국 내의 테스팅 단체가 있다. 이곳의 아티클중 회귀 테스팅과 관련된 내용을 번역해 올린다. 회귀 테스팅이 간단한 것 같지만 실은 아주 많은 전략적 요소가 숨어 있다고 생각한다. 원문은 여기서 보실 수 있다.

REGRESSION TESTING byWayne Mallinson

회귀 테스팅은 소프트웨어 개발과 유지보수 과정에서 발생하는 수정과 변경에 의해 만들어진 결점(failures)을 발견하기 위해서 이전에 올바르게 수행되었던 프로그램의 테스트 케이스를 재실행하는 것이다. (Regression testing is the re-running of Test cases that a program has previously executed correctly, in order to detect failures spawned by changes or corrections made during software development and maintenance.)

이러한 결점은 불완전하며 부정확한 변경에 의해 유발되거나, 종종 명백히 연관이 없는 어플리케이션 영역에서 발생하는 side effect(예상치 못한)의 증거이다. 6개중 하나 (또는 17%)의 수정 시도 자체에 결함이 있는 것은 IT 산업에서 일반적이다. (These failures arise from incomplete or incorrect changes and are often witnessed as (unexpected) side effects in apparently unrelated application areas. It is common in the IT industry, that one in six (or seventeen percent*) of correction attempts are themselves defective.)

개발자 대부분이 그 시스템에 대한 경험이 적거나 없고, 다수의 엉성한 문서를 가진 통합시스템을 유지보수하는 경우 높은 비율의 결함이 과도하게 드러난다. 회귀 테스팅은 모호한 side effect나 그 환경 안에서 고려되지 못한 상호관계를 찾아내는데 효과적으로 사용될 수 있으며, 그렇게 해서 risk를 감소시킬 수 있다. (This high rate of introduced defects is exaggerated when developers maintain a large number of poorly documented, integrated systems where they of ten have little or no experience of these systems. Regression testing may then be used to great effect at detecting subtle side effects and unconsidered inter-relationships within these environments, thus reducing risk.)

테스트 절차 안에서의 회귀 테스팅의 표준적인 액션이 수행되고, 올바른지 확인하기 위해 기대 반응을 체크한다. 예상된 반응중 어떤 것도 시스템이 재현해내지 못했다는 것은 시스템이 회귀되었을 수도 있거나(하나 또는 그 이상의 결점이 더 존재할 수도 있다), 회귀 테스트 그 자체의 시효가 지났거나 부정확함을 암시한다. (In regression testing standard actions in a test procedure are carried out and the expected responses are checked for correctness. Failure of the system to reproduce any of the expected responses imply that the system may have regressed (there may have been one or more introduced defects), or that the regression test itself may be out of date or incorrect.)

만일 모든 반응들이 기대 대로라면, 여전히 결함이 존재할 수도 있다. 이 경우 결함은 발견되지 않은 것이다. 개개의 결함이 실제 운용에서 보고된다면, 회귀 테스팅 동안에 발견되지 않은 결함은 주의 깊게 분석되고, 회귀 테스트 수트는 이후에 유사한 결점이나 이러한 상황을 잡아내기 위해 업데이트되어야 한다. (If all responses are as expected, there may still have been introduced defects. In this case they escaped detection. Each defect that is reported from live or field use, having escaped detection during regression testing must be carefully analysed and the regression test suite(s) updated to catch these or similar defects in the future.)

대개 회귀 테스트 케이스의 주요한 소스는 유닛, 통합 또는 시스템 테스트 케이스를 재사용하는 것이다. 하나의 거대한 회귀 테스트보다 논리적으로 응집된 테스트 수트로 테스트 케이스를 묶는 것이 좋다. 이것은 시간상의 압박, 몇 개의 테스트만 수행해도 된다는 확신이 들 때 수행할 수 있는 서로 다른 테스트 서브셋을 만들수 있다. (The main source of regression test cases is usually from re-use of unit, integration or system test cases. It is good practice to batch test cases into logically cohesive test suites, rather than have a single huge regression test. This allows different sub-sets of tests to be executed when there is time-pressure, or where there is confidence that only certain tests need to be run.)

맨 처음 회귀 테스트 수트를 작성할 때, 테스트의 선택은 80/20의 룰을 따르는 것이 좋다. 시스템 기능 중 20퍼센트는 수행하는데 80퍼센트의 시간이 소모될 수 있다. 따라서, 이러한 자주 사용되는 스크린, 트랜잭션, 메뉴 또는 입력 필드들은 회귀 테스트의 첫째 후보군이 된다. 이것은 이러한 자주 사용되는 기능의 실패를 가정했을 때 쉽게 이해될 수 있다. 유저 대다수에 부정적인 영향을 끼치고, 회사 콜센터가 문의로 빗발치는 상황인 것이다. 하지만, 일반적이지 않은 기능중 하나에 문제가 생기는 경우라면, 소수의 유저만 사용할 것이고 따라서, 소수만 (문제를) 발견할 것이다. (When first creating a regression testing suite, the choice of tests to use can be guided by the 80/20 principle. Twenty percent of system functions are likely to be used eighty percent of the time. Thus these highly used screens, transactions, menus, or fields ought to be the first candidates for regression tests. This is easy to understand if we consider one of these popular functions experiencing failure. The company call centre will be inundated with calls and the majority of users will be negatively affected. If, however, one of the less common functions has a problem, fewer users would have used it and thus discovered a lack.)

더 많은 테스트를 회귀 (테스트) 수트에 추가하는 경우 위험을 고려하여 판단할 수 있다. 자주는 아니지만 발생하기는 하는 몇몇 실패 (사례)들은 비즈니스에 막대한 영향을 줄수도 있다. 이러한 고위험군의 비즈니스 영역을 담당하는 기능, 모듈, 스크린 또는 트랜잭션은 시스템이나 환경의 변경이 있을 때마다 각각 테스트되어야 한다. (Further tests to add to regression suites may be guided by risk considerations. Certain failures may not occur often, but should they occur, would result in a highly negative business impact. These higher risk business areas, modules, screens, or transactions should therefore be tested each and every time there are changes in the system and/or its environment.)

유지보수하기 어렵고, 높은 과거 실패 이력을 가진 어플리케이션 영역에 대해 또 다른 회귀 테스트를 추가해야 한다. (Additional regression tests can be added to application areas that are known to be difficult to maintain, and have a history of high failure rates.)

회귀 테스팅은 유닛 레벨에서부터 추가되어야 하며, 유닛 테스트는 유닛에 영향을 미치는 변경이 발생한 이후에 재실행되고 개정되기도 한다. 회귀 테스팅은 이후 통합, 시스템, 유저인수와 소프트웨어 개발 라이프 싸이클 단계를 통해 계속되어야 한다. (Regression testing can begin at the unit level, where unit tests may be adapted and rerun after changes to the unit have been effected. Regression testing should then continue through integration, system, user acceptance and operational software development life cycle phases.)

최소한, 회귀 테스트는 회사내의 실 운용 환경이나 더 넓은 범위의 사용자들에게 배포되기 전에 수행되어야 한다. 이러한 테스트는 심각한 비용, 일정, 생산성 또는 회사 이미지에 영향을 미치는 주요한 오류를 찾는데 도움이 될 것이다. (As a minimum, regression tests should be run prior to build releases into the broader community and/or company live Environment. These tests will help detect major anomalies that could have serious cost, schedule, productivity and/or company image Implications.)

웹 시스템 그리고 다른 멀티 유저 시스템들은 주기적인 기간을 가지고 회귀 테스트 수행이 지속되어야 한다. 예를 들어, 그런 하나의 테스트가 웹 사이트 내의 모든 하이퍼링크가 올바르고 이동할 수 있다고 체크해야 한다. 심지어 다른 사이트로의 연결은 시효가 지났거나 보안 결함으로 해커에 의해 손상되었을 수도 있다. (Web systems, and other multi-user systems might have ongoing regression tests run at regular intervals. For example, one such test may check that all hyperlinks on a web site remain correct and reachable. Links to other sites may become outdated, or may even be corrupted by hackers in a security breach.)

주기적인 회귀 테스팅은 다음과 같은 생산성과 연관된 질문에 답을 할 수 있다. "우리 제품의 주요 트랜잭션의 성능이 허용 시간 기준 내에 있는가?" "또는" 중요 트랜잭션의 응답 시간을 저하시키는 어떤 요인이 있는가?" (Regression testing at regular intervals can also answer production questions such as: "Is the performance of our major transactions within acceptable time limits?", "or", is some factor slowing our response times on an important transaction?")

성능, 편이성, 보안성과 같은 비 기능적인 어플리케이션의 속성에 대한 회귀 테스트 또한 매우 중요하다. 코드나 디자인 상의 아주 작은 변경사항이라도 시스템의 성능 같은 것에 막대한 영향을 줄 수 있다. 어플리케이션 소프트웨어 내부에서 발생하지 않은 사소한 변경에 주목하라. 예를 들어, PC 바이오스 업데이트, 운영 시스템 소프트웨어, 네트워크 카드 또는 써드파티 데이터베이스의 버전 업데이트 같은 변경은 끔찍한 결과를 가지는 것으로 알려져 있다. (Regression tests of non-functional application attributes such as performance, usability or security, is also very important. A very small change to the code or design may have a significant impact on system performance for example. Also please take note that debilitating changes may not even be within the application software. Changes known to have had dire consequences include an update of PC BIOS, operating system software, network cards, or updates of third party database versions for example.)

정의상 회귀 테스트는 반복적이므로 많은 수의 테스트가 테스트 자동화로 구성될 수 있다. 테스트 자동화는 노동 집약적인 수동 테스트 프로세스에 비해 몇번만 반복 하면 테스팅 시간을 감소시킬 수 있다. (Regression testing is by definition repetitive, and thus many of the tests are likely to be suited to test automation. Test automation can deliver reduced testing costs after a few test iterations when compared to labour-intensive manual testing processes.)

회귀 테스팅을 사용하는 많은 회사에서 정규적인 회귀 테스팅을 시작하기 전에, 아주 축약된 체크 테스트 (종종 'smoke' 또는 'sanity' 테스트로 불림)를 수행한다. 이것은 축약된 테스트가 대개는 명백한 에러들(예를 들면, 변경된 데이터베이스 포맷에 대해 컴파일되지 않았기 때문에 전체 양식이 출력되지 않는 등의)를 노출시켜서 시간을 절약한다. 시간이 소모되는 회귀 테스팅 시나리오를 구동하기 이전에 이러한 유형의 문제를 제거하는 것은 좀더 일찍 개발자를 돕고, 그러한 문제를 찾기 전에 회귀 테스트의 주요한 부분들이 끝나버리는 일을 막아준다. (Many companies who use regression testing conduct a very abbreviated check test (sometimes called a 'smoke' or 'sanity' test) on newly delivered code, prior to starting their formal regression tests. This often saves time as the abbreviated test commonly exposes obvious errors (for example: a whole form may not be displayed because it failed to compile against a changed database format). Removing this type of problem prior to running the time-consuming regression testing scenarios can result in getting earlier developer help, and prevent testers completing a significant portion of the regression testing before finding such problems.)

동일 소프트웨어 개발 라이프 싸이클 단계 내의 다른 테스팅 유형처럼, 테스트 환경의 구성과 제어가 회귀 테스트에 매우 중요하다는 점을 주의해야 한다. (It should be noted that the control and make-up of the test environment is as critical for regression testing as it is for other testing types within the same software development life cycle phase. Refer to the article on page eight that discusses creating a testing environment.)

회귀 테스트 수트는 그것이 수동이던, 자동이던 회사의 중요한 자산이다. 그러므로, 그것들을 백업하고, 형상을 관리하고, 최대한의 효과를 얻을 수 있도록 유지하는 것이 필요하다. 그러므로, 회귀 테스트 수트에 대한 책임과 구체적인 오너십이 명백하게 정의되어야 한다. (Regression test suites, be they manual or automated, are an important company asset. They therefore need to be backed up, configuration-managed, and kept current to deliver maximum benefit to their owners. Specific ownership of and responsibility for the regression test suites therefore needs to be clearly defined.)

Wayne Mallinson