プログラマーは自給自足することになっていますか？

私の現在の職場では、テスターはいません。その理由は、経営陣からの根拠です：「テスターがいれば、あなたはあなた自身のコードをまったくテストしないでしょう」。この種の考え方は、製品の品質に悪影響を与えるようです。自分のコードをテストしている間は、システムを裏返しに知っていて使用方法がわからないという事実だけでなく、見落としがちなことがたくさんあります。それは「間違っています」。専用のテスターが陥る落とし穴を無意識に回避するため、ブラックボックステストは実際には機能しません。私の多くの時間は、実動コードに滑り込み、エンドユーザーによって発見されたバグの修正に費やされます。

問題のシステムは大規模ですが、私だけが開発しています。また、これにより、スケジュールの定義や仕様の作成など、管理業務の一部が私の膝の上に置かれました。

この種のタスクは私の責任ですか？自分は厳密にプログラマーであり、他の何者でもない。そして、これらが私の責任であれば、どの程度ですか？プロジェクトがテスターを必要とするほど大きいのはいつですか？プログラマーは仕様を改良し、プロジェクトの管理について心配する必要がありますか、それともカスタマーサポートを提供する必要がありますか？

注意

私は自分の責任を広げることに反対しているという印象を持っている人もいるかもしれません。そうではありません。より多くの管理職を含む役割を手に入れたいと思っていますが、現在は職務内容にありません。私がそのように正式に雇用されるまで、または追加の職務が私の給与に現れ始めるまで、私は自分を「単なる」プログラマーだと考えます。残念ながら、ジュニア開発者として、管理職への移行はすぐには起こりません。

これまでの優れた答えは、何か追加したいことや共有したい個人的な経験がある場合は、それらを続けてください！

あなたはやるテスターを持っています。ただ、それらを「エンドユーザー」と呼びます。これは、あなたが説明するすべての理由で有害です。どんなに良心的なコーダーであっても、コードがどのように「台無し」になってしまう可能性があるかについての自分の先入観を克服するのに十分な仕事をすることは決してできません。 。

管理者がこの問題を再度開く必要があります。この時点で、ケースを裏付けるいくつかのハードデータがあるように思えます。現在の品質保証へのハンドオフアプローチは、時間の無駄とユーザーエクスペリエンスの低下の両方をもたらします。これは構造的な問題であり、「テストだけではダメだ」というケースではないことを明確にするために、これをどのように提示するかに注意する必要がありますが、発生する必要がある議論のように聞こえます。

この雇用主との岐路に立っているようです。あなたがプログラマーであり、他に何も残さないことに意欲があるなら、誰かを連れて来るか、または既存の同僚の責任を拡大する。（「これはあなたが私を雇ったものではなく、これらのタスクはなくなりません。私がこのようなことをひどく費やす時間は、私が得意なことに費やしていない時間です。）現実的ではありません。あなたが仕事を正しく行うために必要なリソースと権限を与えてくれたなら、あなたはより管理的な役割に移行することができると思いますか？

テスターが必要になる前にプロジェクトがどれだけ大きくする必要があるかについては、その行を正確に定義する方法がわかりませんが、間違いなくあなたはそれを超えたと思います。実際のユーザーからのバグレポートを修正するよりも多くの時間を費やしています。私にとって、そもそもバグがユーザーに届かないようにするためにもっと努力する時間です。

はい。必要な場合は、コードをテストできるはずです。（私はユニットテストではなく、受け入れテストなどを話します。）

いいえ。テスターはあなたよりもテストが上手です。そして、あなたが指摘しているように、校正のように、あなた自身の間違いを見つけるのは非常に難しいです。余分な眼球があると、プログラムの品質に大きな（良い）影響があります。

他にもたくさん質問があります。私は1つだけ答えます：

プログラマーは仕様を改良する必要がありますか？

はい！仕様を実装する必要があるため、仕様が実際に実装可能であることを確認する必要があります。また、明確な思考や精度などの訓練を受けたプログラマーとして、人々は実際に何をする必要があるかを発見し、曖昧な、または論理的に欠陥のある要件を取り除くことができます。

彼らが言っていることと現実はおそらく2つの異なるものです。最も可能性が高いのは、
「プログラマに二重の義務を負わせることができるのに、なぜテスターの給料を支払わなければならないのか」ということです。

もちろん、彼らはそれを言うつもりはなく、彼らが合理的であると考えるあらゆる種類の言い訳を補うでしょう。私は彼らの要点に対するいくつかの反論を考えることができますが、正直なところ彼らは助けにはなりません。私はこの戦いを何度も見てきましたが、彼らが現在の推論を覆すたびに彼らはアプローチを変えるでしょう。最終的に彼らはあきらめて、とにかくそれをするようにあなたに指示し、あなたは不平を言うでしょう。

私が考えることができる最良のアプローチは、問題があるまで経営陣が決して価値がないと思われる品質の観点からではなく、コストの観点から取り組むことです。テスターは、プログラマーよりも安価であるか、少なくとも認識されています。二重の義務を負わせることにより、より安価なリソース（テスター）で達成できる作業を行うために、より高い有料のリソース（プログラマー）を支払うことになります。したがって、彼らはあなたのプログラミングスキルから抽出している価値を最大化していない。

このアプローチには、給料をもらっている場合、バラバラになるというマイナス面があり、無給の残業時間を増やすことについて何の責任もありませんが、一見の価値があります。

問題のシステムは大規模ですが、私だけが開発しています。これにより、スケジュールの定義や仕様の作成など、管理業務の一部が私の膝の上に落ちてしまいました。

けっこうだ。

この種のタスクは私の責任ですか？

最終的に決定するのは管理者次第です。

自分は厳密にプログラマーであり、他の何者でもない。

おそらくあなたは間違った仕事に就いているでしょう。多くの人々は、追加の責任を与えられることを好みます。

そして、これらが私の責任であれば、どの程度ですか？

経営者がそう言うなら、はい。

プロジェクトがテスターを必要とするほど大きいのはいつですか？

開発者がしなければならない他の作業が多すぎる場合。その時点で、管理者は専用のテスターを採用するか、テストをスキップするリスクを負うかを決定する必要があります。（最終的に、開発者は多くのことしかできません。）

専用のテスターを持つことには明確な利点がありますが、欠点もあります...余分なスタッフを雇うコストに加えて。

プログラマーが仕様を改良する必要がある場合、

必要に応じて、はい。実際、仕様の改良が必要で、他に作業している人がいない場合、これを行わないとプロジェクトが失敗する可能性があります。

プロジェクトの管理について心配する

必要に応じて、はい。

または顧客サポートを提供しますか？

必要に応じて、はい。

あなたは働きすぎで、プレッシャーに反応しているように聞こえます。これは問題です。しかし、「X、Y、Zを行うのはあなたの仕事ではない」という立場を取ることは助けにはなりません。より良い計画は、できることはそれだけであることを明確にし、これが期限を逃し、品質が低下し、顧客サポートが不十分になるなどの原因になる可能性があることを指摘することです。とにかく、あなたの健康、人間関係などを損なうことなく、最善を尽くしてください。

テスターがいます。彼らなしでは働きたくありません。ユニットテスト（TDDを使用）、およびすべてのコードの自動化された統合テストを作成しますが、テスターに​​は非常に貴重な機能があります。

1. 彼らは非常に熟練しており、プログラマーとは異なるスキルを持っています。
   1. 彼らは、QAテストの実行方法、および生成されたコードがユーザーの期待とユーザーの実際の動作の両方に実際に一致することを確認する方法について多くの経験と知識を持っています。
   2. 彼らは多くのバグを経験しており、ソフトウェアを破壊する可能性のある状況を考えるのが得意です。
   3. 彼らはシニカルで体系的である傾向があります。私は、プログラマーがしばしばより楽観的であることを観察しました。
2. ユーザビリティに関する貴重な初期フィードバックを提供します。たとえば、最近REST APIを作成するとき、QAテスターが簡単に理解できない領域は、ユーザーも満足していない領域の良い兆候でした。
3. 実際の環境、実際には実際のハードウェア、OSなどの多くの構成でテストします。
4. 彼らは、大規模で現実的なテストベッドを構築し、パフォーマンス、負荷、ストレステストを行う方法を知っています。
5. 彼らは、悪いリリースが外に出ないようにすることに焦点を合わせています。プログラマーは、コードのリリースに集中する傾向があります。そのように、プログラマーはデフォルトでコードをリリースしますが、QAテスターはリリースする理由が必要になります（動作することが示されています！）

「テスターがいれば、独自のコードをまったくテストしません」

「もしあなたの車にシートベルトがあれば、いつもクラッシュするでしょう！」

この種のタスクは私の責任ですか？[...]そして、これらが私の責任であれば、どの程度ですか？

それに対する答えは「依存する」です。私の理解では、あなたの雇用主はあなたを「一人のIT部門」とみなしています。そうだとすれば、はい、彼らはあなたの責任です。絶対に嫌いで避けたい責任がある場合は、大規模なIT部門を持つ企業内の職を探してください。

プロジェクトがテスターを必要とするほど大きいのはいつですか？

それは（まったく）尋ねるべき正しい質問ではありません。「テスターを必要とするほど、会社の製品/画像の品質が重要になるのはいつか」と尋ねる方が良いでしょう。

プログラマーが仕様を改良する必要がある場合、[...]

はい、間違いなく。ほとんどの場合、開発者/実装者が必要とするものと、クライアントが[仕様として]提供するものとの間に大きな矛盾があります。

多くの場合、灰色/不特定の領域を見つけて適切な質問をするか、技術的に不可能または矛盾する要件などに気づき、指摘するかどうかはあなた次第です（特にあなたが唯一の開発者である場合）。

[...]プロジェクトの管理について心配したり、カスタマーサポートを提供したりしますか？

それはあなたがその地位に就いたときに受け入れた責任に依存します。たとえば、一部の職種では、顧客に直接連絡する必要があります。他のすべての条件が同じであれば、私はそのような立場を避けようとします（しかし、それはあなた次第であり、多くの仕事の選択肢がないかもしれません）。

まず、テスト、または品質保証は、アプリケーションをクリックして機能をテストすることだけではありません。品質保証はプロセスに関するものです。エラーを見つけるためにアプリケーションをテストするだけでなく、開発者によるエラーの防止も必要です。

1. 製品仕様+ユースケース
   誰もが製品の機能が何であるかを知っている（またはそうしていると考えている）場合でも、それを書き留める必要があります。明確な仕様なしにアプリケーションをテストすることはできません。仕様では、正しい動作とバグを定義しています。
2. 単体テスト、統合テスト
   UIを介したテストが困難な内部のテスト、例外的なアプリケーションの状態。これはすべての大規模システムにとって必須です。両方のタイプのテストには、別の興味深い特性もあります。これらは、コードのすべての部分をもう一度調べることを強制し、これまでに見たことのないバグ/アーキテクチャの問題を認識します。
3. コード品質とコーディング標準
   QAが行うべきタスクの1つは、コードの複雑さを測定することです。複雑性の低いコードは、エラーの可能性を減らします（バグを防ぎます）。
4. コードレビュー
   プロジェクトが所定のサイズに達するか、多くのユーザーが使用する場合、コードレビューは必須です。別のプログラマーは、見落としていたコードの問題/バグを常に見つけます。プログラマーは、自分のコードの明らかなバグを時々盲目にしています。
5. ドキュメント
   コードとそのアーキテクチャをドキュメント化すると、潜在的な欠陥（私自身の経験）の実現に役立ちます。
6. テスター
   テスターは、UIをクリックするだけの猿ではありません。テスターは仕様とユースケースを受け取り、テストケースを作成します。それから彼/彼女はそれらを一つずつテストする。エンドユーザーからバグが報告された場合、そのためのテストケースを追加する必要があります。

プログラマーが仕様を作成してはいけません（1）。あなたは機能性を決定するためにそこにいません。通常、エンドユーザーと話したり、グラフィックデザインを作成したりする必要があります。これには時間がかかります。プログラマーが機能を決定した場合、通常は「大丈夫ですが、明日までにこのウィンドウのすべてを変更できますか？」「これは私が望んでいたものではない」「機能するが使いにくい」「本当に必要な機能だけが欠けている」。

プログラマーが達成できるのは、2、3、および5です。

4には別のプログラマが必要です。大規模なITプロジェクトを持ち、システムを知っている開発者が1人しかいない会社は、非常に危険な状況に陥ります。

十分な時間がない場合は、テストケースを作成する必要はありません（5）。多くの時間を要するため、通常は献身的な人が必要です。テストケースがなければ、テストは冗談です。