ホワイトペーパー テストを変貌させた自動化 コベリティ開発チーム、テスト自動化への道のり Andreas Kuehlmann コベリティ研究開発担当シニア・バイス・プレジデント 競争激化、短縮する納期、差別化されたセキュアで高品質な機能を絶え間なく求めるソフトウェア開発市場で、 ビジネスを成功させるためは、人、 プロセス、技術が大切です。 また、 「ドライバーズシート」に座り続け、機能提供 の短期的価値と製品を効率的に拡大・維持する長期的能力とのバランスを常に取り続けることが成功の鍵に なります。当社の経験では、 テストをできるだけ自動化し、 テストと機能開発とをインターリーブするのが、 この業界 で成功するためのきわめて重要な要素といえます。 コベリティは、今も組織変革の最中です。 それは、 マニュアル 作業による品質保証 （QA） をアウトソーシングしていた組織から、開発段階から自動化されたコードテストを実行 する組織へと生まれ変わるための変革です。 この変革のためには、QAチームのスキルセットの変更や、新たなプ ロセスの採用、 テスト開発に集中するための新技術やソリューションによるイノベーションが必要でした。 テストを変貌させた自動化 ソフトウェア開発は比較的歴史が浅いエンジニアリング分野 ホワイトペーパー です。アジャイル開発プロセスで、機能に対する「受入れテ です。また、高品質でセキュアなソフトウェア製品を持続的か スト」の実施をデベロッパーに義務づけ、このテストに合格し つ予測可能な方法で提供する製造プロセスを求める企業ニー なければ次の段階の作業に進めないようにすれば、開発とテ ズが高まりつつあることから、開発手順もまだ進化の過程にあ ストがより連動した細やかなステージゲートが得られます。し ります。ソフトウェア開発方法論の「ウォーターフォール」か かし、そうしたテストの適切性を示す計測可能な基準がない ら「アジャイル」への進化に関しては、手順の様々な詳細に ため、どの程度徹底したテストを行うかが主観によって決定さ ついて多くのことが語られてきました。チームのミーティング れがちです。そのため、 「正常系」で機能が問題なく実行でき を 「スタンドアップ」 、 2 週間ないし 4 週間に設定した期間を 「ス れば、それだけで機能を受け入れてしまいがちです。 プリント」と呼ぶことが本当に重要なのかといぶかしく思う人 もいるでしょう。しかし、 「コードを書きながらテストを行う」 現在のソフトウェア開発組織の多くは、製品開発期間を短縮し、 製品の納期を前倒しするために、多かれ少なかれ、アジャイ という「アジャイル」哲学の基本方針に疑いを持つ人はいま せん。 ル開発を採り入れています。しかしそうした組織の多くが、求 められるほど迅速に高品質ソフトウェアを構築できないでいる 大規模な品質保証（QA）組織の存在そのものによって、開発 のが現状です。本稿では、製品開発の加速へと至るコベリティ チームはテストの責任を免除されているように見えるかもし 開発チームの旅路、すなわち、コベリティがいかにしてテスト れません。デベロッパーは自分たちが作成するコードの品質 の自動化を進め、より高品質なソフトウェアがいつ納品される に関して報告責任を負うべきだという考え方が昔からあるこ かを予測できるようにしてきたか、をお話しします。特に見直 とを思えば、品質だけを担当する QA チームを別に設置する しが必要だった 2 つのテスト分野、当社のイシュー・マネジ ことを疑問に思う人もいるでしょう。確かに品質をエンドユー メント・コンソールである Coverity® Connect の機能テス ザーの偏見のない全体論的視点から捉えるには、開発プロセ トと、製品全体のエンド・トゥ・エンド・テスト・プロセスを スから独立した QA チームが必要です。このような独立した 中心に説明します。また、過去 2 年間における変革を詳述し、 エンド・トゥ・エンドのチェックポイントは、高品質製品を出 今後開発する技術についての概要もお伝えしようと思います。 荷するための重要なステージゲートになります。しかし、開発 プロセスの初期段階に検出すべき低レベルのバグが後工程で 発見されたために、QA チームの作業ペースが大幅に鈍ること コベリティ開発チームの旅路 がよくあります。このようなバグにより発生する QA チームと ウォーターフォール・プロセスの要素と、２週間のスプリント 開発チーム間の反復作業には、次の 2 つの重要問題を生じさ で機能構築を行うスクラムなどのアジャイル・プロセスの要 せます。まず、この反復作業がいつ収束するのかが予測困難 素の両方を採り入れた、コベリティの製品リリースサイクル なために、望まれる品質レベルの製品をいつ出荷できるか判 は 6 ヶ月です。リリースサイクルの最後の 6 週間は、 「フィー 断できないことです。次に、長い潜伏期間をもつ反復作業が チャーフリーズ」 （機能追加の凍結） 、 「インテグレーションフ 頻発することによって引き起こされる、ソフトウェア開発コス リーズ」 （統合の凍結） 、 「リリースフリーズ」 （リリースの凍結） トの大幅な増大です。 という各 2 週間の 3 段階による品質「強化」サイクルに充て ています。このプロセスは、 多くのエンタープライズソフトウェ 「コードを書きながらテストを行う」価値は広く理解されてお ア開発企業にとってかなり一般的なものです。 り、開発組織もこの方法を採り入れたいと思っています。それ が実現に至らずに高い目標に留まっているのは、 「開発チーム 2 年前には、コベリティのテスト自動化には大きなばらつき による適切なテスト」を示す明確な基準を持つメトリクスがな がありました。製品の「フロントエンド」コンポーネント（顧 いからです。こうした基準がないため、QA チームは、どのく 客のコードをコンパイルする部分）や「解析」コンポーネン らいの品質レベルのソフトウェアが開発チームから送られてき ト（コード中の潜在的なバグを特定する部分）では、デベロッ たのかわかりませんし、開発チームも、新機能追加の猛烈な パーが自動化されたテストを構築し、機能の一部としてそれら プレッシャーをかけられているため、十分にテストしていない もデリバリーしていました。それに対して Coverity Connect コードを QA チームに提出しがちです。多くの組織は、バグ は、主にマニュアルの QA プロセスを用いて構築されていまし 発生率を詳細にモニターして、履歴データと比較しています。 た。同じようにエンド・トゥ・エンド（E2E）QA プロセスも しかし、このデータでは開発チームの勤勉さを間接的に調べる ほぼ全面的にマニュアル操作を用いていました。図 1 は、2 年 ことしかできないため、こうしたデータの利用は、問題に根本 前の製品コンポーネントおよび機能テストの概要を図説した 的に取り組もうとしない、事後処理的な利用に限定されがち ものです。 2 テストを変貌させた自動化 ホワイトペーパー 表1：2011年夏時での、製品コンポーネントと機能テストアプローチのハイ・レベルでの概要 Coverity Connect の機能テストと E2E テストの 2 つのマ ニュアル QA タスクは、製品のソースコードへのアクセスが 限定されており、10 時間時差のある、東欧のチームにアウト 重大な変革 こうした状況を変えていく必要がありました。私たちは既存 ソーシングしていました。 また当時は、 機能が完成したと 「宣言」 のプロセスを評価し、問題はアジャイル開発の基本方針その されるまで、QA プロセスを開始していませんでした。完成を ものにあるのではなく、Coverity Connect や E2E テストを 示す明確な基準がなかったため、 「フィーチャーフリーズ」段 巡る開発チームと QA チームの文化と方法論の違いにあると 階では機能の品質は未知であり、修正が必要な取りこぼしバ いう結論に達しました。この分断された状態を解消するには、 グの数量がどのくらいで、どの程度の作業が必要かも予測す より多くのテストを自動化して、開発プロセスとテストをイン るのが非常に困難でした。この不確実性のために、リリース強 ターリーブしなければなりません。 化サイクル中に、 デベロッパーも QA チームも超過勤務を重ね、 スケジュール通りにリリースできるか組織全体に不安が広が 最初の措置として、R&D を再編して、QA リソースを開発部 る、危機的状況に頻繁に陥りました。また、このプロセスでは、 門に移転し、開発チームにテストの責任を負わせるようにし 目標とする製品の全体的品質を保証することができませんで した。 ました。2011 年に東欧に置いていた QA リソースの 3 分の 2 を Coverity Connect の組織に移転し、残り 3 分の 1 を E2E テストに集中させることにしました。しかし、この措置 開発チームとテストチーム間の文化的、地理的な距離が、問 では不十分なことがすぐに明らかになりました。QA スタッ 題にさらに拍車をかけました。長いコミュニケーションサイク フが遠隔地にいて、場所によって作業慣行にもばらつきあっ ルや言葉の壁、製品に対する習熟度の違いが、リリース強化 ために、作業のペースが遅くなったのです。また、新たに プロセスの予測をさらに困難にしました。 Coverity Connect チームに配属された元 QA チームのエン ジニアは、限られた開発経験しかないため、効果的な方法で 既存プロセスがうまく機能していないことは明らかであり、よ テストを自動化できませんでした。 組織を微調整するだけでは、 り多くの機能のより迅速な開発に必要なスケーラビリティも欠 十分な成果が得られなかったのです。 けていました。多くのテストをマニュアルで行いすぎ、またリ リースの重要な各段階で品質を追跡できるようにする便利な 「テスト・オートメーション」がコベリティの新たなキャッチ 尺度もありませんでした。コベリティは、アジャイル・プロセ フレーズになろうとしていました。東欧からは段階的に撤退し、 スの採用を謳ってはいましたが、テスト自動化や機能開発とテ リソースをすでに小さなオフィスがあったカナダのカルガリー ストのインターリーブが欠けていたために、開発サイクルの終 に移しました。ここなら、本部のあるサンフランシスコと１時 わりにトラブルに見舞われていました。 間の時差があるだけです。このようにしてコミュニケーション 3 テストを変貌させた自動化 ホワイトペーパー のラインを短縮し、言葉の壁を乗り越えることができました。 東欧からカルガリーへの移転は、長期的な持続性の確保にも 2011 年 8 月から 2012 年 9 月まで 1 年かけて実施したこの 役立ちました。カルガリー大学情報科学部と交流するように 事業再編が、コベリティが人、プロセス、技術の問題に対処 するための基本的な枠組みになりました。 なり、やがて、高度な資格を持つ研修生や将来の社員の安定 供給を確保できるように、同大学の就職説明会に参加したり、 プログラミング・コンテストのスポンサーを務めたり、技術レ 人 クチャーをするようになりました。 まず、開発段階でテストの自動化を達成するためにどんなスキ ルが新たに必要になるのかを考えなければなりませんでした。 プロセス 従来の QA の経験者の代わりに、プログラミング・スキルの 私たちの最大の目標は、 「コードを書きながらテストを行う」 ある人材を雇用しました。自動テストのプログラムコードを作 ことでした。2011 年の夏には Coverity Connect のテスト 成するには、プログラミング言語に精通していなければなりま と E2E テストにまだ多数残されていたマニュアル・アプロー せんが、これによってエンジニア達は、キャリア形成の一環と チが、この目標の達成を妨げていました。 してテストエンジニアと開発エンジニアの役割を交互に果た す機会を将来的に手に入れることにもなりました。常識に反し この重大目標を達成するための第 1 段階は、テスト自動化の て、東欧からカルガリーへの移転には、ほとんど経費がかかり 拡大です。テスト自動化には、2 つの大きな利点があります。 ませんでした。ほんの少しの費用で、東欧にいた 12 人の QA まず、期待される機能の挙動をエンコードしておき、テストの エンジニアの代わりに、11 人のソフトウェア・エンジニアを 実施によってコードが実際に期待する挙動と同じ挙動を示す カルガリーに配置したのです（図 2） 。 と確認できることです。テストに合格すれば、機能は完成し たと宣言できます。2 番目の利点は、機能の開発完了後、他の 開発作業の影響を受けたかどうかを特定することで、リグレッ 東欧からカルガリーへの人員の推移 ションを回避できることです。テスト自動化は、定期的にテス トを実行することでこうしたリグレッションをすばやく検出で きます。そのため、テストが今後の機能開発やアーキテクチャ の改訂のための「ガードレール」の役割を果たすことになりま す。ソフトウェアの複雑化やチームの規模拡大、コード管理責 任の変更に伴い、テスト自動化をベースにした堅実な開発プロ セスが重要になりつつあります。機能とのインタラクション方 法によっては、すべてのテストを同じように開発できるとは限 りません。テストによっては、インタラクションする機能セッ トが完成してからでないと開発できないものもあります。 図2：東欧からカルガリー（カナダ）へのテスト人員の推移 Coverity Connect は、従来通りにサーバー側の操作のため のバックエントと Web クライアント側のフロントエンドとに わかれた、ウェブアプリケーションです。バックエンドには、 人的要素で一番大切なのは、開発チームに均等にテスト側の コード開発の一環としてデベロッパーが自動化されたユニット 責任を担わせることです。しかし、新たな組織構造では品質 テストを作成できるプロセスを組み込みました。過去 2 年間 に関する報告責任が強化され、開発チームが品質を管理して、 に、テストの数を 2,346 から 3,148 まで 34％増大させるこ テストに対する投資の直接的な恩恵に与るようになっていた とにより、ユニットテストのカバレッジを改善してきました。 ため、このことはそれほど困難ではありませんでした。効果的 2011 年秋には、フロントエンドで自動化されたテストはほぼ なテストに対する高い評価が、できる限りプロセスを自動化す 皆無で、機能テストはブラウザーの GUI からすべてマニュア る強力なインセンティブになりました。同じように、このとき ルで実施していました。これを改めることが、 コベリティにとっ には E2E QA チームも優れたプログラミング・スキルを持つ て最も重要なイニシアチブのひとつになりました。手始めとし ソフトウェア・エンジニアによって構成されていました。E2E て、Selenium WebDriver 1、TestNG 2、社内開発したテ QA チームのエンジニア達は、時間に追われながら数百の QA スト自動化技術を組み合わせた総合インフラストラクチャー テストをマニュアルで実施するありふれた作業を自動化する の構築に着手しました。その鍵になったのが、シンプルで使 ことに強い熱意を持ち、本腰を入れて取り組みました。 いやすく、テスト開発をアプリケーション全体および組織へと 1 http://www.seleniumhq.org 2 http://www.testng.org 4 テストを変貌させた自動化 ホワイトペーパー E2E テスト自動化プロセス CC テスト自動化プロセス 図3：2011年秋のAlameda出荷から2013年春までのCoverity Connectの機能テストの開発 スケールアップできるアーキテクチャの開発です。インフラス スの GUI テストをいったん自動化すれば、これをサポートす トラクチャーが完成すると、今度はその上で自動化テストの開 るすべてのプラットフォームやウェブブラウザーに使用でき 発を開始しました。自動化を急速に進めると同時に、より厳格 ます。マニュアルで同じようにカバレッジを拡大しようとすれ なテストを実施できるよう、Coverity Connect の GUI 操作 ば、 途方もない費用がかかるでしょう。E2E テストに関しても、 の機能テストの総数も増やしました。 急速に自動化を進めており、現在では、ライセンス認証やウェ 図 3 は、2011 年 秋 か ら 2013 年 の 春 に か け て Coverity り 3％の E2E テストは自動化が困難で、ブラウザーページの Connect と E2E の機能テスト総数が増えたことを示していま 正しいレイアウトの視覚化など何らかのマニュアル検査が必 す。Coverity Connect の場合、GUI ベースの機能テストが 要です。 ブサービスを含め、テストの 97％が自動化されています。残 4.5 倍に増えています。またインフラストラクチャー導入後に は、急速に自動化のレベルが上がりました。現在、Coverity 図 4 は、テスト実行に必要なマニュアル作業がどの程度減少 Connect の機能テストの 25％が自動化されています。また したかをまとめたものです。今では、フルセットの E2E テス 今後 9 ～ 12 ヶ月間に残りのテストも自動化される見込みで トを 3 人のテストエンジニアで 2 日間で完了できます。これ す。コベリティの自動化インフラストラクチャーは、テストに によってテストの範囲を拡大するだけでなく、最終メンテナン 必要な時間を短縮するだけでなく、より多様なカバレッジを可 ス・リリースの品質強化期間を 2 週間から 3 日に短縮するこ 能にするということに注意して下さい。例えば、 Selenium ベー とができるようになりました。 E2E マニュアルテストエフォート 人日 人日 CC マニュアルテストエフォート 図4：マニュアルでの1度のCoverity ConnectとE2Eテストの実行により得られる労力の削減 5 テストを変貌させた自動化 ホワイトペーパー 「コードを書きながらテストを行う」という重要目標を達成す るための次のステップは、テスト作成と機能開発のインター リーブでした。最終的には、アジャイル開発プロセスに一連の 説明する、新技術の Coverity Test Advisor を用いています。 技術 テストを組み込んで、合格してから機能の受け入れを宣言す テスト自動化を進めるために、テストの開発や実行に使用 るようにすべきです。こうすれば、コードがまだ記憶に残って するツールや技術が必要となるのは明らかです。ビルドプ いる段階でデベロッパーはバグの修正を求められるようにな ロセスには、Jenkins4 プラットフォームを用い、継続的統 るため、機能を最も効率的に開発できるようになります。また、 合（Continuous Integration3） を 利 用 し ま し た。 ユ ニ ッ リリースの進行状況に関して詳細な洞察が得られるため、例え トテストの大半は、このビルドの一環として実行されます。 ば、実装に必要な作業量を過小評価してしまい、機能のリリー Coverity Connect の 3,148 のユニットテストの他に、フ スが遅れそうな場合でも、管理者は是正措置を講じることが ロントエンドと解析コンポーネントでは、10,215 のテスト できます。 がやはりビルドの一環として実行されます。また、より複雑 なテストを実行するために、テストファームでテスト実行の ユニットテストの開発はこれまでも常にコード開発と同時に行 スケジュールを階層的に設定する、シナリオテストシステム われてきましたが、Coverity Connect の機能テストと E2E （Scenario Test System: STS）と呼ぶ社内インフラストラ テストに関しては、各機能を完成させるリリースサイクルの初 クチャーも構築しました。STS は、Coverity Connect の自 期に実施するようにしたばかりです。この移行が成功するかど 動化された GUI テストおよび自動化された E2E テストを実行 うかは、機能のデベロッパーとテストのデベロッパーの密接な するほか、フロントエンドや解析コンポーネントの 1,978 の 協力、製品アーキテクチャおよびリリース中に開発される機能 より複雑なテストを実行します。過去 2 年間にコベリティは、 を分解し、個別に完成させ、テストできるようにする開発スケ テスト実行用のハードウェアリソースを大幅に拡大したため、 ジュールにかかっています。過去数回の Coverity Connect 今では、サポートされているプラットフォームの完全なテスト の大幅なアーキテクチャ再構成に伴い、この 2 番目の問題が セットを半日のターンアラウンドで実行できるようになりまし 困難となり、今のところ型にはまったプロセスまでには至っ た。図 5 は、過去 2 年間のテスト・ハードウェア・リソース ていません。この再構成が落ち着き、自動化がさらに進めば、 の増大をまとめたものです。コベリティのテスト実行プラット 機能とテストの開発をさらに密接にインターリーブできるよう フォームの大部分が仮想化されている点にご注意下さい。 になるでしょう。このプロセスを推し進めるために、次の章で STS テストのためのハードウェア 図5：フィジカル、バーチャルマシーンのタイプ別、ここ2年間のSTSテストの増加 3 http://en.wikipedia.org/wiki/Continuous_integration 4 http://jenkins-ci.org 6 テストを変貌させた自動化 ホワイトペーパー 通常のコード開発プロセスの一環として、自社製品を「プロ 除いたバグの個数をまとめたものです。 テストの自動化を拡大していくうちに、 ダクト・オン・プロダクト」 （PoP）として利用しています。 機能開発の進行に伴い、 Coverity Quality Advisor と Coverity Security Advisor テストの開発を最もテストが必要な分野に集中させる方法が によって検出されたバグは、継続的にデベロッパーによって 必要なことが明らかになりました。コード・カバレッジは、テ 選別され、修正されます。重大なバグの完全除去がコベリティ スト効率を評価する代替的な方法として一般的に用いられて のリリース基準の重要な要素になっています。当社の静的解析 います。2011 年には、コベリティのフロントエンドおよび解 エンジンは、完全に自動化されているため、プロセスの初期段 析コンポーネントのコード・カバレッジは約 83％で、この数 階に非常に費用効果の高い方法でバグを除去することができ 値は非常に優秀と見なされています。しかし、残り 17％に何 ます。したがって、Coverity Quality Advisor や Coverity か隠されていて、どんなテストを追加で開発すべきなのかは Security Advisor は、従来のテスト方法によって検出される わかりません。また、新たなコードを追加するか、コードを変 バグに対して、補完的なタイプのバグを検出できます。これ 更した場合に、どんなテストを追加すべきかに関して、コード・ は、静的コード解析エンジンが、クラッシュ、データ破壊、メ カバレッジは何のガイダンスも与えてくれません。さらにやっ モリリークをはじめとする製品内の深刻なバグの原因となる不 かいなことに、こうした変更は新リリースの最もリスクの高い 具合のパターンを調べ、実行パスをより幅広くサーチするた 部分であり、限られたテストリソースを集中させるべき分野で めです。一方で従来の動的テストでは、機能の意図した挙動 もあります。こうした洞察から、ソースコードのセマンティク を確認することにより、機能バグを検出することが主眼となり スに対する深い理解を利用して、コード変更のインパクトを判 ます。こうしたコードの機能的な意図は、静的解析では推測で 定し、それを効果的なテスト開発のガイドとして利用できない きません。図 6 は、PoP プロセスの一環として検出し、取り かを探究することになりました。 Coverity Quality/Security Advisor で検出されたバグ 図6：各リリース時にCoverity Quality、Coverity Security Advisorによって検出され、修正されたバグ 2011 年春に、想定した原理を確認するために、フロントエ コベリティの実験は、未テストのコードに最新リリースで作成 ンドや解析コンポーネントを用いて C/C++ コードの小規模 されたアップデートをオーバレイすれば、さらにテストが必要 な実験を行いました。その結果、その時のカバレッジでは、 なコードの量が比較的少なくなり、そのためのテスト開発が実 1,372,376 行のコードの 83.7％がテストされ、223,340 行 現可能になることを実証しました。図 7 は、この実験の結果 が未テストのまま残されることが判明しました。このコードを をまとめたものです。最後のリリース以降に導入された一番新 すべてカバーするテストを開発しようとすれば、巨額の投資と しい変更に集中すれば、未テストの 223,340 行のうち追加テ 多大な作業が必要になり、機能開発を一時的に停止しなけれ ストが必要なのはわずか 851 行になります。 ばなりません。 7 テストを変貌させた自動化 ホワイトペーパー テスト開発にフォーカスした早期の検証実験 カバーされていないコード行数 カバーされていないファイル数 図7：リスクの高いコード変更に関し、テスト開発にフォーカスする価値を証明する早期実験の結果 最初の変更時にカバーされていない行がゼロになり、テストを必要とするコードの減少を示している この実験で得た洞察から、社内利用のための新たなソリュー リスクなコード部分をレビューして、不一致や不整合を見つけ ションが開発され、やがてそれが新製品の Coverity Test ていれば発見できたものであったことを注記しておきます。 Advisor に発展しました。Coverity Test Advisor を利用す れば、開発チームはどのコードが最も危険で、徹底したテスト が必要かを精緻に規定するテストポリシーを設定できます。そ フロントエンドコンポーネントの Test Advisor の実験 の鍵となったのが、コード変更、デッドコード・セグメント、 未テストコードの機能面のインパクトや、あるいは、テストか ロッパーやテストエンジニアの処理項目として顕在化され、管 理者はこのような項目の処理状況を追跡することができます。 Coverity Test Advisor は、 「適切にテストされた」機能の受 検出されたバグの数 のコード・フラグメントを特定できる、当社の静的解析能力で した。このプロセスを通じて、テストが不十分な部分はデベ TA のテストの数 ら除外すべき、デバッグコードや特定の例外処理などの一部 け入れ基準を設定することによって、前述のアジャイル・プロ セスの不足部分を穴埋めします。 2011 年夏に Coverity Test Advisor の本格的な開発作業 を開始し、2012 年春には最初のプロトタイプを用いて、フ ロントエンド製品コンポーネントの社内実験を行いました。 Coverity Test Advisor が特定したテスト違反を選別して、 図8：Test Advisorを使用した実験の結果、48人時間で29のテストが され19のバグが見つかった 高リスク・エリアを対象とするテストを開発するために、毎 週正確に 4 時間作業するようテストエンジニアに命じました。 図 8 は、この実験の結果をまとめたものです。テストエンジ 2012 年秋に Coverity Test Advisor を新製品として発表し ニアは、12 週間後に 29 のテストを追加し、特定コンパイラー ました。以来、テストの弱点を特定し、テスト開発活動を拡大 の機能に重大な影響を及ぼすものを含め、19 のバグを検出し 集中するために、すべての製品コンポーネントの生産にこれを ました。この 19 件のバグのうち約半数は、テスト開発中に高 用いています。 8 テストを変貌させた自動化 ホワイトペーパー QA ベースの開発プロセスから機能開発と自動化テストが完 成果と今後の展望 全にインターリーブされたプロセスへの移行は、まだ完了し テスト自動化を拡大し、テストを開発段階に移行させるコベリ ていません。E2E テストの自動化はほぼ終わり、Coverity ティの試みは大きく前進し、製品の品質と信頼性の面で大き Connect のテスト自動化のためのインフラストラクチャーは なメリットをもたらしました。図 9 を見ると、製品リリース後 構築することができました。今後 9 ヶ月から 12 ヶ月間にマ に顧客によって検出された不具合が減少しているのがわかり ニュアルのまま残されている部分の自動化を完了させて、テ ます。図 9 の期間に顧客数が増大し、当社の製品機能が大幅 スト開発をコード開発の重要なプロセスにすることができるで に拡大したことを考えると、この減少はテストの有効性が大幅 しょう。Coverity Test Advisor は、機能が Coverity Test に改善されたことを示しています。また、メンテナンス・リリー Advisor のすべてのテストポリシーに適合して初めて受け入 スの品質強化期間を 2 週間から 3 日間に短縮し、ホットフィッ れられるようにし、開発者をテスト活動に集中させ、リリー クスのリリースや小さな製品アップデートをより効率的にする スサイクルの進展状況を把握できるようにする、必要不可欠 ことができました。これまでと比較して、 コベリティのメジャー なソリューションへと進化しつつあります。コベリティは、メ リリースの納期がより正確に予測可能になっただけでなく、機 ジャーリリース・サイクルを 1 週間以下に短縮して、あらゆ 能も増え、同じかより少ないリソースによって検証されたまっ るビルドから製品の機能性を速やかにデモンストレーションで たく新しいコンポーネントを含むようにもなりました。 きるようにすることを目指しています。 コベリティは、今後も開発プロセスの改善を進めながら、そこ 顧客サイトで検出された正規化されたバグの件数 から得た教訓をイノベーションに転換していきます。また、こ のようなイノベーションを、より優れたソフトウェアの開発を 可能にする新製品やソリューションに発展させていく意向で す。コベリティのビジョンは、静的解析から得た深いコードイ ンテリジェンスを利用して、ありふれた開発やテスト・ステッ プをすべて自動化し、既存の開発プロセスを、高品質な製品 を提供する、予測可能で費用対効果の高い、エンジニアリング・ プロセスに進化させることです。 今後もコベリティがお届けするたくさんのイノベーションにご 注目下さい。 図9：Alamedaリリースと比較して全顧客サイトで検出されたバグの 件数（一週間あたり） この期間に、顧客数はかなり増加している 謝辞 コベリティの R&D チームの全メンバーが、本書の作成に多大 な貢献をしてくれました。特にマラト・ボシェニスタン（Marat Bosherunistan） 、ジョニー・チャン、ディノ・デリアニ、メ ンウィン・ゲイタス、ゾハール、ハーシュフェッド、メル・ラグー ノ、スコット・マックペック、キット・トランスー、ならびに Coverity Connect および E2E テスト自動化チームのクオリ ティに対する飽くなき情熱と、テストを日常的な開発作業の一 部にする絶えまざる努力に感謝の言葉を捧げます。 コベリティジャパン株式会社 Website: http://www.coverity.com/html_ja/
© Copyright 2024 Paperzz
