Hamata log

[2018-06-16]思いつきで開設したものの、続くのかどうか・・・

JaSST関西’18に行ってきた話(セッション 3B-2「ロジックツリーによる不具合分析からのテストの補強」編)

もう記憶が遠のきまくりですが、JaSSTの話の続きです・・・。

 

セッション 3B-2「ロジックツリーによる不具合分析からのテストの補強」

http://www.jasst.jp/symposium/jasst18kansai/details.html#S3B-2

参考:https://www.veriserve.co.jp/event_seminar/2018/jasst_2018_kansai.html

 

3B-2ということで、並行セッションの2コマ目は設計セッションから選択してみました。(クロージングのときに実行委員の方から設計セッションと管理セッションの分類にはそれほど深い意味はない、と暴露されてしまいましたが・・・)

 

このセッションでは設計は設計でも「不具合分析」からのテストの「補強」です。

これは結構私の業務上で時々ある話でして、どんな流れでこういうパターンになるかというと、まず思うように品質が上がっていかない状況で開発の後半で思わぬ不具合に遭遇します。そうなると、「こんなのが出るってことは他にもチェックが甘いところがあるんじゃないか?補強を考えてくれ」ということになります。なるのですが当然内容をどうする、という段で今現在漏れがあるので、今のテストの延長ではちょっと、ということになって何か不足している観点なり切り口をどこからから入手できないか?と悩むのが次のステップ。そしてそうそう自分たちの抜けが意識できるわけもないので壁にあたると。で、なんとか手近なものからということで、例えば下流工程から指摘をくらっている不具合を分析して先回りできないか、みたいな話になるという感じで不具合分析に追われた経験持ちの私です。

なので結構このコマ興味ありまして、選択してみた次第です。

 ですが、「ロジックツリー」が少々独特でした。ロジックツリーというとものごとをMECEに枝分かれさせて分解していくやつを思い浮かべると思うのですが、この講演でいうロジックツリーというのはNGTのことでした。NGTというのはNotation for Generic Testingの略で電通大のにしさんの提唱しているVSTeP(Viewpoint-based Software Test Engineering Process)で使用する記法ですね。

お、じゃぁこの不具合分析はVSTePでやるのかな、と思ったのですが、どうも聞いていると記法を利用する、というスタイルのようです。でもとっつきやすさという意味ではそのほうがいいかもしれないな、と思いました。(とはいえNGTに親しんでいないので、この後の説明の理解に難儀しましたが)

(講演資料が今のところ公開されていないので、文章だけではちょっと伝わらないかもと思いつつ続けます・・・。)

 

そして何をツリー化するのかというと不具合の要素、ということでした。これがまたなかなか曖昧な感じですが、例えば

 

「バックグラウンドへ遷移したアプリに30秒以内に復帰した際に、再生コントロールが正しく動作しない」

 

という不具合だと「バックグラウンド遷移」「再生コントロールが正しく動作しない」「30秒以内」あたりが要素ということになるようです。なんとなくは分かるのですが、他人にうまく説明できるかというとできないなぁ、という感じ。講演中の補足を引用すると

  • 発生しない条件と発生する条件の差異を抽出する
  • 環境-前提―手順(=トリガ)―振る舞い を意識する

というあたりがポイントのようです。

 

そしてここで例になっている「30秒以内に復帰」に関して、実際の不具合例では17秒以上経過すると問題があるということがわかって改修した箇所、という説明があったので、ちょっと引っかかって質問してみました。

 

『なぜ17秒ではなくて30秒を要素として抽出するのか?』と。

 

私が思ったのは、「17秒が境界として存在するのであればその周囲を狙うのが不具合分析としては素直なのでは?」ということだったのですが、回答はちょっと意外な方向から来ました。

 

「我々は第三者検証会社なので不具合に関してその後の情報を得られることが少なく、なので改修に際して得られた情報はこの取り組みでは使用しない方針にしています」ということでした。

 

・・・。なんだか申し訳ない気持ちになってしまいました。私はたまたま不具合改修内容も確認できるような立場で業務をしているのですが、不具合報告しっぱなしでその後のフィードバックがないことも珍しくない、というのは少々衝撃的でした。そんな業務形態もあるのね・・・。

(実際にはこの例でも改修情報についてコメントがあったくらいなので、全然情報が無いわけでは無いでしょうし、得られた範囲で情報使っているとは思いますが、それにしてもなかなか・・・)

 

と、話をもとに戻して要素をNGTでツリーにする話。

ただ、前述したようにNGTの予備知識が無いので、このあたりが理解に難渋しました。

そのあたりは置いておいて、要素間の関係としては以下の4つがあるそうです。

  • And
  • Then
  • After
  • Behavior

多分このへんは全然わかってなかったので今後もしっかりフォローしないとダメだな・・・(泣)。

 

ついで要素をつなげていきます。このあたりもなんとなくな雰囲気になるのですが

  • 画面状態とある機能が動作している状態
  • 画面状態の遷移
  • 画面状態と各操作
  • 端末種類と各種操作

 

あとはこれをフレームワーク(環境―条件―状態―操作)に当てはめるということで新規なテストケースにしていきます。

要素を新たにつなげたルートをフレームワーク上でたどるといいようです。

 

まとめとしてはこの手法である程度不具合を追加で発見できたこと、また、実施タイミングとしては進捗が75%くらいのところでやるのがいいよ、ということでした。

 

感想としては

 まずはこの方法をやるのであれば、NGTちゃんと勉強しないといけないな。

(実際演者さんの会社ではにしさんをお招きして勉強会したそうです)

というのと、もう少し要素の抽出方法や組み合わせ方を言語化というかきっちりさせたいなぁ、というあたりでしょうか。似たようなシチュエーションに遭遇することがあるので、非常によくわかるのですが、うまいこと機能や状況をシステマティックに組み合わせるというとろまでもう一歩な感じのもどかしさを感じました。多分講演した本人が一番そのあたりは実感されているのではないかという気がします。「コツ」という表現をされていました、できれば使いたくない、と思ってそうだなーと。