1月25、26日の2日間にわたって、東京、目黒雅叙園にて「ソフトウェアテストシンポジウム 2012 東京」（⁠JaSST '12 Tokyo）が開催中です。

例年のように海外からテスト著名人を招聘して基調講演が行われる同イベントですが、今年はMicrosoftで長年テストチームを率いてきたBj Rollison氏による「How We Test At Microsoft－マイクロソフトでどのようにテストをしているのか？」と題した講演が行われました。

超巨大開発現場で起こっていること

Microsoftでは全世界で9800名の常勤、社員テストエンジニアが働いています。開発者とテスターの全社比率は1対1＝開発者一人にテスター一人という体制です。「⁠ただ内部ではばらつきがあり、開発グループによっては開発者の方が多かったり、逆にテスターの多い職場もあります」（⁠Rollison氏⁠）⁠。

この体制で、年間1500万のバグが発見され、1日に500回ビルドが行われます。「⁠テスター一人当たりのバグの数なんか計算しないでくださいよ（笑⁠）⁠。これだけのバグに対処するには、『⁠トリアージ』が必要になります」（⁠Rollison氏⁠）⁠。つまり、バグに優先順位をつけて、より重要なものから対応していくことになるわけです。順位付けの判断基準は「どのバグが顧客に最も大きな影響があるか？」です。

また、バグをフィックス後のテストでは、バグフィックスが他の部分を壊していないかも見る必要があります。これを「プライオリティゼロテスト」と呼び、最も重視しているとのこと。このため、大規模で包括的なバグトラッキングシステムを導入しているそうです。

21世紀に通用するテスターの資質とは？

そしてこの体制を支えるために重視しているのは「テスターの質」です。Microsoftでは、2000年ごろからテストに対する意識が変わってきたと言います。「⁠世の中のITへの投資が活発だったころ、コンピュータやエンジニアリングの知識がない人もテスターとして大量に採用していました。バグを見つけるのは得意でも、テストを自動化したり、コードレビューやデザインレビューができない人がたくさんいたのです」（⁠Rollison氏⁠）⁠。Rollison氏は当時CEOだったBill Gates氏から、テストエンジニアの採用を見直すように提案されたそうです。「⁠Billはあまり指示や命令を出しません。提案するだけです⁠」⁠。

新たな採用にあたっての課題は“⁠エンジニアリングの持続可能性（Sustained Engineering）⁠”でした。「⁠つまりWindows 8を手がけながらWindows XPもメンテナンスしなけらばならない、小声で言いますがVistaも（笑⁠）⁠」⁠。以前のように大量に人材を採用できない中、質の高いテスターを確保するのに非常に苦労したそうです。「⁠コンピュータサイエンスの学位を取ったら普通はデベロッパになりたいですよね。テスターになってもらうよう説得するのは非常に難しかった」（⁠Rollison氏⁠）⁠。このため、コンピュータ以外の学位や、エンジニアリングだけではないバックグラウンド、資質をもった人にも手を広げて採用していったそうです。

採用の際には「バグを見つける」といったレベルではなく、「⁠会社や製品に対してどんなものを提供できるか？」を見極めるようにしました。その基準で見たテストエンジニアとしての価値とは、個々のプロジェクトや製品の問題だけでなく「ビジネスの進め方の問題」を見つけることだと言います。「⁠我々は“⁠消防士⁠”になりがちです。その場の火消しだけに対応しようとする。でも同じ問題がまた起こるのです。このスパイラルから逃れるために、同じ問題が起きいないようにビジネスそのものを見直さなければなりません。より高度な問題解決能力とクリエイティビティが必要になります」（⁠Rollison氏⁠）⁠。

管理職という“枷”

こうして採用した人材を活かすため、組織も変える必要があります。アジャイルな考え方、メンタリティが必要になってきた、とRollison氏は言います。ここで言っているアジャイルとは、ただ速く開発することではなく、“⁠変化に素早くきちんと対応できるか⁠”ということです。そのために重要なのはコミュニケーションです。メール、メッセージなどの非対面コミュニケーションの他、Face to Faceの打ち合わせも重要と言います。またこれはテストエンジニア同士だけでなく、デベロッパとテスターとの間にも必要で、そのために「開発のすべての要素に全員が関係する」フラットな組織作りが進められました。

さらにこうした組織作りは、構成員のキャリアパスにも影響を与えます。それまでは、キャリアを積んだテスターは管理職的な地位に就くという出世コースしかありませんでしたが、同社では2005年ごろに「テストアーキテクト」というポストを新設しました。これは高度な技術力が求められるポジションで、管理職的な仕事はせず、通常のグループとは独立して働くためディレクターの命令に従う必要もありません。その代わり、開発のエンジニアリングプロセス改善について責任を持つというものです。テストアーキテクトを設けてから、次々とクリエイティブな試みが提案されるようになったとRollison氏は言います。

またこのしくみは、優れた人材の流出を防ぐ効果もあります。「⁠管理職の枷（かせ）を外したことで、最高のエンジニアが離職するのを思いとどまらせる場合もありました。“⁠ブレインドレイン⁠”（頭脳流出）は今や深刻な問題なのです」（⁠Rollison氏⁠）⁠。

不具合は“より上流”で対処する

次にRollison氏はMicrosoftのテスト戦略について紹介しました。まず日常行っているブラックボックステストとして、探索的テスト、定義済みテストケース、GUI/APIの自動テスト、それにからめ、ユーザをリサーチして典型的な使い方のシナリオを作成し、自動テストに反映させているそうです。

これらに加えて、「⁠ドッグフーディング」「⁠セルフホスティング」と呼ばれる特徴的なプロセスがあります。ドッグフーディングとは、まさにドッグフードを食べるように、普通は食べないようなまずいものを毎日食べること、つまり毎日作られる最新のビルドを自分のマシンに入れて使ってみるというものです。「⁠責任ある者として、ユーザの痛みを感じるため、時にはメールやメッセージが動かないようなものを使います。そうすると、どれに優先して対応すべきかが見えてくるのです」（⁠Rollison氏⁠）⁠。

またセルフホスティングは、同じように最新のビルド自体でテストも行うことで、Rollison氏は会社のご自身の使うマシンにWindows 8を入れ、テスト作業を行う中、何か問題が起きた際にいつでも開発チームにレポートを送ることができるようになっているそうです。

より重要なのがホワイトボックステストで、ビルド前にデベロッパと打ち合わせてコードレビューやインスペクションを行うことで、実際にプログラムを動かす前に問題点を見つけるしくみができあがっているそうです。またカバレッジを上げるテストも常に実行され、解析ツールが整っています。

そしてこれらを維持するテストサイクルについては、「⁠常にテストは続いているので、サイクルをはっきりと認識するのは難しい」としながらも、どのテストを優先して行うかについては常に検討しているとのことです。振り返りも常に行っており「私は『死亡解剖』と読んでいますが（笑⁠）⁠、入社以来振り返りの作業は17年間ずっと続けています」と語りました。

そうした中で、作ったものをただ大勢の人に使って（テストして）もらう方法ではテストや開発の効率は上がらないと指摘します。できた後で不具合を見つけても、手戻りが発生してより多くの時間が費やされます。先に挙げたように開発前にバグの出そうなところを予測して、防止するほうが効率は格段に上がります。そのためには欠陥予防や、より上流での不具合予測ができるエンジニアリングを確立する必要があるのです。

テスト効率を上げるための工夫

Microsoftではこうした取り組みを支援するため、各種の自動化システムやツールが日々開発されています。たとえばどのテストを行うかという優先順位を判断するのにチャーンメトリック（churn metric＝前回ビルドから新たに変更／削除／追加されたコードの量）を指標としています。またゲームに特化した話では、ユーザがゲームのどこを最もプレイするか、といったデータを指標としています。こうしたツールを自動化システムと組み合わせて、効率的なテスト運用が可能となっています。

多くの便利なツールは社外に公開することができませんが、その知見や機能は最新のVisual Studioに反映されてきているそうです。「⁠開発者だけが満足できるツールだったのが、テストエンジニアの重要性に気づいてくれたのは嬉しいですね」（⁠Rollison氏⁠）⁠。

また、同種の不具合、同じ部分についての別の不具合を見つけやすくするという観点から、Microsoftでは全社で同じバグトラッキングシステムを使っていると言います。バグを見つけたら必ずそのシステムに入って報告することが義務づけられています。

同じように、社内のよく見える場所に設置されたモニタに、そのとき行われているテストの結果が刻々と表示されるシステムもあります。テスターのみならず、開発に関わる全員がすぐに目を通す体制ができあがっているのです。

また、継続的な修正の一環として、よくWindowsを使っていてエラーが出た場合に表示される、Microsoftへのエラー報告のダイアログについての説明がありました。「⁠送信ボタンを押すと、あなたの銀行口座番号がMicrosoftに送られるんですが…冗談です（笑⁠）⁠。あれはエラー時のメモリダンプ情報を送るもので、送られた情報は同じエラーごとに“⁠バケツ⁠”に入れられます。バケツの項目が溢れるとバグフィクスマネージャ送られ、対応待ちとなります。ですから、直して欲しい不具合があるときは、エラー時に送信ボタンを押せばそれだけ対応が早くなるのです」（⁠Rollison氏⁠）⁠。

情報の選択とそのポイント

Rollison氏はまとめとして、テストを取り巻く状況の変化、それに対応する重要性を説きました。GUIの発達で、テストの複雑化にも拍車がかかっています。日々のルーチンに追われて「燃え尽きてしまう」テスターも問題になってきました。これに歯止めをかける意味でも、テストの効果を上げ効率化する『トリアージ』やより上流での不具合予測を追求する必要があります。テスターに新しい刺激を与えて、仕事が伸びている実感を持たせるためにも重要といえるでしょう。

また、自動化されたテストにより膨大なデータが集まるようになりました。これらのログや指標をすべて使うのはかえって無駄だと言います。またデータの集めすぎにも注意が必要です。ではどのような指標に注目すべきでしょうか？「現在はすべてのソフトや機器、そして開発者、顧客が連携していることを考えなければなりません。『⁠コネクティッド・カルチャー』なのです。顧客がどのような組み合わせで、どういうデータを使っているのか、それを考えると、どこに注目すべきなのか、おのずとわかってくることでしょう」（⁠Rollison氏⁠）⁠。