Outline

Jasst'21 Tokyo에서 발표할 기회를 얻었습니다.
그 발표 내용의 요약이 Qita에 실렸다

Background

Test automation responsibility

우리의 테스트 자동화 팀의responsibility는 다음과 같은 세 가지가 있다.

1. Test automation covers regression
2. Update regression script and create new script during project
3. Do regression test in test environment everyday

테스트 자동화는 기존 기능의 테스트를 책임진다.
새로운 기능의 추가, 기존 기능의 수정 등이 발생할 때
• 기존 기능 수정 →regression 테스트 실패, 최신 규격에 따라script 수정
• 새로운 기능 추가 → 새 스크립트 생성, 새로운regression test로 추가
이regression은 매일 테스트 환경에서 실행되는 것으로 오류와 환경 문제 등 각양각색의 문제를 조기 발견한다
이런responsibility를 가지기 위해서는 매일 각양각색의operation이 발생한다.

Test automation operation issue

What is test automation operation?

매일 Regression test를 실행할 때 다음과 같은 큰 Operation이 발생합니다.

1. Check test automation results
2. Investigate test result of test automation failed
3. Handle test automation results 

테스트 자동화는 끝난 게 아니야!
모든 결과가 OK라면 문제없지만 그렇지는 않을 거야.
실패한 결과를 처리해야 한다.
현재 2000개에 가까운 제인킨스 잡스(regression test)가 있기 때문에 모든 잡스의 정보를 다시보드에 수집합니다.
그 중에서pickup이 실패한jobs는 왜 실패한 작업이 발생했는지 분석한다.

실패한 테스트 보고서 예

분석 결과는 크게 네 가지 실패 사유로 나뉜다
NG reason
operation
note
Application bug
Bug Report 등 dev의 fix
Test automation script bug
자동화된script 직접 수정
Environment issue
환경이 회복될 때까지 기다리다.Jenkins schedule 조정
Temporary unstable
테스트 자동화 다시 실행
네 번째 "Temporary unstable"에 부합되는 실패 사례는 다음과 같다.

Investigate issue

실제로 우리는 테스트 자동화 실패의 원인이 어떤 경향인지 조사했다.

상술한 시스템을 세웠다.
1. 제인킨스의 테스트 결과를 DB로 자동 취합
2. 테스트 실패를 분석한 결과(4개의 실패 이유 중 어느 것이 일치합니까?)라벨
결과는 다음과 같다.

위에서 말한 바와 같이 고장으로 인한 자동화 실패는 0.5%에 불과하다(응용엔지니어가 그렇게 우수한가?!)맞다
불안정한 환경으로 인한 실패가 4분의 3을 차지한다고 한다.

Improve operation

아까처럼'Temporary unstable'할 때의 확률이 높고 이 문제의 해결은 재집행일 뿐이며 지루한 업무를 개선해야 한다.

失敗レポートを見る　→　Temporary unstableである　→　テスト再実行　→　成功になってることを確認

Auto Healing System

이러한 문제를 해결할 수 있는 방법은 Auto Healing System입니다.

방금 커다란 데이터가 테스트 실패를 표시했다.AI용 교사 데이터로 사용

이 교사의 데이터를 바탕으로 테스트 실패 보고서를 분석하고 실패 이유를 예측한다

예측 결과에 따라 필요에 따라 테스트 자동화

다음은 상세한 절차입니다.

테스트가 실패할 경우 콘솔과 같은 오류 메시지, 실패할 때 라이브러리를 시스템의 INPUT로 설정합니다.

그런 다음 INPUT에서 실패 이유를 예측합니다.

우선, 캡처 예측에 편리하도록 이미지에서 오류 메시지의 문자를 추출합니다

이러한 문자 정보에 근거하여 실패 이유를 예측하다

만약 문자 정보가 예측하기 어려운 상황에서 이미지에 따라 실패 이유를 예측한다

예상 처리의 총결로 이 결과를 교사의 데이터에 피드백하다

마지막으로 이 예측 결과에 따라 자동화된 테스트 재집행을 자동으로 진행한다는 판단이다.

Results

1.Retry operation is dismissed, then human cost is ZERO
2.Test result keep stable
3.Make good use of test environment resources  

이 구조에 따라 일부 실패한 테스트를 자동으로 다시 실시하고 성공을 유도하기 위해 사람의 원가가 0이 된다.
또한 이 메커니즘이 자주 작동하기 때문에 실패하더라도 성공적으로 작업을 할 수 있기 때문에 안정적인 테스트 결과를 계속 유지할 수 있다.
테스트 재실시도 복구 희망 항목만 진행한다.따라서 테스트 자원도 과도하게 이용되지 않는다.

Q&A (Slido)

질문 다섯 개 받았어요.
재차 대답하다.

Q1. How much time takes to update automation script after a new project?

기본적으로 프로젝트에서 테스트 자동화script 수정을 완성한 것은 자동화팀의responsibility이다.
우리 QA팀, 이른바 프로젝트의 QA 완성은 매뉴얼 테스트, 테스트 자동화 쌍방이 OK를 보낼 때입니다.
수정 시간은 프로젝트의 영향 범위에 달려 있습니다.
수정 규모가 작은 안건이라면 당연히 줄어들 것이다.
예를 들어 2weeks 테스트를 할 때 1-2일 정도의 자동 테스트 수정 작업이 발생할 수 있다

Q2. How many test automation script bug % you get daily basis?

발표된 바와 같이 전체 5% 는 자동화 스크립트를 테스트하는 오류입니다.
테스트 자동화가 안정적인 스크립트(1-2weeks run)라면 대체적인 오류가 발생하지 않습니다.
만약 있다면 특수한 날짜 등 시간 서열과 관련된 문제가 5-6개/week 발생합니다

How do you analyze 'daily operation issue' to fix or not?

기본적으로 모든 FIX는 필수입니다.
FAIL을 배치하면 테스트 자동화에 대한 신뢰가 사라집니다.
응용 프로그램 오류, 환경 문제 등 테스트 자동화 엔지니어가 해결할 수 없는 문제를 제외하고는 가능한 한 빨리 해결할 것입니다.

Is your approach based on the facebook's approach or similar ones?

미안합니다.나는 페이스북의 앱 로치를 모른다.
알려주세요!!

Do you have to worry about missing a bug due to a false negative?

가짜 네가티브가 걱정이야.
가끔 테스트 자동화의 행위를 눈으로 보고 확인한다.
그렇게 말하지만, 잡스가 많아서 전부는 아니에요.
프로젝트에서 마음에 드는 스크립트를 픽업으로 확인 중입니다