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

はじめに

各地域で実施するJaSSTの中で、初のオンライン開催である。テーマは「テスらんかぁ？ ～知識イチからテスティング～」。筆者は自宅（千葉県）からZoomで参加した。参加者からのフィードバック方法として、コメントはZoom、質問はSlidoに投稿する方式だった。各講演資料は公式サイト（末尾にリンクあり）から公開されている。

Opening

実行委員長の中岫氏がオープニングトークを努めた。「みなさんの姿が見えないと不安ですね」という、オンラインならではの発言から始まった。

続いて、今回、オンラインイベントを地域でやる意味について考えたと語られた。結論は「そこに文化があれば、やる意味はある」だった。以前から、北海道の特色をなくさないように以下を心がけている、とのこと。

• 地元企業とのタイアップ企画
• 地域ならではの企画
  • テーマの設定と各セッションへの反映
  • ワークショップの実施
  • 招待講演は異業種から　→　視野をひろげるきっかけ

次に、「探索的テスト」と今回のテーマに関連して、簡単な解説（ライトニングトークス）があった。

「テスらんかぁ？」は、テストとスペランカー（注）から作った造語で、テストしてみませんか？その時に無謀なテスト探検者になっていませんか？との問いである、とのこと。

注：スペランカーは無謀な探検者で、ケイバーは知識と装備を持っている探検者を意味する。

最後に中岫氏は以下の言葉で締めくくった。

知識ゼロだと現場では成果を得られないので、知識イチからテスティングできるように、知識を仕入れましょう。今日のシンポジウムで様々な知識と装備を見つけることで、スペランカーからケイバーになって、ソフトウェアという洞窟から成果を得て帰還しましょう。ケイバーになれたらと思うと、わくわくしませんか。

基調講演
「なぜ大規模SIerで探索的テストを推進しているのか？
～NTTデータが目指すソフトウェアテストの世界～」
熊川 一平 氏（NTTデータ）

まず、熊川氏が所属する業界について解説があった。IT業界とSIerとの違いである。一般的にIT業界では自社のためにシステムを作るが、SIerは、顧客のためのシステムを作る。そのため、SIerのテストでは、可監査性・客観性が求められるとのこと。

次に、本日の内容の中心である探索的テストについて解説があった。テスト実行後のふるまいを観察して更なるテストにつなげてバグを「探索」するやり方であり、テストケースは無形である。ここで、SIerに求められる可監査性・客観性に合致していない。

次に、熊川氏がなぜ探索的テストを推進しているかについて以下の２点の説明があった。

• 品質が良いこと、十分にテストをしたことは誰にも証明できないのではないか？
• 複雑な基幹システム構築の難しさに対して、現実的な効果を積み上げていくほうがいいのではないか？

実際、探索的テストを実施した結果から、スクリプトテストに対して10倍近いバグ摘出能力・100倍近い仕様改善能力があったため、スクリプトテストに加えて、効果的に探索的テストを活用することがプロジェクトのためになると考えている、とのこと。

次に、熊川氏が探索的テスト普及のために行なっている活動の説明があった。一つ目は研修である。意図的にバグを混入させたアプリケーションのバグを探索的テストで発見する研修を作って効果を体験してもらっている。二つ目は新しいやり方である。上記で説明した客観性不足の課題に対して、探索的テストをツールで記録することで追跡して抜け漏れを補える「SONAR Testing」を試している。

熊川氏は最後に、これからの活動として日本のSIerを変えたい、技術者がもっとパワーを発揮して楽しく仕事ができるようにしたい、と語った。

※公式サイトの講演資料とグラフィックレコーディング（わかりやすい！）も合わせて参照願います。

Q&A

Q:

探索的テストの向き不向きについて

A:

下記の通りと考える。

不向きなシステムについて：

• 観察することが難しいシステム。システム間のハブとなるような機能は難しい。
• サイクルに時間がかかりすぎてしまうシステム。実行して結果が出るまでに時間がかかるもの。

人のスキルについて：

• 業務スキル面：一般の人にはわからない画面でも、バグに気がつくための業務知識を持つ。
• テストスキル面：事象からある程度推測できる人。トラブルの一次仕分け能力がある人は向いている。

Q:

マネジメント層へのアプローチ方法は？

A:

スモールスタートが良い。投資的にやってみる。マネジメント層に訴える。
例：「試したいことがあるので3日ください」と訴え、結果を出す。
炎上プロジェクトは、たくさんバグが出るので効果が出やすい。

Q:

探索的テストの活用アイデアを出すために普段気を付けていることは？（環境、つながり、生活習慣など）

A:

いろいろなニュースを目にした時に、どのようにテストに置き換えられるだろうか、を考える。
調理器具はすぐれものが多い。ソフトの開発に置き換えてみる、など。材料を入れる、加熱する、とは何か、など。
一見論理的に見えるものは、本当にそうなのか、を考えてみる。自分の中で固定的になっている論理があるなぁと思うことがある。
人間系、他業種には興味あり。医療、健康診断。どういう仕組みなのか？など。

Q:

スクリプトテストではなく、探索テストならではの、発見した価値のあるバグは？

A:

探索的テストで、悪い仕様を発見することは価値があると考える。
変なエラーメッセージなど、ユーザーにとってストレスになる原因を取り除くことができる。
他は、論理的には取り得ないようなバグを見つけた時。設計書から読み取れないタイミングで発生するもの。

Q:

技術者の能力向上について

A:

ビジネスドメイン知識、バグに関する知識を増やす。ペアテスト、モブテストは技術伝承の効率が良い。
セッションベーステストマネジメントというテスト管理手法を用いるのも有効である。
日々の活動では、朝会でテスターから気づきを報告してもらって考え方を共有している。
バグに関する知識はなかなか得られない。他のプロジェクトのバグ票を見る、など。
ASTERの「プロジェクトファーブル」は良い。いろいろなバグを見るのは価値がある。

筆者感想

探索的テストに秘められたパワーを感じた。スクリプトテストに対して、10倍近いバグ摘出能力・100倍近い仕様改善能力が示されたことに、わくわくした。私もSIerが変わらないといけないと日々感じているので、SIerに所属するエンジニアが変わるきっかけのひとつになると信じて、社内に紹介していきたい。とても共感が持てる講演だった。

事例発表１
「チームの改善リズムをつくるための最初の一歩
～メンバーの「気付き」を起点に、日常的に改善が行えるテストチームをつくり、アジャイルな開発サイクルに合流する具体的な進め方～」
常盤 香央里 氏（グロース・アーキテクチャ&チームス）

常盤氏から「まず、予稿集に掲載されているフローチャートをやってみてください」と問い掛けがあった。本講演の対象者としては、Ｂタイプの人がぴったりとのこと。予稿集では、それ以外のタイプの方々にも聴講ポイントが示されていた。

次に、改善のサイクルを身につけ、改善活動が当たり前になるチームになるために、以下の４つの工夫が「とあるテストチーム」での会話付きで紹介された。

1. チームの【定例会】に焦点をあてる
2. メンバーの【気づき】を起点にする
3. 【対策実施】の後押しをする
4. 改善の【サイクル】を意識する

続いて、一歩踏み出してから参考になる、さらなる工夫点が紹介された。

5. より【気づき】を逃さないようにしていく
6. 開発チームの改善サイクルに乗り込む

これで、蚊帳の外だった「とあるテストチーム」が主体的に参加できるようになる、とのこと。

最後に、この先の展望として以下が示された。

• この先も壁にぶつかる。まず定着するまでは半年くらい。改善活動としては停滞している
• 世の中にある手法（SaPID、TPINextなど）を活用することで乗り越えて行ける

なんでも取り込んでしまうのはスペランカー、壁のポイントに絞って導入するのがケイバー、と紹介され、講演は終了した。

※講演内容と質疑応答は、公式サイトの講演資料を参照願います。公開資料は、当日の質疑応答やSlidoに投稿された質問への回答、発表時の様子が加筆されています。

筆者感想

改善活動の発表は背景や経緯よりも成果が強調されがちだが、この発表はケーススタディとしての会話付きの発表で、背景や経緯を知ることができた。よって、自分の経験と照らし合わせることができ、わかりやすかった。質疑応答の中で、「プラクティスを変える目的をチームで話し合いましょう」という回答は、アジャイル開発の支援をしている筆者としては、普段意識していることであり、共感できた。

事例発表２
「GSNを用いた欠陥情報からのシナリオテスト作成の取り組み」
波平 晃佑 氏（宇宙航空研究開発機構）

まず、宇宙機システムの特徴が紹介された。外部環境の状態の影響を強く受ける、複数のコンポーネントと協調しながら動作する、故障・異常があってもできるだけ動作継続が求められる、という特徴だった。

そのため、正常シナリオだけでなく、例外／代替シナリオ＝リスクシナリオの作成が重要だが、作成するためには、時間経過の考慮、外部環境／システム／コンポーネント／ソフトウェアに関する複数の発生条件の考慮が必要となる、とのこと。

そこで、構造／時系列ビューによる発生条件の抽出の誘導、GSN（Goal Structure Network）による組み合わせの分析の誘導、ガイドワードによる網羅補完、という対策を挙げた、とのこと。発表では、事例をベースに解説された。

今後の展開として、当手法の適用拡大や費用対効果の計測について、協力いただける方を募集中とのことだった。

※公式サイトの講演資料も合わせて参照願います。

Q&A

Q:

宇宙分野において「シナリオテスト」の作り方について標準等あれば教えてください。他分野でシナリオテストを担当しており、参考にしたいため。

A:

標準はない。開発企業の方々のエキスパートが頭の中で実践している。製品の知識が豊富で、ロジカルシンキングも強い方々である。

Q:

いろいろな関心ごとから、一気にテスト設計しようとしているが故に難しくなっているように感じました。実際のテスト設計の手順はどのようになっていたのでしょうか？時系列に関する関心事、外部環境に関する関心事、それらの組み合わせに関する関心事、から個別にテストしたい条件を出し、それらの条件を使ってシナリオを作る。でよいのではないかと思いました。

A:

従来だとp.9の表が出てくるが、それではソフトウェアの中だけになってしまう。

Q:

構造ビュー・時系列ビューを作成していたのは？（開発チーム？テストチーム？）

A:

テストチームが作成。

Q:

リスクシナリオは、運用時のコンティンジェンシープランを設計したものか、テストを検討するためのものか、が分かりづらかったです。時間があれば、リスクシナリオの部分をもう少し説明してほしいです。

A:

リスクシナリオは、ソフトウェアのバグを見つける目的。運用前に見つけたい。

筆者感想

宇宙機システムという、普段なかなか触れることがない環境の概要や課題を知ることができた。ソフトウェア中心のシステムを対象としている筆者にとって、ハードウェアとソフトウェアが協調して動作するシステムに対するテストの難しさは想像以上だった。その中で様々な工夫をされている様子、そしてその工夫を組織内で閉じるのではなく、垣根を越えて業界全体を良くするために協力を仰ぐ様子に感心した。

事例発表３
「SikuliXを用いたリグレッションテスト自動化の事例紹介
～「キーワード駆動テストに基づくSikuliXスクリプト自動生成」や「画像認識方式に対する動画を用いたスクリプト開発」による効率化～」
佐藤 祥平 氏（NTTデータ）

初めに、当事例発表の背景が説明された。公共分野の大規模エンタープライズシステムが対象で、サーバ台数が多く、再起動するのに15分かかる。システム画面の特徴としては、リッチクライアントで、オブジェクトが動的に移動する特殊画面や、入力タイミングがシビアな操作が存在し、テスト実施の難易度が高い。

そんな中で、E2Eレベルの結合テストのリグレッションテストを自動化し、試験カバレッジ向上／デリバリ短縮／工数削減への挑戦の様子が語られた。

まず、ツール選定プロセスでは、①座標指定方式、②画像認識方式、③画面要素認識方式の中から、上記のシステムの特徴から②画像認識方式が選択されたとのこと。マッチング画像を用いて対象画面を検索し、一致したオブジェクトを操作する方式である。ツールは、無償で国内での適用事例がある「SikuliX」が選択された。スクリプト記述は python を使用したとのこと。

次に、自動テストの作り方として、最初に手動でテストを実施し、そのテスト証跡を用いてリグレッションテスト自動化を準備し、テスト実行 → 失敗検知 → 原因分析 → メンテナンスのサイクルを実施し、その中で以下の２つの課題を解決した、とのこと。合わせてその他の課題も紹介された。

課題1. テストスクリプトの作成効率化。

テストスクリプトとテストデータを分離してコードのメンテナンス性を高め、テストスクリプトを共通化してパターン化し、Excelマクロでスクリプト自動生成の仕組みを実装した。その中で、入力タイミングがシビアなものについては、入力操作パターンを、トリガーパターンと操作パターンに分類した。また、Excelマクロで python スクリプトを自動生成する仕組みを構築し、python のコーディングスキルがないテスト要員も関われるようにした。

課題2. 画像認識方式の準備作業の効率化

マッチング画像作成で用いる過去のテスト証跡（静止画）に不足があった場合に再試験するなど、準備に時間がかかっていた。そこで、手動の結合テスト証跡を静止画から動画に変更し、その動画を活用することで、効率よくマッチング画像を作成できた。

その他の課題. GUI操作自動化ツールでの結果確認の効率化

実行時の画像と、正解の画像を比較する仕組みを構築し、作業を半自動化した。

最後に、まとめとして以下が語られた。

今回、80シナリオのテストを自動化することができた。今後の課題としては、自動化スクリプトのメンテナンス実施（特に動作確認）に時間がかかっているので、自動化スクリプトに対するCI/CDに取り組みたい、とのこと。

講演内容は、公式サイトの講演資料を参照願います。

Q&A

Q:

動画によっては解像度の違いが生じると思いますが、その差異は吸収できますか？

A:

どの程度一致していれば良いかを表すマッチング率を設定できる。動画から取ってきた画像でもマッチするように調整した。

Q:

リグレッションテストのためにテストを作成されているということでしたが、作成されたテストはソフトウェアの次の版でも使用できますか？動画を取り直したらテストは動作しなくなるのでは？

A:

画面の表示内容が変わってしまうと動かない。マッチング画像の差し替えが必要。今回、画像をできる限り共通化する工夫をしている。

Q:

タイムスタンプが表示されるところは？

A:

その部分は使わず、違うところをクリックするなど工夫。

Q:

今回の事例ではOSSを使われたという事だが、商用ツールを使用する選択肢はありましたか？データ駆動やキーワード駆動などがあらかじめ搭載されている商用ツールもあると思います。

A:

自動化導入スピードのため、社内手続きが簡素な無償ツールを選択した。商用ツールは社内教育も必要になる。

筆者感想

結合テスト以降のテスト自動化は筆者の周囲でも関心が高く、本発表は、その分野での多くの工夫が紹介されていたので有意義と感じた。特に、テストパターンに応じてスクリプトを分類したり、Excelマクロなどを用いてテストスクリプトを出力する工夫は、多くの現場で参考になると思った。

招待講演
「美味しくいただく為のハンティング」
玉木 康雄 氏（玉翠園）

JaSST Hokkaido 恒例の、異業種の人の講演。講演概要は以下の通り。

「お茶を続けるなら水源である森を守りなさい」が家訓であり、水がダメになっていく理由は、森がダメになっている。このままだと、お茶屋を続けていけないため、自然を守る活動に携わった。森の中からブルドーザーはなくなったが、最近は、鹿が樹皮を食べている。その木は翌年には枯れてしまう。エゾシカが増え、木を食べ、森がなくなってしまう。昔はエゾ狼がいたが、今はいない。人間が、増えた分をハンティングする。

ハンティングには流し猟と忍び猟があり、玉木氏は「忍び猟」が専門である。自分の気配を消して探索し、近づいて一発で仕留める。この方法で仕留めた鹿が一番美味しくいただける。

秋は、森を歩くと小枝が折れる音がする。足を下ろした時に小枝があったら、折らないように気をつける。ソフトウェアの開発・テストと同じようにヒントを探す。けものみち、食痕（食べた時間がわかる）、足跡（種類、深さ、天気）、爪痕（熊は木登りが上手、降りる時に爪痕が残る）などのヒントを手がかりにして鹿に接近する。

たたずむ鹿を見つけたら、前足の付け根が狙撃ポイント。その場所以外は鹿が苦しんでしまう。ハンターは、獲物が苦しんでいるのを見て楽しめる人はいない。また、美味しさに関連する。普通に売られている肉は、その動物たちが苦しまずに死んでいる。前足の付け根の的の大きさは20cm程度。

会場に鉄砲（モデルガン）を持ってきた。日本では、銃の目的外の運搬・使用は禁止されている。一発で仕留めるために、射撃場では何発も打って練習する。本物の銃の重さは4～5kg。

目的を達成するためにツールを変える。索敵エリアを広く取る場合は軽い銃、一発で仕留めるには重い銃。

獲物に出会うまで、凍てつく冬山を何時間も気配を殺しながら進む。からだの筋肉は、獲物に出会うまで、筋肉が働いている。普通の登山よりも体力を使う。

獲物の肉は、7割使える。山奥で仕留めた場合は、肉を車まで運ぶために何往復もする。運べない部分は埋設する。

クルマまで2～3km。道程はかなりのアップダウンがある。荷物10kg＋獲物40kg。リュックを背負う時は、地面に置いたリュックの上に体を置いて、よいしょと起きる。結構な重労働である。

仕留めてすぐに血抜きをする。初冬なら冷蔵庫でなくガレージで熟成させる。10日ほど熟成させたもも肉を分厚く切り、ステーキでいただくのは最高である。

普通に売っている肉でも、正面から肉に向き合って食する。原始の時代から、狩猟者が本能的に感じている「獲物とそれを与えてくれた自然」に感謝する。

森に入るのは、日常から解放されたやすらぎと心地よい緊張感がある。山菜取りなど、丸腰で行く時は、これ以上入ってはいけない境界線がある。動物の爪とか牙と人間が対等に戦うためのツールが銃。森では、渓流での一服が楽しみ。お茶を呑む。

息をひそめて、跡を辿り、ついに獲物を見つけた時の高揚感！「よし、やったな」と思う。静かに接近して、音を立てずに撃つ。少しの音でも300m先の鹿は振り向く。荒々しい趣味に思えるかもしれないが、静寂である。

猟友会としての仕事を紹介する。住宅街に熊が出た時に呼ばれる。エゾシカ協会の講師として若手ハンターへの教育活動をしている。美味しくいただくことにこだわってもらえるなら多くの方々に目指してほしい。ただ撃ちたいだけなら、画面の中（ゲーム）をお勧めする。森では数多く撃たない。

自然を守る、美味しい肉をいただけるご褒美。やまほど失敗談がある。狩猟者向けの講義では、その人の参考になるので失敗談をたくさんお話しする。

私の店（日本茶専門店）では、エゾシカのほうじ茶佃煮（エゾシカレシピコンテスト・グランプリ受賞）を販売している。抹茶パフェもある。ぜひ来てください。

思いを山に馳せることがありましたら、この道を目指してください。

※（筆者から）JaSST公式サイト（https://www.jasst.jp/symposium/jasst20hokkaido/report.html#S4）で紹介されている玉木氏のエッセイ「美味しくいただくためのハンティング」もぜひお読みいただきたい。

Q&A

Q:

鹿が苦しんでしまった場合、肉のどのような部分に差が出てきますか？

A:

鉄分の含有量が多くなってしまう。苦しんで死んでしまった動物は、あちこちにアドレナリンが出て、毛細血管のすみずみまで血が行き渡ってしまう。

Q:

命のやり取りを身近に感じる中で、「あ、これは死んだな」と感じた経験があれば教えていただきたい。

A:

失敗談。ガラケーの時代、GPSを持っていったが事情がありGPSの精度が低下している時だった。地図の上ではここにいると思い込んで動いているが、3つ向こうの谷にいた。鉄鉱石、磁石がくるくる廻っていた。重い荷物を背負っていた。遭難する時のきっかけは、楽な方に行きたくなる衝動。ショートカットできるのではないかと思い込んでしまい、その方向に歩きだすが道がない、崖にあたる、など。そこでリュックの中の肉を3分の2降ろした。荷物が軽くなると、ルートをリセットできる。クルマに戻った時には、真っ暗闇だった。

Q:

射撃場で練習する時はやっぱり実際の場面（たたずむシカ）をイメージして練習していますか？

A:

シルエットターゲットもあるが、私が使うのは丸のターゲット。射撃場で練習するのは、弾丸（メーカーによって着弾点が変わる）、風によっても変わる。何百mが必中距離と知る。固定した状態で打つ。

Q:

思うような結果がでないとき、反省したりしますか？どういったことを反省の時に考えるか参考までにお聞きしたいです。

A:

山から帰った時に必ずログを付けて反省する。直後は落ち込む。ルートをミスした、など。しかし、帰ってログを整理している時は楽しい。同じような失敗をしなくなる。引きずらない。

Q:

ふりかえりには、どのくらいの時間をかけますか？

A:

平均的に30～40分。どの山に、どの銃、気温、雪、痕跡、などを整理する。もしこういうことがあったら（オプション）を考える。成功の確率が高まるのはなにかを考える。1時間はかけない。広がるが正解はない。同じ状況は二度とないため。

Q:

お茶と猟と、どちらが深いですか？

A:

お茶を話し始めると止まらない。どちらも深い。
お茶は仕事。生活の糧を得るために、祖父の代から受け継いだもの。猟は、リラックスできる。

筆者感想

私は千葉県にいながら、北海道の自然と、その奥深さを実感することができた。狩猟という異業種の貴重な話をお聞きしたので、ソフトウェア業界での改善のヒントにしたい。

Closing

中岫委員長から閉会の挨拶があった。概要は以下の通り。

テストはクリエイティブな仕事であり、ツールをうまく使いこなして良き探検者（ケイバー）になりましょう。
本日参加して、テストをやってみたくなりましたか？ケイバーとなるナニカを掴めましたか？

筆者感想（全体）

各講演が、テーマの背景にある「探検」という言葉で貫かれていて、統一感があった。実行委員の方々の企画、そしてテーマを汲み取って内容やトークをアレンジされた講演者の方々に感謝する。

オンラインイベントへの終日参加は初めてだった。ネットワーク経由だが、不思議と講演者との距離が近いと感じた。配信ソフトウェアの機能が向上し、画面を通して表情がわかり、ヘッドホンを通して声の抑揚がわかるからかもしれない。また、リアルタイムでコメントや質問が投稿されるので、講演内容を多角的に理解するのに役立ったと思う。