kozawa のたまに気になること

リンクの少ないでもぶろぐ・・・にせぶろぐ?
スポンサーサイト

一定期間更新がないため広告を表示しています

| - | | - | - |
なごやかJava ゆるふわテストツール編
なごやかJava ゆるふわテストツール編 - connpass`に参加しての感想を。
私は体調不良で遅れて参加だたですが(発表で言えば「Selenium導入事例紹介(仮)」の終わりごろから参加。時間は押して進行してたので14:30頃だったかしら)。

みなさんすばらしい発表でした。といっても自分がふぬけでとても理解し切れてないので、感想もまともに言えません。

きょんさん夫婦が子連れ(乳児)参加ということでお二方もうまく子供をあやしながら(あれは大変であったはずである)、みんな快く迎えていて、その辺は模範ともいえるようなところではありますが、きょんさんリスペクト。

まともに感想なんか言えないので、発表「テストの自動化を考える前に」を伺って自分の自分が見かけた「テストでひどい目にあう例(ただし、非TDD。非TDDにおける部分的テスト自動化含む)」を書いてみようかな。もしこんなだめなやり方でTDD 目指すとTDDにもなれずにただただ泣きを見る、と思います。(もし、フリータイムがあったらこういう話をしたらよかったんだろうか。いや私のようなヘタレな話題ではダメだよなぁ…。資料のない即興プレゼンへたっぴぃだしなおのことだ) ※TDDと呼べるものでなければテストの自動化は意味がないなどという意図はありません。念のため

例1)
モジュール単位のテスト自動化がまったくなくて「画面からDBまで結合」した大きな単位でテストの自動化を入れたある例。
そこで「一つのテストだなるべく多くの項目をチェックできるようにテスト設計をしっかりすること」という指示が。
仕様が固定された範囲内でのバグ取りのための再テストの時はまだよかったが、一度テスト完了Fixの後、仕様変更後には、修正範囲が限定的であっても、テスト仕様(自動化データ)の修正点があまりに多すぎて再利用を前提とした予算・工程は組まれず、捨てられた。
これは、まぁ、自動化に悲劇というよりテスト仕様の再利用の悲劇といった方がいいかもしれませんが(自動化以外の仕様やin/out条件定義作業の方がずっとコストがかかっているので)、自動化部分に投じたコストも回収できたかどうか怪しい…。まぁ、自動化自体のコストはこの例ではゴミだったかもしれないです(ツールもアホではないので)

例2)
VisualStudioの単体テスト機能を使って、「テストによるコードカバレッジ100%」になるようにテストコードを書くことを命じられたあるプロジェクト。もちろん、これも、TDDに向かないコードに対しての指示でした(ただ、このプロジェクトは既存コードの低予算でのマイグレーション案件だったので、そもそも既存コードあり、リファクタリング予算なし、という制約だった)。
「バカでかくて複雑な単一メソッド」が癌で、仕様変更なり大きな回収が入る度にカバレッジ100%行かなくなってしまった。ところが、その主な理由は、その後通らなくなってしまったコードに問題があるからではなく、ある修正のために、その部分を通る条件となる元データがかわってしまったが、その条件を満たすデータを作り出すのがあまりに大変であった例。
最初だけ100%で、以下は100%をあきらめるという運用で回避状態だったわけですが、こいつの場合も、当初書いたテストコードは「必要十分」でないゴミが発生したわけです(まともなTDDでものちに要らなくなるテストがゼロと決まってはいないでしょうが、ゴミ発生率が高くて割が合わなかった、という話です)。
テスト自動化自体がまったく無駄だったということはないのですが、コスパは悪かったし、一度かかげた100%が捨てられる等、品質目的に対してかかげられた施策が途中でよれたわけで、品質管理の観点からもどうだったんですかね(現実的に目標や対策を途中で見直すことが悪いというわけではないのですが、なし崩しだとどうなんすかね、評価もしづらいので…)
こちらの場合は、こういうものだと割り切ってやる限りにおいてはコスパが悪いといっても許容範囲だったかもしれない。。。

すんません。マサカリ投げて私に勉強させてください…。
| pc/net | 10:48 | comments(1) | trackbacks(0) |
デシジョンテーブルでMECEをニッチに突き詰めたら実は奥が深いかもしれない話

この記事は、主にITシステム設計書書きな人な気がしまして、それ以外の人にも役に立つことがありますが、なにぶんニッチです。ななめ読みしてか
もっというとフローチャート脳な人向けの記事かもしれません。

さて、デシジョンテーブルとは何ぞやというと、デシジョン・テーブルを活用するのようにいい記事がありますので、そこを読んでもらうとよいでしょう。

例えば、設計書で「この場合はこれをやって、この場合はこれをやる」みたいな話、まぁ条件と結果が1対1とかなら、いいんですけど、これが複雑になった場合、「人間が読む文書」として、網羅性とかそういうのを見落としやすくなるんですよね。目でチェックの漏れが起きやすい。手続き型言語プログラマーやフローチャート脳の人が設計書を書くとif-elseのように

1)何々ならば
1−1)何々する
2)何々でなければ
1−2)何々する
みたいな設計書を書きがちです。
このぐらいならまだいいんですけど、組み合わせやifの階層が深くなると、以下のようなデシジョンテーブル的な表現の方が組み合わせと結果の組み合わせの誤りをチェックをしやすくなります。デシジョンテーブル、素敵です。
場合分けについての、漏れとか重複とかのミスを防ぐ方法の一つとして使えます。

で、ここからが、私が気になっているもっとニッチな話になります。

デシジョン・テーブルを活用する の最初の例を見ましょう。これでいうと条件記述が3つで、すべてYesとNoだけの値を取っています。
この例の場合、「レンジ時間セット」と「トースト時間セット」は同時には成り立たないという前提で書かれています。読み手がそれを誤解する恐れがないときはこれでもいいのですが、網羅性の漏れチェックを容易にするという観点から私が推奨したい記述方法の解説を始めます。もちろん、こういうのはドキュメントの目的次第ですがそれは大前提として…。

まずは網羅性や重複などがないことを重視します。
デシジョンテーブル記事図0
しかし、これに厳格にこだわると、条件の数が増えた時
1)条件記述が多い時
2)条件指定の値の種類が多い時
に全部の組み合わせを入れるととんでもないことになり、結局「人間の目じゃ見てらんないよ」という点において大差ないじゃないか、ということになると思います(条件部分の場合分けの漏れや重複の排除だけならロジカルに並んでさえいれば根性でチェックする余地はありますが、動作記述部が合ってるかを他の条件との関連を見ながらチェックするなどを考えると絶望的になると思います。特に動作記述部分の内容が条件毎にある程度関連があって離れた行同士で規則性があるような場合とか、見るのが大変です。 ※余談、プログラムでチェックするとか、Excelのフィルタでチェックするのであって目だけで見るわけじゃないよ、という方向の解決策を探すなら以下の話はあまり関係がなくなります)。

そこで、条件部のミスしなさと表のサイズ爆発防止をいい感じで両立する方法はないか、といった時、例えばこういう書き方もできます。今回の例の表だと、結果的にこのように書き換えても意味が同じになります。
デシジョンテーブル記事図0.5
※ここでこっそり「不問」という表現を入れてあります。これは便利な簡略化方法で有用だと思います(-とか他にも記法はありますが、「不問」が誤解の余地が少なくて個人的お勧めです)。
デシジョンテーブル記事図1

これの欠点の一つとして、条件記述の並び順をかえてしまっているので、逆に見づらくなっている面があって万能ではないのです。が、ひとまずこの方法を使った場合の話を続けます。また、こういうまとめ方は表の改定容易性を下げている側面もあると思いますがそれも脇におきます。

さて、次が「条件指定の値の種類が多い時」の問題です。ここで「レンジの生産工場」を追加の条件とし、実は工場は100以上ある、とします。
デシジョンテーブル記事図2
元の定義通り全部書いてると、表がすごいことになります。もちろん、それでも書いておくべき名ことというのはあるので、その時はそういうものとして対処を考えるしかないですが妙案はここにはありません。しかし、「漏れもダブりもない」ことをチェックするだけでも大変で、その上で、それぞれ全部についての他の項目や結果との整合を確かめるのも涙目です。
これを、工場が100個あるとはいえ、いくつかのグループに分けることができる場合、見かけの見通しは少しよくなります。まとめた場合、それぞれが一グループであることの正しさも見なければいけないので、一長一短ではあります。※少し乱暴に言えば、技術者よりの人がみる仕様書的なものや辞書的なものなら全部個別記述してなんぼでしょうし、業務の場合分けなどは、これとこれが同じ、と固められて見えることのメリットは大きいと思います。
デシジョンテーブル記事図3

ここで、こういう記述もあり得ます。
デシジョンテーブル記事図4
条件「レンジの生産工場」に項目の漏れがないということは割と容易にわかります ※記述された仕様全体として正しいかはまた別ですが、一覧性がいい方が全体をチェックしやすいので、そこにメリットがあります。
業務の仕様書で条件記述(今回の表で言う条件の縦の個数)が多数のものだと、しばしばこういうのがあります。
「商品の品番コードを条件とする」みたいな場合には、どうしてもホワイトリストで網羅することができず、「〜以外」を条件に入れないと網羅性に問題があることがあるので、今回の私がこれを書いている目的では「〜以外」は積極的に使うべきという発想になります。もちろん、網羅性が自明である時はあります。レンジ時間でYとNの二値であるのが自明なのに「〜以外」の出る幕があるのかと言われると、この場合は要らないと思います。しかし、大量のドキュメントをこの方式で統一しようとするときっと「どれが自明でどれが自明でないか」悩む場面には結局出くわすと思います。特段これにいい解決法とか思いつかないので、「〜以外」はなるべく使う方向でがんばって悩みましょうという程度にします。
この「〜以外」の一つの欠点は上記の「ABC」と「ABC以外」ぐらいだとたいした問題はないのですが、このリストが長くて複雑な場合、表のメンテ性が低下してしまいます。「1〜10」「13〜18」「21,25,29」に対して「1〜10,13〜18,21,25,29以外」とかだと、曖昧性はないけれど、二重記述による記述誤りのリスクが増えてしまいます(読むのも長くて鬱陶しいしその誤りがないかをチェックする負荷も高いということになる)。

「〜以外」の二重記述からの回避方法としては「左記以外」などというのもあります。これはこれで便利なのですが、「〜以外」の導入が結局別の問題を発生させる例が出てきてしまうので、次はその話です。
まずこの例だと、うまく行きそうな気がします。
デシジョンテーブル記事図5

しかし、こちらの例だと、問題があります。
デシジョンテーブル記事図6 「左記」が指定する範囲がわかりにくいのです。今回私の使っている階層構造の条件表記だと、最上位の条件では誤解の余地がほぼないのですが、二段目以降に使うと途端に問題が起きます。
まぁこれも、読み方を以下のように上の段で絞られた範囲とする、などと定義することで回避することも可能は可能ですが、誤読誘発の恐れは増えます。また、「このルールに従ってみんなで書いてね」という標準化に使うと、このルールが徹底されないでめんどくさいことになるリスクは、ここまで書いてきた他のルールと比べても高いのではと推定します(経験談を元に可能性を推定しています)。
デシジョンテーブル記事図7

今回のお題はひとまずここまでです。もっとこれが何を言わんとしているのかもっと明瞭に伝えるには「一見大丈夫に見えるけどMECE的に間違ってる例」や「一見大丈夫に見えるけど解釈に揺れの余地がある誤解を招く例」を例題として色々作って演習問題にするのが一番よいのかもしれないなぁと今更思っています。もっと分かり易く書けば有用度が上がる記事になるのになどと思いつつ今回の品質で妥協して公開します。

まとめると(話を蒸し返しているのですが)、冒頭にリンクした記事でも仕様の記述の明確化の手段としてデシジョンテーブルを紹介しています。
私の問題意識もそこで、しばしばエンジニアは設計書にフローチャート式だったり、if分岐の羅列で書いてしまうのです。これが、ロジックが正しいのかを非エンジニアの人間がチェックするのが難しくなるのでは、それを比較的容易にしたいという方法の一つとしてデシジョンテーブルを持ち出しています。エンジニアでもif分岐の羅列だと、MECEのチェックやロジックの正しさのチェックは結局難しくなります。
仕様記述書の書式として、作業者(ワーカー/PG)にこの方式を強いることでフローチャート/if文式より、「レビューしやすい」設計書ができるのでは、ということです。
ただ、ここまでに色々書いてきて「この場合はうんたら」というのがいくつか出ています。書きたいものが何かによって最適な表はきっとかわります。杓子定規にルール化して守らせると、場合によってとんでもない不自由な表が出来上がりかねません。この辺に標準化ルールとしてのデシジョンテーブル表記法工夫の限界があります。都度表記の利点と限界を加味して工夫してコンパクトにまとめればもっとも都合がよいのですが…。

| pc/net | 08:30 | comments(0) | trackbacks(0) |
名古屋合同懇親会 2014 忘年会
NGK2014B / 名古屋合同懇親会 2014 忘年会
とっても久々にこの手のイベントに顔を出した気がします。
というかNGKははじめてです…orz。 私が存じ上げない方もさくさんでした。

みなさん個性的かつレベルの高いLTで、自分の老害っぷりを再認識して死にたみが高まりました。
順不同で適当にコメントを書きます。雑すぎて失礼な感じになってますが、みなさんリスペクトしてますし、何より私自身の生存報告として書いてる感じなので、なにとぞご容赦ください。

進化するVimはどこへ行くのか。
入院中の点滴等ではりがぐさぐさ状態だとDSみたいなゲーム機は両手本気操作で死ぬ。そりゃそうだ。
ITプランニングさんかっこいい。
OpenStreetMap、興味を持って以降、まともなGPS関係のガジェットへの出費が出来てなくてあこがれだけ抱くばかり…今度こそもうちょっとまじめにいじってみたい…。
IPv6どこへいく。
misocaさん、まだまだ人材募集中広告出されてるようで、実にうらやましい限りです。自分もそういうのに賭けてみたいわぁ。金じゃなく。
フィールドワークさんの帳票素敵。オフィスが愛知県内でも個性的なポジションにあるようで、光る魅力的な企業。
concrete5、katzuenoさんから色々すばらしさを聞いてきましたが、ちゃんとその魅力を理解できるひど調べたことがないのがちょっと自分がもったいない。なによりuenoさんご結婚おめでとうございます。
よんたさんの求人アピール。まだ若いんだし、若いからこそ、こういうコミュニティにある企業さんの中でいい話がまとまったりしそうな勝手な期待をします。まだ若いんだし。年齢だけの問題じゃないけど、私がやってもお祈りアタックを食らいまくるので、本当にお先真っ暗です。
登別クマ牧場、行きたいんですけどね…北海道に上陸したことがない…。
有栖川電算さん、あのラジオ体操アプリ、あれって腰に入れて使うのが正解なんでしょうか。使い方がわからないのですが。そうやってカロリー測定されてるんでしょうか。
えいとすさんのジョブチェンジ。優秀な方なので、さすがです。
ぶれいすさんのExcelで使えるFCellのお話。超ほしい。
maedaさんのEmacsの話。まえださんかっくいい。
smogamiさんのお話、Javaもっと勉強したい…。
コスモルートさんもとがったことやってますね。活躍を応援します。
みずぴー大先生、iOSでSKKとか、クレイジーな素敵なこと。リリースされたら入れてみます。
RKTMさん、登山のすすめがかっこいい…運動したい。。。
こくぼさんの「子持ちになるとかわる生活あるある」。まぁ、そうですね。しまじろうの侵略ぶりに抵抗するの、難易度高いです。
dabitsさんの発表もかっこよかったー。
ネットモチ、実は私は食べてません。フィリップさん今度食べさせてください。

みなさんからエネルギーをもらうとともに死にたみもなかなか刺激された一日でございました。

 
| pc/net | 09:03 | comments(0) | trackbacks(0) |
OSC Nagoya 2012

オープンソースカンファレンス2012 Nagoya - オープンソースの文化祭! に少しだけ行ってきました。

まぁ、色々他の予定との都合があってあんまり居られなかったんですけど。あと、あちこち体を痛めていてたちっぱがつらかったのもある><。
時間の都合その他で聞けたセミナーはオープンソースカンファレンス2012 Nagoya - イベント案内 | 2012-05-12 (土): 全てのエンジニアのためのWeb標準技術とのつきあい方だけでした。

講演の50分の中で講師が「こんなことを言うとMozilla Japanの浅井さん(dynamis)にお壊れるけど」とかざっと数えて7回ぐらいは浅井さんがどーのって言ってたと思う。満席すぎて座れなくって足が痛かったの…。

その他ブース感想とか。OSC浜松やる予定なんだー。浜松ぐらいの都市でやるのはそれはそれで地元へ広がりやすくていいかもね、とか。Mozilla Japanブースは人が多くって、昼過ぎ浅井さんが休む暇がなさそうだった…。LibreOfficeのアンケートに答えたり。毎年恒例スタンプラリーやってきたり。それにしても萌えキャラを全面に出したブースの多さが。増えましたねぇ。傾向として中小企業でわざわざOSCに出展する企業により目立つ気がしたのは気のせいなのかなんなのか。コミュニティ系でもわんくまさんも同人誌かわいいし(本の中身もコミュニティも勿論いいですよ!)、プロ生さんもいいキャラしてるし。まぁいろいろで思い出したらまだ書く事はいっぱいありそうだけどさっさとアップしてしまおう。

| pc/net | 18:30 | comments(0) | trackbacks(0) |
plug and pray

plug and prayというのはITスラングで、PnPとは【Plug and Play】(プラグアンドプレイ) - 意味/解説/説明/定義 : IT用語辞典を皮肉って、「指したら祈れ」(動くかどうかは神のみぞ知る)というまぁ、ITエンジニア系の人なら有名なネタというアレですが、そういうタイトルの映画が2010年制作で、存在します。ネタではないエンジニアリングに関するドキュメンタリーのようです。

…っていうか昨日存在を知ったので見たいなぁと思っただけですが。日本の研究者へのインタビュー(日本語)も出てくるようです。

公式サイト(ドイツ語) Plug ] Pray – Ab 11. November 2010 im Kino – offizielle Seite
英語での公式サイト Plug & Pray - Documentary film - Artificial Intelligence - [[[maschafilm]]]
映画情報(英語) IMDb - Plug & Pray (2010)
予告編(英語) Joseph Weizenbaum: Plug & Pray (movie trailer) - YouTube
日本語で書かれた紹介 2011-10-04 - ./configure --with-blog=nakazawa (中沢実)
日本語で書かれた言及例 Twitter / @getrobo: ドイツでロボットに関するドキュメンタリー映画「Plu ...
映画祭で賞を取ったようだ バイエルン映画賞2011 発表! 海から始まる!?/ウェブリブログ
英語版のDVDはamazonで買えそうだけど。見てみたいなー。

| pc/net | 05:32 | comments(0) | trackbacks(0) |
Firefox3 Meter レビュープラス
    123
45678910
11121314151617
18192021222324
252627282930 
<< June 2017 >>
+ NEW ENTRIES
+ CATEGORIES
+ ARCHIVES
+ LINKS
+ PROFILE