katsu.あかまさん、
みかままです。こういう話を長々と続けていいものか…
katsu.akama wrote:
> 「ソフトウエアテスト２９３の鉄則」Cem Kaner より
>…
> 「質問」を設計するときに必要となる「思考法」のヒントになれば幸いです。
面白いですね。
この本、手配してるんですが、まだ手元に来ていません。
来たら見てみようと思います。
> 「もっと早くそういう質問を投入しておくべきだった」
> 「もっと早くそういう試験を実施しておくべきだった」
>
> ＸＰ的には、「もっと早く」をボリューム１０にして「最初に」になります
ので、
> ＸＰ変換すると
> 「最初にそういう質問を投入しておくべきだった」 になりますね。
最初にテストをすると、それに気をとられて、説明を聞いてくれなくなるんです
よね(w。でも、やはり最初に提示した方がいいかなあ…。
>>したテストがきちんと機能して、そこから内部実装を変更・リファクタリングす
>>ることが実は重要なのではないか。
>「スキル」のリファクタリング。。。。。。
スキルというか、「解法」ですかね。より汎用的なケースに適用可能な「解法」
に高める。高めただけでは、「応用」までには行き着かないんですけど。
＃類似の構造を見出すとかいう能力はまた別に必要な模様
学習に関する研究になかなか面白いのがありました。講義資料ですけど。
「問題解決における方略の学習」
http://www.miyakyo-u.ac.jp/school/taira/Lecture/learning-by-doing.rtf
>>テストで間違うと恥ずかしがりますが、個人的にはよく起こる間違いをやってく
> 「スキル」評価との関係でしょうか。
>
> 受講前は、「これしか理解できなかった」けど、
> 受講後は、「こんなに理解できたよ」 と自信がつき、
> 「恥の文化」がなくなるといいですね。
講師側にとってはFAQの発見という意味もありますが、学生側にとっては、
「エクストリーム・プログラミングの神秘を解く: 価値を重視する」
http://www-6.ibm.com/jp/developerworks/java/030404/j_j-xp020403.html
の最後の方のコメントが私の言いたいことに近い気がします。
（引用はじめ）
現行のソフトウェア品質管理の実務は、「最初から正しい仕事をせよ」という
考え方で支配されています。しかし、複雑な状況においては、「最初から正し
い仕事をせよ」という考え方は失敗の方策になってしまいます。基本的に、こ
の考え方は次のようなものです。
不確実であってはならない
実験をしてはならない
間違いから学んではならない (なぜなら間違いを犯してはならないため)
計画からそれてはいけない
私たちに必要なのは、最終的に正しい結果を導き出すために、初めのうちに進
んで間違うことです。
（引用おわり）
個人的には、学校という場では沢山失敗してそこから学ぶべきだ、と思ってま
す。社会に出るより、被害も少ないし。
＃XPに関係があるようなないような
---
みかまま
http://www.mikamama.com/
mika@....com