MasaoApril's Library.

Software Testingなネタを書いてみた。

システムテスト自動化カンファレンス2015(5)「楽天の品質改善を加速する継続的システムテストパターン」

TestAutomation STAC2015 Conference

　2015/12/13(日)にテスト自動化研究会(STAR)主催のシステムテスト自動化カンファレンス2015に参加しました。
　本blogでは、聴講したセッションから数回に分け、メモとしてまとめたものを紹介します。

セッション

　講演内容は、下記セッションです。
(※<資料>にリンクを貼りましたので、参照下さい。)

1.テスト自動化のスキルを考えよう！ ～テスト自動化エンジニアに求められるスキル、期待される役割～　早川 隆治(テスト自動化研究会)/テスト自動化スキル標準 AutomationTest.SSF 考えてます。　コヤマン(テスト自動化研究会), →<資料1>/<資料2>
2.自動家は見た～自動化の現場の真実～　/".reviewrc"→"おいしが"　→<資料1>/<資料2>
3.広告システム刷新よもやま話 - テストが当たり前となるまでにやったこと -　/森下 大介(ヤフー株式会社MSC開発本部マーケッターPF開発部)　→<資料>
4.楽天の品質改善を加速する継続的システムテストパターン　/荻野 恒太朗(楽天), 菊川 真理子(楽天)　→<資料>
5.キーワード駆動によるシステムテストの自動化について　/小井土 亨(SQiP 運営委員会メンバー、株式会社OSK)　→<資料>
6.Testing Tools for Mobile App　/松尾　和昭(クックパッド)　→<資料>
7.パネルディスカッションLIVE！　テスト自動化”エンジニア” の今とこれから/登壇者：森下 大介(ヤフー株式会社), 荻野 恒太朗(楽天), 小井土 亨(SQiP 運営委員会メンバー, 株式会社OSK),松尾 和昭(クックパッド), AAA(review.rc)メンバ, モデレータ：浅黄 友隆(ヒューマンクレスト), 松木 晋祐(ベリサーブ)

　今回は、「4.楽天の品質改善を加速する継続的システムテストパターン」について紹介します。

4.楽天の品質改善を加速する継続的システムテストパターン//荻野 恒太朗(楽天), 菊川 真理子(楽天)

(1)開発の永続性と継続的テスト

(1-1)Facebook社の論文
  • 開発
    • どんどんリリース
  • テスト
    • テストを成長させる
(1-2)永続的開発
  • 課題
    • ○○機能の仕様を変更→バグがあった。
    • ○○機能の仕様を変更をやめた→どこをどう直したか追跡できない。
  • 困ったこと
    • 用空が適切に優先順位づけ：ない
    • 要求と開発用件のトレーサビリティ：ない
  • 解決
    バージョン管理など
(1-3)CI
  • 課題
    • 継続的な品質のフィードバックが困難。
  • 困ったこと
    • 継続的にソースコードがコミットされない
    • テスト実行時間：長い
    • 品質可視化コスト：高い
  • 解決
    • 毎日自動テスト：Jenkinsで毎日実行することで、いつ失敗したか把握できる。
    • CIの導入：ツールを用いたレポートの自動化
      • メトリクスを自動収集し、現場で品質改善したことが目で見える→モチベーションが上がる。
      • デプロイの頻度で価値を見える化。→機能追加の頻度(2weekで1つから1日で1つ)
    • SQiP2014の経験発表も参考のこと
(1-4)Infrastructure as Code
  • 課題
    • 頻繁なデプロイ・リリースができない。
  • 困ったこと
    • サーバー構築が大変
      • 手動でインフラ構築
      • 秘伝の手順書
      • インフラ構築手順：テスト未実施
  • 解決
    • vagrantでサーバー環境の構築を自動化
    • インフラの設定：SCMで管理
    • インフラ構築手順：テスト実施
(1-5)CI in Test
  • 課題
    頻繁なテスト実行ができない。
  • 困ったこと
    • 問題切り分け：時間がかかる
    • テストの継続的な変更と信頼性が問題
    • テスト設計の変更に時間がかかる
  • 解決
    • 自動テスト：自動テストコードは、gitでバージョン管理。
    • 手動テスト：テストケース管理ツール
      • テスト開発環境を提供
      • テストしてからコミットする
      • テスト設計のリファクタリング容易性(?)の改善

(2)生産性と自動テスト

(2-1)自動テストによる生産性改善

　中身が分からない貯金箱より、目に見える貯金箱。

(2-2)自動テストの実装
  • 課題 テスト自動化のカバレッジが低い。
  • 困ったこと
    • テスト確認項目がシステムから取得不可
    • 外部サービスとの結合テストが困難
    • テストデータの作成が困難
  • 解決 テスト要件をプロダクトに入れる。

(3)信頼性とアジャイルテスター

(3-1)アジャイル4象限
  • 課題
    バグの見落とし
  • 困ったこと
    • 無駄なテストや重複するテストの実行
    • 非機能テストの見落とし
  • 解決
    「誰の？」「どんな？」テストの価値を整理
    • ユーザストーリーテスト
    • オペラビリティテスト
(3-2)スキルセット
  • 課題
    テストができるひと、やりたい人が少ない。
  • 困ったこと
    • テスト自動化エンジニア：新しい
    • トレーニング不足
  • 解決

所感

　現場で困っていることを挙げてあるべき姿を明確にしてから、「解決したい課題(品質)」→「解決方法(コンセプト)」→「実装」と目的から手段にブレークダウンする流れから、QC活動の良好事例に似ていると思いました。私の現場でも、課長や一部の同僚や私が「あるべき姿って何だろう？」と問いかけ、「何がボトルネックなの？」と課題を洗い出し、「じゃあ、どうする？」と課題に対する取り組みを進めています。私の現場では他社事例に触れることが少ないので、本発表の事例での問題解決の良いところを何らかの機会で紹介してみようと思います。