Twitterで、気になったもの。
idがその発言のID,screen_nameが発言した人で、下の行が発言内容
（かなり、ねたが古い）
id:22949836319 screen_name:mkoszk
@YasuharuNishi @Yuko_Ski は@rin2_ さんがリーダーになっている影響分析の分科会に、僕は古畑さんと一緒にゴール指向とUSDMの分科会に入っています。ということで、 @nagworld さん達の分科会の動きがわからないため、反応が鈍かったのです。
id:22949670834 screen_name:mkoszk
@YasuharuNishi 派生開発推進協議会では、SQiPに似た研究会を設けています。 @nagworld さんは、テストと派生開発を研究する分科会のリーダです。 その中には大山さんもいます。でも、 @Yuko_Ski さんと僕は入っていません。
id:22887580903 screen_name:mkoszk
"設問：なぜ男が返答しなかったのか、次の選択肢から選べ。
１、大学の先生は儲からないと思っているから。
２、大学の先生になるのは大変だと思っているから。
３、女との結婚に踏み切れないから
４、電車の中で話す内容ではないから。"
id:22887139166 screen_name:mkoszk
四ツ谷から乗った男女。「ねえ、大学の先生って儲かるんでしょ。」う?。「そうなんでしょ。」・・「大学の先生になるんだったら、考えてもいいのよ。」・・・「何黙っているのよ。結構、わたし思い切ったこと言ったつもりなんだけど。」・・・「どうしたのよ。怒らせること言った？」・・・「もう。」
id:22865412313 screen_name:mkoszk
@keisyun 正美さんがＴＭで書かれたモデルをみて、あれこれ指摘するのを見て、エントリーポイント分析、キーストリーム分析と似ているなあと思ったのでした。イベントとその価値の分析がエントリーポイント分析、対照表の連鎖ぽいものがキーストリーム分析です。
id:22858817313 screen_name:mkoszk
@keisyun いやいや、 @keisyun さんはデータモデルの記事、読まなくてもよいですよ。少しだけテストエンジニアのフレーバーがありますが、中身は正美さんの許可を得て書いたＴＭのことですから。そのＴＭもその記事からだいぶ変わっていますしね。
id:22858666073 screen_name:mkoszk
@keisyun ゾンマービルのソフトウェアエンジニアリングの原書は、ほぼ毎年のように出版されるんですけどね。今、amazonでみたら４万円ですか。この僕でも購入するのは難しいなぁ。
id:22845568234 screen_name:mkoszk
@Unity1004 データモデルに関する部分は意地悪テストではなく、通常のテスト設計で用いる技術です。 ソフトウェア・テスト PRESS Vol.6と7で、テストエンジニア向けにデータモデルの話を書いたのですが、現在入手困難なようです。人が集まればデータモデルの勉強会やりますよ
id:22845012246 screen_name:mkoszk
@tosikawa 意地悪テストのテスト設計だと、両方とも似ているように思うのですが、僕の中では、違うんですね。思考過程がまったく異なるので、人に説明しづらいのです。また、論理的に追い詰める部分（ここは説明できます）と、直感的に判断する部分とが混じり、分けられない感じなのです。
id:22844728520 screen_name:mkoszk
@tosikawa スクリプトは途中経過を人に説明しやすく、探索的は説明し難いところがあります。僕自身が探索的テストを苦手としているので、余計にそう思うのかもしれませんが、通常のテスト設計と探索的テストでは、頭の使い方が違うように感じます。
id:22844531427 screen_name:mkoszk
@zacky1972 エントリーポイント分析とキーストリーム分析は、佐藤正美さんのＴＭの考え方を活用するようになって、僕自身は使わなくなりましたが、業務の分析方法を学ぶという意味ではまだまだ活用できると思います。
id:22844364883 screen_name:mkoszk
@zacky1972 学生相手に演習する場合、ゆもつよメソッドそのものを理解するだけでなく、いくつかの分析方法も同時に教えることができます。トレーサビリティマップは、エントリーポイント分析とキーストリーム分析の二つを使っています。ＰＦＤはＤＦＤの派生系ですしね。
id:22804110771 screen_name:mkoszk
@kai0707 標準確認項目を使うと、テストケース数が増えるので、効率的では無いのです。テスト設計をすればやらなくてもよい項目でも、標準項目として挙がっているのでテストを実施します。そうすると項目数の割にバグ数が少ないという事象になるのです。ドメインが違えばほとんどバグでません
id:22791789835 screen_name:mkoszk
@tosikawa 探索的テストだけが特別に難しいと言われるのは、他のテストとの比較で「難しい」と説明するという理由もあると思っています。テスト設計をしないでテストするわけですから、アドホックテストと見た目は違いがありません。そのため、探索型テストをより難しく解説しているのでは。
id:22785194062 screen_name:mkoszk
保守しているシステムを擬人化したことはあるけど、テスト対象を擬人化したことは無いなあ。 RT @MarkSgt @snsk @mkoszk テストする時に、テスト対象と、お話ししません？ 僕はするみたい、褒めたり、聞いたり、怒ったり すると、当時の部下 現在の奥さんに指摘された。
id:22784846205 screen_name:mkoszk
@oichin USDMとツイッターでつぶやくと、外国人からフォローされます。
id:22766969744 screen_name:mkoszk
@kai0707 ちなみに僕の場合は、オフショアでのテストで活用してみてみました。標準確認項目を参考に（ここ強調！）、テストケースを考えるようにお願いしたのですが、結果は・・・。 http://www.jasst.jp/archives/jasst10e/pdf/A5-2.pdf
id:22766758092 screen_name:mkoszk
. @kai0707 ユーザ企業の品質保証部門が持っている標準確認項目ではなく、ソフトウェアテストの請負企業の言葉だから「？」を投げかけたのです。テストの目的がバグだしのとき、扱う製品、ドメインが異なるテストで標準確認項目をやってどれだけバグをだせるか疑問をもっています。
id:22765117076 screen_name:mkoszk
「これまでのテスト設計ノウハウをまとめた800項目の標準確認項目マスタを利用出来、リリースが迫っている開発においても、押さえるべき項目を確実にふまえたテスト設計が可能です。」 ・・・800もの項目があると大丈夫だと思うでしょう。違うんだな。僕も同じくらい集めたけど効果はいまいち。
id:22762655171 screen_name:mkoszk
. @takeruko 運用テストの範囲が合意できていないので検討違いなコメントかもしれませんが、多くの人はホワイトボックステストの観点でテスト設計をしますし、各社の方法論も概ねそのようになっています。僕はブラックボックステストでテスト設計した後、ホワイトボックステストを使います
id:22761930420 screen_name:mkoszk
SECで要件定義ガイドラインって出していましたっけ？ 共通フレームで取り上げられていたような気がしたのですが。 RT @Taka_bow IPA の SEC は要件定義ガイドラインの制定で「要求」と「要件」という言葉を定義した。（略）
id:22675718088 screen_name:mkoszk
Amazon のソフトウェア・テスト PRESS Vol.9 の著者名が「編集部」。他の号は、「ソフトウェア・テスト PRESS 編集部」。最後まで Vol.9のぐちゅぐちゅ感が、ここにも現れているんだなぁ。
id:22598777034 screen_name:mkoszk
「アクティビティは機能の動的部分であり、反復的で定型的である傾向がある。」・・・やっぱりアクティビティをうまく説明できない。
id:22598510285 screen_name:mkoszk
「一般に、機能は管理され、アクティビティは実行される。」・・・ふむふむ。
表題の件
答え：全部
アクセス
トータル
ランキング
