NaITE #11「ドメイン分析勉強会」
２週間くらい前に参加した勉強会のまとめです。
覚えている範囲で書いています。。。。
nagasaki-it-engineers.connpass.com
前回のWACATEでドメイン分析に関してのセッションがあり、みんな色々と疑問があったので、WACATEの延長でみんなでドメイン分析を勉強しようという内容です。
ドメイン分析勉強会 from Kosuke Fujisawa
ポケッ◯モンスター風な仕様書でドメイン分析が説明されています。
演習を通しての議論がメインな勉強会でした。
出た議論は下記です。
・Y軸のテストを行うときに、XはなぜすべてINポイントでテストするのか？Xが有効値の時にYもテストして正常系のテストとすればテストケースは減らせるのではないか？
→ テストがNGだった時に何が原因でテストがNGだったのかを分かりやすいようにするため、Xの境界値の時はYは正常値とする。Yの境界値をテストするときはXは正常値とする。
・INポイントはすべて同じ値ではあまり意味ないのではないか？
→ ドメイン分析は、グラフなどにした時の境界値の傾きなどをテストする。INポイントは有効値でも同じとするのではなく、本当はすこしずつずらすのが良い。
・１問目の演習の問題は値が上限値を越えた場合の動作が記述されていないが、テストすべきなのか？
→ ドメイン分析の作成物は仕様書の出来が反映される。逆に、仕様書に書かれていない暗黙知となっているものを見つけることが出来るかもしれない。
・境界値分析でテストケースを作成した時よりも、ドメイン分析でテストケースを作成した時のほうがテストケースが少なくなる。境界値分析とドメイン分析で出るテストの差分はやらなくていいということになるのか？
→ テスト技法は時と場合によって使い分ける必要がある。演習１のような要素が２つのものは境界値分析で十分かも知れない。しかし、要素が４つ以上、５つ以上とグラフ化できないようになってきた時に整理する方法としてドメイン分析が有効となる時もある。
また、演習１の問題では、”進化する”というドメインのみに着目するのではなく、本来は”進化しない”というドメイン、”値の有効値”というドメインの３つのドメインが存在する。この３つのドメインは分けてドメインテストマトリックスを作成すると良いかもしれない。
・２次元、３次元のグラフを書くのはできるが、４次元以上となるとグラフが作成できない。
→ グラフは書くと分かりやすいが、ドメイン分析を行う上では必須ではない。むしろ、グラフに出来ないようなときにドメイン分析を使用すると良いかもしれない。
WACATEの延長のような議論ベースの勉強会でとても楽しかったです。
長崎ＩＴ技術者会 第１０回勉強会 「Turnip＆アジャイルプラクティス導入事例＆メトリクス入門」
長崎IT技術者会 第10回勉強会 「Turnip & アジャイルプラクティス導入事例＆メトリクス入門」に参加してきました。
今回は割りとテーマがバラバラでした。
勉強会に参加している人でも専門は結構異なるので、自分が興味を持っていることを、とりあえず話してみようっていうようなスタンスの会だったと思います。
Turnipによるエンドツーエンドテストことはじめ
Turnipとはどういうものかという紹介です。
RSpecで自動テストを行うときに、ユーザ目線のテストを実現する方法って感じなのかなと思いました。
アジャイルプラクティス導入事例
これは私の発表です。
アジャイルというとちょっと敷居が高いけれど、アジャイルのプラクティスはプロジェクト改善に繋がると思うので、適応できるものもあるよっていう紹介です。
プランニングポーカーを実際にやってみたのですが、なんとなくの雰囲気だけでも伝わっていれば満足です。
めとりくすおたくのススメ 〜初級編〜
めとりくすおたく from Asako Yanuki
ソースコードのメトリクスで品質が低いところがわかるという話です。
understandやLattixはどちらも有償ツールで特にLattixはかなり高いツールです。
それでもメトリクスを取ることの効果はあったとのこと。
understandはソースコードに着目した解析ツールで、Lattixはアーキテクチャに着目した解説ツールらしいです。
WACATE 2015 冬 参加報告
WACATEの振り返りとか感想です。
