11章 テスト概観
前文
変化を可能とする能力を備えていくため
過去1年の障害報告書を最近見たが、全件「モックせざるを得なくてテストが不十分な箇所に、いつものノリで手を入れた」だったので、経験的にものすごく同意
11.1 何故テストを書くのか
テストがGoogleのエンジニアリング文化の心臓部に組み込まれた
カッコいい!
テストのプロセスを真に効果的とするのは、テストの失敗にどう対処するかである。
テストに対するポリシーを考えるときに単体テストやユニットテストなどの「どのレベルまで書くか」とかに思考が向きがちだけど、「失敗したらどう対処するか?」というところの対応ポリシーまで考えないと効果が薄れてしまうんだなと思った
DevOps的なところでもそうだなーって改めて思いました。運用の高度な仕組みっていうのは、プロダクトが動かなくなったときにどう対処するのか?までふくめて効果的になるっていうか。
11.2 テストスイートを設計する
我々は上記のように区別しており、もっと伝統的な「ユニット」または「インテグレーション」 の区別は用いていない。その理由は、我々がテストスイートに望む最も重要な特性は、テスト範囲 とは無関係に、速度と決定性(determinism)だからである。
今までの自分にない考え方でなるほどーと思った
Beyoncé ルール
Single Ladiesという曲に 'Cause if you like it, then you shoulda put a ring on it(そんなに好きならそいつに指輪をはめておけばよかったのに)という一節がある模様
t_wada さんのスタンドよりは具体的
コードカバレッジはテストされていないコードについての何らかの知見を提供できるが、システムがどれだけ適切にテストされているかについて批判的に考えることの代用とはならない。
それはそうだなあと思いつつ、だとするとどれくらい適切にテストされているかをどうやって測ったらいいんだろうかとも思ったり
11.3 Google規模でのテスト
テストスイートが大規模になると実行が遅くなるという問題がある
これに対する明示的な解答がないのだけど、小テストが1プロセスに収まるルール、中テストがlocalhostに収まるならほぼ無限に並列化可能なので問題になってないということなんだろうか
Googleだとお金とハードウェア資産でぶん殴れちゃうから、それを生かす方法を考える方が大事かも
11.4 Googleでのテストの歴史
トイレでのテストの話めっちゃいいなー。こういう低コストなのにすごく効果がでる方法をつくれるのがいい。リモートワーク前提になるとこういう実装が難しくなっていて、いつも悩んでしまう。
確かにslackのコミュニティのチャンネルとか、ランチタイムの社内ラジオ(podcastとかも)って結局限られた興味がある人しか見てくれないのでなかなかいいアイディアがない
Googleが原則出社にしているのってこういう理由もあるんだなーと納得した
このプログラムがチームに与えるのを目指していたのは、自分たちのテストプロセスの習熟度を理解する方法と、(中略)テストプロセス改善方法の各種手順書をまとめたものだった。
テストは「とりあえず書かれていれば良い」という空気があって質の担保が難しいので、定量的な評価基準があるのは良い
fleakyなテストが修正される程度
テストの質を上げる方法はコードレビューで検出する、静的解析できる範囲で修正する、程度しか思いつかない
社内ダッシュボードは、全チームのレベルを表示することにより、社会的な圧力をかけた。
こういうのはトップダウンじゃないとできないんだろうな〜
コードの開発方法についての強制は、どんなものであろうが、 Google の文化に真っ向から逆らうものであると同時に、おそらく進歩を鈍化させるものだ。
↑のダッシュボードへのレベル表示による社会的圧力は実質的強制なのでは...?
プロセスは好きにして良いが結果は出せ、ということなんですかね
基準に対する仮説: エンジニアリングプロセスとして真っ当かどうか
再現性がある形でゴール(機能要件、スケール性含む非機能要件)にたどり着けるかどうか
11.5 自動テストの限界
検索結果の品質のテスト
こういうのにChatGPTが使えそう
実際に検索されたクエリからランダムで選び、生成した回答と検索結果の差異をスコアリング、とか
探索的テスト
ビジネス面で、製品の評価をするためのテスト
11.6 結論
11.7 要約
「そんなに好きならそいつにテストつけときゃよかったのに」
秀逸すぎるwww
みんなからのコメント
Googleにしかできないとしたら、それはなぜか?
人間が発見したバグを抽象化して、汎用的なツールで自動的に探索できるようにするっていうのは、高度なエンジニアリング力と、コードやインフラ管理が自動化フレンドリーであるべきっていうところに支えられている気がする。
自動化しやすい環境を整えることの重要性を理解し、実践することが実は難しいのかもしれない。
GWSでの経験を「良かったね〜」ですまさずに、その学びを文化やツールに落とし込むところまでやりきる徹底ぶりとそれを許容できる企業としての安定性や、テストの重要性に対する理解
社員全員が高レベルなコードを書けるところ
現場でどこまでできているか?
WF中心の文化だとフェーズゲートでQAが品質確認してみたいなやり方中心になってしまうので、Googleにしかというわけではないが、もっとアジャイル開発で一般的な品質の考え方(戦後の日本の製造業におけるTQMのような考え)を学ぶ必要がある
自分達で考えることを極端に嫌う印象がある
アウトカムではなくアウトプットを目指す形が当たり前になってしまっていると、脱出が難しいのかもしれない
PMBOK 6版と7版の違いが印象的
SMLでテストをわけるとか、小さいテストをたくさんにするとかは比較的多くの企業でやられるようになったし、自分でもそうしているなー。プロジェクト横断でダッシュボード化するところまではまだできていない。
テスト大事だよねという共通認識はあるものの、具体的にどこまでというところまではみんなイメージが違っていそう
「テストの恩恵はテストが書かれてないとわからない」というジレンマがありますよね
あと、「納品して終わりのビジネスモデルだったりプログラマのモチベが低かったりすると、恩恵をそもそも感じられない」という事情もあるので現場によっては数の力に負けてしまったり
この本があるのになぜ実践する企業はすくないのか?
ちょうど今新入社員が入社して研修で学ぶ時期ですが、うちの社内にはこういうモダンなソフトウェア開発について教えてくれる教材がない気がする(アジャイルの研修はあるんですが。。。)
日本の著者が書いたモダンソフトウェア開発の本が少ない気がする
大学でのソフトウェア工学の研究が難しい立場になっている
過去は大規模なデータセットや演算リソースが大学にしかなかったが、現在はGAFAMの方がたくさんの実データと演算リソース、人材を持っている
Googleのようなエンジニアドリブンな企業でないとテストの費用対効果などの説明がついて回るから?
それの乗り越え方はなにか?
(↑の「Googleのようなエンジニアドリブンな企業でないと〜」を受けて)テスト以外の他のところで信頼貯金を作って裁量を得てから、テスト文化やプロセスの構築するとか
弊社のアプリにテストが書かれるきっかけはアプリ全体のリファクタリング(3年がかり)だったので、それくらいの決断を経営陣に迫ることになる
投資は受けられていてサービス自体も儲かっていたが、アプリの質が低く障害が多かったり機能追加が難しかったりでビジネスを広げられない、という再現性の低い状況だったので他社だとどうなのか……と思っている
ステップを小さくするとしたらどうできそうか?
新人研修で1日トライアル的にやってみるとか
少しでもコードを書いた経験があれば「バグが少ないコードが書ける」実感が得られる