NaITE#12 「PFDワークショップ & JaSST'16 Tokyo 参加報告」
NaITEの12回目の勉強会に参加したので、参加レポートです。
テーマはPFDワークショップ&JaSST'16 Tokyo参加報告です。
JaSST Tokyo 2016 参加報告
先日行われたJasstの参加報告です。
JaSSTソフトウェアテストシンポジウム-JaSST'16 Tokyo レポート
3つのセッションのみ取り上げられていますが、
実行委員会の3人がそれぞれ報告したいセッションを1つずつ決めて参加報告をしました。
JaSSTくらいの規模のイベントだと、セッションが被って全てには参加できないので、他の方が参加してその内容が聞けるというのは貴重だと思います。
PFDワークショップ
PFDの概要説明と、PFDを書いてみようというセッションです。
PFDの詳しい書き方については、下記のPDFを参照してください。
http://homepage3.nifty.com/koha_hp/process/PFDform3.pdf
私はPFDは書いたことがありませんでした。
それどころか、なんとなくは知っているという程度で、詳しくはないという状態で参加しました。
PFDはプロセスフローダイアグラムの略称で、プロセスを図示するものです。
プロセスは時代によって変化するものであるから、プロセスは固定化させるのではなく、PFDによって安定化させることが重要であるとこのこと。
PFDはフローを示すものではなく、成果物がプロセスによってどう変化していくかを図示するツールになります。
セッションでは、「朝起きてから、家に出るまでにやったこと」。
初めてPFDを書いてみたのですが、全然書けませんでした。
最初に朝やったこと（プロセス）を羅列してみたのですが、インプットとアウトプットが何になるかよくわからず、プロセス同士も繋がらなかったです。
他の方も同じように考えていたらしく、PFDはプロセスの順序性というのは示さいという考え方が抜けていたようでした。
朝やったことを書くとなると結果として何をやったかになってしまうため、
やってみるとしたら「朝起きてから、家を出るまでにやらなければいけないこと」とテーマを変えてみるとやりやすいかもしれません。
PFDの書き方のコツとしては、
１，まず成果物（行動）を書き出す。
２，それらを関係でつなぐ
３，全体のMECEを見る
４，全体を調整する
５，他人と認識をあわせる
認識が合わなかった場合は4に戻る
６，５で出来た成果物を計画化する
PFDを利用するときの大きなパターンとしては、
１，プロセスの新規作成のパターン
２，現状のプロセスを改善するパターン
１のパターンでは、図示することでブレストに使用することが出来ます
２のパターンでは、図示することで現状分析ができ、新しいプロセスを導入するときに、前後のプロセスなどをどう修正する必要があるのかが分かる
とのことでした。
今回の勉強会はPFDを書いてみて、ディスカッションが出来たため、とても勉強になりました。
勉強会はディスカッション形式が一番おもしろいのかなぁと思いました。
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の延長のような議論ベースの勉強会でとても楽しかったです。
