@mkoszk まず、境界値テストはブラックボックステストと言い切ってあげたほうが良いと思います。それから怪しいパラメーターについてソースコードを読んで隠れた境界値を探すのはよいですが、ソースコードに「a〉5」と書いているなら5と6をテストするのは危険極まりないです。

posted at 07:25:04

@mkoszk 御意。私は前後の工程を理解する程度の意味でつかっていましたが今後気を付けたいと思います。

posted at 09:12:04

@mkoszk どうもありがとうございます。とても大変で（気も重いこと）と思いますがよろしくお願いいたします。

posted at 20:15:04

@mkoszk 描けると思うけどなぁ。その前の目的機能に分けるのは難しいかもしれないけど。ラルフチャートは作業だから。

posted at 00:00:11

@yumotsuyo @mkoszk そうそうじゃなーい。＞＜

posted at 00:02:39

@mkoszk 入力は期待値を求めるためのユーザの入力、ノイズはシステムの外からの想定外の入力、状態変数はシステムの中からの入出力ですから、区別に迷いようがないと思うのだけど、難しいのかなぁ。ノイズは全部出す必要ないですし。

posted at 00:08:33

@mkoszk バッチ処理のラルフチャートは難しいです。ごめんなさい。　←　いきなり降参。

posted at 00:16:33

@mkoszk DB処理のラルフチャートも、、、難しいです。　←　降参その２。いや、書けるんだけど、初心者にはむり。

posted at 00:17:34

@yumotsuyo @mkoszk はい。バッチやDB処理は、変数の上書き問題があるのでラルフチャートを分割してシリアライズしても後半の因子の水準が作れないのです。そこでたいていの人は詰まります。

posted at 00:23:47

@mkoszk ということは、「取消の取消」で例外処理か？ いや、「取消の取消の取消の取消」辺りか？ｗ

posted at 09:11:20

@mkoszk @yumotsuyo テストケースの粒度になってしまうと、もう、正常系と異常系の割合位しかレビューのポイントないですよ。

posted at 23:48:18

@yumotsuyo @mkoszk 「テストケース条件」って何ですか？

posted at 23:48:54

@mkoszk ありがとうございます。日科技連の「ソフトウェアテスト技法ドリルセミナー」で受講者に配布してくれることになりました。

posted at 23:58:02

@mkoszk ありがとうごうざいます。。。会社の方かな？

posted at 06:03:11

@mkoszk 大丈夫です。今晩、読むのが楽しみです！

posted at 06:50:00

@mkoszk 読みたいです！

posted at 17:43:22

@mkoszk ありがとうございます！！

posted at 18:43:13

@mkoszk @krsna_crespo 5問もですよー。みきおさんはパーフェクトだと思います。そうそう、問題を解いていると、「この問題を作ったのは鷲崎先生っぽいなー。　これは三紀夫さんでは？？」って思い浮かんで楽しかったです。

posted at 18:44:47

@mkoszk 「先手、みきお名人、いきなり端歩を突いてきました」「後手、やすはる永世名人、長考に入りました」「今、やすはる永世名人の頭の中では30階層位のNGTが展開されていると思います」……

posted at 11:57:00

@YasuharuNishi @mkoszk あー。明日までか。

posted at 20:07:08

@yumotsuyo @mkoszk 本当に、凄い技術です。あの技術を誰でも使えるようにしたいです。

posted at 23:30:35

@mkoszk USDMの振舞いは、システム要求だからテストレベルとして結合～システムテストあたりに限定されないかな？

posted at 09:20:18

@mkoszk とすると、ゆもつよからは、シナリオテストは作れないという理解であっていますか？

posted at 09:39:30

@mkoszk 基本的なところについて、厳密に考えるとどうなっているのかが、よく分からないのです。守備範囲とか。(^^;)

posted at 09:41:49

@mkoszk はい。ユースケーステストは作れると思います。でも、ユーザ要求（＋ユーザニーズ）に対するシナリオテストは作れないですよね。

posted at 09:45:56

@mkoszk あぁ。そうか。ちょっと理解が進みました。＜　QT @mkoszk 一覧に記述する際に、情報を落としているので、難しいかも。

posted at 09:46:58

@mkoszk そうなのかもしれません。ただ、テストカテゴリを作る時に、湯本さんならユーザ要求をカバーしているような気もします。やっぱり、テストカテゴリがキー（暗黙知）ですね。

posted at 09:52:48

@mkoszk 「理由＝目的＋制約」という山本修一郎さんの説はちょっと違うんじゃないかあなぁと思います。ちなみに、FV表に制約を書かないのは、テストでは制約はいったん取っ払って、あとで（ラルフチャートの時に）考えた方が良いからです。

posted at 18:50:30

@mkoszk 清水吉男さんの「理由」は、要求を出した人（依頼者）の「要求」を明確にするための道具と思っています。依頼者は要求を上手に伝えることができないですから、「理由」を問うことで正しく要求を捕えようとしているのだと思うのです。

posted at 20:51:59

@mkoszk 私のやり方では、「３．入力文書－処理－出力文書の単位で業務機能を挙げる。 」は「３．処理－出力文書の単位で業務機能を挙げる。 」です。あとは同じです。処理のための入力文書は見落としがちなので５でチェックします。

posted at 07:01:30

@mkoszk 成果物が概ね処理する順番に並んでいる表を２で作っていますのでDFDを描きながらで大丈夫ですよ。３の主目的は「処理に名前を付ける」です。３で入力まで書いてしまうと４で考えなくなってしまいます(自分だけかもしれませんが)。

posted at 08:10:33

@mkoszk 処理の切り出し(名前を付けるステップ３)が人によって変わると思います。

posted at 08:16:40

@mkoszk あ、お隣なのですね。切りの良いところでいいと思いますー。

posted at 18:55:53

はい。私は逆にユースケースについてわざわざ本まで読まなくてもいいやって思って読んでいなかったのです。 RT @mkoszk: @akiyama924 ユースケースではなく、ICONIXの解説本ですね。ユースケースを知りたいと思うと少し不満が残るかも。

posted at 09:25:43

@mkoszk ありがとうございます。次に読んでみます！

posted at 09:37:04

@mkoszk テスト環境設定ミスは不具合に入りません。私の基準ですが……。

posted at 18:11:36

@mkoszk 私の理解では、不具合は必ずインシデントですが、インシデントのなかにはその他に「誤解」があると書きました。テスト環境設定ミスは誤解を与えた要因の一つであり、インシデントではないと思っています。

posted at 18:21:05

@tulune @mkoszk 同じ時代を生きてきたから！（もっと失礼！？）

posted at 18:56:52

@tulune @mkoszk N社からいらっしゃった方、結構多いからなぁ。意外と文化近いのかもしれません。KさんがMさんと知り合いだったのにはびっくりしました。

posted at 20:01:46

@tulune @mkoszk その前にもあるのですよー（偉い人たちの移動が）。Kさんは多分ご存じのない方です。M野さんはＳＱｉＰなどでご活躍の方です。

posted at 20:17:56

@Unity1004 @MAQ69 @krsna_crespo @mkoszk これの29ページみたらなるほどと思いました。 http://t.co/PRf3vAzy

posted at 20:38:00

@Unity1004 @krsna_crespo @MAQ69 @mkoszk 単純に3つの要因の関連性を1枚で示すための図ではないかと思いましたが。

posted at 20:59:46

業務連絡： @mkoszk さん、傘をお忘れです！！

posted at 13:58:27

@mkoszk これみると、3月9日から始まっていたことが分かりますね。逆に言うと、大地震予知が2日前からできるんじゃないかと思いました。

posted at 18:30:15

@mkoszk @shimashima35 テストPRESSの検索ででてこないのでないんじゃないですかねぇ。

posted at 17:36:39

@mkoszk @snsk このルールは複雑ですね。CEGTestの出番？？ http://t.co/AOtcqQL7

posted at 18:30:11

@snsk @mkoszk 最強のエラー処理ですね。ww ＞「詳細は映画館へお問い合わせください」

posted at 18:33:04

@mkoszk 同じなんじゃない？ 縦型は、□→(□→□)→(□→□→□)→(□→□→□→□)なのでは？

posted at 12:32:03

@mkoszk 論点がようやくわかりました。(^_^;

posted at 12:38:22

@mkoszk ざっくりとしたテストレベルは開発に合わせて考えるけど(湯本さん式)、現実としてはテストを実施して段階的に品質を取っている(三紀夫さん式)のでしょうね。

posted at 13:04:12

@mkoszk 登山道は一つだけじゃないから。色々なアプローチがあったほうが良いと思います。

posted at 13:20:46