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

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

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

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

      by Anonymous Coward on 2004年03月29日 14時30分 (#522554)
      >よって、テストは軽視、もしくは省かれる可能性が非常に高い工数の1つになります

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

      なんなら、開発工程もさくっと削減してもらえませんか?
      親コメント
      • by Anonymous Coward on 2004年03月29日 16時24分 (#522684)
        ボクはどっちかというと納品される側の人なのですが、希望としては
        「お金は払うから*ちゃんと*テストしてくれ」
        ってのが偽らざる本音。 いや、正確に言うと
        「何テストしたんだか教えれ」
        って事でしょうか。
        どぉぉぉぉ考えてもテストしてたら出ないだろそんなバグ、という「不具合」をポロポロと発見するにつけ、「やっぱ単体レベルのテスト仕様書も見せて欲しいなァ」と思う今日この頃。
        あとサーバサイドのプログラムで(想像するに)if文1個の修正みたいな改修作業で「テスト1人日」とか見積もりに出てくると、頭を抱えざるを得ないです。テスト全項目通してもそんなに時間食わないだろうによ。

        あー、みなさんのトコって客先に納品する時、テスト内容ってどの程度開示しているんでしょうか? 激しく気になります……。
        親コメント
        • by naruenosekai (13637) on 2004年03月29日 20時19分 (#522954)
          >ボクはどっちかというと納品される側の人なのですが、希望としては
          >「お金は払うから*ちゃんと*テストしてくれ」
          >ってのが偽らざる本音。 いや、正確に言うと
          >「何テストしたんだか教えれ」

          発注仕様書に納品資料として提出するよう記載すればいいだけでは?

          #最近、仕様書にきっちり書くことを学んだので。
          #しかし、打合せで仕様を決めようとすると後で打合せの内容を
          #覚えていない業者の多いこと。おまえらメモとれー。
          親コメント
          • by Anonymous Coward
            >発注仕様書に納品資料として提出するよう記載すればいいだけでは?

            うちではテスト結果報告書も納品資料なので提出
            していただいてます。ソースを見ただけで一発で
            NGになる物件の納品があったときも、すべての項
            目にO
            • by TameShiniTotta (19794) on 2004年03月29日 23時09分 (#523053)
              >結局、その項目がどうして○になったのか、って
              >いうことがさっぱりかかれていないんですよねぇ。

              それははっきり言うとテスト項目が甘いだけ。
              「誰がテストしても同じ結果が出る手順を並べたもの」が試験項目表だよ。
              試験した人が後から理由を書かなきゃならない項目表は項目表としての品質が低い。
              低い品質のものを使っても低い品質のものしか生まれないから。

              試験項目表さえシッカリ作る事ができれば、
              それこそ試験要員なんてパンチャーレベルでも問題ないんだけどね。

              #まあ、大体の人は「結果が1になること」が試験項目だと思ってるようだけど。
              #「○をして×をすると結果が1になること」としっかり提示できなきゃ、
              #「×を2回して○をやって結果が1になったからOK」と言われても文句が言えない。
              親コメント
              • by k 2 y (5354) on 2004年03月30日 1時52分 (#523166)
                もちろん手順書が甘いって可能性も大いにありますが、
                ホントに手順書どおりにやってんのかゴルァということもありますね。
                いずれにしても、手順書どおりに実施することもできないようでは、
                そもそも手順書自体も甘々ってとこでしょうねぇ。
                親コメント
            • by naruenosekai (13637) on 2004年03月30日 12時37分 (#523364)
              >結局、その項目がどうして○になったのか、って
              >いうことがさっぱりかかれていないんですよねぇ。

              事前に試験内容と手順を確認する必要があります。
              そうでない場合には、もう仕様書にこれこういうテストを
              こういう手順でやってこういう結果がでたらOKと書く必要があります。

              で、危なそうな所ならさらに測定ログやテスト記録・写真などの全データをテスト環境・条件含めて提出させます。
              どちらにしても、手放しでお任せはまずいかと。
              親コメント
        • Re:テストとコスト (スコア:2, おもしろおかしい)

          by G7 (3009) on 2004年03月30日 4時00分 (#523200)
          >何テストしたんだか教えれ
          >単体レベルのテスト仕様書も見せて欲しい

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

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

          てか、確実に理解できる保証なんてものは無視して、
          とりあえず「多め」に情報を納めさせるほうが、
          絶対に有利であるはずだ。お客にとって。
          だって理解できなくて「困ったら」、誰か理解できる人を掴まえて読ませりゃいいだけなんだもん。
          でも情報そのものを納めさせていなけりゃ、永遠に読めない。
          幸いにして現在は、多めの文書を仕舞っておく場所には(電子データなら)苦労しないんだしさ。

          ただ、

          >if文1個の修正みたいな改修作業で「テスト1人日」とか見積もりに出てくると

          それは、アーキテクチャ(の不味さ)次第では、なんぼでもありえることです(T_T)

          逆にいえば、作りかけの時点でも観察することは、
          お客にとっても利益(つーか損害を無くす)のために重要だと思う。
          「技術的負債」を抱えまくった開発を受注者がやってんじゃねーの?ってのを
          建築^H^H開発途中にも頻繁に査察したほうが良い、と俺は思うっす。
          #無理の有る査察のしかただと困るけど、ね。

          あ。そういう意味でも、XPは旨いよな。
          Projectはお客に、常時査察されてるようなもんだもん。

          >どの程度開示しているんでしょうか

          ウチの社長が何考えてるかはともかく、開発者たる個人としての俺は(^^;、
          相手が吐き気催すまで出すのもヤブサカじゃないですよ。
          ほら。ここでのカキコみたいにさ(藁

          #最近、ソースごと納入な仕事ばっかりしてる気がするんだが、
          #お客がそのソースだのなんだのといった情報を有効活用してるのを、見た験しがないのでG7
          親コメント
          • by Anonymous Coward
            顧客の為を考えれば
            報告書は書かなくちゃいけないけど
            小難しいといわれる
            分かりやすい報告書を書こうと思うと
            筆力が足りない。。。
            自分の力が足りないのかと一人鬱。
            • by naruenosekai (13637) on 2004年03月30日 12時48分 (#523368)
              分かり易い報告書を目指して、説明が足りない報告書をよく見かけるようになりました。

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

              で、その何を調査したかは説明してない。結果だけ。
              良くわかってない上司とかはそれを分かり易いとか言って鵜呑みにしてしまうけど、
              それではミスや調査不足があっても判らないし、その後それに基づいて改良しようとしても
              何を調べて、何を試してないのか判らないから、同じ事をやる羽目になるという事が判っているのか...。
              親コメント
              • by G7 (3009) on 2004年04月01日 3時21分 (#524606)
                >分かり易い報告書を目指して、説明が足りない報告書をよく見かけるようになりました。

                あ。それ有る有る。

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

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

                それと比べると、見た目が「判りやすくない」かどうかは、読めばすぐ判るんで、
                そこを「評価」するのは簡単なんだよね。

                まあ、だからこそ、ああいう人々は見た目の判りやすさばかりを評価するんだろうな。
                情報が足りないかどうかは評価のしようがないわけだ(^^;

                >同じ事をやる羽目になるという事

                「後で役立てる」という発想をそもそも採用していないのではないかと。
                積読するためだけに作らせてる、と。

                「効果的にバグを報告するには」 [unixuser.org]みたいな境地は、遠いです…しくしく。

                まあ、肝心の納入ソフトすら積読する企業は珍しくないようなのでね。
                #じゃあ納期厳守させる意味が無いじゃんか、と、かなり脱力したのでG7
                #バグレポが2年(!)後に来たから何かと思えば、初めて評価したのが先週だったというオチ…などなど。
                ##AprilFoolじゃないのでG7(T_T)

                で、結果的にソフトにとって「どんな情報をどう伝えれば」役立つのか?っていうパターンって、
                それなりに有るわけじゃないですか。
                だけど、そういうのは門外漢(だよな)なお客とかにはしばしば「小難しく」映るらしい。
                で、そういう真に有意義なパターンを正に「禁じ手」扱いしてくれちゃったりするのな。
                つまり、無意味なドキュメントや無意味なバグレポ「しか書けない/受け取れない」という状況を
                わざわざ作ってくださる。
                親コメント
              • by naruenosekai (13637) on 2004年04月05日 0時36分 (#526366)
                >「情報量スカスカである」ことを知るための情報自体が無くなっている(笑)ので、
                >そのドキュメントの不味さは、読み手に伝わらないんです。

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

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

                仕様確認もせずに、まちがった仕様の物を堂々と納品して、あとでやりなおしとか、
                ほんとにデバックしたしたかと思うほどバグバグな物を納期に納めてくれたりして
                それを受て開発する予定がずるずると延びて、納期ってなんなのて思った事もありました。

                >つまり、無意味なドキュメントや無意味なバグレポ「しか書けない/受け取れない」という状況を
                >わざわざ作ってくださる。

                どう仕様書を書けばその様になるのは解りませんが、
                文章を書く本によると、読手が知りたい事から順番に書いていくと良いそうです。
                最初に結論をわかりやすく書いて、詳細は後に書けという事らしい。
                人は知りたいことしか知ろうとしないから、まず知りたいことを教えてやり、その延長線上で知らせたいことを伝えるという事らしいです。
                親コメント
              • by G7 (3009) on 2004年04月10日 12時25分 (#529541)
                >私は結論からその根拠を文章中に探したときに何も説明していないことに気がつきました。
                >書いた人間にその事を言ったのですが、何がまずいのか全く解っていない様でした。

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

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

                >>#じゃあ納期厳守させる意味が無いじゃんか、と、かなり脱力したのでG7
                >仕様確認もせずに、まちがった仕様の物を堂々と納品して、あとでやりなおしとか、

                状況によりけりなんでしょうけど、
                「真のエンドユーザ」からの声が来ない状況ってのに出くわして、困ったことは有ります。
                客とウチラの間に更に一社挟まっていて、そいつらが情報を「仲介」してたんですが、
                ここで情報の欠落(伝言ゲーム)や遅滞が起きるんですね。
                おかげで、ユーザが実際に困っている事柄が、正確かつ迅速に、伝わってこない…

                >>つまり、無意味なドキュメントや無意味なバグレポ「しか書けない/受け取れない」という状況を
                >>わざわざ作ってくださる。
                >どう仕様書を書けばその様になるのは解りませんが、

                フォーマットの問題です。

                「所定の」フォーマットで情報伝達(意思疎通)をしろと要求される。
                #そうすれば「正確に」伝わる、と先方は思ってらっしゃるらしい。

                ところが、そのフォーマットには、実用上困ってしまうような過不足が色々有って。

                「こういうような事柄が書きたいんだけど、このフォーマットじゃ書けない」っていう事態が頻発しまして。
                そういう場合、そのフォーマットに従えば従うほど、情報は欠落するわけです。

                結局、備考欄しか役に立たなかったりする。それなら最初から備考欄(フリーフォーマット)だけでいいじゃん…

                >文章を書く本によると、読手が知りたい事から順番に書いていくと良いそうです。
                >最初に結論をわかりやすく書いて、詳細は後に書けという事らしい。
                >人は知りたいことしか知ろうとしないから、まず知りたいことを教えてやり、その延長線上で知らせたいことを伝えるという事らしいです。

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

                結局、アジャイルが最強なんじゃないか?という気がしています。
                つまり、フォーマットはあまり気にせずラフに書き始めて、
                その代わり要求を随時フィードバックしてバンバン改訂してく、という奴ね。
                #ただし、「フォーマットをきちんとしてくれ!」という要求は、聞かないほうが良さそうですが:-)

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

                で、仕様の打ち合わせみたいなものってのは、
                もともとそんな制約とは無縁であるはずです。
                製品の仕様を向上させるのが目的であって、
                前述の制約を守ることが目的ではないから、です(笑)。
                つまり便利な媒体は随時選べばいいし、
                まして現代なら電子媒体が情報の改訂し易さを大幅に援助してくれる。

                つまり、「たまにしか会えない」ことを前提にしちゃ、
                駄目なんだと思うんです。
                親コメント
              • by naruenosekai (13637) on 2004年04月15日 10時52分 (#532127)
                >そういう…これも一種の「論理的思考」っていうのかな…考え方を、
                >理解する人間と、しない人間が、居ますよね世の中には。

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

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

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

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

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

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

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

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

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

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

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

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

                同意。

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

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

          問題は、「納品される側の人」と「納品されるモノを使う人」が違うことでしょう。
          使う人はきちんと出来てないと困るに決まってるんだけど、
          お金の計算をする立場の人は
          「それくらいどうでもいいから安くあげよう」
          と決めてしまいがちです。

           
          --
          --------------------
          /* SHADOWFIRE */
          親コメント
        • by Anonymous Coward
          納品先からの要求でテスト仕様書のみならず、evidenceを寄越せと言われ、テスト前、テスト後のDB内容をExcelに貼り付けたものを延々とプリントアウトしたことがあります。
          A4用紙にして1万枚以上……。
          evidence(証拠)を出せと言うなら、納品先の会社から
        • by Anonymous Coward
          私も同じく納品を受ける立場の末端だったんですが、
          「完成していない製品をパッケージ製品として納入するのはやめてくれ」
          と言いたいですね。

          鶴の一声で導入決定されたものを動かしてみると、複数データをバッチで読み込むと2レコード目から桁ずれが起こる。何これ。
          で、SEに訊ねたら「単体テストはちゃんと通ってます」…パッケージだから一切の改修不可。彼等も命ぜられたこと
        • by Anonymous Coward
          >あー、みなさんのトコって客先に納品する時、テスト内容ってどの程度開示しているんでしょうか? 激しく気になります……。
          一応テスト項目と確認項目(と「OK」マークの羅列)を書いた一覧を出してますが、客先担当者がちゃんと見てるかどうかは疑問。
          テストが足りないって文句は納品後に不具合が発覚してからじゃなくて、一覧の提出時に言ってくれよ。
        • by Anonymous Coward
          むしろ「テストしていないものには金を払いたくない」つうのが本音だわな
      • by cassandro (6035) on 2004年03月30日 1時11分 (#523155)
        > なんなら、開発工程もさくっと削減してもらえませんか?

        なんなら、テストを省こうなどという、顧客/開発会社/エンジニアもさくっと削除ですね。

        # あー、そういう日は何時来るのだろうか
        親コメント
      • by Anonymous Coward
        > なんなら、開発工程もさくっと削減してもらえませんか?

        世間一般ではそれを「丸投げ」といいます。
        直接受注者において開発工程を極限まで削減する事です。
        テストの削減と同様、クオリティには期待出来ませんが、
        それでも宜しければ、コストは大変お安くなります。

アレゲはアレゲを呼ぶ -- ある傍観者

処理中...