Test Confessions: A Study of Testing Practice for Plug-In Systems Michaela Greiler †, Arie van Deursen †, Margaret-Anne Storey ‡ † : Delft University of Technology ‡ : University of Victoria 担当：山内寛己 株式会社アクセス

概要 プラグインベースシステムのテストは非常に複 雑であり，テストが難しい – 数多くのプラグインとの相互作用（競合の確認） – 異なるバージョン（プラグイン，プラットホーム）， 設定など プラグインベースシステムにおけるテストにお いて，テストエンジニアおよび，開発者の意識 と行動の実態をより理解する

Research Question RQ1: プラグインベースシステムのテストにおいて，広 く行われているテストプラクティスは何か．そのプラク ティスは非プラグインシステムと異なるのか． RQ2: プラグインのアーキテクチャがプラグイン特有の テストアプローチにつながるのか．何がテストを困難に させるのか． RQ3: プラグインベースシステムのテストを困難にさせ る要因は何か． RQ4: プラグインのテストを支援する付加的な補償の戦 略があるのか．

調査対象とその採択理由 調査対象： – Eclipse プラグインとその開発コミュニティ 採択理由： – 洗練されたプラグイン機構を持ち，数々のプラグイ ンが広く使われている．また，個々の開発規模が大 きく，複雑で，業務用途にも耐えうる – 大きな開発コミュニティを持ち，専門的知識を持つ 開発者が多い． – Eclipse コミュニティ全体がテストについて前向きに 取り組んでおり，プラグイン開発環境 (PDE) が整って いる． – プラグイン開発プロジェクトの多くがオープンソー スで他の研究者と議論もしやすい．

本論文の研究アプローチ 1. サーベイ： 一般的なプラグイン開発に関する情報と Eclipse プラグ インに特化した情報の収集（開発フォーラムや文献な どから） 2. インタビュー： 25 人（ 18 組織）の様々なドメインの Eclipse プラグイン エキスパート * に 1 ～ 2 時間の grounded theory (GT) に よるインタビューを実施 3. 会議で報告： 2. の結果，分析と見解を EclipseCon** で発表 4. アンケート： 3. の発表に対するフィードバックとアンケートに 151 人 のエキスパートから回答があった（そのうち， 60% ほ どが開発者）． * 開発者 12 名，プロジェクトリーダ 11 名，テスタ 1 名，テストマネージャ 1 名 **

Research Question RQ1: プラグインベースシステムのテストにおいて，広 く行われているテストプラクティスは何か．そのプラク ティスは非プラグインシステムと異なるのか． – 非プラグインシステムとプラクティスは変わらない． – Eclipse コミュニティでは， unit testing が重要な役割を担っており， そのほとんど（およそ 70% ）が自動化されている．一方で， system testing, integration testing, acceptance testing は unit testing ほど頻繁ではないが導入，自動化がされている． RQ2: プラグインのアーキテクチャがプラグイン特有の テストアプローチにつながるのか．何がテストを困難に させるのか． – プラグインの性質がテストアプローチに与える影響はあまりな い． – 拡張ポイントの使用やプラグインの組み合わせ，プラグインの バージョン，プラットホームのバージョンが特有のチャレンジ になる．

Research Question RQ3: プラグインベースシステムのテストを困難にさせ る要因は何か． – 主な障壁は，不明確な説明責任や当事者意識，容易にテストす るためのインフラの欠如，テスト容易性が担保できない，テス ト実施時間の長さである RQ4: プラグインのテストを支援する付加的な補償の戦 略があるのか． – ユーザや開発者をコミュニティに巻き込む．そのためには … オープンなコミュニケーションが可能な環境の整備 – 機能拡張のリクエストやバグレポートの報告 – テスト環境やリソースの提供， self-hosting など

Resources 文献 [11] の Technical Report: -SERG pdf インタビューおよび，アンケートの質問内容や項目，そ の回答の統計などのデータが掲載さている． -SERG pdf ICSE 2012 の発表スライド : confessions-a-study-of-testing-practices-for-plugin-systems confessions-a-study-of-testing-practices-for-plugin-systems

Asking and Answering Questions about Unfamiliar APIs: An Exploratory Study Ekwa Duala-Ekoko and Martin P. Robillard (McGill University) 担当：吉田 則裕 奈良先端大

本研究の概要 大量の API の使い方を学ばなければ，開発を行う ことができない時代になってきた． 本研究では，被験者に API を使ったプログラミン グを行なってもらうことで，以下を調査した． – 開発者が， API を使用する際に持つ疑問（ question ） – その疑問に答えることが難しい理由 実験結果を踏まえ， API を用いた開発に必要と考 えられるツールについて述べる

被験者とタスク 被験者 – 著者らが所属する大学の学生２０名 – 最低一年間の Java 言語を使った開発経験 – 対象の API に詳しくない タスク – タスク１： JFreeChart API を使って円グラフを描く – タスク２： JAXP を使って，与えられた XML スキーマに XML ファイルが合っているか検証する – 時間制限は， 35 分間 – Eclipse を使用 – API ドキュメントと Web を閲覧可

データ収集の方法 think-aloud プロトコル – タスクを解決する際に考えたことを言語化 スクリーンキャプチャの録画 実験後インタビュー

分析結果 被験者が API を使用する際に持つ疑問を，２０種 類発見した． 更に，被験者が手戻りを起こすなど，解決の難 しかった疑問を５つ特定した（抜粋）． – 型 X と Y の関係は何か？ – Public コンストラクトを使わずオブジェクトを生成す る方法は？ – メソッド呼び出しの結果，得られるものは何か？

考察 観察（抜粋） – 開発者が使用している型から直接アクセスできない が，関連する API を発見することが難しい – API の一部をクエリとして取り込むと，良いコード例 を探しやすい – メソッド実行と例外の関係の理解が難しい 実験結果から必要と考えられるツール – 開発者が使用している型から直接アクセスできない が，関連する API の情報を提供する – タスクに関連する型の発見する – API 間の関係を発見する

How Do Professional Developers Comprehend Software? Tobias Roehm*, Rebecca Tiarks**, Rainer Koschke**, Walid Maalej* *: TU München, **: University of Bremen 担当：戸田 航史 福岡工業大学

概要 プログラム理解については，これまで多くの研 究で様々な手法やツールが提案されてきた しかし現実の開発者のプログラム理解における 行動や，利用されている手法やツールについて はほとんど知られていない – 特に納期等の実プロジェクトでのプレッシャーがか かる中での行動についてはほとんど知られていない そこで，開発者のソフトウェア理解に関する業 務中の行動の観察し，現実のプログラム理解行 動の内容を明らかにする – 研究と実践のギャップを埋める

貢献 1. 実環境でのプログラム理解戦略について詳細に 記述した 2. プログラム理解についての行動仮説をまとめた – これは応用研究やツール開発の助けとなる 3. 実験の手順や内容について詳細に記述した – 本研究の実験デザインは同種の実験でも利用できる 開発者の振る舞いに関する研究での実験

実験環境 7 企業 28 人の開発者に対し，作業内容の観察とイ ンタビューをそれぞれ 45 分行った – 観察対象作業はソフトウェア理解に関する業務 日常の業務を勝手に観察しているというスタンス – ただし観察時には，ある程度以上（ 45 分以上）の規模の ソフトウェアを理解の対象にしてもらった 観察とインタビューから，ソフトウェア理解で 行われる 20 の行動を特定し，そこから 23 の行動 仮説を立てた

状況 S2: problem-solution-test パターン ソースコードの修正を含むタスクに開発者は 3 ス テップで対処する 1. 問題点の特定 2. 解決策の適用 3. 適用結果のテスト ある開発者は UI の色に関するバグの解決のため ，デバッグと print 命令を実行し（ステップ 1 ）， ソースコードについていくつかの修正を施し（ ステップ 2 ），その後テストを行っていた（ステ ップ 3 ） – ちなみに時間内にはバグは取れなかったらしい

S5: クローン作成による理解の回避と工数削減 1. コード変更の結果が予測できないとき，開発者は 既存コードをコピーすることで，プログラムの理 解自体を避けようとする – ある開発者はオリジナルのソースコードをリファクタリン グする代わりにコードをそのままコピーしていた その開発者は「オリジナルのコードを改ざんするとど こに影響が出るか分からないし，その影響は調べるの は時間がかかりすぎる」と述べている 2. 開発者は必要な情報を見つけやすいように統一さ れた構造のドキュメントを好む – ある開発者は「ドキュメントはコピーして使い回した方が 統一性が取れる」と述べている 3. 開発者は通常，ソフトウェアを理解することより もタスクを完了することを優先する

I6 ：現実の利用シナリオの有用性とその稀少性 1. 「エンドユーザがアプリケーションをどのよう に利用するか」はプログラム理解において有用 な情報源である – 「ユーザのニーズのうち，アプリケーションで実装さ れているものはプログラムを理解する上で必要な情報 である」とある開発者は述べている 2. 多くの場合， 1. の情報は存在しない – 「「アプリケーションをエンドユーザはどのように使 うのか」が不明である場合や，アプリケーションのド メインについての知識がほとんどないという状況は多 々ある」とある開発者は述べている

その他の行動 ドキュメント読むよりソースコード見た方が早 い ドキュメント読むよりも隣の部屋にいる同僚に 聞いた方が早い Eclipse の全文検索機能とか知らんし，という開 発者が居た プログラム理解を助ける特別なツール類を使っ ている開発者は一人もいなかった – 可視化，コンセプトロケーション，ソフトウェアメ トリクスツール等 – IDE とデバッガくらいしか使われない