私は、QA チームがプロジェクトの開始から保守まで、開発プロセスに積極的に関与している環境で働いてきました。QAチームはプロセスの早い段階でビジネスの見通しから何が起こっているのかを理解しているため、これは一般的に効果的であることがわかりました. 非常に早い段階でテスト スクリプトの作業を開始できます。
しかし、私は QA チームが開発チームから切り離された環境で働いたこともあります。彼らはプロセスに関心がなく、単に「開発」フェーズの終わりに向かって関与し、テストを思いつき、ビジネス要件に対する独自の理解に基づいて限られた一連のテストを実行します。
これについてどう思いますか？QA チームはプロセスにどの程度関与する必要があると思いますか? 「関与しない」ことに慣れているチームを、プロセスに積極的に参加するチームに移行するにはどうすればよいでしょうか?
QA/テストをプロセスに早期に関与させるというあなたの目標を称賛します。私は、強力なテスト チームがプロセスの最初から最後まで関与することを強く支持します。QA を含めようとする開発を見るのは素晴らしいことです。多くの場合、彼らはテストへの関与に抵抗します。
QA チームにもっと関与してもらいたい場合は、彼らに関与してもらいたいと思わせる必要があります。これはおそらく、彼らの経営陣がそれに価値を見出し、彼らが関与することに資金を提供することを確実にすることを意味します. 一部の QA チームは、仕事が多すぎて早期に関与できない (または関与していると感じている) 場合があります。これには、QA 管理が含まれます。彼らが賛同しなければ、あなたとの関わりに時間を費やしている人に報酬を与えることができなくなります。
プロセスの早い段階で貢献できること、そしてそうすることで利益が得られることを QA に示す必要があります。QAチームを見回してください。プログラミングの方法を知っているか、少なくともプログラミングの方法を知りたい人を見つけてください。彼を設計会議に招待します。彼に話すように勧めます。基本的に、会話に彼を含め始めます。彼が参加し始めない場合は、参加する人を見つけてください。テストは劣等コンプレックスを持っていて、聞かれなければ来ないこともあります。しかし、一度尋ねられれば、彼らはおそらくチャンスに飛びつくでしょう。
QA担当者が現れると、彼らは参加し始め、彼らのテストは利益を得るでしょう. 1 人がメリットを認識すれば、他の人も従うでしょう。
したがって、簡単な答えは、経営陣と話し合って賛同を得ることです。次に、チームに近づき、1 人の個人を招待して励ますことで関与させます。残りは従うべきです。
チームをゆっくりとプロセスに取り入れることの問題だと思います。私が現在働いている場所では、プロセスはあまりなく、QAは「テスター」と見なされていました。QAがDevと同等であった前の会社で働いていたので（給与面でも！）、これは受け入れられないことに気づきました。私は開発によって提供されたもの以外のテストを実行する傾向を開始し、この方法でより多くのバグを見つけました。
しかし、深く根付いた企業文化と戦う可能性があるため、注意する必要があります。変化を提唱することもできますが、最初は氷河をノミだけで角氷に変えたような気分になります。
4年後、私は現在QAチームリーダーであり、私たちのグループはすべての要件文書を承認する必要があります。私たちはできるだけ早く関与し、ほとんどのプログラマーとシステムアナリストは変更についてアドバイスを求めます。これは、私たちがビジネスのジェネラリストであり、変更が影響を与える可能性のある他のモジュールをプログラマーに伝えることができるためです。
このチームで私が持っていた利点の1つは、QAスティントの合間に別の会社でプログラミングの役職を務めたことであり、チームをBSしようとしたときにそのことを人々に思い出させました。しかし、それはすべて非常に外交的に行われています。
QA チームは開発とは別であるべきだと思いますが、開発と緊密に連携しています。
そうは言っても、プロセスの早い段階で彼らをより関与させる良い方法は、優れた仕様を書き、プロセスに含めることだと思います。製品の実装に取り組むとき、彼らはコア部分にテストを集中することができ (それらは仕様で定義されているため)、開発プロセスで協力することができます。
QA担当者として、私は明確な目標を持ち、理解できる製品をテストすることと、カバーする必要がある漠然としたフレームワークをテストすることの違いを直接経験しました.
両方でバグを見つけることは可能ですが、製品が何をすべきかを知っている環境で作業する方が楽しく、やりがいがあります。
QAチームがまったくいない環境で働いています。テスターでもある開発者だけがいます。仕様、製品コード、テストを作成し、探索的テストを行います。そして私は、開発とテストが不可分であると真に信じています。開発プロセスの最初から最後までアプリケーションをテストすると、優れた結果が得られます。しかし、私には専任の QA 担当者またはチーム (私のコーダーの考えとは異なる人) が本当に不足しています。彼らの役割は、かなり遠くにいる私たちのコミュニティを演じています。
私はこれについてかなり幅広い感情を持っています。QA チームは早い段階で関与する必要があると思います。そうすれば、要件を収集する段階で、コードを作成する前に、いくつかのテストのアイデアについて話し合い、ベースラインを形成することができます。これにより、QA は、まだ作業することが十分にある場合、またはさまざまなテストの構築に役立つ機能をさらに確認したい場合に対応することができます。
Dale Carnegie の著書「How to Win Friends and Influence People (友達を獲得し、人々に影響を与える方法)」からの移行を実行しようとする場合、いくつかの重要なポイントがあります。
自分の考え方を人々に理解してもらう 12 の方法
リーダーになる: 人を怒らせたり憤慨させたりせずに人を変える方法
これらの中には、他のものよりも適用しやすいものもありますが、なぜ早期に参加したいのか、それがどのように役立つのか、なぜより良いテストを実施したり、より良い製品や製品の開発を支援したりする必要があるのか を説明するために、何か言いたいことがあります。サービス？
当店では、QA マネージャーと開発マネージャーは同僚であり、尊敬と共通の目標に基づいて構築された関係です。
強力で経験豊富な QA エンジニアが必要です。つまり、すぐに学び、すぐに結果を得ることができる人材が必要です。または、QA チームを率いる強力なシニア メンバーが 1 人以上必要です。上級開発者の尊敬を集めることができる人物です。次に、チームを実際の問題に集中させ、リスクベースのアプローチを採用し、その価値を示します。製品がリリースされる前に実際の問題を発見し始めると、賢い開発者が決して見逃してはならない種類の問題が発生し、その後、ダイナミックな問題が発生します。変化し始めます。
QA チームと開発チームの両方をレトロスペクティブ / リリース レビューに参加させます。彼らが協力して、ソフトウェアのビルドとリリースの方法を改善する方法を考え出します。
ソフトウェア QAの役割。この役割は、要件が基本的な標準 (テンプレート) に準拠していること、および要件にあいまいさが存在しないことを検証します。完全性の観点から、ソフトウェア QA は非機能セクションを完了しない場合のリスクも確認します。ソフトウェア QA は、すべての要件が参照されていることを確認するために、トレーサビリティ マトリックスも確認します。
ソフトウェア QA は、欠陥の原因を分析し、SDLC を調べて、欠陥が導入された場所 (要件\設計またはコーディング) を特定し、プロセス所有者と一緒に改善の可能性を検討する必要があります。
QA は、既存のコード ベースに対してこれらのテストも実行する必要があります。これにより、テスト ハーネスが正しく機能していること、および新しいコードを必要とせずに新しいテストが誤ってパスしないことが検証されます。明らかに、新しいテストも予想される理由で失敗するはずです。これは、テスト自体を否定的にテストします。新しいテストが常にパスする可能性を排除し、したがって価値がありません。では、1日目と2日目です。
メソッドエンジニアリングについて聞いたことがありますか？このアプローチを使用すると、QA チームは、会社 (または開発チーム) が最終的に各プロジェクトで使用する特定の方法論 (または方法論) の設計に貢献できます。
それが機能する方法は、方法工学では、方法 (論理学) が既製のもの (RUP や XP など) ではなく、事前に定義された方法コンポーネントから構築されることです。QA 担当者が、うまくいく傾向にあるプラクティス、テクニック、および作業成果物を認識している場合、これらをメソッド コンポーネントとして提供し、方法論の仕様に参加することができます。