테스트 실행 및 종료기준에 대해 기재해봅니다.
5. Test Excute - 테스트 실행
테스트 실행에서는 구현단계에서 만든 테스트케이스 순서에 따라 프로덕트/서비스를 조작하여 기대한 대로 동작하는지를 확인합니다. 기대하지 않은 동작결과라면, 캡처등의 증거자료를 만들고 하나의 issue로써 관리해야합니다. 또한 해당 issue의 원인을 분석하고, 원인을 특정하여 개발팀에 연계합니다.
수정이 끝났다면 발견했던 issue가 제대로 수정되었는지, 같은 테스트케이스를 다시 한 번 실행하여 확인합니다. 또한 해당 수정범위로부터 영향받는 다른 기능들을 도출해내어 같이 확인해야합니다.
테스트 실행단계에서는 좀 더 구체적으로 아래와 같이 task를 나누어볼 수 있습니다.
1. 이해관계자들에게 테스트 개시를 안내
이해관계자들에게 테스트를 시작했다는 안내를 실시합니다. 보통 메일로 연락을 돌리는데, 이때 포함되면 좋은 내용들은 아래와 같습니다.
- 테스트 일정
- Release 예상 일정
- 테스트나 issue의 상황을 다른 이해관계자도 쉽게 알 수 있는 dashboard(관리 한다면.)
- Test대상 범위, 기능, Epic
2. Sanity Test의 실시
Sanity check or Sanity test
A sanity check or sanity test is a basic test to quickly evaluate whether a claim or the result of a calculation can possibly be true. It is a simple check to see if the produced material is rational (that the material's creator was thinking rationally, applying sanity). The point of a sanity test is to rule out certain classes of obviously false results, not to catch every possible error. A rule-of-thumb or back-of-the-envelope calculation may be checked to perform the test. The advantage of performing an initial sanity test is that of speedily evaluating basic function.
Sanity Test의 목적은, 테스트 대상 아이템, feature, product가 테스트가 가능한 상황인지 가볍게 훑어보는 것입니다. 가령, 특정 서비스에 로그인하여 테스트를 진행해야하는데, 로그인도 할 수 없는 상황이라면, 테스트를 할 수 없을 것 입니다.
Sanity test는 테스트 대상을 가볍게 조작해보는 것입니다.
3. 테스트케이스의 실행
테스트 구현단계에서 작성한 테스트 케이스를, 정해진 우선순위/순서대로 실행해나갑니다. 테스트케이스 별로 담당인원이 있을 수 있으며, 정해진 일정내에 소화하기 위해, 하루 목표치가 정해질 수도 있습니다.
테스트케이스를 실행하면서 발생하는 issue (Bug, Improvement, Additional task) 등은 따로 Bug Tracking System (BTS)을 이용하여 관리/추적할 수 있도록 합니다.
많은 회사들이 표 만들기도 쉽고, Gant chart처럼 사용하기도 편해서 엑셀로 관리합니다만..., BTS에는 많은 유명한 툴들이 있습니다.
- JIRA
- RedMine
- Asana
등등... 보통 Issue를 찾아내면, QA담당자는 직접 해결하는 issue도 있겠으나 대부분은 개발자나 기획자들을 비롯한 이해관계자들에게 해당 issue를 assign합니다. 때문에 BTS Tool도 좋지만, Asana, Trello같은 Task management tool도 issue관리를 위해 사용되기도 합니다.
issue를 관리할 때는, 어떠한 테스트 케이스에서 발생한 issue인지, 테스트케이스와 issue간의 tracability를 유지하는 것도 중요합니다.
Issue를 관계자들에게 연계할 때 포함되어야할 정보들
테스트 대상이 기대하지 않은 동작결과가 나올 때, 많은 분들께서
이거 안돌아가는데요, 이거 문제있는데요
라고 간단하게 말씀하시는 분들도 있습니다.
관계자들이 알기쉽고, 재현해볼 수 있을 정도의 세부정보를 같이 연계하는 것이 좋습니다.
보통은 아래와 같은 정보들이 있으면 도움이 될 것 입니다.
- 실행환경 (OS,단말기, 브라우저, 테스트 대상의 버전 등)
- 실행횟수 (반복실행하면 발생하는지, 단일 실행만해도 발생하는지, 똑같은 것을 몇 번 시도하였는지 등)
- issue확인 시나리오 (기본적으로 테스트케이스대로 하면 재현해볼 수 있겠으나, 테스트케이스에서 약간 벗어난 동작을 진행했을 때 발생하는 issue들도 많이 있습니다.)
- 기대결과값
- 해당 issue를 바로 알 수 있는 log나 Screenshot 등의 자료
- 기타 의견
- 해당 issue와 관련있는 issue (의존성이 있는지, 다른 issue로 인하여 발생된 issue인지 등을 파악하기 위해)
4. Ad-hoc Test(애드혹 테스트)
Ad-hoc Test
Ad hoc testing is a commonly used term for software testing performed without planning and documentation, but can be applied to early scientific experimental studies.The tests are intended to be run only once, unless a defect is discovered. Ad hoc testing is the least formal test method. As such, it has been criticized because it is not structured and hence defects found using this method may be harder to reproduce (since there are no written test cases). However, the strength of ad hoc testing is that important defects can be found quickly.
It is performed by improvisation: the tester seeks to find bugs by any means that seem appropriate. Ad hoc testing can be seen as a light version of error guessing, which itself is a light version of exploratory testing.
테스트 일정의 중후반정도에서는 꼭 Ad-hoc 테스트를 실행해보길 권장합니다. 정해진 계획이나 테스트케이스 없이, 테스트 수행자(테스터)의 감각으로만 진행하는 방법입니다.
"테스트 케이스만 실행하면 다 된거 아니야?"
라고도 생각하실 수도 있겠으나, 테스트를 진행하면서
"아 이것은 이렇게 조작해보면 어떤 동작을 할까?"
등과 같은, 테스터에게 의문이나 호기심이 생길 수도 있습니다. 혹은 Spec과 실제 구현간이 모순된 점을 알게 될 수도 있습니다. 이러한 점들을 정리하여 테스터의 호기심대로 실행해보는 것입니다.
5. Regression Test(회귀 테스트)
Regression Test
Regression testing (rarely non-regression testing) is re-running functional and non-functional tests to ensure that previously developed and tested software still performs after a change. If not, that would be called a regression. Changes that may require regression testing include bug fixes, software enhancements, configuration changes, and even substitution of electronic components. As regression test suites tend to grow with each found defect, test automation is frequently involved. Sometimes a change impact analysis is performed to determine an appropriate subset of tests (non-regression analysis).
테스트 일정의 끝부분에 이르러, 테스트케이스를 거의 확인하였다면, regression test를 진행해야합니다. regression test란, 계획된 테스트케이스들을 진행하면서 마주친 수많은 bug나 spec수정 등으로 인해서, 영향이 없던 다른 기능들도 제대로 동작하는지, 수정한 bug가 다시 재현은 안되는지 확인하는 것 입니다.
보통은 regression testcase를 따로 작성해놓고, 매 테스트마다 실시하는 것이 일반적이며, 대부분 정상계열 패턴으로만 이루어져있을 것입니다.
regression test는 매 테스트마다 기능추가가 이루어지는 경우, 해당 기능을 위한 regression testcase가 계속되어 추가되어야만 합니다. 성장하고 있는 product / service라면 주기적으로 관리를 해주어야만 합니다.
또한 매번 같은 테스트케이스를 반복하기에, human error가 발생하기 쉽습니다. 집중도의 저하라던지, 저번에 잘되었으니 이번에도 잘 되겠지~ 라고 방심한다던지 등, 이유는 많습니다. 때문에 Regression test를 자동화하여 진행하는 경우도 많이 있습니다.
6. 이해관계자들에게 테스트 상황을 공유
이해관계자들에게 테스트의 상황을 공유합니다. 보통은 테스트 기간내내 매일 테스트 업무를 종료하면서, 상황을 공유합니다.
공유하는 내용은 product / service 혹은 조직문화마다 다르겠지만, 보통은 아래와 같은 내용을 기재하여 공유하면 좋습니다.
- 현재 테스트 진척상황
- issue 발생 상황
- 기능별 issue 분포상황
- 총 issue들 중 아직 해결되지 않은, 해결이 필요한 issue
- 기타 테스트 담당자가 판단하여 보고가 필요한 내용
테스트 상황은 테스트를 진행하면서 실시간으로 관계자들에게 보고해야합니다만, 매일 테스트 업무를 종료하면서 공유하는 내용은, 많은 정보들을 요약하여 공유하면 좋습니다. 특히 QA/테스트 담당자는 기획자, 개발자 이외의 이해관계자들과는 커뮤니케이션하기가 어려울 수도 있는데, 이 것을 이용하여 Business logic에 대한 우려사항 등이 있다면, 공유해야합니다.
6. Test exit criteria - 테스트 종료판정
1. 이해관계자들에게 테스트 종료를 공유
테스트 계획/분석단계에서 정의한 테스트 종료기준을 만족한다면, 이해관계자들에게 테스트 종료를 공유합니다. 많은 종료기준이 있겠지만 보통 아래 조건을 만족한다면, 테스트를 종료한다고 판단해도 될 것 입니다.
- 정해진 Testcase 진척상황 100%
- 특정 우선순위 이상의 issue 전 건 해결완료
- 특정 issue가 있어도, 이해관계자들과의 합의를 거쳐 추후 대응해도 되는 상황
- 이 외 급하게 Release가 필요하여 이해관계자들로부터 합의를 얻은 상황
또한 테스트 종료시에는 테스트 결과를 같이 공유합니다. 테스트 결과에는 전체적인 issue의 갯수와 기능 별 issue 분포도, issue의 원인 분석 및 경향 등을 포함하여 공유하면 좋을 것 입니다.
2. 실제 환경에서의 테스트 의뢰 / 실행 공유
혹여나 테스트환경 뿐만 아니라 실제 환경에서도 테스트가 필요하다면, 이 테스트 종료를 공유하고 다시 테스트 실행단계로 돌아와 정해진 시나리오대로 확인을 할 필요가 있습니다. 혹은 실제 환경 상에서의 테스트 담당자가 다르다면, 테스트를 대신 진행하도록 의뢰해야할 필요가 있습니다.
