【読書メモ】テストから見えてくるグーグルのソフトウェア開発
【読書メモ】テストから見えてくるグーグルのソフトウェア開発
この本のまとめ
品質管理はデベロッパーの仕事
- 品質は、設計段階から作り込むもの
- テストは品質そのものではない
- 品質は最初から組み込まれていなければならないもので、あとから付け足されるものではない
- 品質管理はデベロッパーの仕事だ
Googleのしくみ
- エンジニアはSWE/SET/TEの3チームに分かれている
- カナリア、開発、テスト、ベータ、リリースのステージを通過することで品質担保する
- S/M/Lの3種類のテストを実施する
- S：完全なフェイク環境でコードの1単位をテストする
- M：フェイク環境または実環境で複数の相互作用するコード単位をテストする
- L：フェイクを使わず、実際の本番環境で、任意の個数のコード単位の塊に対して、実際のユーザが使うシナリオをテストする
品質の作り込み
- 設計ドキュメントのレビュー
- 記述に不完全な部分がないか
- 特殊な知識を必要とする部分がないか
- ずさん・雑な記載がないか
- 与えられたリソースで実現できるか
- 設計が複雑すぎないか、単純化できるか
- 設計が単純すぎないか
- 製品が使うプロトコロルが明確か
- どのようにテストできるか
- 設計を工夫してテストが楽にならないか
- コーディング
- 既存のライブラリを再利用すること
- 読みやすいこと
- 将来読んだり書き換えたりしやすいこと
- 複雑さや巧妙さよりも、再利用できることをはるかに高く評価する
- よりよい方法を思いついたらすべてのライブラリをリファクタすること
- コードレビューを真剣に行い、「読みやすさ」を他人にレビューしてもらうこと
- コードレビュー
- Googleは、コードレビューを開発の中心に置いている。
- コードを書くことよりも、レビューすることの方がずっと大切なこととして取り扱われる
E2Eの自動化にこだわりすぎると、テストは特定の設計に縛り付けられ、役に立たないものになりがち
製品の品質を向上させるために使うはずだった時間を、ずさんなE2Eテストスイートのメンテに使う羽目になる
テスト計画
- 理想的なテスト計画を実現できたものはGoogleにもほとんど存在しない
- 現実的には、ACC分析を行う
- 短時間で、書き換えやすく、テスト対象が書いてあって、進捗の度合いがわかりやすい
やっているのが「テスト」だから
品質はコードを書く人の責任
Googleのエンジニアたちは、機能の数よりも品質をとる
品質≠テスト
テストをすることが品質を担保すること、ではない デベロッパーは、プロダクトのオーナーとして品質に対して責任を負う
設計段階から品質が組み込まれていなければ、製品は決してまともなものにならない
コードレビューでは、テストコードも必ずレビューする
コードレビューでかならず「テストはどこか？」と質問する
組織
テスト自動化は、実際にはそれだけで1つのソフトウェア開発の仕事 テストコードが役立つのは、開発を加速する形で実行できる場合だけ 開発がスローダウンするのでは意味がない テスト開発は、開発の一部であって、開発から切り離してはいけない 機能コードは孤立して存在し得ない、テストコードも同様
TE
開発が中止される可能性が十分にある場合や、ユーザの関心をまだ惹きつけられていない場合、 機能セットの敵がまだ明確でない場合は、テストは主としてコードを書いている人が行うべきもの 製品が出荷されることが確実でも、機能がまだ流動的だったり、開発の初期段階では、TEがすべきテストはほとんどない
TEが判断すべきこと
- ソフトウェアの弱点はどこにあるか
- セキュリティ、パフォーマンス、信頼性、ユーザビリティ、その他懸念されることは何か
- 主要なユーザシナリオが想定通りに動作するか
- 他の製品と相互運用するか
- 問題が起きた時の診断の品質は十分なものか
ACC分析
ACC=アトリビュートコンポーネントケーパビリティ
Googleテストチームのベストプラクティスをまとめ、様々な製品分野の同僚たちが開拓したプロセス
ACCの指導原則
- 文章を書き連ねず、箇条書きにする
- 売り込まない
- 飾らない
- 行動につながらないことを含めない
- 流れを作る
- プラン立案者の思考を導く
A：アトリビュート＝属性
- 製品が、ユーザや会社にとって重要なのかはなぜか
- 製品と特徴として、競合製品から区別するための性質や特徴
- ユーザが、競合製品ではなく、この製品を選ぶ理由
Chromeであれば、速くてセキュアだ、とか。これがテストされないと意味がない
C：コンポーネント＝部品
- ソフトウェアを構成するのに必要な部品は何か
- 列挙する際の粒度が大事、10ならよいが20なら多すぎる、小さなものは省略してよい
- コンポーネントをリストアップするのに苦闘するようなら、担当する製品のことを知らなすぎる
- すぐに時間を割いて、パワーユーザレベルに達するように製品を使うべき
- リストが完全かどうかは気にしてはいけない
- ACCプロセス全体は、素早く仕事を片付けること、必要になったら作業を繰り返すこと、を基本方針としている
C：ケーパビリティ＝機能
- ケーパビリティは、入力に対する応答、クエリーに対する回答であり、ユーザのために実行される王佐
Chromeであれば、WebページをレンダリングしてFlashを再生する、とか
ACCのポイント
- ACCのポイントは、システムの中で最も重要でチェックが必要なケーパビリティを、重要なものから順にリストアップすること
- ケーパビリティで最も大切なのはテストできること
- 個々のケーパビリティが正しく実装されていて、ユーザが役に立つと感じられるようなエクスペリエンスになっているかどうかを判定するためにテストケースを書く
- ケーパビリティは、テストケースとは異なる、実際の値や特定のデータは含まない
