パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

テストってどれだけやってますか?」記事へのコメント

  • テストには工数がかかります。
    工数とは、そのまんま「人件費」です。
    人件費は減らしたい、というのが客先の第一の要望です。
    人件費は減らしたい、というのが開発会社の第一の要望です。
    よって、テストは軽視、もしくは省かれる可能性が非常に高い工数の1つになります。

    つまり、ご質問へのお答え
    • Re:テストとコスト (スコア:1, すばらしい洞察)

      by Anonymous Coward
      >よって、テストは軽視、もしくは省かれる可能性が非常に高い工数の1つになります

      なんて考えを持っている発注側はもちろん、受注側にも大きな問題があるのでしょうねぇ。
      本来外すことの出来ない工程を外すことを許容してるんだから。

      なんなら、開発工程もさくっと削減してもらえませんか?
      • by Anonymous Coward
        ボクはどっちかというと納品される側の人なのですが、希望としては
        「お金は払うから*ちゃんと*テストしてくれ」
        ってのが偽らざる本音。 いや、正確に言うと
        「何テストしたんだか教えれ」
        って事でしょうか。
        どぉぉぉぉ考えてもテストしてたら出ないだろそんなバグ、という「不具合」をポロポロと発見するにつけ、「やっぱ単体レベルのテスト仕様書も見せて欲しいなァ」と思う今日この
        • Re:テストとコスト (スコア:2, おもしろおかしい)

          >何テストしたんだか教えれ
          >単体レベルのテスト仕様書も見せて欲しい

          こういうお客さんに巡り会いたい(T_T)
          #会えてないのでG7

          結局、「小難しい。なにいってんだか判らん。
          そんなもんはいちいち見せるんじゃねえよ」なんていうお客は
          自分の首を締めてるんだよね。

          てか、確実に理解できる保証なんてものは無視して、
          とりあえず「多め」に情報を納めさせるほうが、
          絶対に有利であるはずだ。お客にとって。
          だって理解できなくて「困ったら」、誰か理解できる人を掴まえて読ませりゃいいだけなんだもん。
          でも情報そのものを納めさせていなけりゃ、永遠に読めない。
          幸いにして現在は、
          • by Anonymous Coward
            顧客の為を考えれば
            報告書は書かなくちゃいけないけど
            小難しいといわれる
            分かりやすい報告書を書こうと思うと
            筆力が足りない。。。
            自分の力が足りないのかと一人鬱。
            • 分かり易い報告書を目指して、説明が足りない報告書をよく見かけるようになりました。

              「調査した結果、何々となる事が判りました。」

              で、その何を調査したかは説明してない。結果だけ。
              良くわかってない上司とかはそれを分かり易いとか言って
              • >分かり易い報告書を目指して、説明が足りない報告書をよく見かけるようになりました。

                あ。それ有る有る。

                判りやすくするためには2つの方法が有って、1つは文字通り判りやすく「する」こと、
                そしてもう1つは、判りにくい(説明がしんどい)部分を削るだけっていう奴(笑)。

                で、元々「判りやすい」ってのは相対評価だから、ヤバイんですよね。
                なんぼ下手くそな削り方をしてしまった(=情報量スカスカなドキュメントにしてしまった)としても、
                「情報量スカスカである」ことを知るための情報自体が無くなっている(笑)ので、
                そのドキュメントの不味さは、読み手に伝わらないんです

                それと比べると、見た目が「判りやすくない」かどうかは、読めばすぐ
              • >「情報量スカスカである」ことを知るための情報自体が無くなっている(笑)ので、
                >そのドキュメントの不味さは、読み手に伝わらないんです。

                私は結論からその根拠を文章中に探したときに何も説明していないことに気がつきました。
                書いた人間にその事を言ったのですが、何がまずいのか全く解っていない様でした。

                >#じゃあ納期厳守させる意味が無いじゃんか、と、かなり脱力したのでG7

                仕様確認もせずに、まちがった仕様の物を堂々と納品して、あとでやりなおしとか、
                ほんとにデバックしたしたかと思うほどバグバグな物を納期に納めてくれたりして
                それを受て開発する
              • >私は結論からその根拠を文章中に探したときに何も説明していないことに気がつきました。
                >書いた人間にその事を言ったのですが、何がまずいのか全く解っていない様でした。

                あはは。なるほど。
                そういう…これも一種の「論理的思考」っていうのかな…考え方を、
                理解する人間と、しない人間が、居ますよね世の中には。

                #論理思考の苦手な人間は、少なくともソフト受注者や「発注者」には成らないほうが良いと思うのでG7
                #受注者は言うに及ばず。発注者も「なにをさせたいのか」論理的に説明できないようじゃ駄目です(コッチが対応しようが無いので)。

                >>#じゃ
              • by naruenosekai (13637) on 2004年04月15日 10時52分 (#532127)
                >そういう…これも一種の「論理的思考」っていうのかな…考え方を、
                >理解する人間と、しない人間が、居ますよね世の中には。

                特に作業報告書などはやった事とそこから得られる結論を書けばいいのに、
                何故か、やった事を書こうとしないのですよね。
                「調査した結果」とか適当な言葉でお茶を濁しているのですよね。
                理数科系の職業のハズなのに~とか思ってしまうのですよ。

                >#受注者は言うに及ばず。発注者も「なにをさせたいのか」論理的に
                >説明できないようじゃ駄目です(コッチが対応しようが無いので)。

                それは耳が痛いなと思いつつ。
                私も顧客から受注して、その一部を外注に投げている身なので、
                発注者/受注者、両方の立場なのですが、
                「曖昧な仕様を確認、明確化させるのも仕事の内」なのではないかと。
                私の場合、殆ど仕様書なし。お客から聞出してこっちが書くものと成っているの
                で。
                仕様書が出てくるだけましかと。もっと色々仕様を書いてくれー。

                >客とウチラの間に更に一社挟まっていて、そいつらが情報を「仲介」
                >してたんですが、ここで情報の欠落(伝言ゲーム)や遅滞が起きるんで

                よくあります。相手先の営業が間に入って理解しないまま適当な事をしたりとか、
                担当者として紹介された人と話したはずなのに、実際にはその人の部下に丸投げとか。
                ちゃんとしたところは質問票を作って確認してきますね。
                うちの会社ではレビューで顧客に確認したかという事をしきりに聞かれるのですが
                他の所ではやってないのですかね。

                >「所定の」フォーマットで情報伝達(意思疎通)をしろと要求される。
                >「こういうような事柄が書きたいんだけど、このフォーマットじゃ書けない」っ
                ていう事態が頻発しまして。

                昔、発注先から要求された事がありましたが、結局破綻しました。
                問題や質問があると新規項目に書くのですが、説明になっていない説明で
                終了させようとするので、全然意味がなかったですね。

                >あー。「相手が知りたいこと」と、こちらが用意する「結論」とは、一緒じゃない可能性が結構あるんですよね。
                >結論も、こちらが用意する限り、あくまで「知らせたいこと」の範疇でしかないのです。

                相手の質問に対して回答するような形式だと、そうですね。
                そういった場合、これ(ここ)はどうするつもりなのかと、逆に考えを問うてみて
                相手の思考の枠を広げるという事も必要でしょう。

                >言い換えると、「まず結論を書いて…」みたいな、結局は書き手側の発想でしかない方法論は、
                >古典的な書籍みたいに改訂をやりにくい環境に「特化」した方法論なんじゃないか?と思っています。
                >改訂できないという制約のもとで最高なものにしようとしたら、
                >仕方ないから自分が言いたいこと(の核心)を最初に相手にぶつけるというスタイルしか無い、という。

                それは一面にしかすぎない。会話にも使える話ですよ。
                書くのも話すのも、結局相手にどう伝えるかに尽きると思います。
                その時に相手の立場に立って伝えられるかどうかで、
                同じ内容を伝えるのでも伝わりやすさが全然変ってきます。
                判断して貰うのであれば、選択肢を提示するなど、
                これを怠ったり、無意識に片方の選択肢を捨てているために
                後で問題になるんですよね。

                >で、仕様の打ち合わせみたいなものってのは、
                >もともとそんな制約とは無縁であるはずです。

                同意。

                >つまり、「たまにしか会えない」ことを前提にしちゃ、
                >駄目なんだと思うんです。

                ソフトウェアの技術者にメールで済まそうとする人が多いですよね。
                ずぼらな人はメールすらしない。
                やはり、コミュニケーションが重要という事ですね。
                親コメント

※ただしPHPを除く -- あるAdmin

処理中...