TEST Study #1「品質とスピード」 参加メモ
こんにちは。kubopです。
本日はTEST Study #1「品質とスピード」という勉強会に参加したため、その参加メモ・感想です。
※ 個人的に書いたものなので、認識の齟齬や理解し切れていない部分があるかもしれません。
「『質とスピード』初演からの変化」
スライドが完璧なので、書くべきところは無さそうですが…。
気に入ったところ・忘れたくないところを、備忘のためメモします。
品質とは
品質というとかなりわかりにくいので、品質ではなく「質」とすると捉えやすい。
品質とは誰かにとっての価値である。
「品質」っちゅうから難しく聞こえてしまうんや。「質」といえばみんなわかってくれる。
品質を犠牲にすれば、スピードは得られる？
品質を犠牲にしても開発スピードは上がらない。
内部品質への投資は、長期的観点かと思いきや一ヶ月ですぐ元が取れるらしい。そんなに早く元取れるんだ・・・。といっても何をもってそう判断しているんだろう。後で見てみよう。
ただ、品質に全振りしてもいけない。
クオリティに優先度を全振りしても、フィードバックサイクルが回らない。
スピードに全振りしても、脆く壊れやすくなってしまう。
どちらもバランス良く選択していくのが良いんだろうなぁ…。
品質とスピードはトレードオフである、というのは大きな誤解で
品質として犠牲にされるのは「保守性」であることが多い。（テスト容易性や理解容易性、変更容易性）
しかしながら実際は保守性を高めれば自然とスピードは上がる。（リファクタとかしやすくなるからかな）
スピード・質とトレードオフなのは、教育・成長・多様性への投資
"内部品質がスピードを生み、スピードが学びのループを生み、学びのループが外部品質を生み、外部品質が競争力を生み、競争力が売上を生み売上が内部品質を生む"
デリバリー速度が一ヶ月 -> 5日に短縮した例
品質モデルの変化(スライド内
QWAN(Quality Without A Name)
名前のない品質とは、「The Timeless Way of Building」にて建築家クリストファー・アレグザンダーが、良いとされる建築物には、言葉では表現することのできない「質」として現れる、と定義しています。
建築をシステムに適用するのがすごい。知らなかったけど確かに「良いとされているもの」の共通点があるんだろうな。
また、同時に紹介されていたのがMcCall’s Factor Modelと、Boehm, Brown, and Lipow's 23 Quality Characteristics
しかしながらこれらは少々抽象的であるらしいため、SQuaRE(Systems and software Quality Requirements and Evaluation)という、立体的に品質を捉えるモデルを紹介。
「品質を犠牲に…」と言った場合に、「なんの品質？」
といったように、どの品質を犠牲にするのかを議論できるようになる。
SQuaREには、利用時の品質や、システム・ソフトウェア製品品質などの品質項目・品質特性のツリー以下に、品質副特性としてそれぞれ定義づけられている。
https://www.ipa.go.jp/files/000065855.pdf
現代における質とスピードを測る4つのキーメトリクス
リードタイム
デプロイ頻度
MTTR(平均修復時間)
変更失敗率
質とスピードを測定する。
仮説検証をするために、リードタイムやデプロイ頻度が重要になってくる。
また、不具合が発生した際に復旧できる速度。
不具合が少ない、ということのみを品質とするならば、萎縮してデプロイ頻度が減ってしまう。
これらは生産性、会社の業績にダイレクトにつながる。
質問コーナーでの学び
Q. テストが増えすぎている問題。
テスト実行全件10分が防衛ラインとすると良いらしい。(全て、ユニット・E2Eを10分はめちゃくちゃはやい気がする！！！）
テストピラミッドがうまく構成できておらず、E2Eが多く、ユニットテストが多い場合に起きるらしい。
この場合は、E2Eでカバーしている、論理的重複部分をユニットテストに置き換えていくといいかも。
テストピラミッドはこれがわかりやすいかも。
しかしながらこれらは結構手間のかかるものなので…
短期的には、テスト実行を間引きする方法がある。
失敗するテスト迄の最短経路を探す。
Googleでは、テスト結果をDBに入れて、最も有効なテストのサブセットを作成し実行しようとしている。
ディレクトリ・テストサイズ などの構造で分けて実行する。
テストサイズにタグをつける。
フィーチャーの種類でタグをつける。
メタデータをテストに与える。
タグはツリーとは異なり、様々な切り口を作れる。
ユニットテストと、E2Eテストでは、同じ感覚で設計するとE2Eテストが膨らみがちになる。
E2Eテストでは、シナリオの深さ。
目的を持ったユーザーがどのような手順をふむか、といったユーザージャーニーをテストする。
ユニットテストでは、ひとつひとつが大きくなりすぎないように。
ロジックの網羅性を大切に。
とあらかじめ作成時にチーム・組織で合意をとって作成すると良い。
Q. テスト網羅性が気になる。
問題になるのは、仕様のカバレッジ。
プロダクトコードからは見えてこないので、テスト実行結果をツリー形式にして、仕様のツリー構造と対応付ける。
仕様とMECEになっているかをPRのレビューでは見ると吉。
（そもそも仕様がツリーになっているドキュメントを作らないとダメだ…!
仕様の整理整頓は、テスト技法を学ぶと良いかも。
どのテストで何を担保・何を保証するかをチームなどでポリシーを設定すること。
ついつい自分の責任範囲の網羅性のためにテストを書いてしまうが、そもそもテストで何をカバーするのか、という決めが重要なのかな。
※ 合わせて読みたい
クラシフィケーションツリー
Q. テストのないレガシーコードの打開方法
レガシーコード（テストのないコード）では、テストのことを考慮して書かれていないコードなので、テストが書きにくいコードになっている。
そのため、構造を変えないとテスト自体が書けないことがある。
「安全にコードをかえたいからテストをつくりたいのに」
「テストをつくるためにコードをかえる」
というデッドロックに陥る。そのため、2種類の手法があるらしい。
テストを無理やり書く。
E2Eテストを柱に、リアーキテクトする。
そこからユニットテストを積み上げていく。
その後、網羅性のあるE2Eテストは削除していく。
テストコードがないのを承知で既存コードを変更する。
レガシーコード改善ガイド参照。
静的解析・IDEなど、安全にコード改善できる手法からテストを書いていく。
Characterization test
E2Eを先に作成するのはキャラクタライゼーションテスト。
コンピュータプログラミングにおいて、キャラクタライゼーションテスト（ゴールデンマスターテスト[1]とも呼ばれる）とは、既存のソフトウェアの実際の動作を記述（キャラクタライズ）し、自動テストによってレガシーコードの既存の動作を意図しない変更から保護する手段である。この用語は、Michael Feathersによって作られた[2]。
Q. 能動的にテストを書いてもらいたい。
テスト書き慣れている人は、テスト書きながら実装するほうがはやい、ということがわかっているが
書き慣れていない人は学習コストがあり、テストを書かないほうがはやいと感じる。
学習コストを低減するのは、まずはコピペで真似してもらうことが大事。
… コピペすること自体は、後々テストメンテコストに苛まれるが
それは次のゴールに設定、リファクタリングをしていくのが良い。社内チュートリアル・プロジェクトチュートリアルを設定すると良い。
手を動かしていくうちに、だんだんわかってくることがあるから。
背中を見せる、ということが大事らしい。
ファーストペンギンになるのが・・・。
Q. テスト文化を広めるにあたっての、おすすめ本。
Agile Testing Condensed
BDD Books Behavior Driven Testing
はじめての自動テスト(持ってる!)
ソフトウェアテスト技法練習帳(持ってる!)
ソフトウェア技法ドリル
しかしながら、
開発プロセスそのものの理解度が甘いと、テスト技法にフォーカスしすぎてしまうため、注意。
テストにこだわりすぎずに、テストと、開発プロセスをバランスよく取り組む。
テストのみで質を上げるのではなく、全体のプロセス自体の質をあげていく。
テストだけでは品質は上がらない。
開発プロセスとテスト、相補的に関与して全体の質が上がっていく。
紹介された記事・気になったもの
この「質v.s.スピード」という概念は根本的に間違っていると思う。
だって素早く開発をしなくては環境、あるいは自分の環境の理解の変化にソフトウェアがついてこれず、ソフトウェアが解決すべき問題が解決できなくなり、必然的に質が落ちてしまう。
逆に、質の高いソフトウェアを書かなくては、なにかある度にインフラが崩壊し、素早く開発をすることができなくなってしまう。
インフラの崩壊は、やる気を削ぐので特にたちが悪い。
フェイスブックでは「質v.s.スピード」ではなく「質＝スピード」を念頭にソフトウェアを書いてきた。
相当たくさんの仕事をフェイスブックではしたし、書いたもののかなりの部分が今でも使われていることを考えると、ぼくの考え方は間違っていなかったと思う。
感想・まとめ
すごい学びになった・・・。
次回もすごく楽しみになりました。
品質の損益分岐点があって、しかも1ヶ月とはたまげました。
だけど、導入する際は何が問題で、導入した後は何が解決されて、コストがどう減ったか、を観測できるようにすると良いんだろうな。
いろいろ書きたいけど一旦今日は閉じます。
この記事が気に入ったらサポートをしてみませんか？