TEF道勉強会'15#02『クラシフィケーションツリー法を描いてみよう！！』

みなさんこんにちは。
（おそらくブログでははじめまして）高木です。
投稿が遅れてしまったことをお詫びします。


2015年2回目のTEF道勉強会は、2/25(水)にMAQさん講師で「クラシフィケーションツリー法」について勉強会を行いました。

# 当日はお久しぶりの方、始めましての方2名を加え、9人での開催となりました！

■動機・困りごと
MAQさん自身、社内向けのAll-pair法の勉強会資料作成に向けて題材を考えていたとき、因子と水準の粒度がそろわないことがあり、その悩みを解決するためにクラシフィケーションツリー法（以下CTM）を勉強してみた、とのことでした。

■CTM概要
まずはCTMの概要について講義してもらいました。

・テスト対象の機能を分類木（クラシフィケーションツリー）でモデリングする
・対象の解釈の仕方によって、モデリングの結果が変わる場合がある。
・ルールさえ守れば書き方は自由

その書き方のルールとは、、、
ドメイン：分類木の最上位、機能名やテスト対象名
クラシフィケーション：因子
クラス：クラシフィケーションがとりうる値、同値クラス

is-a 関係
クラシフィケーション⇒クラス

has-a関係
ドメイン⇒クラシフィケーション
クラス⇒クラシフィケーション
クラシフィケーション⇒クラシフィケーション

・兄弟ノード（同じノードから出てくるノード）は、同じレベルのものにしましょう
・クラシフィケーションの兄弟は直交しているのが理想


■ワーク1
技法は習うより慣れろ、ということで早速身近なネタをCTMで表現してみることにしました。
最初のお題は「スープカレー」です。
今や北海道のソウルフードとして有名な「スープカレー」を、参加者みんなでCTMで分解してみました。

UED氏の例



OGS氏の例


Oさんはスープカレー自体に着目し、"具" "スープ" "ライス"のクラシフィケーションに分類、さらにそれぞれをクラシフィケーションおよびクラスに分類しています。それに対してUさんは、スープカレー自体に着目する前に、その"作り方"、"食べ方"にも分類しています。ひとつ抽象度が高いところから始まっているのがよくわかります。（ちなみに高木はOさん派でした。）
概要でも述べたように、どちらが正解ということはありません。

Uさん感想
クラスからクラスを出しそうになったけれど、
焼く⇒しっかり、表面のみ
間に"焼き具合"を挟むことによって整理しやすくなりました。"焼き具合"クラシフィケーションに"焼き方"クラシフィケーション（炭火、ガス）が兄弟で並びます。最初から"しっかり"というクラスを出してしまうと、"焼き方"は出てこなかったでしょう。


また、スープと具は同列のクラシフィケーションとして扱えるのか、という点で議論になりました。
Uさんの「スープと具は直交する。別々に決めるものなので、具によってスープの味が左右されることはない。逆もまた然り。」という意見に対し、MAQさんは「具によって選べるスープが限定される店もある。禁則が出てくるものもある。」と主張していました。
スープと具が直行するかどうかは店によって違うのでここでは結論が出ませんが、要は「同列なのに禁則が出てくるものに関して、CTMではどのように整理するのだろう」という点で議論になりました。

その他の意見として、
・関連性が高いと兄弟にはならない。後から禁則を考えないといけなくなる
・最初は禁則まで考えないで、発散させてもいいのでは？
・たくさん出してから、禁則で整理してもよさそう
とありました。


■ワーク2
2つ目のワークとして、「表計算ソフトのオブジェクトのプロパティのうち、"塗りつぶし" "線の色" "線のスタイル"」についてです。
普段よく使う機能なので楽勝か？と思われたのですが、これが複雑ですぐに発散する･･･。

実は、講師のMAQさんが参加者を躓かせるためにわざと発散するネタをワークの題材として選んできたのでした。さすがSっ子。
こういう複雑な場合は手書きだとすぐに限界が来てしまいますが、マインドマップツールを活用すると書きやすそうでした。
みなさんも是非チャレンジしてみてください！


■All-pairとCTM
さて、MAQさんの当初の困りごとだったAll-pair法の因子の抽出はうまくいったのでしょうか･･･？

組み合わせテストを設計するときの困りごとのうち
・因子がよくわからなくなる
⇒CTMに整理することでわかりやすくなった（解決）
・因子の粒度をそろえたくなる
⇒CTMに整理することで自然と粒度がそろう
⇒粒度がそろっていないくても、重点的に確認したい項目をピックアップできるようになった

社内勉強会のAll-pair法の講義もうまくいったようです。
よかったですね、MAQさん！！

参加した皆さんからも、「すぐに使えそう」 「組み合わせテストだけでなく、単に機能の整理にも使えそう」 「スープカレーが作りなくなった」との感想がありました。

MAQさん、ありがとうございました。
次はFさんの登場です！


■その後は、、、
新しい人を交えて終電間際まで呑んでました･･･。
Uさんがやたらとどうでも良い事を熱弁していて、それがみんなのツボに入ったことだけ覚えていますが、何のことだったかさっぱり覚えていません･･･。どんな話しいましたっけ？＞Uさん

高木

TEF道勉強会'15#01『新しい利用時の品質とシステム／ソフトウェア製品品質特性』

みなさんこんにちは。（またまた）小楠です(^_^)
今年のTEF道は、毎月一人一回テーマを決めてTEF道内で講義する！という目標を立てました。

輝かしい第1回目は、2/4（水）に上記のタイトルの内容で、安達さんがISO25010 について講義してくださいました！
が、私、インフルエンザやJaSST東京の参加などで、レポートのアップが非常に遅くなりました。。。すみません(･д･`●)

品質特性に書いてあることは難しいので、まず、日常生活の例を挙げてそれをシステムに置き換えて「システムとはなにか？」を考えた後、続いて同じように日常生活の例を品質特性に置き換えてわかりやすく考えていきました。このわかりやすさ、、、安達さん、さすがです！！！

まず、システムの外側の品質、利用時の品質について。
例えば、Amazon.comで商品を購入するときの例を利用時の品質に置き換えて考えると
・欲しいものが手に入る　→　有効性
・手間のかかりぐあい　→　効率性
・目的は達成されるけど、イヤなことが起こらない　→　リスク回避性
・商品を購入して最終的に満足したのか？　→　満足性
・コンテキストにどのくらい合っているのか？　→　利用状況網羅性

「そのシステムが誰をターゲットにして何を目指すのか？」を常に考えて利用者にあったシステムを考えなければならないということですね！システムを作る側（例：開発組織）も、そしてシステムによるサービス を提供する側（例：発注組織も）も本来の目的が達成されたのか（今回のワーク では利用品質領域）を評価して把握することが大事なのに、なかなかやっていないところが多いので、もっとやったほうがいいよね！ということを教えてくださいました。

ここで、利用時品質の主特性について５つの要素をモデル化してみましょうワークを行いましたφ(｡_｡*)
結果としては、みなさん異なるモデル図を書いていましたが同じことを言っていました。
言葉で簡単に言うと、「有効性、効率性、リスク回避性、利用状況網羅性を満たすことで、ユーザーの満足性につながる」ということをモデルで表していたカンジです。皆さんのイメージを匿名で一部載せてみます！

続いてシステムの内側の品質、システム／ソフトウェア製品品質特性について。
ISO9126の品質特性との違いやその内容についてわかりやすく説明してくださいました！
なお、こちらの主特性のモデル化については数名がモデル化してみようと思ってまだできていないとのこと。
挑戦した方がいらっしゃいましたらぜひご連絡を！！！

今回の勉強会を通じて安達さんが一番言いたかったことは以下のことだと思います。
「品質モデルは、システムを作るときに頭のなかにあるけど出すことができずにいるものを引き出すときの助けになるものであり、このモデルにしたがってシステムを作ればいいというわけではない。使い方を間違わないようにしてくださいね」ということ。

確かに私も、この品質特性モデルから考えると難しくなっちゃってもうダメ(>_<)となることが多いので上記のように忘備録的に使うともっと品質特性を楽しく使えるんじゃないかなーと思いましたヽ( ´ ∇ ｀ )ノ

その他参加者の皆さんから次のような感想が挙がっていました。
　・実例に当てはめる考え方でアプローチしてたので参考になった。
　・自分でもやっていたので助かりました。モデルを作ってみたが、時間軸やべん図を使うとよさそうとヒントをもらった。
　・システムの外と中で分けて考える、というのが参考になった。
　・実務に取り込みたい。これまでは表で整理していたがわかりにくかった。今回のようにモデル化するとよいかも。
　・品質モデルを漏れや抜けを発見する手段として使うのはよさそう。
　・使い方を間違わないようにしなくちゃ。

安達さん、ありがとうございました！
次回のTEF道の担当はMAQさんです！

ちなみに今回はこの後、たこ焼き食べましたよ～( ´艸｀)

NTTデータの町田欣史さんによるリスクベースドテストの勉強会

みなさんこんにちは。小楠です。
久々の更新になってしまいました・・・

2014/12/17に、なんと！！！
NTTデータの町田欣史さんが、TEF道で「リスクベースドテストにおけるリスク分析の妥当性評価手法の提案」について話してくださいました。

町田さんはQCDのバランスをとってテストを行うための解決策の一つとしてリスクベースドテストを行っているそうです。手を抜くところは手を抜き、しっかりやるところはしっかりやるというように効率よくテストができるように日々、実践と検証をされているのです！！そのお話を具体的に教えてくれましたヾ(*´∀`*)ﾉ 

リスクベースドテストを行う流れについては、とても具体的にお話ししてくださったのですが、要約するとこんな感じです。

(1)テスト対象（機能など）に欠陥が存在する可能性に関わる要因（リスク要因）をいくつか定める。

(2)(1)で挙げた要因ごとに、各テスト対象に対してリスクの大きさを1点～3点などの数値で評価する。

(3)それぞれのリスク要因に対する重みづけをして、テスト対象ごとに(2)で設定した数値の加重合計を求める。
　→リスクの発生確率に対するリスク値

(4)テスト対象に欠陥が存在した場合の影響度について、(1)～(3)と同様に評価する。
　→リスクの影響度に対するリスク値

(5)発生確率と影響度のそれぞれのリスク値を掛け合わせて、テスト対象ごとのリスク度を求める。

(6)リスク度（あるいは発生確率、影響度のリスク値）を基にリスクの高・中・低を定める。

(7)リスクの高いものについてはテストを増やし、低いものについてはテストを減らす。
　　・テストを増やす／減らす方法としては、観点やテスト技法の網羅度を変えるなどする。
　　・ベースライン（通常のボリュームのテストをする）をどこにするかはプロジェクトの特性によって変えている。
　　・ベースラインをリスク高にすれば全体のテスト量は減る（リソースが限られているときなど）
　　・ベースラインをリスク低にすれば全体のテスト量は増える（強化テストなど）

そして、上記のテストが妥当かどうかを検証したお話もしてくださいました。まとめると、こんな感じです。

・重回帰分析で妥当性を検証した
　→その結果、リスク要因と欠陥数の間に相関があるといえることがわかった。
・どのリスク要因が相関に寄与しているかを分析した
　→相関の低いリスク要因は、次の機能追加開発時に除外することも考えられる。
・影響に関するリスクと欠陥数の関係を分析した
　→重要度の高い欠陥は、影響度に関するリスクが高い機能から検出されていた結果となった。

今後はさらに実践を積み重ねてさらに検証を重ねるそうで、また続きをお聞きしたいですヾ(*´∀`*)ﾉ 
町田さん、またお待ちしております！

この後、時間いっぱい質疑応答が行われ、その後懇親会でブドウエビ食べましたー　ｷｬｯｷｬ(*´∀｀) (´∀｀*)ｳﾌﾌ
TEF道は去年はみんな忙しかったので、今年はもっとがんばりたいと思います♪

（参考）今回の講師のご紹介
町田さんってこんな方
コラム：テスト自動化の現状
本の紹介