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

高松にしては気温が低く四国からの参加者も口々に「今日は寒いね」と言うほどではあったが、前日の雨もあがり晴れ間も伺える天候の中、寒さに負けないあたたかさを持ったシンポジウムが開催された。

オープニングでは実行委員長の高木氏より今回のセッション概要が紹介された。例年と同じく今回も講演とワークショップの2部構成であった。

講演
「探索的テスト - 全機能テストできない、全部のバグを見つけられない時代の効率的なテストを考える」
（高橋 寿一）

講演内容

「テストを破壊する3つの波」として、OSS(Open-source software)・Android・IoTというキー・トピックがある。民生機器はもちろんのことメディカルでもOSSを利用している現状では、OSSを使っていないケースの方が少ないのではないか。しかし、商品に使ってよいOSSと使うべきではないOSSがあり、そのことを考慮せずに気軽に使ってしまうケースもある。その結果として使うべきではないOSSが持つセキュリティホールによってユーザーに損害を与えた場合、会社として「僕らのせいではない」とは絶対に言えない。クラウドサービスを利用するとしても「クラウドサービス側のせいです」とは言えない。そのような状況の中で、どうやって品質を担保するか？についての解はあまり明確になっていない。アメリカの大企業はOSSに対して適切な使い方をしているが、日本ではそのようなことがない。もはや自分のコードだけをきちんと書いていればそれでよいという時代ではない。OSSの品質がどれだけ担保されているかの知識のほうが重要になってきている。

IoTも最近安価になってきて使われやすくなっているが、他のシステムとの通信に関する品質はどう担保すればよいだろう？自分の作る範囲よりもその外の範囲のほうが難しくなってきている。

OSSを利用することで開発部分が少なくなることから開発スピードが上がっている。昔はテストケースを書くスピードがコードを書くスピードよりも速かった。現在もコードを書くスピードは変わらないがOSSを利用することによりコードを書く量が減るため、テストケースを書くスピードが追いつかなくなった。

基本的には全部テストできないので、探索的テストを勧めたい。網羅率を問われて網羅できないと説明するとマネージャーが怒り出すことはよくあるが、よく考えてみるとOSSやIoTを利用する場合、自社のコードに対するテストを100%実行できたとしても製品全体としてのテストの網羅率は1%程度になってしまうだろう。ブラックボックステストをしても網羅率は10%には達しないだろう。網羅を目指すよりも、ユーザーの欲しいものは何か、ユーザーにとって一番嫌なことは何かを想像してベストエフォートなテストをしたほうがよい。

DevOps、Scrumによる2週間のスプリントやデイリービルド、チャットツールを利用した協調作業など、開発手法は進化している。ところがテスト手法の進化がみられない。テスト手法だって進化しなければならない。「早くて安くてそこそこの品質」を目指す新しいテストの枠組みが必要である。

従来のテストケースベースのテストでは、テストケースを作成する時間がテストの活動の半分を占めている。そのうえ仕様変更が入れば変更処理に時間が費やされる。テスト実行を行っている時間は8時間のうち30分程度というのが実際のところではないか。それよりも探索的テストにより「モノを触る」時間を増やす方が効果的である。昨今のプロダクトのライフサイクルは短い。半年くらいであれば、テスト担当者は覚えていられるという点でエビデンスをしっかり残さなくても支障はないのではないか。

また、最近は要求仕様自体が複雑化しているが、探索的テストでは要求仕様に関するバグを発見するケースが多い。

それでは探索的テストはどのように行うのか？まったくテストケースを書かないわけではない。タスクシートを作成する。タスクの例としては「ここのコンポーネントの入力に対する境界値をテストする」という程度で、テスト対象とテストの目的が透けて見える抽象度の高いテスト条件とする。
探索的テストに求められることとして、以下の事項が挙げられる。

• マネージャーに対して自分のやりかたが正しいという説明ができること
• Pass/Fail基準を設けること
  　その際に製品の目的(ユーザーがその製品に対して何を欲しているか)を明確にすること
• アプローチとしてスコープや意図を明確にすること
  　網羅できない箇所を「そこまではやらない」と明言すること
• プロセスについての記述はステークホルダーに合意が取れる程度(A4用紙1枚)に収めること

また、コードを書く人と並んでテストを行うのが理想である。コードを書く人と並んでテストを行うことで、主に分岐処理に対して「ここが抜けている」「ここを忘れている」ということに気付く。問題が起こる原因として多いのは分岐のケース漏れである。

探索的テストはトレーニングを十分に受けたテスト担当者により行われるべきである。トレーニングとして、プログラム言語は学んで欲しい。学んで欲しいのはサイズや構文といった仕組み、プログラムはどういう振る舞いをするか、その言語の特徴や問題が起こる傾向などの基礎的なところでよい。また、もちろんテスト手法については理解しておく必要がある。

非機能テストは探索的テストでアプローチしないかもしれない。しかしユーザービリティテストについては効果がある。

質疑応答

Q)

非機能テストは探索的テストでアプローチするのは難しいのだろうか？

A)

例えばセキュリティに関するところはファジングの技術があるが、探索的テストを割り当てるにはまだ高いハードルがある。

Q)

探索的テストの普及度は？

A)

明確ではないが結構広まっていると思う。ただし最後に一気通貫でやろうとするような「なんちゃって探索的テスト」を行っているところはあると思う。
今後は網羅的にはテストできないので嫌でも使わざるをえなくなるだろう。

Q)

リソースの関係からプログラマがテストをしなければならない。分業すべきか？本人が探索しても効果はあるのか？

A)

分けるのはベストだが、分けなくてもよい。ただし、自分の書いたコードに対してやらないこと。10人の開発チームに対して品質の責任を持つ人を1人置くことがおすすめ。

所感

冒頭で高橋氏が語られたように全体的に実務ベースの話が盛り込まれた身近な話題で構成されており、納得する点が多かった。

安価だからといって、安易に、スキルを持たないテスターを雇うことに対する問題は筆者も日頃実感している。そのようなことをしても効果が見られない。テストは考える仕事であり、構造と振る舞いの両側から見つめることで探索的アプローチが活かされることに気付く人が増えて欲しいと願っている。高橋氏の講演はそんな思いを勇気づけてくれる内容であった。

ワークショップ
「なんとなく実施するレビューからの脱却 ～目的・観点設定に基づくレビューの効果を体感してみよう！」
（安達 賢二）

演習内容

電気ポットの要求仕様書を題材としてレビューの演習が行われた。

最初に何もアプローチを提示せずに、いきなり「これをレビューして。よろしく！」と言われたという前提で、各自自由に15分間のレビューを行った。

その後、指摘事項に対して「それはどのように調べた結果わかりましたか？」「それはどのような観点でレビューした結果ですか？」「観点はどのような目的を達成するものですか？」とヒアリングしていくことにより、リバースが行われ指摘の意図を見せることができる、という解説があった。このヒアリング演習も用意されていたが時間の都合により解説のみとなった。今回の演習では「先に意図を整理してからレビューを行うことによる効果」を体感することに重点が置かれた。

この後、4名から5名のチームを形成し、グループワークが始まった。

レビュー計画として、各チームで複数の立ち位置からレビュー観点を出し、その中から今回のレビューで扱う観点とレビューの目的を決め、観点ごとに担当を決めることになった。レビュー計画を立てる前に今回の対象フェーズとタスクについて情報が追加された。システム要求仕様書作成が終了した時点で、システム要求仕様の確認を行うとのこと。更に背景として「電気ポット企画書」が提示された。電気ポットが備えるべき特徴とターゲットユーザーが記載されていた。

まずは「ターゲットユーザー」「製品企画担当」「設計担当」「システムテスト担当」の4つの立ち位置をチームメンバーで割り振り、各自がその立場で観点を出してみることになった。

観点を出すときのポイントとして、観点には粒度があること、粒度を意識して親子関係も考えてみること、具体的に掘り下げる必要があれば掘ること(例えば「使いやすさ」だけではわからないので具体的にどういうことが使いやすさに繋がるのかを分解して考えてみる)、迷ったらまずは書いてみてから吟味する、という解説があった。

チームメンバーがそれぞれの立場で観点(気になる点、やばそうな点、気にしてほしい点など)を挙げてみたところ、それぞれの立場で気づきそうな観点が出ていた。また異なる立場で同じ観点が出たとしても立場により表現が異なっているなど、立場らしい特徴が出ていた。

表出された観点を整理してその中からメンバーの人数だけ観点を選び、それぞれ適切と思われる立場の担当者に割り振った。

レビュー計画がまとまったところで、再び15分のレビューを行った。今度はそれぞれの立場を演じ、担当の観点にそってレビューを行った。

その後、レビューの指摘事項について、効果の度合い(上下方向に上から効果大・中・小の３段階)とそれを見逃したときにその後発見されると想定されるフェーズ(左から右方向に時系列に並べる)との２軸で分類した。

この後、講師からレビュー観点を用いることの効果について解説があった。
一般的にはレビュー観点を軸にレビューを行うほうがより右上(効果大であり見逃すと市場ででてしまうような問題)に指摘が集まりやすくなる。しかし、いわゆる「腕っこき」の優れたレビューアではアドホックで行っても効果が出せてしまう。また、観点という制約が入ることで思考の枠を限定してしまい、効果が下がることもある。

筆者のグループではこの両方の特性が見える結果となった。

更に講師から、以下のアドバイスがあった。

• 観点は人それぞればらける傾向にあるため、せめて会社の中では揃えられるようにしたほうがよい
• レビューチェックリストを作成するケースでは「それがあれば」と形式的になりやすく、頭を使うことに対して妨げになる可能性があるので安易に使わず、頭を使う領域を増やすようにしたほうがよい

所感

とても練られた演習で、企画など背景を把握することの大切さ、どこのフェーズなのかを意識する必要性、観点を共有する大切さ、様々な立場からレビューを行う大切さ、という事項を体験し実感できる点が素晴らしいと思った。

筆者のグループには開発者・学生・テスト担当者がおり、それぞれの立場で気付けることの違いが見えた。また、役割が異なると「見る目が違う」という感覚を体験した。テスト担当者である筆者にとっては開発担当者や他の立場の方々と一緒に考え情報共有をすることの大切さを改めて感じるよい機会になった。

ワークショップが終わり、ふと外を見るともう日が落ちて暗くなっていた。それくらいあっという間に時が過ぎていた。コンテンツの魅力が時間の経過を忘れさせるシンポジウムであった。

クロージングでは八重樫氏から次回がJaSST Shikokuの10周年であることが伝えられた。参加者から実行委員になる方々も徐々に増えてきており、今後も更に魅力的なシンポジウムになると期待している。

情報交換会は近くの居酒屋で骨付鶏を始めとする料理を堪能しつつ、講師と参加者と実行委員が入り混じり様々な話で盛り上がった。この瀬戸内の風土に似た和やかさが四国の魅力だと感じている。