組織にテストを書く文化を根付かせる戦略と戦術 #jopf

勉強会告知ページ

connpass.com

発表スライド

www.slideshare.net

発表のねらい

  • 戦略の話と戦術の話

自己紹介

  • 昼はコンサルの仕事をしている
    • いろんな組織にテストの書き方を根付かせるための活動とか

銀の弾丸はない

  • レガシーコード改善に正解はない
  • テスト自動化は銀の弾丸ではない
  • 導入方法にも銀の弾丸はない
  • 導入を目的にしてはならない
  • 状況は現場によって全く異なる
    • 勝ちパターンはだいたいある
  • 「t_wadaが来たから大丈夫だ」ではない

ジェラルド・ワインバーグの影響図

f:id:nihonbuson:20160217215450p:plain

  • ストレスが増えるとテストの回数が減る
  • テストの頻度が減るとストレスが減る
  • どうやってこの無限ループを抜け出すか
    • ノードを増やす?
    • テストではなく自動テストにする&テストが先に来るようにする

f:id:nihonbuson:20160217215505p:plain

  • テストを書く時間がないのではなく、テストを書かないから時間が無くなるのです by James Grenning

文化を変える

  • 文化はすぐに変わらない
    • 大体2年ぐらいはかかる
  • ソフトウェアプロジェクトの掟「動くコードに触れるな!」に戦う
    • コードは緩やかに死んでいく
    • どうやって動くコードに触れるような仕組みにするのか

イマココから始める

  • ToBeではなくAsIsとNotToBeから始める
    • 「自動化すれば、ChatOpsにできて…」とかではなくもっと現実的なところを考える
  • 現状がどうなっていて、どうなりたいか
    • ヒアリングする
    • 「勘弁して欲しい」ということを裏返すことから始める
  • 期待値のマネージメントをする
  • 人やプロジェクトの速度はそこまで変わらない
  • 日本人を行動させる言葉「まわりはもうみんなやってますよ」は劇薬なので、用法用量を守ること

夢を語りがちになるよねぇ…

それよりもロードマップをきちんと引く方が良いと思ってます


人を知る

  • チームメンバーはストロングポイントが違う
    • 楽しいから頑張る
    • 定時で帰れるから頑張る
    • 自分のコードが綺麗になっていくから頑張る
    • 回帰テストを機械がやってくれるようになるから頑張る
    • コードカバレッジなどのメトリクスの達成感があるから頑張る
    • ビジネス価値が増えるから頑張る
      • 不具合修正ではなく、新しい価値を提供する

変えることの難しさ

  • 人は誰しも変化に対して身構える
  • リファクタリング(振る舞いを変えないままで中身を変えていく)をやろうというとやる気になるが、「今やりましょう」というとなかなかやってくれない(リファクタリングのジレンマ)
    • 「後でやるよ」と言ったりする(TODOタスクになりがち)
      • そしてやらない
    • 部屋の掃除と同じ
    • リファクタリングはお客様に価値を与えないように見えてしまう
      • 実際には中長期的には価値を与えるのだが…
        • ソフトウェアの成長速度が下がっていく
      • ボディブローになる
    • リリース後は、別機能の着手に追いやられる
  • プログラミングの中に混ぜ込まなければならない

変えることの難しさは以前に #cooketn でも松尾さんが伝えてましたね

nihonbuson.hatenadiary.jp


Grace Hopper(COBOLの作成者)の言葉

  • 事前に許可を得るより、後で許してもらう方が楽

すべては変化する。これを受け入れざるをえない

  • 仕様が固まることはない
  • 開発が終わることはない
  • 理解は常に深化する
    • 1年前のコードより今書いたコードの方が技術的にも業務理解的には深いはず

技術的負債の四象限(マーティン・ファウラー

f:id:nihonbuson:20160217215545p:plain

  • 第四象限に対して、どのようにアプローチしていくか
    • 気付くチャンスを増やす
    • 気付いた時に改善できるようにする

テストは品質を上げない

  • 品質が「わかる」ようになる
  • テストは体重計のようなものである
    • 体重計を買ったって痩せない
    • 体重計に乗っても痩せない
    • 体重計があることで現状が分かる
  • テストを書くだけでは良くはならない
    • 情報が増えても、悪いことが分かるだけ
  • 設計とプログラミングを見直すことで品質を上げる
  • 再設計とリファクタリングをテストで支える

戦術編

  • 全部書こう!→破綻する
  • 改革は小さくかつ最も効果のあるところから
  • 最も困っているところから
    • ECサイトなら決済などのお金&個人情報
    • お客さんによっては、新機能のところから
    • バグを修正をするところから
      • 欠陥は偏在する
    • 静的解析でピンポイントに
      • 複雑度が高いところから

完全にテスト分析・テスト計画の話ですね


テスト戦術

  • 『リーン開発の現場』に、どこから始めるべきか書いてある

リーン開発の現場 カンバンによる大規模プロジェクトの運営

リーン開発の現場 カンバンによる大規模プロジェクトの運営

  • リスクが高い
    • 例えば管理画面の履歴とかはリスクが低い
  • 手動テストのコストが高い
  • 自動化コストが低い
  • リスクが高くて自動化コストが低いならやってみるべき

誰とやるか

  • 少しずつ広げていく
    • 改善の芽が育つように
    • 親離れできるようにするのがコンサルのゴール
  • 最初はペアプロからやってみる
    • 1人が2人、2人が4人に
  • 最初の1人は若手のエースかベテランから
    • 戦略編の「人と知る」にも繋がる
    • 依頼をくださった人と相談することが多い

こだわるな

  • 最初から全部やろうとしない
    • 何はやって、何をやらない
    • テストを書きながらコード書いて、リファクタリングをやって…とかもこだわらない
      • 慣れが必要だし
      • 「テスト駆動までできてないんですよー」という発言はどうでもよい
  • テスト駆動にこだわるな
  • テストファーストにこだわるな
    • テストの書く順番は最初はこだわらない
    • 慣れてきたらテストの書く時間とコードを書く時間を同じぐらいにしていく
  • ユニットテストにこだわるな
    • ネットワークやデータベースを偽物に置き換えて…とかに拘る必要がない
    • t_wadaさん自身もこだわっていない
  • テストの速さにこだわらない
  • テストの網羅性にこだわらない
    • 最初から「例外系を網羅する」とか考える必要はない

こだわろう

  • 良いユニットテストの指標にも優先度がある
    1. 再現可能であること(Repeatable)
      • Aさんは動くけどBさんのところでは動かない
      • もう一回動かすためにはこのファイルを消して
    2. テストは互いに独立していること(Independent)
      • A→B→Cの順番なら通るが、C→B→Aの順番だと通らないとか
      • 並列で走らせる時にエラーにならないようになっていること

レガシーコード改善ガイドは必ず読むべし

レガシーコード改善ガイド (Object Oriented SELECTION)

レガシーコード改善ガイド (Object Oriented SELECTION)

  • テストが書かれてないコードはテストが書きにくい
    • テストが書けない構造を変えていく
      • 組み込みソフトウェアの場合は、テストが書けるようになるまで外科手術を行う
    • 外から無理やりテストを書くようにする
      • WEBアプリケーションならば、HTTPのrequest/responseとDBの事前状態と事後状態で抑える
  • 絞込点を探す
  • 仕様化テストを行う
    • 仕様との乖離が起きる
    • 何が正しいか分からない
    • とにかく現状で動いていることを正の状態にする
      • 動きが変わったかどうかだけは分かるはず
    • 十分綺麗になったら、何が正しいか考える

見える化

  • 割れ窓理論
    • NYは治安を上げていくために、割れている窓を綺麗にしていく
    • 汚いものがあると罪悪感がなくなっていく
    • 気付いたところから綺麗にしていく
  • メトリクスを取る
    • カバレッジが低いうちは効果大
    • 変化がすごいあると人間のモチベーションが上がる
  • 小うるさいツールを乗りこなす
    • 大量の出力を出したりする
  • 分母分子を見ないで傾きを見る。

静的解析を使いこなす

  • 動的テストと静的テスト
    • 対象を動かすことによって調べる
    • 対象を動かさずに調べる
      • コード行
      • メソッドごとの行
      • テストは書くだけではない
  • 全体のメトリクスを計測して俯瞰の視点を得る
    • ヒートマップ的な
  • 部分的なメトリクスを計測し続けて傾向を見る
    • リスクインパクトのある決済部分は改善しているなど

コードレビュー

  • コードレビューのインフラに投資する
  • WIP pull request
    • 完成する前から共有する
  • コードを見る文化、見られる文化を育てる

設計の可動域を確保する

  • テストがないのは設計が悪い兆候
    • 今の状態のものにテストを書くと、改善時にテストを書き直すはめになる
  • テストと実装の間に遊びを持たせる
    • 大外からテストの手をのばすとか
      • その代わり、動作は遅いし、データの準備が必要だったりする

背中を見せる

  • サンプルとデモが大事
  • 真似してもらう土台を作る
    • 最初はサンプルのコピペでもOK
    • 架空のプロジェクトでもOK
  • テストのある生活を体験してもらうことが大事
    • その生活を体験するとそこから辞める人はほとんどいない
  • その後にテストのメンテナンスを学ぶ

改革について

  • 自分達から始めてみる
  • できるからやるのではなく、やるからできるようになる