年功/賃金は、効果的なQAメンバーにとって重要な要素ですか？
私の会社のQAチームのメンバーとして、アジャイルなWebベースのサービスとしてのサービスショップでのテスト結果に対する開発者からの反応について、まったく熱狂的なフィードバックを頻繁に受け取ります。現在のところ、自動化されたテストは実際には意味をなさないため、ほとんどのテストは手動で行われ、開発者は通常、javascript/500エラーを防止する変更以外の変更提案に耳を傾けることに抵抗があります。修正/変更には作業が必要であることを理解しています。開発者が行う作業が不足していることはめったにありませんが、開発者がQA入力を尊重するとは思いません。
残念ながら、私たちの製品所有者は空席です。受け入れテストは存在せず、ユーザーストーリーは通常1文のみであり、開発者に何をすべきかを提供しません。もちろん、開発者には開発者ではなく、提案が全面的に行われているx週間後の顧客以外には、開発に対するフィードバックメカニズムはありません。
私は技術的には有能ですが、悪いことに、LAMPスタックでの簡単な開発が可能であり、開発者が私の知識を尊重していると確信しています。ただし、重要なエラー（データの整合性または最終的な機能に影響を与えるエラー）を防止するフィードバックを超えて、ほとんどの部分をあきらめています。
これは、開発者がQA入力をどれだけ真剣に評価するかにおいて、年功か賃金かが重要な要素であるかどうかという問題を提起しています。私たちの場合、自動テストを行わず、QAメンバーがそれほど技術的な専門知識を持っていない可能性が高いため、開発者よりも（60〜70％程度、学年によって異なります）理解するのは理にかなっています。給与が最も多いチームメンバーの意見が最も重要であるとは信じていませんが、1年か2年経験の少ないチームメンバーからフィードバックを得るのが難しいのは想像できません。技術的な知識があり、著しく少なくなります。結局、最高のアイデアが勝つはずですが、残念ながら、機能強化が数か月にわたって製品化されてから、ユーザーがそれを気に入ったり嫌ったりした後に決定される可能性があります。
カウボーイカルチャーの機能不全のチームがあり、根本的な原因が何かを理解しようとしているように思えます。何らかの暗黙的な階層やサービスの長さなどの要因により、開発者がテストを尊重しない可能性があるという仮説を提案していますが、必ずしもケースの証拠を提示しているわけではありません。どうしましたか？"
実際、組織には多くの問題があるように思われ、ステータスや権力の認識によって引き起こされる問題は、リーダーシップが不十分であることの兆候にすぎません。アジャイル開発を可能にするメカニズムを実践していない場合、あなたはアジャイルショップではありません。 1つのラインストーリーは俊敏ではありません。これらはウィッシュリストの単なる箇条書きです。ストーリーには、ビジネスの動機、顧客と製品との相互作用の説明、ストーリーがいつ完了するかの定義が含まれます。これら3つを用意していない場合、何をすべきかを判断するための十分な情報がないか、またはそれを正しく実行したかどうかを確認できないため、ストーリーが「完了する」ことはありません。それは進歩を遂げるものではなく、水を踏むことです。開発者は、自分たちの尿の小さなバケツだけで助けられて常に消防活動をしているので、そのような組織でやるべき仕事が不足することは決してありません。
「完了の定義」の一部は、一般的なチーム合意の一部になる可能性がありますが、簡潔な場合でも、ストーリーの具体的な受け入れ基準は不可欠です。
「現在、自動テストが実際に私たちにとって意味をなさない」ケースはほとんどありません。 test teamは、特に初期の段階で自動テストを実施するのに適した組織ではないかもしれませんが、自動テストを行うことは常に理にかなっています。私の本では、開発者が正式な自動テストなしで少し探索的なコーディングを行うことは問題ありませんが（私はTDDでもBDDの純粋主義者でもありません）、開発者としてコードをリリースすることを検討するのは恐ろしいようです。開発者が作成した自動テストのないテスト組織。開発者が作成した単体テストとBDDテスト、およびできれば製品所有者が作成したシナリオは、アジャイル配信の重要な部分です。
アジャイルチームでテスト組織の最適な使用法を理解することは、成功のための単一の公式がない、難しい問題です。完了の定義がない組織では、テストチームが「完了」に貢献したかどうかを知る方法がないため、価値を実証することは非常に困難です。私は、1）明確なテスト組織がないか、2）適度に統合されたテストチーム、3）個別のストーリーと作業成果物を備えた部分的に統合されたテストチーム、および4）ゲート付きリリースモデルを使用して、古い学校のウォーターフォールチームとアジャイルチームで働いています。通常の開発と並行して一部のQAが発生しましたが、レガシーまたは規制上の理由により、明確な「テストパス」がありました。
テストチームの「適切な」モデルは、実際には、テストチームメンバーの技術的な高度さのレベルに依存します。自動化のケースを提案するために、コードの記述中に、開発者と中程度またはそれ以上の技術的洗練度を備えたテストチームメンバーがいるのは素晴らしいモデルになると思います。しかし、テストチームは、ストーリーが測定可能な受け入れ基準を持っていることを検証し、開発者がコードをチェックインするときにいくつかの探索的テストを行い、統合シナリオで開発者のユニットテストを強化し、特別なケースを具体化するのにかなり効果的です。ストーリーをテストケースに変換する方法があり、製品の所有者と開発者との何らかのフィードバックループがある限り、状況によっては壁に投げるアプローチを採用することもできます。
しかし、組織の優先事項とは何か、テストの役割はどうあるべきかについて、経営者や製品所有者から積極的に購入することなくして、実際にそこに到達することはできません。 「ああ、私は他のソフトウェアプロジェクトに取り組んできたので、何らかのテストを行う必要があることはわかっています。テストチームを雇いましょう。」以外の真剣な会話はなかったと思います。ほとんどの平均的な開発者と平均を超える開発者は、テストチームに関与することを要求しない組織の慣性に寛容です。実際の進歩を遂げるためには、「より良い」開発慣行を推進するための管理またはコンセンサス主導のイニシアチブが発生する必要があります。
開発者として、かつてのSTE、STEリード、SDETとして、私はテストチームメンバーがどれほど年長であるか、または彼らに支払われる金額にほとんど興味がありません。私が気にしているのは、それらがどのようにしてより良いソフトウェアを出荷するのに役立つかです。私は個人的には、チームの望ましい組織の速度を考えると、意味のある調査ができない大量のシナリオに取り組むことができる人々のスキルを活用することが好きです。既存の単体テストまたはシナリオから開始してより適切なカバレッジを構築する方法、またはテスト計画を読んでフィードバックを提供する方法について、テストチームのメンバーに説明させていただきます。しかし、私は「十分に良い」カバレッジに焦点を当てることに落ち着いて、製品の所有者に任せて、おそらく組織が価値があると思われる場合は、テスターが私が逃したものをキャッチすることを望みます。
どういうわけか、あなたはあなたがあなたの経営陣またはあなたの最も同情的な開発者にもっと取ることで販売を始める必要があるだろう、私はそれを言うならあえて、開発と品質へのアジャイルアプローチ。変化に抵抗する組織でそのようなことを推進するのはそれほど得意ではないので、これについての式をお伝えすることはできませんが、期待できる最善の方法は、ビジネス価値主導のケース（ビジネス側に話しかける）またはおそらく技術的な側面での職人技/継続的な改善のケースです。
私の会社のQAチームのメンバーとして、アジャイルなWebベースのサービスとしてのサービスショップでのテスト結果に対する開発者からの反応について、まったく熱狂的なフィードバックを頻繁に受け取ります。
その理由は：
私たちの製品の所有者は空です：受け入れテストは存在せず、ユーザーストーリーは通常1文のみであり、開発者に何をすべきかを提供しません。もちろん、開発者には開発者ではなく、提案が全面的に行われているx週間後の顧客以外には、開発に対するフィードバックメカニズムはありません。
QAフィードバックは、開発とテストの両方の取り組みを推進する明確で測定可能で実用的な要件と、それらの要件を満たす高品質な製品の作成に関心がある開発者がいる場合にのみ有効です。 成功を宣言できる要件が必要です。目標の投稿を常に移動して、開発者がタッチダウンのスコアリングに熱心であると期待することはできません。
関連項目
適切な要件の特性
私の本能は、ここでの問題は、実際には期待とチーム管理者から示された尊敬の組み合わせであるということです。
QAの主な目標はドキュメント製品の仕様からの逸脱、使いやすさの問題、パフォーマンスの問題の組み合わせです。キーワードはdocumentです。
プロダクトマネージャーの役割は、開発者がどこに努力を費やすかに関する優先順位を決定する責任があります。つまり、現時点では、優先順位は機能の実装であり、後で不具合に対処することであると判断したことを意味します（無限バグ戦略）。これは長期的な戦略としては不十分であることが知られていますが、短期的には政治的に正しいことである場合がよくあります。 （たとえば、来週の会議で顧客に進捗状況を示す）。
欠陥を文書化している限り、あなたはあなたの仕事をしており、製品マネージャーは既知の欠陥で出荷する決定をすることを正当化しなければなりません。
とはいえ、2番目の問題は、チームマネージャーがあなたに示した尊敬についてです。あなたがバグを見つけ続けているために彼らがあなたを問題として見ている場合、彼らがやりたいのは製品を売り出してお金を稼ぐことだけであり、解決策は同じです。バグを特定し続けますが、選択（および非難）は、開発リソースを出荷または適用する決定における管理者の責任であり、あなたの役割は、決定を行うための正確かつタイムリーな情報を提供することです。
私の本能が正しければ、このプロジェクトはひどく終了する可能性が高いので、私は働くためのより成功した組織を探し始めます。
年功/賃金は、効果的なQAメンバーにとって重要な要素ですか？
要するに：いいえ、そうではありません。効果的なQAメンバーは、要件に照らして検証することにより、成果物（例：モジュール機能）の品質保証を提供するメンバーです。これらは、要件のギャップ、アプリケーションおよびデータベースシステムでのビジネスルールの誤った実装を発見する貴重なチームメンバーです。
開発者として、私たちはソフトウェア開発プロセスをよく理解し、新しいことを理解/理解する能力があり、優れたユーモアと態度でデータベース内のデータエントリの正確性をチェックするスクリプトスキルを持つ、精通したQAを尊重し、高く評価しますチームメンバー。