テストから見えてくるグーグルのソフトウエア開発 メモ
書籍の内容から自分が使えそうなところ紹介です。
テスト関連の書籍を読み始めた背景
ServiceNowというPaaSをカスタマイズ（開発・・かな）するチームにいるのですが、どうもテストの範囲や粒度がつかめんなぁと思っています。
特にバージョンアップの時。半年1回大きなリリースが入りますが、その時に問題ないかチェックする・・チェックってどこまで？？？ってなります。全然使えなくなっているはずはないと信じて進むのですが、翻訳違いを見つけたり、思わぬところが動かなくなっているのを発見したり、値がコピーされなくなっていたり。といっても全カスタマイズの単体テストからやり直すのも時間的にありえないでしょうと・・。
ソフトウェア品質知識体系ガイドとかも今後見ていきたいと思っていますが、先に面白そうなグーグルのテストの紹介の本です。
グーグル社の開発の規模(2011年ころ）
- 毎日数百万のソースファイルに数億行のコードを詰め込んでリリース
- 毎日数十億のビルド操作
- 毎日数百万の自動テストが数十万のブラウザーで実行される
- ウェブアプリケーションはほとんど連続的にリリースされている
- エンジニアリングプロダクティビティチームには約1200人の精鋭エンジニアがいる。
エンジニアリングプロダクティビティチームって？
- ソフトウェアテストを縄張りにしているチーム（直轄部門）
- フォーカスエリア（広告、アプリ・・などのビジネス単位組織）にまたがる組織横断型の独立組織。
- 開発者とテスターが使うツール、リリースエンジニアリング、安泰レベルのテストから探索的テストまでの様々なテストを担当。
- テスターは、開発者の生産性を引き上げることを目的にしている。
- 以下に紹介するSET、TEが所属している。
- SET、TEは、フォーカスエリアのプロジェクトに貸し出される。
- この製品の品質は大丈夫です！とお墨付きを与えたり、バグが出たときに謝るチームではない。
Google用語
- SWE ソフトウェアエンジニア：従来の開発者。製品のオーナーとして品質に責任を負う。テストをするのは当然。
- SET ソフトウェアエンジニアインテスト：テスト機能を提供する開発者のひとつ。設計をレビューし、コードの品質とリスクをチェックする。コードのリファクタリングもやる。単体テストフレームワークも作るし自動化もする。SWEのパートナー。SWEが積極的にテストケースを書けるようにする。品質とテストカバレッジの向上に力を注ぐ。
- TE テストエンジニア：第一にユーザーのため（製品がユーザーのニーズを満たせるかどうかたしかめるため）にテストを推進する。全体的な品質チェックを組織し、テスト結果を解釈し、テストの実行を指揮してエンドツーエンドのテスト自動化を行う。製品のエキスパートであり、品質のアドバイザー、リスクの分析者。コードを書く人も書かない人もあいる。契約テスター、クラウドソーステスターなどを動員するのもTEの仕事。成否にゃサービスを全体的にみて最もリスクの高い分野を探し出して力を貸す。途中からプロジェクトに投入されることも多い。
- Sテスト：1つの関数またはモジュールの機能をチェックする。データ破壊、エラー条件、off-by-oneエラー)（境界条件の判定）などをチェック。モックやフェイクを使う。
- Mテスト：たがいに呼び出しあったり、直接やり取りしたりする関数の相互作用を確認する。SETが主導。
- Lテスト：3つ以上の機能から構成され、実際のユーザーが使うシナリオを表現し、実際のユーザーデータソースを使う（本番環境で行う）テスト。TEが主導。
TEの立案するテストプラン
（「ユーザーが利用可能か確認」というキーワードから、自分が一番興味があるポイントなのでここだけクローズアップ）
TEの仕事に「テストプランを立案する」がある。
理想のテストプランとは・・・
- いつも最新の状態を保っている
- ソフトウェアの意図、ユーザーがソフトウェアを愛する理由を記述している
- ソフトウェアがどのような構造になっているか、さまざまなコンポーネントや機能にどのような名前が付けられているかを示すスナップショットを含んでいる
- ソフトウェアが何をすべきか、どのようにして実現するかの概要を記述している。
- 作るのに長時間を必要とせず、すぐに書き換えられる
- 何をテストしなければならないかが書いてある（テストケースを導くことができる）
- 進歩の度合いや、カバレッジのギャップをわかりやすくして、テスト中役立つ
上記のために、ACC（アトリビュートコンポーネントケーパビリティ）分析が導入された。
Googleテストアナリティクス
Google Testing Blog: Google Test Analytics - Now in Open Source
として自動化されている。
- A アトリビュート： 製品の存在理由。競合製品から区別するための性質や特徴。セキュア、安定、エレガント、無料、便利、正確、高速、共有、簡単、拡張性、プライバシー、表現力など。
- Cコンポーネント ：製品の機能のかたまり。システムがよほど大規模でない限り、10ならよいが20では多すぎ。小さなものは省略してよい。オンラインストアなら「カート」「精算機能」などで、ワープロなら「整形」「印刷」など。
- Cケーパビリティ：ユーザーに提供される機能。ユーザーのコマンドを受けたときにシステムが実行する動作。Chromeなら、ウェブページのレンダリングや、Flashファイルの再生など。オンラインストアなら、カートの商品追加・削除、送料の計算など。最も大切なのは「テストできること」
＃コンポーネントは、製品のアトリビュートを満足させるために何らかの仕事を行い、その仕事の結果がユーザーにケーパビリティとして返される。
サンプル：Google＋のACCスプレッドシート例
- 縦方向に、コンポーネントを並べる。 プロフィール、人、サークル、通知、ポスト、コメント
- 横方向に、アトリビュートを並べる。ソーシャル、表現力、簡単、適切、拡張性、プライバシー
- それぞれのセルに、ケーパビリティを書く（一つでも複数でも）
- それぞれのセルで、リスク分析を行う(頻度×インパクト）
ちなみに上記3では以下のような書く。
- プロフィール×ソーシャル ： 友達、知人らとプロフィールを共有する
- プロフィール×プライバシー：プライベートデータを非公開に保つことができる
- プロフィール×プライバシー：承認した適切な人々とだけデータを共有する
それぞれのセルのリスク判定結果で色をぬれば ヒートマップが完成。
高いところから順にテストを行っていく。
自動化や、テストのレポートのためのツール
・Autotest
・BITE バグ登録を効率化、Chromeエクステンション
Google Testing Blog: Take a BITE out of Bugs and Redundant Labor
・QualityBots 複数リリースChrome間でのピクセルベースDOM分析
Google Testing Blog: Unleash the QualityBots
・RPF（Record/Playback Framework）
Google Testing Blog: RPF: Google's Record Playback Framework
所感
- 2012年（日本での発刊は2013年）なので、ツールだとか情報が古そうで、アップデートを探し出す必要があると思う。
- ACCで機能の優先順位をつけるのはいいかもしれない、、すべてをテストできないなら、重要なところからやります、って言えばいいのだから。。
- ジェームズ・ウィテカーのインタビューの中に、グーグルのテストのマジックの４つの秘訣としてあげられているのが「１．テスターのスキル（コンピュータ科学の学位を含む）、２．デベロッパーがテストを書き、テスターが仕事を最適化する強制的な要因となっているテスターの人手不足、３．自動化優先（コンピュータが得意でないことだけを人間がやる）、４．速いイテレーションとユーザーからのフィードバックのスピーディーな統合」・・・人手不足もひとつの鍵とは、、、そこだけは真似できそうだ。
- 本としては、話があっちこっち、技術になったりマネジメントになったり採用になったり、目まぐるしい印象。カバー範囲は広いから、興味のあるところだけ読むのがいいんじゃないでしょうか。
- 日本のゴリゴリ品質管理も調べてみて、違いを見るのが楽しみ・・といって自分を鼓舞します。ふー
