今後のテスト

「テストの未来」と題されたジェームズ・ウィッタカーによる一連のノートの翻訳の継続。 このシリーズは元々2008年の終わりに公開され、その中で、ジェームズはテスターの仕事が10〜20年後にどのように見えるかについて多くの予測をしました。 彼の予測は、ジェームズが当時働いていたマイクロソフトで開発され、引き続き開発されているアイデアに基づいています。



この翻訳では、シリーズのすべてのメモを8つのパートで構成される1つの記事にまとめました（最後の4つのパートはこの投稿にあります）。

1. 「テスト」
2. 仮想化
3. 情報
4. テストをトップに移動
5. 可視化
6. テスト文化
7. デザイナーとしてのテスター
8. リリース後のテスト

5.可視化

コンピュータプログラムはどのように見えるでしょうか？ 開発やテスト中に使用できるプログラムを視覚化すると便利ではないでしょうか？ 一見すると、製品のどの部分がまだ不完全であるかが明確になります。 依存関係、インターフェイス、およびデータは理解しやすくなり、できればテストしやすくなります。 少なくとも、開発中に製品がどのように成長および開発するかを観察し、テスト中に入力データがどのように処理され、環境とのやり取りがどのように行われるかを観察できました。



他のエンジニアリング分野には、このような視覚化があります。 車を作る人を連れて行ってください。 組立工程に関係するすべての人が車を見ることができます。 バンパーまたはステアリングホイールがまだ車に取り付けられていないことがわかります。 彼らは、空の箱からフル機能の製品まで、コンベヤー全体の組み立てを観察し、ディーラーに出荷する準備ができています。 完了まであとどれくらいですか？ さて、ラインの終わりまで20メートル！



車の組み立てプロセスのすべての参加者が製品の共通のビジョンを持っているという事実は非常に便利です。 各パート、各接続、各インターフェースは、あるべき場所にあり、あるべき場所にあるため、誰もが理解できる共通の用語を使用します。



残念ながら、これは私たちの世界ではありません。 私たちは、「完了まであとどれくらい残っていますか？」、「完了していないタスクは？」という質問に常に苦しめられています。 これは、21世紀のテスターが解決する問題です。



建築家と開発者はすでにそれを行っています。 Visual Studioには、シーケンス図から依存関係グラフまで、多数の図と視覚化が含まれています。 テスターはすでにこの問題を解決しています。 「帝国」の壁の内側には、Xboxでコード変更を表示するための視覚化システムが既に存在し（コードが変更されたオブジェクトはレンダリング時に緑色で強調表示され、テスト後にバックライトが消えます）、Windowsコードの十分にテストされていない複雑なセクションを特定します（カバレッジ率を示すヒートマップ3次元空間で実行されるコードとコードの複雑さにより、問題領域を検出できます）。 これらの視覚化は印象的で、美しく、テスターはテストが必要なものを一目で判断できます。



これらの視覚化をさらに必要としますが、このタスクには注意してアプローチする必要があります。 UMLおよびモデリングチームから提供された図をそのまま受け入れることはできません。 これらの視覚化は、私たちが遭遇する問題と一致する場合としない場合がある他の問題を解決するように設計されています。 既存の視覚化の多くは、設計者や開発者を支援するように設計されていますが、それらのニーズは私たちのものとは異なります。 テスターの観点から考える必要があります。 要件とコード、テストとインターフェイス、コードの変更とユーザーインターフェイス、コードカバレッジとコントロールを関連付ける視覚化が必要です。 テスト対象のアプリケーションを起動し、テストカバレッジまたはそれらが関与したテストの数を反映する強度でコントロールが「点灯」しているのを見るのは素晴らしいことではありませんか。 それとも、ネットワークの使用状況やリアルタイムのデータベース相互作用のアニメーショングラフを見るといいでしょうか？ ネットワークトラフィックまたはSQLクエリをすぐに表示できないのはなぜですか？ アプリケーション内に隠されているものの多くは見えません。それを表面に引き出して、プログラムの品質を改善するために使用するときです。



この問題は近い将来解決することができ、多くの賢い人々がそれに取り組んでいます。



これは明るい色のプログラムをテストしています。

6.テスト文化

数ヶ月前、私はマイクロソフトのリーディングスペシャリストの一人が行った講義に参加しました（ただし、おそらく優秀なエンジニアだったので、両者の違いを実際に把握していません）。 他のすべてのリーディングスペシャリストと同様に、彼は非常に頭がよく、同僚と一緒に行ったいくつかの新製品を開発するプロジェクトを発表したとき、何かが思いつきました。



どうやら、私はそれを自分の中に保持することができず、腎臓結石の人に時々起こることを連想させる表情が私の顔に現れました。 リーディングスペシャリストはこれに気づき（ちょうど私の隣に座っている女の子のようですが、私はそれについて話したくありません）、講義の後、私に近づきました。 これが私たちの会話の始まりです。



-ジェームズ、-（まあ、彼は私の名前を知っていました！）-私のプロジェクトや私が話した製品について、あなたは疑問を持っていることがわかります。 あなたの意見を聞きたいです。



-いいえ、製品またはプロジェクトに問題はありません。 私の疑いはあなたに関係します 。



-すみません。



「あなたのような人々は私を怖がらせます」と私は言いました、「あなたはすべての時間を新しい機能とその使用方法を夢見て、あなたはインターフェースとプロトコルを設計します。」 あなたは大切な人であり、人々はあなたに耳を傾け、あなたが夢見ていることをします。 しかし、あなたはテストについての手がかりを持たずにこれをすべて行います 。



そしてその瞬間、彼は正しいことをしようとしました-テスターに​​連絡して助けを求めました。 彼は製品設計の評価に参加するように私を招待しました。 それはまさに彼に期待されることでした。



しかし、これは絶対に必要なものではありません。



製品設計にテスターを関与させることは、まったく行わないよりも優れています。 しかし、それほど良くはありません。 テスターは、テスト容易性の問題に焦点を合わせます。 実装の可能性に関する開発者。 そして、誰が両方の側面を考慮しますか？ 誰が正しいのか、いつ妥協するのかは誰が決めるのでしょうか？ 誰も。 設計にテスターを含めると、わずかな改善しか得られません。 テストへのデザイナー（および他のすべての参加者）の関与は将来です。



真剣に、なぜプログラムを作成する人はテストについてあまり理解していないのですか？ そして、なぜこれを変えようとしなかったのですか？ たぶん私たちテスターは私たちの役割にあまりにも根付いており、今や私たちの知的王国の鍵を熱心に守っていますか？ テストは開発者が理解できないほど秘密と謎に満ちているのですか？ それとも、開発者は私たちのためにこの「あまり面白くない」部分を捨てて、今では当たり前だと思っているのでしょうか？



開発チームにテスターを含めることは役に立ちません。 それらも初期段階で関与します。 開発者とテスターの比率が1対1のプロジェクトがありますが、製造された製品はまだ十分に信頼できるようには見えません。 製品をリリースするテスターの数に対する開発者の数が明らかに「悪い」比率のプロジェクトもあります。 将来的には、役割の分離が機能しないことがわかると思います。 それどころか、この分離はテストの適用が遅すぎるという事実に寄与しており、その可能性を最大限に活用することは不可能です。



現在のテスト文化と役割の分離は悪質であり、正しい方法は役割を結合することです。 品質は全員の仕事でなければなりません。 トールキンの観点から考えてみてください： みんなを支配する1つの役割！



開発プロセスのすべての参加者がテストに関する知識を持っている世界を想像してください。 設計者はテストの方法を知っており、設計者はこれを知っており、開発者も遅れることはありません。そして、彼らはすべて、この知識を常に一貫して一貫して適用します。 これは、専用のテスターが存在する必要性を排除するものではありません-誰かが独立した意見を持つべきであり、それは単により良いテストにつながるでしょう。 開発のあらゆる段階で行われたすべての決定が適切なチェックの対象である場合、最終テストでは、今しか夢に見られないレベルの徹底を達成できます。 各プロジェクトの参加者がテストを理解している場合、複数の熱心なテスターが達成できることを想像してください！



このユートピアが現実になるには、テスト文化の大きな変化が必要になります。 テストは、プログラマーを卒業させるすべての教育機関のプログラムに含める必要があります。 開発者が専門的に成長するにつれて、テストトレーニングが停止するのではなく、より強力で洗練されたものになるはずです。 プロジェクトに関心のあるすべての人がテストを理解するレベルに到達する必要があり、テストの原則を彼らが行うすべてに適用する以外に選択肢はありません 。 ある日、これをサポートするツールが登場します。 ある日、私たちはテストできないプログラムを書くことができず、クールなテスターがこれを達成したのではなく、各プロジェクト参加者がそれに取り組んだために、その日の番になります。



テストは開発プロセスに遅れをとるにはあまりにも重要です。 テストの観点から重要な設計上の決定は、早い段階で行われ、その時点でテストを開始する必要があります。 また、品質を担当する唯一の専用の役割の手でテストを行うことはできません。 それどころか、すべての人にとって質の高い仕事をする文化的な変化が必要であり、テストの原則は私たちが行うすべてに浸透します。

7.デザイナーとしてのテスター

現代の世界では、テスターは主に最後の防衛線を占有しますが、これは仕事の評価やボーナスの配布中に認識されないことがよくあります。 深刻なバグを見つけた場合-予想どおり、それを見つけたはずです。 バグを見逃した場合、質問があります。 多くの場合、テスターはこのように扱われます。そうでない場合は無視され、そうでない場合はscられます。



しかし、すべてが変化しています。また、変化しなければならないので、それもすぐに変化します。 私の友人であるロジャー・シャーマン（Microsoftの最初の企業テストディレクター）は、テストを蝶になりつつあるイモムシと比較することで、この変化を説明しています。 ロジャーによると、テストから生まれるべきバタフライはデザインです。



そして、私は彼に反対することはできません。 開発プロセスの初期段階でテストとテスト手法が適用される場合、テスターの作業は検証よりもプログラムの設計に似ています。 実行可能コードだけでなく、 すべてのソフトウェア成果物の品質戦略の開発により注意を払います。 テストケースを実行するよりも、テストの必要性を特定することに多くの時間を費やします。 自動化を作成およびデバッグするのではなく、自動化を監視および評価します。 新しいテストを作成するよりも、既成のテストの状態を分析するのにより多くの時間を費やします。 私たちはデザイナーになり、私たちの仕事はより高いレベルの抽象化に上昇し、ライフサイクルの始まりに近づいていきます。



マイクロソフトでは、テストアーキテクトがこの役割を果たし、ほとんどのテスト作業はその方向に進んでいると思います。 前の6つのパートを読むと、この設計指向の役割を前面に出すために必要な変更を理解できます。



明るい未来のように見えますが、軟膏には間違いなくハエがあります。 問題の原因は、現在使用しているエラーの種類とテスト方法にあります。 ビジネスロジックエラーよりも、構造的なエラー（プログラム自体に関連するクラッシュ、ハング、および機能自体ではなく、内部デバイスに関連する欠陥）を探す方が良いと言っても過言ではありません。 しかし、私が話している将来、構造的なエラーを排除するための多くの技術的解決策があるでしょう。 これにより、テスターはビジネスロジックエラーを処理できるようになります。これは、私には思われるように、業界全体が組織的または体系的な方法で対処できない問題のカテゴリです。



ビジネスロジックのエラーを見つけることは、ビジネスロジック自体を理解する必要があることを意味します。 ビジネスロジックを理解するということは、お客様や競合他社とのより緊密な相互作用を意味し、ソフトウェアが機能する知識の領域に没頭することを意味します。開発サイクルの初期段階だけでなく、プロトタイプ、要件、ユーザビリティ、これまでにやったことのないように。



開発サイクルの初期段階での作業は非常に難しく、テスターに​​は関連する経験がありません。 成功するには、これらの新しい問題に直面する準備ができていなければなりません。新しい考え方、ユーザーや品質に対する新しいアプローチを習得する準備ができていなければなりません。



コンベアの最初の作業は、私たちが現在行っている作業とは明らかに異なります。これは、将来が現在になると、多くの多くのテスターが自分の場所を見つける場所です。

8.リリース後のテスト

これは、将来のテストに関する私の予測の最後の部分です。 前の記事をお楽しみください。 そして最後に、おそらく矛盾する予測の1つを保存しました。将来、ソフトウェア製品とともにテストコードを提供し、リモートで実行できるようになります。 私はすでにハッカーの笑顔とプライバシー擁護者のalreadyりを予見していますが、少し後でこれに戻ります。



Vistaがリリースされたとき、私はWindowsグループに所属していました。ある晩、自宅で8歳の息子に見せた方法を覚えています。 彼はコンピューターでたくさんプレイします（信じられるなら動作します）。彼はAeroインターフェース、サイドバーのきれいなガジェット、お気に入りのゲームが動作する速度（当時はLine RiderとZoo Tycoon）が本当に好きでした。 ）、本当に感銘を受けました。 私はまだ「彼が業界のブログを維持していないのはなんて残念なことだ」と思っていましたが、私はこのトピックから逸​​脱しています。



それで最後に、彼はすべてのテスターに​​恐怖を抱かせる質問を私に尋ねました：「お父さん、ここで何をしましたか？」



私は静かになりましたが、これは私にとっては珍しいことで、理解できない何かをつぶやきました。 8才の子供に、数か月間何かに取り組んだことをどう説明しますか（Microsoftで働き始めたばかりで、最後にVistaに参加しました）、実際には何もしませんでしたか？ 私はこの恐ろしい質問への標準的な答えでうまくやろうとしました（感嘆符は必須です、彼らは私の言葉に何らかの真実があることを私に確信させるのに役立ちます）：



「私は彼女を良くするために働きました！」



「彼女が働くように働くという事実は...私に感謝です！」



「もし私たちテスターがいなければ、それは社会に対する脅威になります！」



これらのステートメントの最後は、特に気に入っています。 しかし、それらはすべて同じように説得力がないように聞こえます。 長い間製品の開発を続けてきたのに、どうすれば貢献できるのか、エラーがないことを示すことはできません。



このアイデアが生まれたのはその瞬間だったように思えます。テストコードはプログラムと共に提供されるべきであり、リリース後も存在し続け、テスターがいない場合でもその作業を行うべきです。 これは、私と同僚に自慢できるものを指摘する機会を与える哀れな試みではなく、継続的なテストと診断を提供する方法です。 それに直面してみましょう、リリースする頃には、テストが完了したとは決して言えません。



すでにこれのいくつかを行っています。 Windowsの一部であるWatsonテクノロジー（おそらく、Windowsアプリケーションで「エラーレポートを送信/送信しない」というメッセージを知っています）により、操作中にエラーが発生した場合、すぐにエラーデータを収集できます。 次の論理ステップは、受信した情報を使用して何かを実行できるようにすることです。



Watsonは現在、エラーデータを収集し、関連するデバッグ情報をキャプチャしています。 次に、一部の貧しい仲間の開発者は、このすべてのデータを取得し、Windows更新プログラムで修正する方法を見つけ出す必要があります。 2004年には、これは革命的なアイデアであり、今でも関連しています。 数年後、これは時代遅れのアプローチとみなされるかもしれません。



その貧しい仲間が追加のテストを実行し、製品のリリース前に存在していたテストインフラストラクチャを最大限に活用できるとしたらどうでしょうか。 障害が発生した環境で修正をインストールし、回帰テストを実行できるとしたらどうでしょうか？ 運用環境に更新プログラムをインストールし、アプリケーションに自分自身の回帰テストを実行するよう依頼できるとしたらどうでしょうか。



彼は貧しい奴ではありません、それは確かです。 しかし、製品の最終的な組み立てと納品後にテストとテスト成果物が失われるため、これは不可能になりました。



このような機能を実現するために、アプリケーションは予備のテストデータを保存し、常に手元に置いておく必要があります。 そしてこれは、自己テストの可能性が将来のソフトウェアの主要な機能の1つになることを意味します。 私たちの仕事は、「マジック」テストを製品自体に組み込む方法を見つけることです。 そして、私たちの報酬は、製品の第一級の特徴が私たちが設計したものであると子供たちの目がどのように輝くかの喜びです！



そうそう、ハッカーとプライバシー擁護者について：恐れるな！ ヒュートンプソンと私は、テストコードを配信に含めることについて長い間警告してきました（ソフトウェア保護のハッキング方法の本の攻撃＃10の章を参照）。 ハッキングの方法を知っているので、正しくハッキングするチャンスがあります。

おわりに



同僚は、ジェームズが表明したアイデアに同意しなくても、1年後、2年後ではなく、半世紀後にテストで何が起こるかを考えてください。 今、この未来の構築を開始する必要があります。 そして、私たちはあなたと一緒にそれを構築しますので、それは私たちがそれを行う方法になります。



James Wittakerの予測のより詳細なバージョンをご覧になりたい方は、GTAC会議でのスピーチの記録と、 uTestウェビナーの記録をご覧ください 。