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

勉強会告知ページ

connpass.com

発表スライド

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

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サイトなら決済などのお金＆個人情報
- お客さんによっては、新機能のところから
- バグを修正をするところから
  - 欠陥は偏在する
- 静的解析でピンポイントに
  - 複雑度が高いところから

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

テスト戦術

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

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

作者: Henrik Kniberg,角谷信太郎,市谷聡啓,藤原大
出版社/メーカー: オーム社
発売日: 2013/10/26
メディア: 単行本（ソフトカバー）
この商品を含むブログ (9件) を見る

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

誰とやるか

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

こだわるな

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

こだわろう

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

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

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

作者: マイケル・C・フェザーズ,ウルシステムズ株式会社,平澤章,越智典子,稲葉信之,田村友彦,小堀真義
出版社/メーカー: 翔泳社
発売日: 2009/07/14
メディア: 大型本
購入: 45人クリック: 673回
この商品を含むブログ (153件) を見る

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

見える化

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

静的解析を使いこなす

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