5章 最後の味付けとしての品質
恥ずかしいバグをリリースしてしまい、一部の領域がまったくテストされていないという事実を浮き彫りにしてしまう..
↑リアルに毎日恐怖に苛まれています..(^^;
あるあるだけど、こわいですよね。。。
5.1 テストピラミッド
「開発ライフサイクルの最後まで待ってテストを実行することは災いのもとです」
↑あたりまえなんですけど、できてない……。
ユニットテスト・統合テスト・E2Eテストはコンピュータによって実行すると仮定します
でも実際には人手でテストすることも多そう。。
ランダムに失敗してしまう不安定なテストと.. 失敗したテストを見分けることはできません。..こういった区別を自動的に行えるようにテストスイートを設計しなければなりません
そうだけど、難しい。各社苦労してますよね。
DevOpsの本になぜテストに焦点をあてた章があるか?
読み始めに疑問に思ってたことがここに書かれてた
テストのライフサイクルはDevOps の変革において非常に重要 -> 感覚としてはわかるが..
-> 10年くらいまえに Ops の人たちがすぐ壊れるUIテストをたくさんつくってしまうということがあった
5.2 テストの構造
もしあなたの組織で現在、開発者以外の人がユニットテストを書いているとしたら、申し訳ありませんが、それは間違っています
いいきっていていいかんじだ。
xUTPとかテストピラミッドとかを参照しているのがソフトウェア工学の王道って感じがする。(Googleのような自分たち用語を持ち出さないというか)
・エンドツーエンドテストは可能な限り分離しましょう。
ほんとそれ……。
コントラクトテスト -> エンドポイントの入出力が期待通りの動作をしていることを確認するもの
なるほど。。確かにこれが必要なことがある。
-> マイクロサービスの文脈ででてきた。専用のツールがあった。
5.3 テストスイートの信頼性
代わりに自動テストという考えを、「そうすることになってい る」というだけの理由で崇拝しています。
テストスイートへの信頼性を測ることは科学というよりも技巧です。それを測る簡単な方法は、テストスイートが失敗したときの人々の反応を見ることです。
なるほど……
エンドツーエンドテストが多くなってしまう理由の 1 つは、テストの大部分を担当している
チームが開発チームではないことです。
ですよねー。テストの文化がないか、マネージャーがユニットテストの必要性を理解していない場合に、どうユニットテストの文化を導入したらいいんだろう。
・エンドツーエンドテストの数を制限しましょう
E2Eテストの上限数を予め決める、というのがプラクティスになっているのは新鮮でした。QA担当者の作業負荷から,数を制限せざるをえない……という事情で制限している事例は多そうでしょうけど。
-> たしかに新鮮。E2E増やしすぎると、テストの時間がかかる。。
テストカバレッジは虚栄のメトリクスの一例です
言い切ったーー。いや、カバレッジも使い方次第だと思うんですが。 Mutant kill ratio (percentage of mutants that they kill) は出てこないのかな。
5.4 継続的デプロイと継続的デリバリ
全体的になつかしい感じだったが、たしかに継続的デプロイを喧伝している人はいるかもしれないが、そこまでいるだろうか?っていう気もした。たいていは継続的デリバリーの話をしている気がする。
5.5 機能フラグ
継続的デリバリと機能フラグはきっても切り離せないんだよなーっていう。ほとんどの場合において機能フラグは継続的デリバリの必要条件な気がする。
一方でその難しさってほんとうにありふれているよなともおもう。先日の牛尾さんの記事もそうだったなと。
→ 機能フラグのコード例がハードコーディングされていて、このままコミットするのはためらわれる感じかな……と思いました。ライブラリなどを使うことで綺麗にできるものでしょうか。
SaaSとかOSSとかありますけど、SaaSは結構値段高いなーていうイメージです。いっぽうでABテストサービスとあわせてあるとかふくめてならまぁいいかとかおもったりも。
5.6 パイプラインの実行
世の中でCIが誤解されてきているっていう筆者の主張はめっちゃかんじるわ。。。
5.7 テストインフラの管理
私はテスト環境は運用チームが所有するべきだと提唱しています。
納得しました。
5.8 DevSecOps
最後の味付けとしての品質というアンチパターンは、DevSecOps を語る上で非常に役に立ちます。なぜならほとんどの組織では、プロジェクトの最後にセキュリティのチェックを行っているからです。
本質だ……
まずは、自動化してビルドやテストパイプラインに統合できる、基本的なセキュリティ監視ツールに時間とエネルギーを投資する必要があります。
自動化が大事だ……というこの本で繰り返されていることがまた出てきましたね。
設計プロセスの初期段階でセキュリティチームに参加してもらうことで、実行面と安全面の両方で組織のニーズのバランスが取れたソリューションを共同で開発できます。
理念としてはよくわかるのですが、具体的にどういう相談をするのか、イメージがわきづらいところがありました。(Jim Bird
著 “DevOpsSec”(O’Reilly、2016 年)や Julian Vehent 著 “Securing DevOps”(Manning、2018 年)を読むべし……ということでしょうね)
なにかの機会にチラッとよんだりとかしたいですね。アジャイルなセキュリティみたいな。
やりたいことはリスク管理であるっていうのめっちゃわかるなーっておもいつつ、自分はセキュリティチームとがっつりと話したことがあんまりないので、もっと近寄って行こうってあらためておもった。
5.9 本章のまとめ
いいことしか書いてない!!
みんなからのコメント
実践する/伝えるためのハードルはなにか?
ツールに普段からなれていないと、導入が大きなステップになってしまうとか
導入した後にスキル高い人が関わり続けることができないとか
「改善に使える時間がない」という意見
一緒に使うと良さそうなプラクティスやマインドセットはなにか?
XPのBaby Step
勉強会
👍️
ペアプログラミング
ハードルの乗り越え方はなにか?実践/伝える方法はなにか?
発生してしまった障害の対応時に少しづつ取り入れる?
やりやすいところからでも実践する(あるべきよりも実践しやすいところから導入して練習する癖をつける)
♥️
計測して問題に気付いてもらう
計測していなくても、問題があることには気付けるはずだけど、気付いていない人に伝えるには……という観点
どれくらい効果がありそうか?
すごくある……というか必須な気がする
学習時間が必須になっていくのがいいきがする。一定のハードルを超えた人しか入れないプロダクトっていうか。
何もない状態に比べると、バグを発見するスピードは体感で10倍くらいかなぁ。