NPO法人ソフトウェアテスト技術振興協会 イベント報告-JaSST'13 Tokyo

1/30(水)　10:00～11:40
基調講演 「Challenges in Software Testing　ソフトウェアテストのチャレンジ」
Dorothy Graham氏 (Software Testing Consultant)

テスティングコンサルタントDorothy Graham氏による基調講演。
IT業界の歴史＝技術や環境の変化などからテストやテストエンジニアの位置づけ、役割などがどのように変化してきたか、そして今後はどうあるべきか、つまりチャレンジが必要な事項を伝える内容であった。

以前は"テストは誰でもできるもの"と認識されていたため、テストエンジニアは開発者に比べ二流扱いであった。しかし、PCの登場、GUI、CASEツール、オブジェクト指向、オープンソースなど技術・環境の変化に伴い、テスト資格制度も整備され、専門的なスキルの必要性やテストエンジニアがキャリアの一つとして認識されるようになった。
また、欠陥検出、品質情報提供、リスク低減などテストの目的も変化し、対応範囲が広がってきた。今後も新技術の登場・環境変化に応じて対応していく必要がある。
一方で変化していない事項として「管理職のテストに対する理解不足」「大学でのテスティング教育不備」「過去から学ばない傾向」などが提示された。どれも身近に感じるものであるが、これらを解消しない限りテストに求められる次の変化に対応できないのではないかと感じた。
そして、欠陥検出におけるテストの価値を示す指標としてDDP：欠陥検出率の具体的活用方法、そしてテスト自動化とよくある知的な間違いを紹介した。
最後にテストの将来としてAgileやCI（Continuous Integration）・DevOps、さらなる自動化の展開などの技術・環境の変化を例に取り上げ、今後テストエンジニアは開発者への不具合原因究明アドバイスの提供やユーザ・ビジネス問題への高度な対応が求められる、非常に面白いものになるでしょう、と結んだ。

長きにわたりテスト・テストエンジニアの価値向上に携わり、自らその変化を作り出し、体感しきたDorothy Graham氏が、できるだけ難しい言葉を使わずに分かりやすくテストの過去・現在・未来について受講者に伝えてくれた印象を持った。

1/30(水)　13:10-14:40
A2) テスト開発方法論～とびだせテストアーキテクチャの森～
「テスト要求分析やテストアーキテクチャ設計を重視したテスト開発」
智美塾塾長＋塾生一同
吉澤 智美 （日本電気）・秋山 浩一 （富士ゼロックス）・鈴木 三紀夫 （MRTコンサルティング）・西 康晴 （電気通信大学）・湯本 剛 （日本HP）

受講者が自らテスト開発方法論を構築できるようになることを目的としたセッション。
前回まで内容を高度化しながら継続開催してきたセッションであるが、ほぼ満席となった会場の約半数が初めて受講する方達であった。ますますこのテーマへの関心が高まっている証拠であろう。
セッションはテスト開発方法論で特に戸惑うことが多い「テスト要求分析」・「テストアーキテクチャ設計」を題材に、代表的なテスト開発方法論 １．HAYST法（秋山氏） ２．ゆもつよメソッド（湯本氏） ３．VSTeP（西氏）の違いを比較することによりテスト全体とそれぞれの構成要素が持つ意図を把握するアプローチで進められた。
随所でそれぞれの方法論で行う内容、その意図や注意事項などが解説され、特徴／共通点及び違いが明確になっていった。
それぞれの特徴や違いはともあれ、共通点として言えることは、テストは開発のおまけではなく、それとは独立してテストに必要な事項を組み立てられるようになることを目指している、ということであった。
最後に、"はじめから100%完成した方法論は存在しないため、これらの情報を参考にまずは自ら作り上げ、それを実践で活用しながらブラッシュアップしていってください"と結んだ。

1/30(水)　16:50-18:20
C4) 不具合情報の活用　～パターン青、バグですっ！～
「過失に着目した欠陥のモデリング　～バグ分析はなぜうまく行かないのか？～」
細川 宣啓（日本IBM）・西 康晴（電気通信大学）・野中 誠（東洋大学）
嬉野 綾（ワークスアプリケーションズ）・原 佑貴子（日本IBM）

昨年「欠陥マスター情報構築ワークショップ」を実施したProject Fabre（プロジェクト　ファーブル）のセッション。野中氏が突然病欠となったのは残念であった。
まずバグ分析の典型的なアンチパターンを示し、周知対応、教育実施、チェック項目追加（実践できない項目数へ）などマネジメント対策にすり替えられることにより効果が出なくなってしまう事例が紹介された。
その上で、個人攻撃になりがちな「なぜなぜ分析」は「なになに？」と聴き方を変えるだけで欠陥を作り込んだ背景情報など俯瞰的・多角的に把握し、ポジティブに原因分析ができることを示した。
また、人はどのような罠にはまってバグを作り込むのかを分析する方法として"過失に着目した欠陥モデリング手法"により、エンジニアへの個人攻撃を防止し、関係者間の共感と欠陥作り込みのからくり・構造をチームや組織で共有・活用していくことを提案した。
毎日一生懸命作業しているエンジニアへの尊厳を奪わないためにも、欠陥を作り込む構造を誘発因子・過失因子・増幅因子・表出現象などの要素でモデリングし、「この状況ならわれわれも同じように間違うよね！」「今後われわれはどうしようか？」と関係者が共感し、問題対われわれの構図を作り出すことが重要だと説いた。
さらに、欠陥モデリング結果を蓄積・活用して組織内への水平展開を可能にする方法など、とかくやりっぱなしで終わる原因分析への処方箋を示した。
業界では「バグを憎んで人を憎まず」とよく聞くものの、"人を責めない""事実に基づく"などの対応方針以外、その具体的な実現方法や作法を明確に示すものはあまりなかったように感じている。この「なになに分析」と「欠陥モデリング」は実務における具体的対応策を提供しているように感じた。

1/31(木)　9:00-11:30
A5) テスト設計コンテスト～目指せ霊長類最強テストエンジニア～
「テスト設計コンテスト'13 本選決勝大会　～目指せ、霊長類最強テストエンジニア～」
(テスト設計コンテスト運営委員会）

今回で3回目を迎えるテスト設計コンテスト。
今年は全国各地域で開催された予選（応募21・予選参加16・予選通過8）から最終的に勝ち上がった5チームと前回優勝チームの計6チームによる本選でテスト設計の出来栄えを競い合った。
シンポジウム期間中、受付横オープンスペースに当コンテスト参加チームの成果物が掲載され、休憩時間などに多くの来場者が足を止めてその内容を興味深く観覧していた。
そして当セッションは2日目朝9:00～であったが、会場は一時立ち見が出るほどの盛況ぶりであった。
発表では、自らの実務／テストで直面している課題をベースにその解決策を組み込んだチームや、仮想のプロジェクト条件に沿ってテストマネジメント～テスト設計までを一貫して対応したチーム、利用者の性格分類からのテスト設計などが紹介され、20分という限られた発表時間にそれぞれのチームの特徴・工夫を把握することができた。昨年に比べアプローチ方法・内容のレベルアップが感じられ、このコンテストの意味・意義を再認識した。
最後に運営委員会より次回もテスト設計コンテストを開催することがアナウンスされた。
今後も各地域でさらに当コンテストへの参加チームが増え、自らの取り組みとお互いに競い合う中でテスト設計の腕を磨いていくことを期待したい。

1/31(木)　14:20～15:50
招待講演 「ソフトウェア・テスティングについて　－無形労働の視点から－」
岸田 孝一氏 (SRA)

黎明期からこれまでIT業界を牽引し、強い影響を与えてきた岸田氏が、農耕→工業→情報などの社会の変化、業界や開発方法論などの変化から、ソフトウェア開発の捉え方の変化と芸術の共通点から言えること、そしてテストエンジニアの役割を提言した。
以下に筆者が感じた要点を列挙する。

• ソフトウェア開発は、マテリアルではないものを作る労働＝非物質的な労働＝無形労働である。これにはファッション産業やソフトウェア開発が含まれる。
  よってソフトウェア開発は、その中に含まれる文化や情報が重要であり、利用者と開発者の密接なコミュニケーションと相互学習から構成される。
• 仕様化とは、ある仮説に基づいて利用者の現実世界の情報を削除した結果である。
  仮説はいつか破たんする。よって仮説の管理と検証がテストエンジニアの役割である。
• テストエンジニアの大事な仕事は、開発者が（暗黙的に）設定している仮定や前提がこれからも成り立ち続けるかを考えることだ。
• ベストプラクティスの再現は難しい。現在のソフトウェアプロセス改善は再現・反復のための改善になっている。反復ではなく、差分・差異に着目することで創造性を生むことができるのではないか。まずは自分がそれに気づく、そして他者にも気づいてもらえるようにすることが重要だ。

時間の関係で終了間際にスライドと話が駆け足になり、最後まで詳細を聞けなかったのが残念であった。

1/31(木)　16:00-17:40
A8) クロージングパネル　「エンジニアリングの本質　～人月、自動化、無形労働～」
モデレータ：板倉 稔（イネーブル・ツリー）
パネリスト：Dorothy Graham（Software Testing Consultant）・岸田 孝一（SRA）・榊原 彰（日本IBM）・西 康晴（電気通信大学）

エンジニアリングとは何か、テストやテストエンジニアの価値はどこにあるのか、価値を提供するために何をしていく必要があるのかを問いかけ、一緒に考え、提言を提供したパネルであった。
その進行過程は非常に混沌としている印象ではあったが、今回のシンポジウム各セッションで伝達されていた大事なメッセージを裏うちする言葉や提言がしっかり存在していた。以下に筆者が重要と感じた、パネリストからのコメント・提言を示す。

• 長年解決しない問題に対して少しでも解決するように努力する／過去の経験から少しでもよいものを、よい結果を出そうとするのがエンジニアリングの本質ではないか。（榊原）
• ナレッジ（知識）ベースとスキル（技能）ベースを一緒にしてはいけない。
  知識と経験・技能から良い判断ができる。（Dorothy）
• ソフトウェアエンジニアリングは未解決のまま。科学的アプローチではなく、社会学的なアプローチが必要ではないか。答えを一つに決めるのではなく、いろいろな立場や背景からいろいろな答えが存在することを理解する必要がある。（岸田）
• ソフトウェアエンジニアリングは"誰がやっても同じになること"ではない。
  価値を生むところに誰がやっても同じものはないし、テストは誰がやっても同じようにできるものではない。（榊原・西）
• 毎日の練習度合に応じて上達するわけではないが、少なくとも毎日の練習なくしてものごとが上達することはない。（榊原）
  よりよい結果を目指してコツコツ取り組むことが大事。（西・Dorothy）
• エンジニアは既成のものの表面や形をなぞるだけではダメ。
  形にとらわれず、よりよい結果になるよう日々工夫することを忘れないこと。（西）
• 今後はテストの価値を提供するためには、ドメインに依存しない／開発とは独立したテストをする必要がある。その実現のためにテストエンジニアは開発者の考えや考え違いを予測する技術を身に付ける必要がある。（西）
• テストでもっとも難しいのはプログラムのテストではなく、要件に合うのかのテストである。今後のテスト、テストエンジニアの挑戦は、（明確化することが難しい）要件を（ソフトウェアが）満たすことをどうやって確認するかだ。（Dorothy）
• パネルはオープンエンドがよい。答えをどれか一つに固定するのではなく、いろいろな考え方や見方を知りながら継続して考えていく必要がある。それぞれ自ら考え、自分の答えを見つけること。（岸田）