ブラックボックステストの意義とは？

質問

最近、ブラックボックステストに従事しています。
計算式の設置もれ、計算式の誤入力によるバグを報告しています。
設置もれの主な理由は、
設計者が、計算式の設置が必要な事に、気がついていないからです。
なので、設計書に記述自体が存在しないのです。
この状態で、黒テストの意義って有るのでしょうか？
どうして、白テストを開始しないのでしょうか？
プロジェクトリーダーがプログラミングを書けない人の場合、黒テストしかしないのでしょうか？
誤入力分の訂正が完了しても、その影響で新たな箇所に別の数式バグが発生しています。このような場合、黒と白、どちらのテストが最適なのでしょうか？

回答No.3

precog

大変そうですね。

正しい手法は何か? という話と、過重労働の問題は別に考える必要があります。あなたの立場が派遣であるなら、いずれにせよ、責任を負う必要はありません。理解して付き合うのも人としての道ですが、それと責任は別の話です。

>テスト担当は過労で退職、又は欠勤多発の状態です。
>私自身も体調が優れず、欠勤回数が増えてきました。
>派遣先は休出を、テストリーダーの中には、懲りずに残業を打診してくる人がいる有様です。

状況を訴えて、Noって答えるしかないですよね。(^_^;
Noといったら上が何か考えるでしょう。

>業務日誌で、「テストを続ける意義はあるのですか？」と問うてみる事は、雇われてる立場として、生意気でしょうか？

上に書いたように絡めるのは得策ではありませんね。

>テストって、仕様もれを見つける事が目的なんですか？仕様の校正をする事が目的なんですか？

あなたは上で設計書と書いてますよ? 仕様書とプログラムの不一致(原因は設計書かもしれないが)を見つけるのがブラックボックステストです。

仕様書が間違っているなら、そこのテストは一旦中止すべきと判断しますが、他のテストを進めることで全体の進捗に穴をあけることは防げますよね? なので部分的な障害の話と、稼動の話は分けて考える必要があります。

部分、部分で、自分の受け持ちを勝手に止めたら、全体のマネージメントが出来ないですね。遅れる部分があるなら、他の部分を先にやるというのは何が起きるかわからないプロジェクトでは当たり前のことです。

それと、下流工程ほど、無駄なことをやらねばなりません。腹が立つかもしれませんが、どんなに優れたチームでも無駄はゼロにはならないし、それは常に下流で清算するしかありません。

>そしてなんで、設計者のほうが、仕様に対するスキルが低いのでしょうか？設計者のほうが、テスト担当者よりスキルがあるもんじゃないのでしょうか？

設計をしたことがあってそう思ってるんですか?

Yesであれば、、、聞かなくてもわかってると思いますが、そういうことは起きえますね。最初から下手くそだとわかってれば使いたくないですけど、わかるのはいつも結果が出てからです。大きいプロジェクトなら精査出来ませんし、そもそも請け負い契約だと何人でいくらで請けるので、玉石混合です。問題が出てから「変えてくれ」ということしか出来ません。請ける側はそれでも金が取れるので、わかってて出来ない人も混ぜます。プロマネは知恵を凝らしますが、それは「確率を上げる」といった類の話でしかありません。

Noであれば、、、それが一部であれば、それはあなたが部分しか見てないからそういうことが言えるのだという可能性は高いです。100やってれば1のミスがあるのが人間で、そのためのデバッグです。1のミスだけみたら簡単なものであったりしますが、それをなくすのは大変な労力がかかります。むしろ、設計者の入れたミスを見つけられないデバッガーなら要りません。

どっちにしても程度問題です。設計ミスも多すぎる場合はなんらかの対策が必要です。影響が少なく、件数も少ない場合は通常のルーチンどうりの処理で問題ありませんが、類似バグの調査は必要でしょうね。

当然、上流ほど、ミスは大きな影響を与えますので減らさねばなりません。良くある失敗プロジェクトは、要件のすれ違いによって引き起こされます。

>定時で帰りたいです。帰っていいのかな？

開発で定時帰宅の主張とか無理なような気が、、、

いずれも程度問題ですよ。末端なら、ちょっとマージン取っておいて「これ以上は無理です」って伝えることですね。残業ゼロは法律的にはどうか知りませんが納得はしてもらえないでしょうね。

上に訴えるコツとしては、基本的には稼動の話だけすることです。上が「いや、どうしてもこの人数でやらねばならんのだ」等いいはじめたら、効率の話をしましょう。誰が悪いとかじゃなく、どうしたら解決出来るかを提案してください。ただし、ある程度プロジェクトマネージメントや品質管理のことがわかっててしゃべらないと相手を怒らせるだけになるかもしれませんのでご注意を。

お礼

テストが止まる要因→設計書に記述自体がない、サーバーが足りないので、集計時間が長すぎる、テスト作業書に記述が足りない、ため、バグの報告書作成に時間がかかる。テスト操作自体が進まない。テスト結果が返って来ない。
時給泥棒は嫌。
私はとある業種の事務派遣の経験が長いので、仕事が出来ない人と発覚した時点で即、解雇される業界で働いてきました。仕事が出来ないと気付いた人は即、自主退場の業界で働いてきました。
ソフトハウスってなぜ、こんなに甘ちゃんな業界なんでしょうか？
こんな失敗が止まらない物に対して、いつまでも黒テストしてる意味が分かりません・・・
私はテスト担当者ですが、一歩派遣先の外を出たら、エンドユーザーでも有るのです。だから設計者の記述もれ・定義もれを見つけるのです。
自分の頭より頭が悪い製品をテストする事態って、エンジニアの方はどなたも経験、なさってるのでしょうか？
エンジニアは自分で区切りをつけて、プロジェクトを乗り換えないと、体を壊して家族に文句言われてしまっては、どうしようもないですよね・・・家の事をおろそかにしては、旦那子供にしかられます。
私は日当と法定内の残業代だけ出して頂ければ、ボーナスとか要らないし・・・あ～ん、これ以上、体壊したくないから、頼むから定時で帰られせてくれ～！！
バグがなきゃ、こんなに楽しい仕事ってないのですが。
この状況を大変だと気が付いてなかった、自分のIT素人さに愕然としました。回答頂きありがとうございました。
大変なのですが、大変だと上に伝えるスキルが、私には足りない様です。ホントの責任者って、一体誰なんでしょう？
仕様を知らない分、現状も分かってない人がリーダーをしてる限り、私は誰に、テストいつまで続けるんですか？と問えば良いのか分かりません・・・涙

回答No.2

precog

設計に問題があったのですから、黒で正解です。
白はありえないケースを走らせるのに使ったりします。

黒で設計に問題があることが判明したのであれば、設計の見直しです。

作る側の意識しだいですが、1件なら設計フェーズには戻さずデバッグで対処し、黒テストを続けます。

設計を見直した結果数件見つかるようなら、その設計者の作ったコードすべての設計を見直しです。それでまたバグが見つかったら人員交代ですな。問題はコードでも設計でもなく人にあったと、、、

ただ、あなたがテスター専業であれば、止めることに意味はないと判断すればテスト続行となるでしょう。

お礼

シンプルレス、ありがとうございます。永久保存版にさせて頂きます。

補足

テスト担当は過労で退職、又は欠勤多発の状態です。
私自身も体調が優れず、欠勤回数が増えてきました。
派遣先は休出を、テストリーダーの中には、懲りずに残業を打診してくる人がいる有様です。
業務日誌で、「テストを続ける意義はあるのですか？」と問うてみる事は、雇われてる立場として、生意気でしょうか？
テストって、仕様もれを見つける事が目的なんですか？仕様の校正をする事が目的なんですか？
そしてなんで、設計者のほうが、仕様に対するスキルが低いのでしょうか？設計者のほうが、テスト担当者よりスキルがあるもんじゃないのでしょうか？
定時で帰りたいです。帰っていいのかな？

回答No.1

umeume7777

その状況では、ブラックボックステストは全く意味をなしません。
リーダーがプログラミングを書けない人（コーディングできない人）でも問題はないですが、設計、仕様を理解している必要はあります。
設計書が完了した段階での内部のレビューは行わなかったのでしょうか？あきらかに設計漏れですね。仕様と見比べ再度、確認する必要があるように見受けられます。

ちなみにブラックボックスとは
http://e-words.jp/w/E38396E383A9E38383E382AFE3839CE38383E382AFE382B9E38386E382B9E38388.html
この辺でどうぞ

お礼

リーダーと呼ばれる人間は、テスト担当者のスケジュールしか管理しておらず、仕様は知らないのです。
期日内にテストを終わらせたい意思しかなく、休出依頼をなさるのみです。それに対して絶対応じないテスト担当者もおられます。
結局無意味だから、出ないのかな？
私はテスト経験が浅く、周りの状況が把握出来ず、倒れるまで残業してしまってました。一部のリーダーに怒られるのが恐くて、残業を断れませんでした。でも、そもそも派遣なので、断っても良いのですよね？
こんな感じで、成果物がゴタゴタしてる場合、無理に残業、しなくても良いのでしょうか？