プロジェクトマネージャーはコードをコミットするたびに100%の完全な信頼性を求めてくる

この場合、無能と思われないように、どのように彼の質問に答えればいいのでしょうか？正直なところ、私はサイト全体に100%の自信を持っているわけではありませんが、自分のテスト方法には自信を持っています。また、開発者として、これらのコアの変更から予期せぬバグが後から出てくることも珍しくないことを知っています。

このプロジェクトマネージャーはソフトウェアを十分に理解していませんし、テストを十分に理解していません。

もしあなたがプロのQA部門を持っていたら、QAマネージャーのサポートを得て、このプロジェク トマネージャーにソフトウェアの性質、バグの性質、テストの性質を説明するように言います。QAマネージャーには、なぜすべての条件をテストすることができないのか、また、リリース/リリースしないことがどのようにし てテストの結果に助けられたビジネス活動であるのか、完璧な情報に助けられたことはないのかを説明してもらいま す。第3章（"Why Not Just Just Test Everything?“）では、Weinbergは "There are an infinite number of possible tests. "と呼ばれるセクションを持っています

彼は非常に安全なプログラムに置かれたバックドアについて話しています。ソフトウェアを網羅的にテストするのに必要なテストの数は無限大であること、少なくとも「私が一生のうちに実行できる数よりも大きい数」であることを推測しなかったなら、この章のポイントを理解していなかったことになります。今は理解しています。”

あなたのプロジェクトマネージャに、毎日追加テストを行うことで、あなたのコードに対する信頼度は多少は向上するでしょうが、100%には決して到達できないことを説明してください。あなたの他の生産的な仕事を犠牲にしてでもテストを続けることに満足していることを彼に伝えてください。そして、テストにあと何日費やしてほしいか、他の仕事のうちどれを先延ばしにしてほしいかを彼に尋ねてみてください。彼が今から永遠に書くメールにタイプミスがないことに100％の自信があるかどうかを聞いてみてください。今も将来も間違いを犯さないという100％の自信があるかどうかを聞いてみましょう。

**この修正が既存の機能を破壊したり、ユーザーエクスペリエンスに悪影響を与えたりしないことを100%確信していますか？

私:いいえ。100%カバレッジのテストスイートを持っていないので、コード変更がアプリケーションの破壊や悪影響を回避できるかどうかを確認する方法はありません。しかし、私はそれが意図しない方法で実行される可能性が低いことを保証するために、次のアクションを実行しました。

• 私は、変更の範囲をそれが影響するモジュールだけに限定しました
• 私は、それに応じてドキュメントを読み、更新しました
• 私は、このモジュールと影響を受けるモジュールのためのユニットテストを実行しました
• 私は、追加された新しい機能をチェックするためのユニットテストを作成しました、そして、非推奨のテストは、もはや変更のために関連していません

私はあなたに正確に100％の保証を与えることはできませんが、私はこの機能の実装のために合理的であると信じている時間枠内で私ができる限りの保証を提供しました。実際には、私はすでに減少するリターンのポイントに達しています。0.1%の保証を提供するためにあと5時間を費やすこともできますが、そのような努力が正当化されない可能性はすでに低いのです。しかし、あなたはプロジェクトと時間枠を担当しているので、私はこの機能にあとどのくらいの時間を費やすべきかを教えてください。

今、ボールは彼のコートにあります。彼は本当に私が私の個人的な見積もりを移動したい場合は、数時間以上の仕事のために95％確実に95.1％確実に、と言う、から、ちょっと - 私はそれを行うことができます。

彼はそれについて不愉快であり続けている場合、私は彼とこの “100％テストされた "要件についてのプロジェクトの "所有者 "との電子メールの会話を持っているだろう、と私は信じているどのようなリソースは、それを満たすために必要とされています。

開発者として、あなたはコードの変更をUNITでテストしています。開発者としての）私の意見では、明らかなエラーがないか、すべてがコンパイルされているか、すべてのエラーがトラップされているかをチェックすることです。コードが本番になったら、どんなシナリオに遭遇するかを知る方法はありません (悪いデータ、予期せぬ入力、クライアントソフトウェアの変更、リストは無限にあります)

変更が何にも影響を与えないという100%の自信を持つためには、本番環境を完全にミラーリングしたテスト環境 (データ、ハードウェア、パーミッション、接続性) と、すべてのシナリオをカバーするテストスクリプトが必要になります。これはよく知られているように、様々な理由で作成することは事実上不可能な環境です

もし彼が100%の信頼を期待しているのであれば、彼は彼の期待をバックアップするための環境と人員を提供する必要があります

それは、プロジェクトマネージャーやクライアントが将来的に保証されたものを要求するときに少し似ています!

彼は悪い癖に陥っているようだな ある程度のレベルでは 愚かだとわかっていて質問している でも少し強迫観念的な要素があります 私の推測では、彼は根底にある不安に基づいて行動していて、理不尽な質問をすることで、彼はよりコントロールされていると感じるようになっています。このような状況では、私は通常、私が品質を確保するために取ったすべての措置を提示することによって、経営陣の恐怖を和らげることができます。彼は、結局のところ、顧客であり、彼はあなたの優先順位が彼と一致していることを知っている必要があります。このユニットテストを見てください。このモニタリングを見てください。変更をローカルでモジュール化するためにコードがどのように構成されているかを見てください。もしあなたが自信とコントロールの感覚を伝えれば、彼の不安を和らげることができるでしょうし、あなたはおそらくより合理的な会話をすることができるでしょう。ただ「うまくいくかどうか」ではなく、顧客がそれを良いと感じているかどうかです。

最終的には、しかし、それはビジネスの関係です。契約の取り決めが自分にとって快適で、利益が出るのであれば、このクセを我慢することに価値があります。それは彼がそれについてのすべての深刻なようには聞こえませんが、単にしつこいです。私が言うように、彼は厄介な習慣を開発しています。もし彼が敵対的な反応をし始めて口調が険しくなってきたら、ビジネスのバランスを考えれば、あなたにとって価値のないものになってしまうかもしれません。しかし、あなたの短い文章からすると、まだ効果的に関係を管理できそうですね。

多くの人がこれを教育の問題として説明していますが、私は彼らが間違っていると言っているわけではありません。この質問が実際に意味するのは、プロジェクトマネージャーはミスの責任を免除されたいと思っているということです。彼は、彼は彼が “合理的に "頼ることができると感じていることをあなたから宣誓文を取得しますので、何かがうまくいかない場合、彼は彼がそれを防ぐために、あなたが失敗した可能性がありますが、すべてを行っていると言います。もしこれが本当だとしたら、問題を解決するためにあなたがすべきことは、100%の自信は不可能だということをマネージャーに教育することだけではありません。また、バグは個人的にも会社にとっても災難ではないと彼を納得させる必要があります。それは彼自身の会社の文化を見ていることを意味するかもしれません、何かがうまくいかない場合は彼に不当な非難を置くために会社の誰かが準備しているかどうか。また、将来のバグに可能な限り迅速かつ安価に対処するための手順を導入することを意味するかもしれません。もし会社が本当にコードに100%の自信を持っていたとしたら、そのような手順は無意味なものになるでしょう。

究極の制裁として、もし彼(雇用主)があなた(請負業者)に、あなたの仕事についてあなたが保証できないという保証を売るように頼んでいて、この点で彼の気が変わらないとしたら、あなたにできることは、あなたがその保証を提供できないことを明確に伝えることと、彼ができる人がいると思うならば、他の人を雇うことを歓迎することです。もちろん、それは長い道のりですが、始める前に自分のBATNAを知っておいた方がいいかもしれません。

**厳密に言えば、コミットがプログラムを壊さないことを100%保証することはできません。これは、停止問題に起因しています。ウィキペディアからの関連する抜粋は以下の通りです。

計算可能性理論では、ハルティング問題は次のように述べることができます。"任意のコンピュータプログラムの記述が与えられたとき、そのプログラムが実行を終了するか、永遠に実行し続けるかを決定しなさい。これは、プログラムと入力が与えられて、その入力で実行されたときにプログラムが最終的に停止するか、永遠に実行されるかを決定する問題と同等です。

アラン・チューリングは1936年に、すべての可能なプログラムと入力のペアに対して停止問題を解く一般的なアルゴリズムが存在し得ないことを証明しました。この証明の鍵となる部分は、コンピュータとプログラムの数学的定義であり、チューリングマシンとして知られるようになりました。

もしあなたのPMが価値と安定した予測可能な納品を気にしているのであれば、おそらく彼にSCRUMフレームワークを見るように説得することができます。個人的に、私はあなたのプロセスを議論することができるあなたの PM およびチームとの会合をセットアップするように助言します。私は SCRUM を強く支持しています、従ってこれは SCRUM に主に関連しているでしょう。到達することはできません。絶対に。全宇宙では。歴史はそのような例をたくさん見てきました、例えば Windows 95のリリースのデモ 。昔の話？さて、オープンソースプロジェクトのための公開CIサーバでどれだけのレッドビルドが行われているかを見てみましょう。この結果、ソフトウェアは失敗します。

第二に、コミットの信頼性ではなく、valueを提供できるようなプラクティスを採用することをお勧めします。顧客が気にする何かを。反復的に、繰り返し、確実に。これで、PMの視点を100%の確信から、実際に重要なものへとシフトさせることができます。それは次のとおりです：ソフトウェアは使用中であり、あなたの製品は改善され、チームは顧客に価値を提供しています。何か、開発チームが思いつくこと。これには、ドキュメント、実装、テスト、品質ゲートなどが含まれる場合があります。これは非常に重要なことで、主観性（「100%確信しているか？しかし、それらのすべては、開発者がそのようなフラストレーションを緩和し、主観的な保証と比較して、客観的に定量化可能な結果を提供できるようにすることを可能にするだろう。

この種の目標に対する通常の答えは、ピアレビューとリグレッションテストです。

1) 本番のコードストリームに何かをコミットしないでください。

2) すべてのリグレッションテストが再実行され、テスト対象となる何かを壊さないことが証明されるまでは、本番のコードストリームに何かをコミットしないでください。そのテスト中に障害が発生した場合、問題の原因ではないことが明確に確立されるまで、変更はバックアップされなければなりません。

3) アルファテストとベータテストは、現実世界の顧客のシナリオで早く、頻繁に行います。顧客はあなたのコードを使って、あなたが予想していなかったようなことをするでしょう。しかし、これらはあなたをかなり近づけてくれます。これらは追加のリソースの投資を必要とします。これらは、"ただやればいい、壊れたら修正する “コーディングの練習に比べて、開発を遅くします。しかし、もしあなたが本当にバグのないコードを望んでいるのであれば、人間は落ちこぼれやすい存在であることを認識し、顧客に届く前に失敗をキャッチするための対策を講じることは、それらのコスト以上の価値があるかもしれません。

私は、IBMがNASAのために書いたコードにはバグが報告されなかったと聞いています。もしあなたが大企業のためのインフラを作っているのであれば、それは投資する価値があります。最初の一回目で彼らの尻を救うまではね。

貧弱なテストというのが現実です。QAチームに投資する気のない企業は、貧弱なテストをするというのが現実です。良いテストにはお金がかかり、時間もかかります。会社は時間とお金を承認しないことでリスクを受け入れているのです。

複雑なプログラムを通る可能性のあるパスは基本的に無限大なので、QAチームでもすべての可能性がテストされていることを保証することはできません。しかし、彼らはあなたを今よりもはるかに近づけてくれるでしょう。理由の一つは、開発者が自分のコードを適切にテストすることが不可能だからです。開発者はコードが何をするかを知っているので、コードが何をすると思っているかを中心にテストを設計する傾向があります。エッジケースを見逃したり、開発者が絶対にしないようなバカなことを見逃したり、要件を間違って解釈してしまうこともありますが、すべてのテストには元々の間違った解釈が反映されてしまいます。彼らはしばしば、要件の誤りを見逃してしまい、やるべきだったことではなく、やるように言われたことをやってしまうことがあります（これが、実際のユーザ（要件定義の際に相談されないことが多い）がソフトウェアを使ってみて初めて発見される膨大な数のバグの原因となっています）。特に専門家によって行われている部分(例えば、アプリケーションにとっては意味のある表の変更ですが、自動化されたイン ポートプロセスやレポートを壊してしまうようなものです。)

もし、より高い品質を望むのであれば、時間とお金の両方を払わなければならないでしょう。確かにNASAとその請負業者は近くに来ますが、完全なQAでも100％になることはできません。彼らはまた、あなたの会社が支出されているよりも偉大な取引より多くのお金を費やしています。

もし彼が望んでいるのは、問題があってもクライアントに危害が及ばないことを保証することであれば、テストのためのあなたのプロセスについて話してください（彼にあなたが実行したテストのリストを見せてください）、何が影響を受けると思うか、どのようにチェックしたか、悪いプッシュをどのようにして元に戻すかのあなたのプロセスと、ほとんどのクライアントが気づく前にそれらを見ることができるようにエラーを記録するためのあなたのプロセスについて。問題があったとしても、それは修正することができるという自信を彼に与えてください。コード（新機能や修正）を素早く出すことの価値について話してください。

また、あなたが変更を加えるたびに、システムの徹底的なリグレッションテストを提供するように彼に頼むこともできます。アプリケーションのすべてのページをテストしなければならないことを彼が知っているかどうか、そしてページ上で可能な限りの順序ですべてのことをテストしなければならないことを確認してください。そうそう、インポート/エクスポート、レポート、自動化されたジョブもテストしてください。そして、影響を受ける可能性のある関連アプリケーションもすべてテストしてください。彼が一度システムを徹底的に行使しようとしたら、彼はあなたがその保証をすることができない理由を理解するでしょう。

もう一つの試みは、あなたがその保証をすることはできませんが、もし彼がX時間のテストを許可するならば、あなたはその保証をすることに近づくことができることを彼に前もって伝えることです。彼に追加のテストの箇条書きにされたリストを与え、それが設計し、それぞれを実行するためにかかる時間。これらのテストをすべて実行した後に、あなたがどのくらいの割合の自信を持つことができるか、また、あなたが今持っている自信の割合はどのくらいかを彼に伝えてください。

それに関しては、この問題に関連しているかどうかに関わらず、あなたが持っている現在のユニットテストをすべて実行するだけでどのくらいの時間がかかるかを彼に伝えてください。もし、現在1000のユニットテストを持っていて、それぞれが5分で設定して実行して結果を評価するとしたら、83時間になります。その時間を費やして実行する許可を彼に求めてください。

もし彼が実際にあなたをマイクロマネジメントしていて、プロジェクトを構築する過程であなたの肩越しに見守っているのであれば、後で彼があなたにそれについてタカをくくることなく、あなたが100%の信頼を「保証」できることを確認する簡単な方法があります。

Get him to approve it himself

はっきり言って、あなたはこれを要求としてではなく、もし彼が本当に100%の完璧なコードを望んでいるのであれば、彼はあなたが何をしているかを自分で見て、あなたが途中で行っているすべての変更を承認すべきだという提案です。

もしあなたが自分のコードの唯一のテスターであるならば、これは不合理なことではありません。

もし何かの理由で、これがうまくいかないと思ったら（例えば、あなたが既に分かっていることをもっとやってくれと頼んだら最悪です）、あなたにできることは、できるだけ多くのハードエラーテストをして、正しく動くことが分かっていることをすべてレポートに書いて、「私のテストの範囲内で、この変更には100％の自信があります」と彼に100％の保証を与えることです。残念ながら、あなたの仕事に対する理解度が限られている「上司」の立場になるかもしれませんが、エラー修正がいかに100%の自信を持って維持することが不可能であるかを説明しようとするときには、いつも苦労します。つまり、できる限りのことをして、すべてを記録して、自分の限界の中でできることをしているということを理解してもらうことが最善の策かもしれません。

ここではいくつかの良い回答がありましたが、PMはソフトウェアを書くことが何を意味するのかを教育され、少し学ぶ必要があります。この方法はかなり危険であり、あなたの評判がどのくらい高いか、あなたのスキルがどのくらい良いか（あるいは、どのように認識されているか）、そしてあなたの性格とPMのそれの両方に非常に依存しています。私は、あなたが彼を誤解していないことを推定している、と彼は本当に100％を意味する（私はしばしば人々が100％と言っているが、実際には「あなたができる最善を尽くす」という意味を参照してください）＆002＆002それは一度私のために働いた、と私はここでそれを言及している唯一のreaonsです。あなたは警告されています。

時々、PM(または他のマネージャー)はただ聞くことを望んでいないので、どこかで彼(またはチーム)が一瞬停止して考えるために壁にぶつかるようにしなければなりません。このシナリオでは、それが意味します。あなたができる限り良い仕事をし、あなたができる限り良いようにテストしようとします。もしあなたが非常に運が良ければ、バグは発生せず、誰もが幸せになりますが、実際には何が起こるかというと、バグがあります。あなたはどうしますか？自分のミスを認める。バグと１００％確実であることの間違いを結びつけてください。人間は不完全であり、ソフトウェアにバグを作ることができる。人間は不完全であり、テストでバグを作ることができる。その結果、人間は不完全であり、バグがないことを100%確信しているという認識の中で「バグを作る」ことができるのです。

これをうまく提示して、100%水を差すようにしましょう(はははは、j/k、また100%ですね)。このすべての後に、オーバーしたメッセージが「私は私のテストで100％の自信を持つことができません」であることを確認してください。PMが「これはすべての開発者にとって同じ」という論理的なステップを踏むことができなければ、すべての希望は失われてしまうでしょう…

でも、まずは他のことを試してみてください!

重要な指標は、これが最近の変化であるということです。何か（または誰か）は、おそらくあなたのPMに悪い経験を与えている、と今、彼は何かが変更されるたびにエッジ上にある。

もしあなたが PM に彼の話をしてもらうことができれば(おそらく彼の選択した飲み物を飲みながら)、あなたは共感することができますし、彼は “イノベーション” a.k.a.の健全なソフトウェアエンジニアリングの実践を受け入れるようになるかもしれません。テスト、ピアコードレビュー、形式的な方法(構造による正しさ)への様々なアプローチから生じる信頼性、品質、リソース、スケジュールのトレードオフについて話してください。問題の大きさを説明するために比喩を使用してください。40,000行のコードですか？外国語で600ページの殺人ミステリーのようなものだと伝えてください。あなたが第12章の途中で何かを変更したい場合は、どのようにしてそれが物語の残りの部分との連続性の中断を引き起こさないことを確認しますか？

合理的な経済的境界内で許容可能な目標に向かって自信を高めるための方法についてのバイインを探してください。一晩でSEIの能力成熟度モデルレベル5を実装することはできません。しかし、現在の質問から “自動化された回帰テストスイートは合格するのか？"、"この新しい要求を回帰テストシステムでどのように表現するのか？"に行くことができるかもしれません。

私は、彼が100％の信頼度を持つ確率を求めていることを考慮して、最も数学的な方法でそれに答えると思います。90%で1週間、95%で2週間、100%で6ヶ月。最後の数字は誇張されたものですが、ポイントを掴んだと確信しています。

もっと読みたい方は、 ウィキペディアの信頼区間に関する記事 を参照してください。