주식회사 크로스 커뮤니케이션 카메이입니다 ^ ^
당사에서는 품질보증부 시작 중입니다. Selenium을 포함한 테스트 자동화도 추진하고 있습니다. 그 일을 중심으로 다양한 논의가 가능하면 다행입니다.
설계서나 사양서를 Markdown으로 이행하고 싶기 때문에 Qiita에 발표 자료를 각 시도를 해 보았습니다.

자기소개

카메이 료스케
3아의 아버지로 프리랜서를 거쳐 2018년 3월 크로스 커뮤니케이션 입사해, 품질 보증부를 시작 중

장녀 13세
축구를 하기 위해 기숙사가 있는 축구 아카데미에…

차녀 11세
파티시에 하고 싶다. 손쉽게 최근에는 레진 세공에 빠져 있다.

두 사람에게 공통점은 별로 없지만, 팝테픽을 좋아…

장남 7세
여러 사정 있어 멀리 살고 있다. 굉장히 귀엽다. 가면라이더 좋아(건담 좋아하게 되면 좋지만…)

개인적인 생각
월요일에 즐거워지는 직장으로하고 싶다.

1. 품질 보증부 시작 배경

htps //w w. c로 s-c. 이. jp / 아보 t / 코 mpa ny /
고맙게도 프라임 안건이 많습니다.

상시 프로젝트가 다수 돌고 있다

2. 크로스 커뮤니케이션에 있어서의 품질 보증부란

3. 프로젝트의 표준화·구조 만들기

개발 회사이므로 품질을 기술적인 접근 방식으로 해결하고 싶습니다.
(not 인해 전술·노동 집약)

테스트 자체 "일"화

Infrastructure as Code

CI/CD DevOps

Swagger

4. 크로스 커뮤니케이션에 있어서의 테스트 자체 「일」화 방침(본제)

테스트 자동화로 실패한 사람이 있습니까?

안티 패턴… 대체로 실패담을 들으면 이런 느낌

유지 보수 나선형

시험 열사병 및 커버리지 지상주의

소프트 크림 타입

테스트 자체 "일"화는 쌓여 있기 때문에 무리하지 않아도됩니다.

안티 패턴을 방지하기 위해

1. 유지 보수 나선형

메인터넌스성이 저하되어, 사양이 바뀔 때마다 과도한 소스 수정 발생(메인터넌스·스파이럴)이 발생하지 않도록

Geb, Spock 등을 활용하여 누가 써도 비슷한 코드로 한다

id 속성을 흔들어 xpath로 기재해 통일감을 갖게 한다

어려운 어설 션은 가능한 한 많이 사용하지 않습니다

오류 메시지 등의 표시 확인은 문장 레벨이 아닌 필드의 표시/숨기기로 평가

2. 시험 열사병·커버리지 지상주의

테스트하는 것이 즐거워지고, 테스트를 작성하는 것이 목적이거나 (테스트 열사병)를 예방하기 위해

코드: 테스트 코드는 8:2 또는 7:3

커버리지는 그다지 중요하지 않고 기준 정도로 한다

3. 피라밋형(not 소프트크림형)

원칙적으로 단위 테스트를 작성하고 API 테스트도 자동화합니다

게다가, Selenium의 탁월한 테스트에만 집중한다

과제 공수 vs 테스트 자동화

우리는 원가 관리에 엄격하기 때문에 시간이 많이 걸리는 것은 피하기 쉽습니다.

원래...

UT, IT의 자동화하고 비용 상승은 제조 초기에만 테스트로 회수할 수 있을 것이다.
그럼에도 불구하고 UI 테스트 (Selenium)까지 원가가있는 것은 조금 까다 롭습니다.
→ UT, IT는 프로젝트가 있고 Selenium은 품질 보증부가 있다

과제 앱 테스트

Test lab + Xcode나 Kotlin의 UI 테스트 활용일까(현재 테스트 전략 입안중)

다음에 성공사례를 소개하고 싶네요~ ^^