株式会社クロス・コミュニケーション 亀井です^ ^
弊社では品質保証部立ち上げ中です。Seleniumを含むテスト自動化も推進しています。その事を中心に様々な議論ができれば幸いです。
設計書や仕様書をMarkdownに移行したいのでQiitaに発表資料を各試みをしてみました。
自己紹介
亀井亮介
3児の父親でフリーランスを経て2018年3月クロス・コミュニケーション入社し、品質保証部を立ち上げ中
長女13歳
サッカーやるために寮付きのフットボールアカデミーへ…年頃なのでラインでの会話がちょうどいい距離感
次女11歳
パティシエやりたいらしい。器用で最近はレジン細工にハマっている。
二人に共通点はあまりないが、ポプテピピックが好き…教育上どうかと思いつつ一緒にみて笑ってしまう…
長男7歳
諸事情あり、離れて暮らしている。すげー可愛い。仮面ライダー好き（ガンダム好きになればいいのに…）
個人的な思い
月曜日に楽しくなる職場にしたい
1. 品質保証部立ち上げの背景
https://www.cross-c.co.jp/about/company/
ありがたいことにプライムの案件が多いです。
常時プロジェクトが多数回っている
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テスト活用かな（現在テスト戦略立案中）
次回は成功事例を紹介したいなぁ〜と^ ^