その2はこちら。
今日は2日目のお話です。さっさと書き終わろうと思っていたのに、もう開催から1週間経ってしまった。
テスト
組み合わせテストの手法、テストシナリオの網羅性、テスト観点の体系化と、それぞれかなり違うお話が聞けました。
B3-1：組み合わせテスト技術の導入・定着への取り組み、および上流設計への適用検討の事例
株式会社 東芝の中野さんの発表です。
組み合わせテストのテストケースを合理的に減らす方法としての直交表やPairwise法を、『ソフトウェアテスト技法ドリル』などを通じて学んできました。
組み合わせテストのテストケースを合理的に減らす方法としての直交表やPairwise法を、『ソフトウェアテスト技法ドリル』などを通じて学んできました。
本発表は、これらのテスト技法の導入により、どのような効果があったかという内容です。結果として欠陥の摘出が効率的になり、大きな工数が削減できた。また、テストケース生成時に禁則（実現できない組み合わせ）を確認しながら進めることから、設計の検証を兼ねることもできたとのことです。
1点気になる点が。
事例で紹介された、欠陥の内訳の数字を計算してみると、組み合わせがらみの欠陥のうち、2因子間網羅だと65%程度しか取れていないように見えること。となると、2因子間網羅じゃ全然テストが足りていない、ということにならないか・・・？という疑問です。
事例で紹介された、欠陥の内訳の数字を計算してみると、組み合わせがらみの欠陥のうち、2因子間網羅だと65%程度しか取れていないように見えること。となると、2因子間網羅じゃ全然テストが足りていない、ということにならないか・・・？という疑問です。
www.kzsuzuki.com こちらのエントリ紹介した資料では、2因子間網羅で概ね8～9割の欠陥が取れるとのことだったので、6割台だとかなり違うな、という印象です。もしかすると、ここはわたしが数値の解釈を間違っているのかも知れません。
B3-2：テスト開発プロセスの適用による網羅的なテスト設計の取り組み
富士フイルム 株式会社の堀川さんの発表。テストの観点を、網羅的・体系的に整理しよう、というものです。
たとえば機能がすべて仕様通りに動作することを確認できたとしても、応答速度が悪すぎたり、同様のことを行う操作が画面によって違ったり、故障解析に必要なログをまともに吐いていないようでは、やっぱりソフトウェアとしてよろしくない。では、どういう観点があるのか、網羅的に知りたいわけです。
たとえば機能がすべて仕様通りに動作することを確認できたとしても、応答速度が悪すぎたり、同様のことを行う操作が画面によって違ったり、故障解析に必要なログをまともに吐いていないようでは、やっぱりソフトウェアとしてよろしくない。では、どういう観点があるのか、網羅的に知りたいわけです。
そこで、テスト観点をツリー状に整理する。これによって、テスト観点の抜けを防ぎます。
紹介された手法では、ツリーの第1階層を「視座分析」で、第2階層以降は「ステレオタイプ分析」で洗い出す。
視座分析では、機能だけでなく、使い勝手、動作環境といった観点を、過去の知見から挙げます。ここで漏れると、それ以下でもずっと漏れることになるので、この作業は重要です。
ステレオタイプ分析では、視座分析で洗い出した観点を、IS-A関係・HAS-A関係でMECEに分解していきます。
確かにこのように展開していけば、最初の視座分析を外さない限り、テストの観点が網羅的に拾えるように思えます。
紹介された手法では、ツリーの第1階層を「視座分析」で、第2階層以降は「ステレオタイプ分析」で洗い出す。
視座分析では、機能だけでなく、使い勝手、動作環境といった観点を、過去の知見から挙げます。ここで漏れると、それ以下でもずっと漏れることになるので、この作業は重要です。
ステレオタイプ分析では、視座分析で洗い出した観点を、IS-A関係・HAS-A関係でMECEに分解していきます。
確かにこのように展開していけば、最初の視座分析を外さない限り、テストの観点が網羅的に拾えるように思えます。
気になる点は、観点をMECEで分解していくせいで、観点同士の組み合わせというテスト観点が落ちていくのではないか、ということです。発表では、「事前条件」という観点を「状態」と「画面」に分割していましたが、状態と画面は、画面遷移のテストでは組み合わせるべきテストです。観点を洗い終わったら、それらの組み合わせを網羅的にチェックする必要があるのでは、と考えています。
また、どこまで細かく分割するのが適切なのかも判断が難しそうです。観点のツリーで、画面の種類まで書きだすことが必要なのか、ということです。
また、どこまで細かく分割するのが適切なのかも判断が難しそうです。観点のツリーで、画面の種類まで書きだすことが必要なのか、ということです。
ところでこの発表は、電気通信大学の西康晴さんが連名されています。西さんはJaSST2006で、『テスト設計におけるモデリングのための記法の提案』（PDF）という、同様の発表をしておられるようです。SQiPでの発表は、JaSSTでの発表内容を成長させたものかと思いますが、どの点がよくなったかなどは特に説明がなく、それが残念でした。
なお、JaSSTの発表では、上述の「観点同士の依存関係」に言及しています。
なお、JaSSTの発表では、上述の「観点同士の依存関係」に言及しています。
B3-3：状態遷移および機能連携に着目した業務シナリオテストの新手法
株式会社 NTTデータの岩田さんの発表です。
業務を想定したシナリオテストを行うにあたり、設計工程で作った業務フローやユースケースを元にテスト設計をすることになります。が、業務フローはたいてい、ざっくりとした業務の流れを描くことが多く、ありうる業務シナリオを網羅的に抽出するには心もとない。
業務を想定したシナリオテストを行うにあたり、設計工程で作った業務フローやユースケースを元にテスト設計をすることになります。が、業務フローはたいてい、ざっくりとした業務の流れを描くことが多く、ありうる業務シナリオを網羅的に抽出するには心もとない。
そこで提案されるのが、「SFマトリクス」。状態遷移表の兄弟です。
状態遷移表では、遷移前の状態に、ある機能を実行することで、遷移後の状態に至る、という関係をマトリクス整理します。一方SFマトリクスでは、「ある機能とそれを実行した後の状態」と、「次に実行する機能」の組み合わせをマトリクスにしています。
状態遷移表では、遷移前の状態に、ある機能を実行することで、遷移後の状態に至る、という関係をマトリクス整理します。一方SFマトリクスでは、「ある機能とそれを実行した後の状態」と、「次に実行する機能」の組み合わせをマトリクスにしています。
ちょっと例を考えてみました。
家に、ライトをつけるスイッチが2箇所にあったりしますよね。
スイッチの状態は2つありますが、どっちがONでどっちがOFFと決まっているわけではなく、ONの状態でいずれかのスイッチを切り替えるとOFFになり、OFFで切り替えるとONになる。
状態遷移表を考えてみると、状態「ON」と「OFF」の2*2のマトリクスになります。2つのスイッチをそれぞれ「A」「B」と呼ぶことにすると、ON状態でスイッチAを切り替えるとOFF状態。OFF状態でスイッチAを切り替えるとON状態。つまり、「スイッチBを切り替える」という機能を使わなくても、状態遷移の0スイッチカバレッジが満たされてしまう。
家に、ライトをつけるスイッチが2箇所にあったりしますよね。
スイッチの状態は2つありますが、どっちがONでどっちがOFFと決まっているわけではなく、ONの状態でいずれかのスイッチを切り替えるとOFFになり、OFFで切り替えるとONになる。
状態遷移表を考えてみると、状態「ON」と「OFF」の2*2のマトリクスになります。2つのスイッチをそれぞれ「A」「B」と呼ぶことにすると、ON状態でスイッチAを切り替えるとOFF状態。OFF状態でスイッチAを切り替えるとON状態。つまり、「スイッチBを切り替える」という機能を使わなくても、状態遷移の0スイッチカバレッジが満たされてしまう。
一方SFマトリクスでは、「その状態に至らしめた機能」の情報をもっているので、
| ・スイッチAの切り替えによりON状態 → スイッチAを切り替える ・スイッチAの切り替えによりON状態 → スイッチBを切り替える ・スイッチBの切り替えによりON状態 → スイッチAを切り替える ・スイッチBの切り替えによりON状態 → スイッチBを切り替える ・スイッチAの切り替えによりOFF状態 → スイッチAを切り替える ・スイッチAの切り替えによりOFF状態 → スイッチBを切り替える ・スイッチBの切り替えによりOFF状態 → スイッチAを切り替える ・スイッチBの切り替えによりOFF状態 → スイッチBを切り替える |
の8つが全てが出てくる、ということになります。
・・・という理解で合っているのかな。
・・・という理解で合っているのかな。
SFマトリクスでは、後機能によってもたらされる状態は見ていませんが、すべての機能を組み合わせるのだからすべての状態遷移も網羅できるはず。よってSFマトリクスは状態遷移表を包含しているのでは？と思いますが、まだ確証がありません。
かつてこのブログでは、画面遷移表というものを考えて、そこからシナリオを作れないかというエントリを書きました。
この画面遷移表の悩みとして、モーダル/モードレスの表現方法や、同じ画面の中での遷移の扱いがありましたが、SFをマトリクスではそういうことを全然気にしなくてもよさそう。
ただし、アクターごとの機能の実行権限については、同じ悩みを抱えているようですね。また、機能数が多くなるとマトリクスが爆発するのことも変わらないので、うまく分割する方法も模索する必要がありそうと感じました。
ただし、アクターごとの機能の実行権限については、同じ悩みを抱えているようですね。また、機能数が多くなるとマトリクスが爆発するのことも変わらないので、うまく分割する方法も模索する必要がありそうと感じました。
その4はコチラです。
