LINE Developer Meetup in Tokyo #39 Testing & Engineering

line.connpass.com

LINE Developer Meetup in Tokyo #39 Testing & Engineeringのレポート。

イマドキのソフトウェアのテストやQAの考え方

www.slideshare.net

スライドの中身が非常に多く、以下に抜粋して説明された内容のメモをまとめる。

労働のスケールアップから知のスケールアウトへ

目的なくテストを厚くするために人的コストの投入量を増やす「労働のスケールアップ」ではなく、
プロダクトの価値の最大化のために技術を活用して効率的に品質保証を行う「知のスケールアウト」をしようという話。

知のスケールアウトを促進するような品質保証戦略を立てる

  • 技術を活用するといっても流行りの手法を闇雲につぎ込めばいいという話ではない。
  • バズワードに振り回された戦略は必ず失敗する。
  • 大事なことは事業や開発力といった組織全体のコンテキストに合わせた品質保証戦略を立て、それに基づいたフローや自動化を導入すること。

品質保証戦略を立てる際に考えるべきパラダイム

  • 品質保証とは納得のマネジメント、価値の最大化に自信を持つ行為。
  • ソフトウェアという目安となる指標を算出できても測ることはできないものを無理に測ろうとしない。
  • デベロッパーとQAでミッションをシェアし、違和感があれば進捗を止めて納得感を上げる活動をQAが促進する。
  • その中で単純作業を自動化し、自動化によって思考に使える時間が増加した割合、納得度に対して自動化の価値を見出す。

テストにもエンジニアリングアプローチが必要

  • 測定や手順による品質の保証はできない、テストは3 × 5 × 3=45種類の保証動作の重ね合わせ価値の最大化に自信を持つ行為。
  • テストアーキテクチャは設計における責務の分担と配置と同様である。
  • テストアーキテクチャはすでに様々なものが存在するが、組織に合ったものを考える。

テストの自動化

Fully-automated VSTeP
テストの要求分析、アーキテクチャ設計、詳細設計を自動化する。
テスト、QAにも投資が必要。

感想

単純にテストをこなすのではなく、何のために品質保証をするのかを考え組み立てていく上で、フレームワークや自動化を取り入れていくということを意識させられる話だった。 盲目的にテストを継ぎ足していくということではなく、新しいテストを追加する目的とそれで得られる価値をより深く考えていきたい。

LINE のUI自動テスト事例

www.slideshare.net

LINEのテスト自動化事情

  • グループ全体
    • 各開発拠点でそれぞれにQAチーム、自動テストチームを持っている。
    • 拠点ごとに見ているプロジェクトが違う、テストの粒度ややり方も違う。
  • LINE Fukuoka
    • かつてQA組織はあったが自動化に特化したチームはなかった。 今回はLINE Fukuokaの自動化特化チームが作ったE2E UIテスト(for iOS,Android,Browser)の話。

ツール選定

  • ツールとしてはオーソドックスなものを使っている。
    • 傾向としてはJava系のツールをよく使っている。
    • Javaで書かれたプロダクトが多く、ライブラリも多く、とっつきやすいため。
    • 代表的なものではSelenium,Appium,Jenkinsなど。

テスト自動化で気をつけていること

  • Stability
    • 基本に忠実に。
    • 不安定な実行環境を作らない。
  • Maintainability
    • UI変更に対して強く。
    • テストをしやすいプロダクトを作る。
  • Readability of the test result
    • テスト結果を全員にとって見やすいものにする。
    • 非エンジニアがログを生で見ても的確な情報は得られない。
    • わかりやすい可視化をするためのレポートツールを作成。

LINE STOREでの事例

  • リリースサイクルが早い。
    • リグレッションテストの需要が大きい。
  • 既存機能に対するテストは自動、新機能に対しては自動テストの準備が間に合わないという都合もあってManual QAも入るハイブリット。
  • 大規模な更新の場合、Manual QAでのバグ発見件数が多くなる。
  • 自動テストは実装したことしかテストしてくれないのでテスト選定が重要。
  • 自動テストの導入は人的コストの削減には至らない。（狙っていない）
    • 自動化にもコストがかかる、テストを増やしてもメンテナンスコストもかかる。
  • 全てを自動化することが善ではない。

チームの指針

  • E2Eのテストを全てQAチームで作るのは無理。
    • Engineerと積極的に協業する。
  • 全てをE2Eで解決しようとはしない。
    • コストも膨大になる。
    • テストを作ることが目的化するとメンテナンスできずにテストが腐っていく。
  • 開発チームが仕事しやすくならなければ意味がない。
    • リファクタに対する躊躇など、やりたいことを阻害する要因をカバーする。
  • テストを書くことが辛いことになってしまっては意味ない。
    • テストがあることで楽に開発できると思ってもらえるようにしていく。

感想

全てをただ自動化しようとするのではなく、人によるQAと自動テストの役割・価値を考えてコントロールされている良い事例だと思った。
E2Eテストや可視化ツールなど揃えておきたいものを揃えつつ、自動化やツールで全てを解決できると考えないことが品質を保ち続けるために必要な考え方だと思った。

An Agile Way As an SET at LINE

www.slideshare.net

SETとしての活動

  • SET部隊の立ち上げとテスト自動化の推進がミッション
    • SETに対する共通認識がない、そもそも問題の言語化ができていない。
    • 遭遇した課題
      • 何を為すべきかわからなかった
      • テスト対象システムの詳細を知らなかった
      • 幅広い関係者の支持・協力が必要だった
    • 解決方法
      • 何を為すべきなのかを見つけ出す
      • トライアル＆エラーで高速に学習する
      • 定期的に進捗と成果を見せる

何を為すべきなのかを見つけ出す

SETに対する共通認識がない、そもそも問題の言語化ができていない。

  • アジャイルの要素

    • プロダクトディスカバリー
      仕様は絶対的ではない、仕様は仮説、SETがやるべきことも仮説設定

  • 共通認識づくり

  • 施策、目標の策定
  • 継続的合意形成 ビジネスの3KPI(売上・利益・従業員満足度)に基づいて施策の優先順位づけ、効果測定を行なった。

現状把握・課題発見・言語化

  • テスト対象システムの解析
    • 静的コード解析によって技術的負債を見える化、共通認識を作る。
  • 障害報告はヒントの山
    • 障害報告から情報をかき集めてくる。
  • 困っている人と直接対話して言語化する

施策・目標案の策定

  • 障害の頻度と金銭的被害の大きさをKPIとする。
  • 障害検知速度の向上とMTTRの短縮に絞った。
  • デベロッパーの自律的テスト作成の土壌づくりをする。

共通認識を作る視点はビジネスKPIに基づく。
プランは必要ないがプランニング(ゴールと施策の定期的な見直し)は必要。

トライアル＆エラーで高速に学習する

自動テストを活用したプロダクトの仕様・設計の把握。

  • アジャイルの要素

    • Extreme Programingを活用した高速な学習の仕組み

  • 動かしてみてわかることが多い。

  • 動かしても壊れないことが理想。
    • プロダクトとテストスクリプトを適切に作っていればプロダクトを壊さない。 = 安心して失敗できる、心理的安全性につながる。

定期的に進捗と成果を見せる

多くの人と協力関係を築く必要がある。

  • アジャイルの要素

  • ビジネスの3KPIの活用

    • 売上・利益
    • 従業員満足度
      • 役員・マネージャー
        • ソフトウェアの負債・不安の発見
        • 数値的な報告が必要
          テストのレポーティングを活用、わかりやすい指標を提供する。
      • デベロッパー
        • 知識欲の刺激
          興味を持ってもらえるように刺激を与える。

  • 例：本番APIのSmoke Test

    • 各環境でSmoke Testを動かしている。
    • 絶えず数値をチームに対して送ることで開発チームのMTTRを短縮することが狙い。
      • 負荷に対するインフラの障害や脆弱性も検知できた。

今後の課題

ビジネスに絡めたインパクトを出し続けて、より受け入れたいと思わせる。

まとめ

  • 課題を見つけて言語化
  • 協力者を得る
  • 全てのビジネスは3KPIに基づいている
    ビジネスに貢献しよう

感想

定期的に進捗と成果を見せるということが特に良い取り組みだと思った。 品質という概念やテスト自動化の推進による成果というものは、指標はあってもインパクトを測ることが難しいものである。
ビジネスの3KPIに基づいて優先度付けをし、効果測定と事業貢献を念頭に置いて取り組むということが、テストや品質保証に対して前向きな文化の醸成を推進する上で効果的な手段だと思った。
アジャイルの考え方も含めて様々なアプローチでSETの役割・働きを定義して推進しているのはすごいと思った。

全体の感想

とにかく目的を見出してテストを導入するという話が多かったと思う。
世の中には便利なツールも多く存在するが、まず導入するよりも何がプロダクトの品質面で不足しているのか、新しいツールを導入することでどういった価値を生み出せるかを自分の頭で考えて取り組むことではじめて効果が得られるのだと思った。
また品質保証チームから組織の考え方、間違った当たり前を正していくという話も多かった。
自分は開発者という立場で仕事をしているが、テストコードを書いたり品質を保つための改善をし続けることに変わりはないので、今回聞いた話も参考にしつつより明確な自分の考えを持って開発に取り組んでいきたい。