マイクロソフトの責任者が語る「われわれはどのようにソフトウェアをテストしているか？」 JaSST'12 Tokyo

ソフトウェアのテストに関わるエンジニアが集まる国内最大のイベント「ソフトウェアテストシンポジウム JaSST'12 Tokyo」が1月25日、26日の2日間、都内で開催されました。

10周年を迎えた今回のイベントの基調講演を行ったのが、開発しているソフトウェアの規模、分野、種類において世界最大の企業、マイクロソフトのプリンシパル テストリードのBj Rollison氏。

「How We Test At Microsoft（マイクロソフトでどのようにテストをしているのか？）」という題で、同社がどのようなソフトウェアテストを行っているのかを中心に講演を行いました。講演の内容をダイジェストで紹介しましょう。

開発者とテスターはほぼ同数

マイクロソフト プリンシパル テストリードのBj Rollison氏。

マイクロソフトはワールドワイドで9800人のテスターがいて、開発者とテスターはほぼ同じ、開発者一人にテスターが一人という割合。

年間で1500万個ものバグが見つかり、1日に500以上ものビルドが作られている。

これらのテストを行っているテスターはどんな人たちなのか？ コンピュータサイエンスや電子工学の卒業者を採用しているが、そういう人はみな「デベロッパーになりたい」と考えているため、テスターになるよう説得しなければならないことが多い。

ソフトウェアテスターに望む資質は、単にバグを見つけるのではなく、ビジネスに対して価値を提供すること。

実はバグはビジネスの中にたくさんある。消防士のようにその場の火を消しても、3カ月後にはまた同じ問題が発生する可能性があるならば、それを二度と起きないようにする。それが実現できれば、次の大きな問題に対処できる。

そういうことができる人を採用するために、問題解決能力やクリエイティビティを求めており、いろんなインタビューをする。

そしてアジャイルなメンタリティ、変化に対応できる人が業界全体で求められている。マイクロソフトではテスターもデベロッパーもイコールパートナーであり、開発プロセスに関与できる。

開発者としてのキャリアでありがちなのは、昇進すると何らかの管理職に就かなければならないことだ。しかし開発者として優秀でも、マネージャになりたくない人、向かない人はいると思う。

マイクロソフトには「テストアーキテクト」というポジションがある。これは管理職としての仕事はしない。開発のエンジニアリングプロセスの改善に責任をもっている。テストアーキテクトになるにはバイスプレジデントの承認が必要なため、なかなか簡単にはなれないが、こうしたキャリアパスがあることで優秀なエンジニアを引き留めることができている。

テストで重要なのはシナリオ、そして欠陥予防

マイクロソフトではどういうテストを行っているのか、説明しよう。

ブラックボックステストでは、探索的テスト、事前定義テストケース、テストの自動化はAPIとGUIのどちらでも行っているが、GUIの自動化はつねに保守をしなければならないため難しく、やっかいだ。

テストで重要なのはお客様の利用シナリオだ。どの製品であってもシナリオから始まり、フィーチャー（機能）を設計、開発していく。開発サイクルでは継続的にシナリオに当てはめ、バグフィクスの優先度を決める際にもシナリオを重視している。

また、日々のテスト以外に「ドッグフーディング」を行っている。私たちは毎日、ビルドしたばかりの開発中のソフトウェア（これがドッグフードにあたる）を使う。例えば自分のスマートフォンに開発中のWindows Phoneを入れるとメッセージが受信できなかったりするが、私は責任者として開発チームに参加しているのだから、日々の痛みを感じる必要がある。製品チームはこのことを通して、どのバグをまず直すべきなのか理解できるのだ。

ホワイトボックステストでは、コーディングが始まる前の設計時やコードレビューにも私たちは組み込まれ、コードを動かす前から問題点を見つけることができるようになっている。

テストが機能しているかどうかの評価指標としてデータカバレッジ分析、コードカバレッジ分析などを行い、そのためのツールも用意されている。テストの優先順位をどうすべきか、テストを設計し、導入し、測定し、分析をすることを繰り返す。いつも振り返り、レトロスペクティブを行い、時間をかけてよりよくしていくということがずっと続いている。

マイクロソフトの会社全体を通じた戦略は、コードや製品ができてから品質のチェックをするのではなく、より早い段階で関与し、バグの発生を抑える。バグをあとから取り除くのではなく、最初から押さえ込むというものだ。

つまり欠陥予防、川上における質の向上が重要だ。これはアジャイル開発と整合性のある考え方であり、マイクロソフト全体で取り組んできたことだ。

テスト自動化のモデル

社内のテストツールの多くはテスターによって開発されたものだ。テストを効率的、効果的にするには何が必要かは、テスター自身がいちばん分かっているためだ。

そうした社内で使っていたツールがVisual Studioにも組み込まれるようになる。これまでVisual Studioは開発者向けにフォーカスしていたが、ソフトウェアライフサイクルの中でテストの重要性が増してきたということ。

そしてこれが、マイクロソフトにおける悪夢のようなテスト自動化のモデルだ。

テストデザイナーによる自動テストコードは日々のビルドに組み込まれる。

テストケースマネージャは、ビルドシステムから、どういったビルドがされたのか、どんなテストが実行されたのか、といった情報を得る。バグが修正されたら、どのバグに対する修正なのか、といった情報も得る。

そして、テストケースマネージャがすべてのコードをテストコントローラに送る。

テストコントローラがテストラボ内のマシンのコンフィグレーションを行う。自動テストを実行するためのパラメータを設定し、仮想マシンのイメージを作り上げ、そして実行を行う。

ログファイルをチェックする人はいない。結果は自動的に分析が行われ、アノマリーをここで見つけるのだ。

日々のテスト結果は、社内に大きなモニタがあってリアルタイムで表示されている。開発チームのメンバー誰もが簡潔に状況を知ることができるようになっている。

日々の生活の中でのテスト

「Day in the life Testing」（日々の生活の中でのテスト）もしている。製品の各機能はシナリオに基づいているが、往々にして起こるのは全体としての体験シナリオになっていないことだ。

それを改善するためには新しく楽しいことをしなければと、人々が普段どういう形で電話を使っているのか、メッセージのやりとりや写真を撮るなどいろんな活動にあたる宝探しのようなゲームを作った。

Kinectのチームでは、テストのために踊ったりマラソンしたりと、いつもゲームで遊んでいる。

これからのテストの課題

私は将来的なコンピュータパラダイムのことをよく考える。

いま、PC、スマートフォン、タブレット、ゲームといったものは個別の存在となっているが、これらはすべて連係しはじめていることを考慮しなくてはならない。

例えばXBoxはネットとスマートフォンから情報を取り入れてテレビに表示したりできる。クラウドにアップロードされた写真をピクチャーフレームで表示できるようにもなった。

つまり、テストすべきものがどんどん複雑化してきている。

クラウドのテストは、OSをテストするのとは大いに異なるし、ゲームやアプライアンスのテストもまた異なる。そしてこれらを結びつけるシナリオ、お客様がこれらをどう使うのか、データがどうやりとりされるのかも考えなければ行けない。

これらの課題を考えることによって、テストのプロフェッショナルな面をこれからも前に進めていかなければならないと考えている。

（続いて、会場との質疑応答の記事「マイクロソフトでは「開発プロセスのすべてにテスターが関与している」 JaSST'12 Tokyo」へ）

関連記事

グーグルにおけるソフトウェアテストについて、以下の記事で紹介しています。

• グーグルはあれほど多くのソフトウェアのテストをどのように行っているのか？
• 開発とテストの融合こそゴール。続、グーグルはあれほど多くのソフトウェアのテストをどのように行っているのか？
• グーグルが行っているビルドとテストの種類。続々、グーグルはあれほど多くのソフトウェアのテストをどのように行っているのか？
• プログラマーにとってのテストの重要性

ソフトウェアテストシンポジウム JaSST'12 Tokyo

• マイクロソフトの責任者が語る「われわれはどのようにソフトウェアをテストしているか？」 JaSST'12 Tokyo
• マイクロソフトでは「開発プロセスのすべてにテスターが関与している」 JaSST'12 Tokyo
• みんなはどんなテスト技法を使っているの？ JaSST'12 Tokyo
• ソフトウェアテストの30年前と30年後（前編）～テストの根幹は30年前に書かれた JaSST'12 Tokyo
• ソフトウェアテストの30年前と30年後（後編）～30年後のテスト技術、期待を込めた予想 JaSST'12 Tokyo
• ソフトウェアテストの近未来を話そう（前編）～テストと開発の融合が必要 JaSST'12 Tokyo
• ソフトウェアテストの近未来を話そう（後編）～テストプロセスには魂が必要だ JaSST'12 Tokyo