読者です 読者をやめる 読者になる 読者になる

MasaoApril's Library.

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

システムテスト自動化カンファレンス2015(4)「広告システム刷新よもやま話 -テストが当たり前となるまでにやったこと-」

TestAutomation STAC2015 Conference Management development environment

 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)メンバ, モデレータ:浅黄 友隆(ヒューマンクレスト), 松木 晋祐(ベリサーブ)

 今回は、「3.広告システム刷新よもやま話 -テストが当たり前となるまでにやったこと-」について紹介します。

3.広告システム刷新よもやま話 -テストが当たり前となるまでにやったこと-/森下 大介(ヤフー株式会社MSC開発本部マーケッターPF開発部)

(1)B to B でエンプラシステム

 データ登録の比重が大きい。

(2)困ったこと「妙につらい」

  • 小改修だが...
    • 大規模かつ複雑化
  • 結合が...
    • 道具とやり方が合わない
  • なんとなく動いていて...
    • 積み重なる技術負債

(3)組織変更のタイミング

 (組織変更後の)部門長「いちから全部変えろ!」というきっかけがあった。

(4)目指したもの

  1. 3倍早い開発スピード
  2. 変わるべきは「自分たち」
  3. システム刷新は「結果」

(5)やったこと

(5-1)体制づくり
  1. リード役の配置
    部付きで刷新活動に集中できる環境へ
  2. 仲間づくり
    同じ問題意識の人に声かけ。
  3. 部門長による宣言
    刷新することをステークホルダや部内メンバに宣言した。
(5-2)プログラミング言語を変える
  • 変える前 型が使えなくて、痛い目(金銭的損失)にあった。
  • 要件 コンパイルできること、型宣言。(C++もあったけど)Javaを選択した。
  • その他
    しょうもないレベルのものを潰す。
(5-3)テストできるアーキテクチャ
(5-4)テスト向けのDSL採用(Spock)
  • JUnit
    Java言語でテストを書くことになるが、Java言語はテストを表現する手段がない。
  • 記述言語は、JVM言語のgroovy
    テストを記述するためのDSLが構築されている。
  • IDE
    eclipseからInteliJに変えた。
(5-5)CI/CD、静的解析
  • Cloverによるカバレッジ計測
  • Coverityによる静的解析
    • Quality Advisor
      NullPointerExceptionを検出。
    • Test Advisor
(5-6)インターフェイス定義言語(IDL)
  • テストと別の観点で、開発効率向上と品質向上のため、インターフェイス定義言語(IDL)を選択。
  • OSSを利用できないか検証したが、以下の理由で一から作った。
    • バリデーションが表現できない
    • ドキュメントが生成できない

(6)ふりかえっての所感

  1. 問題検出をできるだけ前工程にもってくる
  2. テストできないと言い訳される要因を潰す
  3. 未熟でも早めに適用/フィードバック受けて磨く
  4. 部門長サポートと仲間が大事

所感

 開発における課題を乗り越えるため、技術的に工夫することも大切ですが、組織の中でも部門長の後押しが無いと、自動テストシステムの開発や保守が頓挫するので、仲間作りも軽視できないと思いました。また、組織の体制や役割も適切に機能しないと、技術的に工夫することが難しくなるので、どのように組織のマインドを変えるか、クリアすべき課題に取り組むことも大切と思いました。