ソフトウェアの品質を学びまくる2.0

ソフトウェアの品質、テストなどについて学んだことを記録するブログです。

CFDの補習会でさらなる学びを得た(つもり) - その3

 補習会の終盤は、CFDに関する質問に、秋山さんが答えてくださるという内容でした。その中から、いくつか選んで紹介いたします。

つなぐとグチャグチャ複雑になるのは?

 CFDを描くときの悩みとして、「つなぎ方がよくわからない」「つなぐと、ぐちゃぐちゃになってしまう」というものがあるようです。
 その原因は、同値図と同値クラスが多すぎるせいであり、もっと小さい範囲での単体テストを徹底的にやっておくことがコツだと習いました。そのときのCFDは同値図がせいぜい2個。この後に、それぞれの範囲をズームアウトして見れば、シンプルになる。という2段階で、進めていくのだそうです。

どこまで組み合わせればいいの?

 流れ線を引く際、同値図間の同値クラスを、どのように組み合わるべきでしょうか。
 その原則は、「同値図同士に関連があるのであれば、有効クラスは掛け算で組み合わせる」。特に単体テストについては、関連のあるなしに関わらず掛け算でやるという意見があるとのことです。
 一方システムテストまで行くと、各機能が凝集しているはずなので、関連がなければやらない。といううことのようです。

CEG(原因結果グラフ)との違いは?

 ザックリいうと、CEGは処理の順番を問わない((REQ制約で順番を縛ることで、テストケースを削減することはできます。ため、実装を把握していなくても作ることができるのに対し、CFDは実装を意識しないといけない。前者がブラックボックス、後者がホワイトボックス。
 わたし自身は、CEGとCFDとは、表現方法が違うだけで、本質的に同一のものと考えていただけに、意外なお話でした。外部仕様からテストケースを作る場合は、CEGの方が適しているのですね。
 他にも色々な話題があったのですが、消化できていないため、うまく紹介できません。
 そのうちの1つ、「機能図式」については盛り上がったので、自分でも論文を読んでいるところです。この表現形式は本当に、仕事にそのまま使えそうな予感がしています。
 なお、第5回勉強会も6/1に開催されましたが、FV表・FL表がまともに書けておらず、紹介できるほど理解が進みませんでした。加瀬さんのまとめてくださったtogetterのリンクはっときます!
 ん・・・?これってもしかして、落ちこぼれ始めているのかしら・・・。