これは私が非常に多くの企業で出くわした質問です.QAチームは開発組織に報告するべきですか、それとも会社の階層における開発と同等であるべきですか?
13943 次
15 に答える
17
まったく逆です。開発はQA に報告する必要があります。
QA 部門が顧客 (注: テストではなく QA) であると想像すると、非常にうまくいくでしょう。バグは修正され、製品は適切な標準に合わせて開発され、開発は、ビジネスに役立つためにそこにあることに気づき、それに応じて製品をコーディングします。
ただし、会社の政治は他の方法で年功序列を与えるため、QA 部門がある場合、一般的に、開発は小規模な QA 部門の上位になります。
編集：自分自身を説明するためのちょっとした補遺：私が働いていたある会社では、顧客サイトとして設定された「モデルオフィス」がありました. インストーラー CD を作成して QA チームに渡し、QA チームはそれをクリーンに復元された一連のマシンにインストールします。なんらかの問題があった場合は、報告が返され、別の CD を作成してプロセスを繰り返す前に (明らかに、バグの重大度に応じて) 修正する必要があります。最初は「これは地獄だ」と思っていましたが、それは..しかし、ほんの数回の繰り返しで、開発者はメッセージを受け取り、それらの CD が機能し、インストールされたソフトウェアが機能することを確認しました。
私の現在の会社は、サイトからのフィードバックがメーリングリストを介して行われ、インストーラーが完全に機能しないことが多く、依存関係が欠落している場合があり、同じインストールの問題が何度も発生するなど、そのようなものが必要です。ここでの品質は、以前はうまく機能していることを確認した QA 部門と比較して劣っています。ここには開発主導のグループがあり、常に次のリリース、新機能に焦点を当てています。QA は常に現在のリリース、つまり既存の製品に関心を持っています。エンドユーザーが得るものに大きな違いをもたらします。
したがって、品質が許容範囲内であることを確認するために QA 部門が存在する場合でも、開発が「報告」するのは顧客であるかのように扱われるべきだと思います。
于 2009-04-22T21:47:02.837 に答える
13
同等。目標は同じであるべきです - 高品質のソフトウェアのリリース。対等な人々の間で開かれた議論がなければ、これは起こり得ません。
于 2009-04-22T21:51:40.670 に答える
6
誰が適切な品質のソフトウェアを提供する責任があるかによると思います。それが開発グループである場合、QA はその一部である必要があります。そこでは、開発が QA に必要なリソースと開発に必要なリソースを決定します。
一方、一般的に技術部門である場合、両者は対等であり、どちらもディレクターまたは CIO または CTO に報告し、リソース割り当ての決定は、両方のグループのニーズのバランスをとることによって行われます。より大きな目標。
QA 部門が開発目標を推進する場合、開発部門が QA に報告することは理にかなっているかもしれませんが、それは確かに珍しいことです。
QA が開発プロセスの一部ではなく、組織内の特定の慣行である場合は、おそらく開発グループに報告するべきではありませんが、多くの場合、内部アプリ開発に関しては、QA は重要性を与えられていません。
于 2009-04-22T22:16:52.157 に答える
5
私が約 1 年前に働いていた会社で、私が今まで見た中で最高の開発プラクティスを持っていた会社では、QA と開発が並行して機能していました。どちらも同じように機能しましたが、QA はリリースされたコードをリリースしてサポートする責任がありました。修正し、その後でのみ開発に行きます
于 2009-04-22T22:30:17.677 に答える
3
QAが実際に何をするかに少し依存すると思います。QA の使命がエラーの欠如を提供することである (そして間接的に (できれば) 品質を向上させるだけである) 非常に典型的なシナリオでは、それらを等しくすることが最良の選択肢であると思います。一方、QA の主要な使命が本当に品質の向上である場合、開発は QA に報告されるべきであるというgbjbaanbに同意すると思います。
于 2009-04-22T22:05:31.200 に答える
2
真剣に、この質問は永遠に出回っています。少なくともQAと開発者がいる限り。
個人的には、組織ではないと思います。優れた、倫理的で正直なマネージャーがいる限り、チャートは重要です。
「R&Dマネージャー」がQA担当者に特定のことを実行/報告するよう圧力をかける可能性があるという議論は真実です. また、筋肉を動かし、要点を証明するのが好きな QA マネージャーを配置することもできます。また、2 つの別々の部門を持つこともできます。マネージャーが貧弱な場合でも、問題が発生したり、人々が物事を「微調整」するよう圧力をかけられたりする可能性があります。どのように切り取っても、内紛や政治的BSにつながる可能性があり、リリースが不十分になる可能性があります.
ただし、プロセスの両方の部分を理解して評価し、可能な限り最高のリリースに真に焦点を当てているマネージャーがいる場合、組織が何であるかは問題ではありません. チャートは次のようになります。QA はフロント デスクまたは管理スタッフに報告することができ、彼らが結果を正直に報告でき、情報に適切な重みと考慮が与えられれば、すべて問題ありません。
于 2009-06-02T19:20:07.917 に答える
2
開発チームの一部として統合します。
開発者に、自分が取り組んでいるすべての自動スモーク テストを作成してもらい、それらを強化/協力してもらいます。qa が開発部に直属しているわけではありませんが、qa の役割を果たしている従業員は、開発を行っている従業員と同じ船に乗っています。
テストの自動化には開発者のスキルが必要であり、通常の開発/品質への取り組みの配布は間違っていることに注意してください。
個別の階層を使用する場合でも、緊密に連携する必要があります。各役割は、独自の観点からプロジェクトの成功に貢献します。チーム間で階層を追加すると、どちらかが優先され、プロジェクトの成功への貢献に影響します。
于 2009-04-23T18:05:28.527 に答える
2
私は、最終製品の品質が重要な小さなショップの出身です。私はまた、支配的な人格 (つまりデマゴーグ) が、顧客が (恥ずかしいことに) 真の現実を視野に入れるまで、製品の真の現実を人々に無視させた店を扱ってきました。
最終製品のゲートキーパーとして、QA 部門は自律性と権限の両方を必要とし、何かが不完全または受け入れられないことを宣言します。QA は「物事を現実に保つ」必要があります。
製品品質に関するドメインに加えて、QA 部門は、品質に影響を与える開発プロセスを変更/進化させる権限も所有 (および使用) する必要があります。（つまり、将来の問題を防ぐ、物事を改善する）
距離と視点は、QA が適切に実行するために必要なものです。QA 部門は、テスト対象のコードを実際に開発するという実際のコード作成作業に関与するべきではありません。おそらくテストの自動化ですが、テストされる実際のコードではありません。また、QA が開発の日常業務に関与するべきではありません。
于 2009-07-15T16:00:26.103 に答える
2
あなたの質問はあいまいなようです。残りの回答が対処していない意味に返信します。テストを行っている個人は、非 QA マネージャーに報告する必要がありますか? それには答えがあります。その答えは次のとおりです。召集せよ」Joel Spolsky による「テスターがいない (間違った) 理由トップ 5」 ( http://www.joelonsoftware.com/articles/fog0000000067.html )
テスターが QA 責任者ではなくエンジニアリング部門に報告することは、企業があらゆる再編成を試みたいと考えているようです。これは通常、上層部が、サポートすると思われる基準を満たした時点ではなく、予定どおりに出荷したいと考えていることを示しています。たとえそれが想定された意図ではなかったとしても、品質問題に対する説明責任を回避するための良い方法です。
聞いたことのないバグであっても、強力で説明責任のある QA の責任者は非常に重要です。私が重要だと考えるバグを報告するか、異議を唱えるかを決定する場合、QA の責任者は、それは本当に重要です。エンジニアリングが問題を修正したくない場合でも、私はおそらく正しいことをします. 最終的な決定は、スケジュールを守ることでボーナスが決定され、品質に影響されないエンジニアリング マネージャーによって下されることを知っている場合、無意味な戦いをかわしたくなるでしょう。
于 2009-06-16T20:47:08.613 に答える
2
あなたの質問の焦点は少し混ざっています。それは会社の構造についてですか、それとも部門の組織についてですか? それともプロジェクトの組織についてですか？
問題、バグレポート、プロジェクト組織について質問するつもりなら、qa は、特定のプロジェクトの問題に対して何をすべきかを決定する責任を負う役割に報告します。開発者、アナリスト、事業主、クライアントの代表者などです。与えられた問題をどうするかを決定し、他の人を従わせることができる人。
休暇、残業、会社の組織について尋ねるつもりなら、qa はライン マネージャーに報告します。組織の規模に応じて、QA と開発者の 1 人のマネージャー、または組織内の非常に多くのテスターと開発者が別々の部門を持っているため、独自のマネージャーになる場合があります。
どちらの場合も、会社の階層における開発者とテスターの位置は関係ありません (同等であると私は信じています)。
于 2009-11-03T21:34:17.707 に答える
1
QA は開発部門の不可欠な部分であると考えていますが、グループとしての QA は、力という点でははしごの半歩上にあるべきです。QA 部門が機能するコードをパスまたは認証する必要がある場合、彼らは開発に戻ってやり直すように指示できるため、本質的に上位にあります。
開発者の時間とリリース日の間に競合が発生します。不完全なコードをリリースしなければならない場合や、開発者がバグを今すぐ修正する必要があると感じていない場合があります。理想的には、QA リードとリード開発者の両方が同じ人に報告し、これら 2 人が対等であると見なされるのが理想的です。
于 2009-06-02T19:05:09.290 に答える
0
QA should report to DEV is wrong and not accepted in any case. Dev can never be held responsible in case of failure at Production Environment. Why would they report to QA, why not the other way around? After all, they hold responsibility of releasing a functional requirement as per the client's requirements. Seeing products through client's perspective is the main job of QA. In case if anything crashed/failed in sanity, they'd be responsible of shipping the incomplete/immature product. Still this is a traditional approach.
After the advent of Agile Methodologies, QA and Dev should work side by side under product development manager or QA and Dev can have separate heads but working for the same agenda which is Delivering a full-fledged product in accordance with client's requirements.
于 2016-11-20T18:59:11.380 に答える
0
問題を認めたくない開発マネージャーによって政治的に黙られることがないように、彼らは対等に働くべきです。Qa は、効果があるかどうかを開発者に報告することはできません。
于 2009-04-22T22:34:55.623 に答える
0
QA と開発は密接に連携する必要があると思います。組織が提供できる製品の最高品質に責任を持つのは、QA と開発者です。QA と開発者の関係を妨げるものはすべて、製品開発を妨げる可能性があります。
于 2016-10-13T07:44:42.957 に答える
-1
QAとして、直面した問題を報告することをお勧めします。開発者が発生してはならない何かを見逃している可能性があります。
于 2016-05-10T05:25:20.420 に答える