読者です 読者をやめる 読者になる 読者になる

NaITE#12 「PFDワークショップ & JaSST'16 Tokyo 参加報告」

NaITEの12回目の勉強会に参加したので、参加レポートです。

 

テーマはPFDワークショップ&JaSST'16 Tokyo参加報告です。

 

 

JaSST Tokyo 2016 参加報告

www.slideshare.net

 

先日行われたJasstの参加報告です。

JaSSTソフトウェアテストシンポジウム-JaSST'16 Tokyo レポート

 

3つのセッションのみ取り上げられていますが、

実行委員会の3人がそれぞれ報告したいセッションを1つずつ決めて参加報告をしました。

JaSSTくらいの規模のイベントだと、セッションが被って全てには参加できないので、他の方が参加してその内容が聞けるというのは貴重だと思います。

 

 

PFDワークショップ

www.slideshare.net

 

 

PFDの概要説明と、PFDを書いてみようというセッションです。

PFDの詳しい書き方については、下記のPDFを参照してください。

http://homepage3.nifty.com/koha_hp/process/PFDform3.pdf

 

私はPFDは書いたことがありませんでした。

それどころか、なんとなくは知っているという程度で、詳しくはないという状態で参加しました。

 

PFDはプロセスフローダイアグラムの略称で、プロセスを図示するものです。

 

プロセスは時代によって変化するものであるから、プロセスは固定化させるのではなく、PFDによって安定化させることが重要であるとこのこと。

 

PFDはフローを示すものではなく、成果物がプロセスによってどう変化していくかを図示するツールになります。

 

 

セッションでは、「朝起きてから、家に出るまでにやったこと」。

初めてPFDを書いてみたのですが、全然書けませんでした。

 

最初に朝やったこと(プロセス)を羅列してみたのですが、インプットとアウトプットが何になるかよくわからず、プロセス同士も繋がらなかったです。

 

他の方も同じように考えていたらしく、PFDはプロセスの順序性というのは示さいという考え方が抜けていたようでした。

 

朝やったことを書くとなると結果として何をやったかになってしまうため、

やってみるとしたら「朝起きてから、家を出るまでにやらなければいけないこと」とテーマを変えてみるとやりやすいかもしれません。

 

PFDの書き方のコツとしては、

1,まず成果物(行動)を書き出す。

2,それらを関係でつなぐ

3,全体のMECEを見る

4,全体を調整する

5,他人と認識をあわせる

  認識が合わなかった場合は4に戻る

6,5で出来た成果物を計画化する

 

 

PFDを利用するときの大きなパターンとしては、

1,プロセスの新規作成のパターン

2,現状のプロセスを改善するパターン

 

1のパターンでは、図示することでブレストに使用することが出来ます

2のパターンでは、図示することで現状分析ができ、新しいプロセスを導入するときに、前後のプロセスなどをどう修正する必要があるのかが分かる

 

とのことでした。

 

 

今回の勉強会はPFDを書いてみて、ディスカッションが出来たため、とても勉強になりました。

勉強会はディスカッション形式が一番おもしろいのかなぁと思いました。

NaITE #11「ドメイン分析勉強会」

2週間くらい前に参加した勉強会のまとめです。

覚えている範囲で書いています。。。。

 

nagasaki-it-engineers.connpass.com

 

 

前回のWACATEでドメイン分析に関してのセッションがあり、みんな色々と疑問があったので、WACATEの延長でみんなでドメイン分析を勉強しようという内容です。

 

 

 

www.slideshare.net

 

ポケッ◯モンスター風な仕様書ドメイン分析が説明されています。

演習を通しての議論がメインな勉強会でした。

 

出た議論は下記です。

・Y軸のテストを行うときに、XはなぜすべてINポイントでテストするのか?Xが有効値の時にYもテストして正常系のテストとすればテストケースは減らせるのではないか?

→ テストがNGだった時に何が原因でテストがNGだったのかを分かりやすいようにするため、Xの境界値の時はYは正常値とする。Yの境界値をテストするときはXは正常値とする。

 

・INポイントはすべて同じ値ではあまり意味ないのではないか?

→ ドメイン分析は、グラフなどにした時の境界値の傾きなどをテストする。INポイントは有効値でも同じとするのではなく、本当はすこしずつずらすのが良い。

 

・1問目の演習の問題は値が上限値を越えた場合の動作が記述されていないが、テストすべきなのか?

→ ドメイン分析の作成物は仕様書の出来が反映される。逆に、仕様書に書かれていない暗黙知となっているものを見つけることが出来るかもしれない。

 

・境界値分析でテストケースを作成した時よりも、ドメイン分析でテストケースを作成した時のほうがテストケースが少なくなる。境界値分析とドメイン分析で出るテストの差分はやらなくていいということになるのか?

→ テスト技法は時と場合によって使い分ける必要がある。演習1のような要素が2つのものは境界値分析で十分かも知れない。しかし、要素が4つ以上、5つ以上とグラフ化できないようになってきた時に整理する方法としてドメイン分析が有効となる時もある。

また、演習1の問題では、”進化する”というドメインのみに着目するのではなく、本来は”進化しない”というドメイン、”値の有効値”というドメインの3つのドメインが存在する。この3つのドメインは分けてドメインテストマトリックスを作成すると良いかもしれない。

 

・2次元、3次元のグラフを書くのはできるが、4次元以上となるとグラフが作成できない。

→ グラフは書くと分かりやすいが、ドメイン分析を行う上では必須ではない。むしろ、グラフに出来ないようなときにドメイン分析を使用すると良いかもしれない。

 

 

 

 

WACATEの延長のような議論ベースの勉強会でとても楽しかったです。

 

長崎IT技術者会 第10回勉強会 「Turnip&アジャイルプラクティス導入事例&メトリクス入門」

長崎IT技術者会 第10回勉強会 「Turnip & アジャイルプラクティス導入事例&メトリクス入門」に参加してきました。

 

今回は割りとテーマがバラバラでした。

勉強会に参加している人でも専門は結構異なるので、自分が興味を持っていることを、とりあえず話してみようっていうようなスタンスの会だったと思います。

 

Turnipによるエンドツーエンドテストことはじめ

www.slideshare.net

 

Turnipとはどういうものかという紹介です。

RSpecで自動テストを行うときに、ユーザ目線のテストを実現する方法って感じなのかなと思いました。

 

 

アジャイルプラクティス導入事例

www.slideshare.net

 

これは私の発表です。

アジャイルというとちょっと敷居が高いけれど、アジャイルのプラクティスはプロジェクト改善に繋がると思うので、適応できるものもあるよっていう紹介です。

プランニングポーカーを実際にやってみたのですが、なんとなくの雰囲気だけでも伝わっていれば満足です。

 

めとりくすおたくのススメ 〜初級編〜

www.slideshare.net

 

ソースコードのメトリクスで品質が低いところがわかるという話です。

understandやLattixはどちらも有償ツールで特にLattixはかなり高いツールです。

それでもメトリクスを取ることの効果はあったとのこと。

understandはソースコードに着目した解析ツールで、Lattixはアーキテクチャに着目した解説ツールらしいです。

 

 

WACATE 2015 冬 参加報告

www.slideshare.net

 

WACATEの振り返りとか感想です。