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

基調講演
「未来の話をしよう」
榊原 彰 （日本アイ・ビー・エム）

「テストの話はしませんよ」

会場に笑いが広がるなか、一部には戸惑いの雰囲気も。なにしろソフトウェアテストに関するイベントにもかかわらず、テストをテーマに話をしないと宣言したのだ。

「ITを使って生活の質を向上させたい」

スライドをめくると、タイトルが「都市の起源と変遷」
静かにざわめきが広がる。ITと直接は関係がないメソポタミアやアテネなど歴史上の都市の話から始まった。どこに進むのだろう、不安と期待が交錯している雰囲気が漂っている。

都市の変遷に続き、現代の都市に関する様々な課題が列挙される。

• 交通渋滞
• 食べ物の廃棄
• 水の安全
• 空のコンテナ（経済情勢によって、）
• データセンター（８５％の計算能力が使われていない）
• ヒートアイランド
• 新電力
• 安心安全

「都市の課題をＩＴで解きたい」

複雑で複合化された都市の課題をITで解くためのキーワードを取り上げている。

• モノのインターネット（Internet of Things）
• ビッグデータ
• レジリエント
• システムズ　オブ　エンゲージメント
• モバイル・ファースト
• メーカーズ
• 自動運転車とドローン
• オープンデータ

これらのキーワードを単に解説するだけでなく、バンコク、ロンドン、リオデジャネイロ、埼玉、千葉などで実際に取り組まれている事例を基に話されているため、聴衆はどんどん話に引き込まれていった。

最後に「広い範囲でシステムを使う人がでてきたときに、その人がどのように使うか。テスト技術者は、このような目を養ってもらえれば」と、テスト技術者に向けたメッセージを送った。

なお、この講演の一か月後に、Amazonがドローンを使った配送サービスの構想を発表しており、改めて講演内容のタイムリーさ、凄さに驚いた。

「概略！自動結合テスト」
きょん

講演というよりは、LT（ライトニングトーク）の拡大版という趣である。

きょんさんの活動されている環境に依存する話が大半であり、「テスト専門教育を受けていない１００人のテスト担当者と一緒にやる場合に、これが言えるかどうかは分からない」という内容であった。
そのため、自社に何らかの知識を持ち帰ろうという趣旨で聴いていた人にとっては、期待外れであったかもしれないが、技術を突き詰めたテストとは何かということに関して刺激が得られたのではないかと思う。

なお、興味深いと思ったメッセージは次の２つである。

• 「テスト自動化は３回やらないと元が取れない」というのは嘘である。
• テスト自動化は、テスト実装者がプログラミングスキルとアーキテクチャ知識を得られる。自動化しないと知識が得られない。

「初心者向け！Excelで分析する際の7つのポイント」
イワノフ

先ほどとは一転して、多くの職場で持ち帰って活用できそうなテーマである。

すべての不具合をすぐに直すことはできないため、発生しているバグを分析して、どれから直していくか。時間との闘い、限られた時間の中でクリティカルなバグをつぶしていく。一日３回ぐらい同じデータを分析していく中で、イワノフさんはExcelの分析テクニックを磨いていった。

Excelで分析するとき考慮すべき事柄を、具体例を挙げて説明していた。

• データ分析にはピボットテーブルを使う
• カラムには項目名を付ける
• すべてのデータにナンバー付与、ID付与
• 元データを直接操作しない
  　→　修正時に困ったことになるから
• 数式で加工するけれども、数式のままで保存しない
  　→　大量の数式を保存するとファイルが重くなるから
• 表記を統一する
  　→　大文字、小文字が異なるなど、表記が異なると別データとして扱われるから
• 一つのセルに複数の値は入れない
  　→　ピボットテーブル作成時に別のデータとして扱われるから

ポイントの中には当たり前と思われるものも入っている。しかし、当たり前と思われるものこそ大事なポイントであることを講演を通して気付かされた。

「これからの"バグ"の話をしよう」
細川 宣啓 （日本アイ・ビー・エム）

欠陥学、欠陥エンジニアリングを体系化しようとしている細川さんの講演である。
クヌースやバイザーの欠陥分類を振り返りつつ、欠陥とは何かと聴衆に問いかける。

「発生頻度の高い欠陥ベスト10があげられますか？」
「再度発生する確率が最も高いのは？」
「そもそも、欠陥って何でしょうね？」

テスト技術者にとって、欠陥は馴染みの深いものである。それにも関わらず、実は欠陥についてよく知っていないのかもしれない。そのようなことに気付かされる。

欠陥学における欠陥とは、従来プロジェクトで管理されてきたバグ票とは異なるものである。
従来のバグ票はプロジェクト欠陥とみなし、欠陥学における「欠陥」とは区別されている。欠陥学における「欠陥」とは、どのプロジェクトでも参照可能な抽象化されたものであり、欠陥マスターとして整理されたものである。

この欠陥を分析するために、欠陥モデリングを提唱している。本講演では、分析した結果を「時間がない」「しようがない」「やっぱりやめた」「怠慢」などの具体例を通して紹介していた。

欠陥学はまだ完成していない領域であるため、講演内容を持ち帰りプロジェクトに適用するまでには至らないが、欠陥をよく知ることで欠陥検出のためテストの効率が上がることは理解できた。

「ちょっと明日のテストの話をしよう」
西 康晴 （電気通信大学）

「本当に自信をもってテストができますか？」

本番障害、市場トラブルなどの原因分析の現場でよく聞く言葉が「テスト漏れ」である。できる限りのテストをやっているつもりでも、自信を持ってやっていることなのかどうか、改めて問われると不安に思う人もいることだろう。

その自信のなさは、単に仕様書の焼き直しのようなテストケースを作っているからであり、テストの全体像が見えていないからだと言い、CPM法（コピー＆ペースト＆モディファイ法）の問題点について具体例を挙げて述べている。

次にやり玉に挙がったのが、テストタイプやテストレベルである。テストタイプやテストレベルは標準を持っている組織が多いため、十分な考慮をせず標準をそのまま使ってしまうことが多い。そのために自信が持てないのだ。

では、テストの全体像を作ればよいかとそんな簡単な話ではない。テストの全体像を書けと言われても、書けるものではないからだ。
そこで、にしさんは既に作成しているテストケースをリバースすることを提案している。
テスト観点を用いてテストケースをリバースすることにより、テスト設計時の意図が明確になり、テストの良しあしが分かるという内容をストレス系テストの観点を例にして分かりやすく説明している。

次にリバースしたテスト観点モデルを基にテストを改善する手順について紹介している。

1. ［数週間］テスト観点モデルのリファイン
2. ［２～３ヶ月］テストアーキテクチャの構築
3. ［３～４ヶ月］テスト開発プロセスの確立
4. ［５～６ヶ月］テストマネジメントの改善
5. ［１～２年］テスト自動化の確立
6. ［２～３年］開発上流との協調

最後に「ずっと『テストは何を評価するのか』を考え続けましょう」と問いかけ、LEDの点滅制御テストなのか、それともエンターテイメントの素晴らしさを評価するのかを例に挙げました。

なお、講演時間を大幅に超過する大変の熱のこもった講演であった。

おわりに

テストの実務で必要となってくるExcelの話から、ソフトウェアが関わる未来の話まで、今回のJaSST'13九州は幅広いテーマが特徴であった。技術習得が目的の研修とは異なり、今後を見据えた刺激を得られるのがJaSSTの良いところであり、JaSST'13九州ではその良さが聴衆に届いていたと思う。地域JaSSTの難しいところは、地元の技術者による発表をいかに確保するかであるが、イワノフさんというタレントを発掘できたことにより、今後のJaSST九州に繋がるのではないかという期待が持てた。次年度以降のJaSST九州が楽しみである。